Going Non-Native

Supporting your application on multiple operating systems requires some tough decisions.  Do you develop natively for each OS and maintain multiple code bases?  Do you use a cross platform development framework?  Or do you do something else?

This is the fourth of several articles about my  journey developing an application for NASA’s Fermi Gamma-ray Space Telescope mission.  Earlier articles can be found here:

I knew from the start that in the end the application needed to run on both Android and iOS devices as both are widely used in the scientific community the app targeted.  I chose Android for the prototype simply for practical reasons:  I owned an Android phone and tablet but the only Apple devices in my house were my old MacBook from work and my daughter’s 4th gen iPod Nano, neither of which ran iOS.  I didn’t have a device to test an iOS prototype on.

I originally toyed with the idea of just doing two different apps, one in Java and the other in Objective C to target the two platforms.  Of course that would require learning Objective C as I had (and still have) zero experience with that language.  More appealing would be to find some cross platform development framework that would allow me to target both platforms simultaneously.  And so I started looking around.

I new the app was going to be fairly basic, it would make plots, have some lists and buttons and serve up webpages and data tables.  So the cross platform environment didn’t need to be that spectacular.  I looked at several.  Many of the cross platform systems seemed to be focused on game development (or at least their sales pitches on their websites were).  Others were a little too pricey.

In the end, I settled on Titanium Studio from Appcelerator.  It allowed development for Android and iOS, code was written in JavaScript (which I had some familiarity with), and it was free.  Using this tool, I would be able to write a single program that would compile down to native code on both platforms, and it would look and behave similarly on both.

Switching Development Environments

Up to this point all my work had been done in my primary work environment, namely Linux and the Eclipse IDE.  Titanium uses a customized version of Eclipse for their IDE so that wasn’t an issue, but in order to develop for iOS you have to build and compile on a Mac.  If there is one thing I don’t like about writing iOS apps, it’s that you have to do it on the Mac.  I understand why, but it is still frustrating.

Unfortunately for me, my MacBook is pretty old.  And I definitely felt it.  The iOS simulator was snappy enough but the Android Emulator was painfully slow.  In fact, in the end, it was faster (by nearly an order of magnitude) to deploy test versions to my phone (A Motorola Droid X) and test there instead of trying to use the emulator.  There were times I could definitely relate to this XKCD comic.

There were other issues with working on the Mac, but I’ll save those for another post.  Beyond the slow computer and minor interface dissimilarities, the switch was relatively painless and worked just fine.

One Code Base?

One of the draws of working in Titanium Studio was the promise of being able to develop in a single code base for both mobile OSes.  I knew that there would have to be some OS specific coding in the app to deal with different features (i.e. no hardware back or menu buttons in iOS) but at least it would all be in the same language.

This aspect of the development turned out pretty much as advertised.  I have a single set of classes/files that work just fine on both iOS and Android.  I don’t have to worry about implementing a feature for one OS and then going and reimplementing it for the other.  I just have to do it once and it is there for both.  I believe that this definitely cut down on the total development time it would have taken to build it as two separate apps.

Page 1 of 2 | Next page