What is a “Native” App?

Posted on by
2

I was recently asked my opinion on what makes a “native” app, and this was my response:

It depends on how you split that hair.

I think it depends on what platform level (hardware, OS, etc.) the particular user of the word native thinks that word applies to. It seems many use the word to refer to the actual bytecode and whether it matches the hardware (the CPU) – but in those cases I often see the term native used with the CPU architecture in the description – such as native ARM, or not native x86. iOS apps compiled with AIR 2.6 I’d say are compiled to native ARM bytecode.

There are other ways to parse it though – for example, it was pointed out to me that AIR for iOS apps are compiled from ABC bytecode into ARM bytecode to avoid the JIT (and Apple’s restrictions on the use of JIT), but that code still uses the virtual machine – the garbage collector, sandbox and whatnot. This gets right up to the edge of my understanding of virtual machines. But, if the use of a VM precludes an app from being called native then could .NET be native on Windows, or Dalvik apps on Android? In the case of .NET, there is even a JIT (pretty sure on that one, but not entirely so).

Then there’s the issue of targeted API (and ABI) – if an app is compiled to run on Windows, but is running in a VM on Linux, it’s probably not native (even though it’s CPU architecture probably matches), but if it runs in WINE on Linux, is that native?

Speaking of the Linux crowd – they parse their platforms even more granularity – Gnome apps, running on KDE are not native to some people, simply because they use a different GUI toolkit, though something running in an interpreted language like Python are native if they use the “native” GUI toolkit. Games are not subject to this line of reasoning – if it runs on Linux in OpenGL (without WINE) then it’s native.

I even remember reading some opinions in various places that programs not written in C are not native to Linux, and programs not written in C++ are not native to Windows – despite those programs using all the same APIs, ABIs, and not running a in VM.

So what is my opinion? As it relates to my current favorite target platform, I wouldn’t call an AIR app native – especially since it requires a 3rd party runtime to be installed separately (like on Android or desktops), and doesn’t have access to the native GUI toolkits and widgets and other OS APIs. That’s not a hard and fast opinion though, my definition of native is pretty malleable, and likely to change over time (or over the course of writing this response). I think I’d have a hard time selling the idea that a Java or AIR app is native to a client – on Android mostly because of the separate runtime requirement – and on all platforms, because of the lack of access to OS level APIs. It would feel disingenuous to call an AIR app a native app.

AIR for iOS comes closest to being reasonably called a native app – it is compiled as a complete standalone package, and runs pretty close to the metal (being compiled to ARM code) – and most importantly doesn’t require a third party runtime to be installed separately. If AIR for iOS apps had access to the native (underlying OS platform) GUI toolkit and other APIs, I would be more comfortable calling it native, though probably still wouldn’t.

Probably the best definition of “native” I could come up (which you still won’t get anywhere close to universal agreement on) is an app that comes out of using the platform maker’s tools to develop apps for the platform – XCode + Objective-C (and other supported languages) for OSX and iOS, Visual Studio for Windows and Windows Phone, Android SDK for Android – even using Adobe’s tools to make an AIR app makes it a “native” AIR app – where using HaXe may not count as native.

Generally though, as much as I could, I would try not to discuss whether or not an app development tool like AIR is native at all – especially since that term is so subjective. A project needs a particular problem solved, and if I can do that with AIR (on iOS that means it doesn’t require iOS GUI elements and conventions, or other features of iOS), then that’s what I’d recommend.

Update: AIR 3.0 closes this gap, and makes the “Native App” comparison easier because of two features; 1. Captive runtime – no more separate runtime requirement means it’s a standalone app. 2. Native Extensions – now an app has access to all the native functionality of the underlying platform. I’m comfortable calling an AIR app a Native App with AIR 3.0.

Fork me on GitHub

WordPress Admin Bar Theme Support

Posted on by
Reply

Here’s a quickie for WordPress Theme designers:

If your theme is getting unwanted scroll-bars because of the new Admin Bar is WordPress 3.1, the core team included a way to handle it. Add Theme Support for it!

With a full height layout, you’ll want to avoid adding a margin or padding to a height that is already at 100% because you’ll get useless scrollbars, and no one wants that. Instead, find the first non-full height element (usually #header or some-such), and apply the margin there (either the 28px for the height of the admin bar, or add 28 to the existing margin if the element already has one). In the code snippet below I assumed you’d create an element or assign the class ‘admin-bar-fix’ to an existing element.

In your theme’s function file, add the following and modify as you see fit: (best to leave out the closing php tag though)

<?php
add_action( 'after_setup_theme', 'custom_theme_setup' );
function custom_theme_setup() {
add_theme_support( 'admin-bar', array( 'callback' => 'admin_bar_bump_callback') );
}
function admin_bar_bump_callback() { ?>
<style>.admin-bar-fix { margin-top: 48px; }</style>
<?php } ?>

This snippet is derived from the TwentyTen Theme’s function file. The callback’s original code can be found in the source. Original snippet also found commented in the source (props ocean90).

Basically, by declaring support for the new (as of 3.1) “Admin Bar,” you declare that you can handle how your theme’s content gets “bumped” (by default, it gets pushed down by 28px via a margin on the html.) Most of the time the default behavior is fine… but it’s not fine on theme’s that have a height declaration of 100% (even min-height) or that have external scripts that declare 100% height on the html/body (like Google Translate does).

WordPress’s admin needed a similar treatment but that got patched. The 28px margin is just a default to handle most normal cases. Your theme is your responsibility :-)

Cheers! Hope this saves some time for someone!

Update: Admin Bar Shim!

If you don’t have a 100% height type of layout but are annoyed by improperly scrolling anchored links try the following.

If you add a >div id=”admin-bar-shim”> (for lack of a better name) in your theme surrounding everything inside the body except the wp_footer call (where the admin-bar gets echoed), you can add

.admin-bar #admin-bar-shim {
    position: fixed;
    bottom: 0pt;
    left: 0pt;
    right: 0pt;
    overflow: auto;
    top: 28px;
}

to your style sheet, or use the method above adding the callback. This new method allows anchor links to scroll properly.

unBrix Alpha in Android Marketplace!!

Posted on by
Reply

My first Android app is in the market place! Built with Adobe AIR, unBrix Alpha is a quick take on the classic breakout style game. This is more of a “lite” game at this point (hence the “Alpha” suffix), but it is already more complete than many of the other Arkanoid clones in iOS App Store. There also seems to be some last minute performance problems on the Android version. :-/ I guess that’s what I get for only testing on an iPhone for most of the development. I’ll have fixes to that soon. I’m pretty sure it’s related to the scaleMode I set in Flash – the problem is if I set that the faster mode – NO_SCALE – it’s way too small on most Android devices. I’ll probably need to add some manual sizing based on measurement. Of course non of this was needed on the iPhone version.

Download unBrix Alpha and let me know what you think! I’d provide a link, but I don’t know how.

Update: I Nerfed the framerate a bit to get it to run a little smoother. I think the problem will be solved better by setting NO_SCALE, but I’ll have to do that another time (probably when I get to iPad port!). I also fixed the red line, and the icon too (I don’t know that didn’t show up last time). There is a report of the paddle jumping to one side when some users remove their finger from the screen. I haven’t been able to reproduce, but please let me know if this happens to you! Here is a link to unBrix Alpha on appbrain (it isn’t showing the update yet).

Update 2: I switched to CPU rendering, because it seems as though GPU rendering is just slower on Android devices than CPU rendering – at least in this kind of game. Anyway, this solved a lot of problems, including missing text and missing affects. I also had to set a fullScreenRect to match the original intended size of the game (iPhone 3Gs size). Doing these two things cleaned up most of the performance issues and graphics glitches. I’ll work on getting the remainder of the basics in place, like proper shutdowns – so this doesn’t run in the background like it does now (didn’t have to worry about that for iOS!).

Flash iPhone Game at Silky 60FPS on 3GS

Posted on by
Reply

Well, it’s only a tech demo at the moment. I’ve been playing with this Breakout like game for a while, trying to learn the ins and outs of Flash mobile development – particularly as it relates to performance. I now have the unBrix demo running at close to 60FPS (59.1) – smooth as silk.

This won’t run at 60FPS on Android Flash Player plugin in the browser (or Firefox on Mac!) – this post is about the iPhone build – but here’s the web version to look at anyway.

Here is a blurry video of the thing running as a native iPhone app on a 3GS (I smoothed out the choppy splash transition in a later build by setting the BG element with cacheAsBitmapMatrix):

The most important thing was to make sure GPU acceleration was working, and to learn what things will impact performance in that area.

It turns out, there are some important differences with how GPU accelerated Flash woks compared with the traditional software renderer. In the software Flash renderer keeping your display list shallow, and sparse (using addChild/removeChild a lot) or avoiding the display list completely (by writing to BitmapData – as the Flixel game engine does) is a key optimization for performance. This is how the exploding bunny video demo is done, and why it’s so fast.

My current theory is that on GPU accelerated content (even on desktop) the reverse is true. You want to avoid CPU/system RAM to GPU/video RAM updates as much as possible – which means avoiding BitmapData updates which cause the player to upload a new texture to the GPU VRAM with every update. Because I don’t have access to the internals of the Flash Player architecture, I can’t be sure, but I think the bottle neck comes from clogging up the lanes between the CPU and GPU, and all stressing all three areas of the rendering pipeline (CPU, GPU and the bus) as they juggle around objects in memory. The key observation this conclusion is based on is the large performance impact addChild and removeChild has on the framerate. So I relentlessly avoid that in my iPhone Flash development – I precache everything, and don’t mess with the display list. This is also one reason why filters (which operate on a BitmapData representation of the DisplayObject you apply them to) are not recommended on mobile content.

Anyway, hopefully I can turn this into a full app for iPhone in a reasonable timeframe. :-)

Scripts n Styles

Posted on by
Reply

Introducing a new plugin for WordPress from unFocus Projects!

Ever need to add a CSS style or some code snippet to just one page or post in WordPress? We release an admin tool to do just that.

On the post edit screen of the admin, Scripts n Styles adds a meta box where you can add JavaScript, CSS or even add class names to the body tag or the post content wrapper (as long as the theme supports wp_head, wp_footer, body_class, and post_class functions and almost all do).

The plugin is available on WordPress.org Extend (and therefor your plugin admin screen :-) ). You can also fork it on Github. It’s licensed GPLv2. (current version 1.0.2)

Enjoy!