In mobile development, make sure you use the right tool for the right task.
A few weeks ago, I had the opportunity of being interviewed by Bil Kridel for a post on Intelligence on Software, which deals with OS updates and applications stability:
It’s one of the biggest headaches in mobile app development: The operating system (OS) vendor issues an update that immediately renders some apps partly or completely inoperable, sending developers scrambling to issue their own updates to fix the problem. For instance, remember when Android 2.3.3 broke Netflix’s app in June, as iOS 5 did to The Economist’s in October? These examples show how breakage can potentially affect revenue — especially when it involves an app that’s connected to a fee-based service. In the case of enterprise apps, breakage can also have a bottom-line impact by reducing productivity and inundating the helpdesk.
You can read the actual interview on the link above. While there are a few minor inaccuracies there – mainly due to the fact that all this was done by a remove video conferencing call with some technobabble being discussed, I think the subject deserves some more thought – especially if you are planning on writing a mobile application.
Mobile Application Architecture
To write mobile applications properly, you first need to understand how the whole mobile device is “stitched” together.
There are several powers that be that make up the handset:
- The chipset vendor, who take care of most of the important piece of- hardware in the system – the application chip. Today, these will mostly be Qualcomm, NVIDIA, TI and Samsung; although there are others such as Marvel, Broadcom and Intel to name a few.
- The operating system vendor, who is the one providing the software platform that gets used. Usually these will be Apple with their iOS, Google (or Amazon) with Android or a few others: Microsoft and RIM comes to mind here.
- Third parties, who either provide drivers to their own hardware or those that provide SDKs that offer additional functionality or just ease the use of the platform.
While most of the time the development is done in front of the operating system itself, at times there is a need to interact with the chipset directly – mainly for the use of hardware accelerators such as media processing – especially when these are not supported official or in a standard fashion by the operating system itself. You won’t find it on iOS – there is would be restricted from us, but in the wild west that is Android it can be quite common.
Ecosystem Vendors
Third parties may allow you to make a few shortcuts along the way. Two good examples of it are Appcelerator and Urban Airship:
- Appcelerator provides an application framework that can be used to develop applications once and run them on multiple devices (Android and iOS). There are a lot others as well.
- Urban Airship provides a simplification of a service. It gives easy access (and better) push notification and in-app purchasing support for multiple operating systems. Instead of writing push notifications in front of different servers of different OS vendors – you can just use Urban Airship’s service. Again – there are other services and features you can tap into using such third parties if you see the need.
My Tip
The amount of players, variance of devices and the speed of innovation in this space make it hard to keep pace. The best thing you can do is prepare yourself. You can do that by making sure you write the different modules of your application using the highest possible abstraction APIs. This will mean the following:
- Use HTML and CSS to write the user interface itself and then use an application framework such as Appcelerator to use it across platforms. If you don’t fancy HTML or it doesn’t fit your needs then find an application framework that does.
- The code that can’t go in such a high level of abstraction write in native code. For iOS this will be in Objective-C while in Android this will be Java.
- At times, on Android, Java just won’t do – especially for media processing. It will mean for you going and using the Android NDK and writing in C or C++. Once you are in this territory, make sure only code that must be written in that way is written in that way and the rest goes to the SDK which is Java.
- And then only if you must, use proprietary APIs and drivers that can be found on the specific device or OS version.
In a sentence – use the right tool for the right task and vary between them in your application. It won’t save you from handling the occasional OS breakup due to an upgrade or a new device, but it will make it happen less and make your update work easier as well.