Going Non-Native
By Tom. Filed in Mobile |
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.
In addition, it saved having to deal with context switches. I was working in JavaScript with the Titanium APIs. While developing I didn’t have to switch out of that mode. Had I tried to do native Java and Objective C applications, I would have been constantly switching between the Java/Android APIs and the Objective C/iOS APIs. That’s a lot more you have to keep straight in you head and many more chances for errors. I think of all the benefits, being able to work in a single context and not having to continually switch is probably one of the best benefits of the cross platform framework.
Does that outweigh the issues encountered? That remains to be seen. From the point of view of the programmer, I think so. From the point of view of the functionality provided and the user experience, I haven’t decided yet. There were several gotchas that I had to deal with where something would work on one OS and not the other that I had to work around but for the most part these were minor. And there was one major issue that I encountered that I had to work around. But those issues will be the topic of a future post.
Conclusions
Looking back, maybe Titanium wasn’t necessarily the best choice of a cross-development framework. It’s been a rocky road that I’ll detail in a future post and give my reasons for that assessment.
However, the decision to use a cross platform development framework was, I believe, a good one. It kept all the code in a single place. I didn’t have to worry about implementing a feature in Java and then making sure I remembered to go and reimplement it in Objective C or vice versa, I could implement it once and it would be there. I think it definitely cut down on the development time, if not the testing time.
So, if you want to target both iOS and Android and possibly others, I think it is definitely worth the effort to look at the existing cross platform development frameworks. Look closely at the features that you need and what they provide. And pick a framework that provides what you need/want. It could save you a lot of work.