Category Archives: AIR

Work in Progress: Choices for Mobile Development

Posted on by

Example “every day” app request:

Build me a “recipes” app that lets me browse resipes and take a photo of a dish and upload to Facebook App, Flickr account, Twitter feed, or Generic Server so it can later be displayed in a web view or another in-app view that gets refreshed after you get a “success” message back from the server that you uploaded to.

Right this second, I’d personally code it in Objective-C/Xcode first, then do a Java version for Android.

QUESTION: Given a bit more time and a chance to step back for a minute, which language, IDE, SDK should it be written in?

Near Term Technology Choices

  • Corona SDK
  • Objective-C in Xcode for iOS / Java in Eclipse for Android
  • AIR 3.1 for mobile, CameraUI
  • PhoneGap
  • Titanium

Corona SDK, media.Camera

Cons

  • As of 02.20.2012, lack of support for Web Services (REST, SOAP, etc) processing. So far just HTTP POST & GET and sockets.
  • 2.5D is not easy in Corona SDK. Trying to “fake 3D” or do 2.5D by scaling a physics body while animating it’s position doesn’t work out of the box, for example. Various hacks are required to fake it. While you’re resizing the visual graphic for every frame, collision detection is likely to get screwed up because the physics body’s collision bounding box doesn’t resize “on enter frame” after it’s been set once. This is a Box2D limitation, from what I’ve heard. In general, Corona is best for 2D content only, at least for the moment.

Pros

  • Holy shit! It’s so easy! If you have Actionscript experience (or Javascript application dev experience), Corona is a piece of cake. Feels easier than web Javascript (no DOM differences or old browsers to worry about). Here’s a Flash to Corona porting guide, their pitch to Flash Devs.
  • Has support for device hardware access to Camera (native Camera app can be call up) via media.show().
  • Has access to SQLlite.
  • No iAds support but has custom Ads framework with support for two ad networks.
  • Has built in Physics, Animation, Facebook, Analytics, JSON, In-App Purchases libraries.
  • Looks super approachable for the average AS3 developer. A bit more to learn for Front End devs who’ve never worked with sprite sheets, movieclips, easing equations, etc. Faster for Front End and Flash Developers to learn than learning about reference counting in Objective-C.

Objective-C / Java native, UIImagePickerController or AV Foundation framework / android.hardware.Camera

Cons

  • Building for iOS first (most likely). Will need to write separate Java version for Android. Two code bases to maintain.
  • Possible code base fragmentation between iPhone, iPad 2 and iPad 3, depending on how the app file size download limits issue plays out and whether. People are expecting x4 the pixels for iPad 3 high res display.
  • More dev time required

Pros

  • Closer to the metal, more hands on control of everything in the iOS / Android SDK. Fewer problems, re: lack of full native support in 3rd party mobile tools? (a.k.a. no need to find or write “native extensions”).
  • Cleaner code – just try opening up a published Titanium project in Xcode and take a look at the crap load of native code that converts JS to Obj-C included that would not be there if you built your app using native code in the first place.
  • A lot of clients, for the moment, seem very into iPads and iOS, more so than into Android (not a long term bet, considering Android’s market share, even with the hardware fragmentation).

AIR 3.1 for mobile, CameraUI and CameraRoll

Cons

  • Adobe’s sloppy management of the Flash platform was a highly frustrating and uninspiring series of events. Between the buggy releases of Flash IDE, Flash Builder and the Flash browser plugin, especially on Mac OS X, and Adobe’s bumbling PR fiasco re:HTML5, it’s belated focus on the Gaming market and it’s late introduction of Stage3D for mobile devices Adobe is not a company that inspires me with confidence when it comes to IDE’s and SDK’s for any kind of code.
  • Lack of full native support in 3rd party mobile tools? (need to find or write “native extensions”).
  • Need to super optimize AS3.0 code. Possibly at the expense of code clarity.
  • To get access to the Gyroscope and Notifications, you need to use a Native Extensions
  • Potentially unable to use some commonly used libraries, for example, if they’re not compatible with Starling framework (Stage 3D) etc. or if they’re likely to affect performance on slower mobile processors

Pros

  • There’s a legion of Devs with years of AS3.0 experience out there.
  • Tons of free resources all over the web.
  • I’m getting up to speed w/ Objective-C, have Java experience, how complex will it really be to write my own native extensions?
  • Possibility of a Single Code base for iOS and Android…

PhoneGap

Cons

  • Adobe…
  • Lack of full native support in 3rd party mobile tools? (need to find or write “native extensions” ?).
  • Will still require lots of conditional code / State design pattern to account for platform specific features as well as iPad v. iPhone, standard display v. high retina display, etc.

Pros

  • PhoneGap has some elementary access to the iOS camera (at least).
  • More developers know Javascript, HTML, CSS or at least, those are easier to pick up than manual “reference counting” in Objective-C
  • Support for Web Services via Javascript, examples in their wiki.
  • Possibility of a Single Code base for iOS and Android…

Titanium

Cons

  • Lack of on device debugging in the FREE version of Titanium IDE itself. Looks like there’s a 3rd party tool that might work.
  • Incomplete documentation in Titanium’s API docs. For example, as of 03.19.2012, the Filesystem API doesn’t document methods like mimeType(), which is nontheless included in the Kitchen Sink’s filesystem.js example.
  • Lack of full native API support. Need to find or write modules for certain native features.
  • Will take months for Titanium to be updated for features in every new native OS release (like it did with the iOS 5 release).
  • Will sometimes still require lots of conditional code to account for platform specific features as well as iPad v. iPhone, standard display v. high retina display, iOS v. Android, etc. Perhaps, this is not a surprise, since for Universal apps in Xcode one sometimes has to create separate Views or .xib files for Universal apps, one for iPhone, one for iPad.
  • Titanium IDE was super buggy on my OS X 10.6.8 machines at work and home. SDK 1.8.2 seems to have fixed these issues.

Pros

  • A reasonable level of Memory Profiling is possible for Titanium apps using Xcode’s Instruments.
  • Titanium offers you access to your device’s built-in basic camera app (UIImagePickerController on iOS), but it looks like a lot of the Titanium.Media camera related methods are iOS-only.
  • Enterprise-level support available, which Tech / IT Directors in charge of larger projects will find appealing.
  • Titanium allows developers to write their own modules, if Titanium itself is missing native features. There’s an iOS Module Developers Guide. For example, Titanium doesn’t support the iOS AV Foundation framework, the one that allows you to write your own custom Camera or Video application (as opposed to using UIImagePickerController, etc). Here’s a Titanium AV Foundation module written by a dev on GitHub (free, open source, under Apache License 2.0).
  • Has a Web Services (SOAP) example in it’s demo Kitchen Sink app. More developers already know Javascript.
  • Has iAds support. Possible to use other networks, like AdMob, through plugins/extensions (write yourself or get from their Open Mobile Marketplace)
  • Possibility of a Single Code base for iOS and Android…