Many companies today recognize the need to provide their applications on mobile devices. The recently concluded Mobile Expo — the premier event in mobile technology — revealed that devices this year will include multicore processors running at over 1GHz, making them the processing equivalents of PCs less than five years old. Unfortunately, for many companies without experience in mobile development, they're likely to attack new application development with the traditional mindset, even though the user experience is wholly different. Herein are some development differences that are necessary — indeed crucial — to bear in mind when entering into the mobile development realm.
A mobile device is often used like a laptop in the sense that you install applications on it, run multiple applications at the same time, store data, use social networks, consume remote data, and interact with the native hardware. A mobile device, however, is fairly different from a laptop — memory, processing power, battery, screen real-estate, local storage capabilities, input devices, sensors. All these differences necessarily make writing a mobile application a different type of challenge and require a different set of design patterns.
The multi-touch capability of the screen makes it natural to use fingers to select items and command actions. While soft, and sometimes hard, keyboards are supported, the reduced size of the device makes using fingers much easier. Mobile applications, therefore, are UI-focused and should always be super-optimized for the task they intend to carry out; and mobile applications are not usually designed to carry out many tasks. It turns out that behavior-driven design is a very valuable approach for mobile applications and so is the KISS (Keep It Super Simple) principle. A very small number of use-cases, and a UI-focused design, are the pillars of any mobile application.
When it comes to mobile development, the first step is having a well-defined mobile strategy. Defining a strategy is a management's task, but in the implementation of such a strategy, as a software professional, you may be facing the challenge of creating the "same" mobile application for multiple platforms. How would you take the challenge?
Native Applications vs. Web Applications
There are three main platforms in the mobile arena for which a company might want to write applications: iPhone/iPad, Android, and Windows Phone 7. Frankly, it is quite unlikely that these three majors will reduce to one or two. So companies have the problem of investing three times to build three distinct but similar-looking applications.
An alternative is using a framework like PhoneGap, which offers a more powerful and specific interface to the device. Your application will still run within the browser, but it can be given access to an external framework acting as a facade for the device's specific capabilities. Performance, bandwidth, and control are a few aspects that you might want to consider carefully before making this choice. Having said that, for straightforward applications, frameworks like PhoneGap offer real benefits.
As years of real-world experience prove (this is not certainly the first attempt to write cross-platform code), the risk for developers is that the final application effectively has a common body for a subset of features and still requires different branches for the rest. This generally doesn't result from limitations of the product, but from deep and scattered architectural differences that can't just be unified in a single and equally powerful view. Whether the aforementioned subset is large enough to serve the needs of your application ... well, that's just your call. Anyway, a lot of progress has been made in this area and not just from Titanium. Several other frameworks exist that are trying to make writing a multi-platform application simpler and cost-effective. It's an interesting field to explore for changes in the near future.
Planning a Native Application for Multiple Platforms
Whatever way you look at it, planning a native application for a variety of platforms is no more or less the classic pain in the proverbial neck. No single, clearly ideal solution exists, and none will likely exist in the future. Here's the summary of one approach that worked and that I feel confident enough to share. Rest assured that this matter is highly dynamic and a better approach can emerge from the community at any time.
A generic mobile application results from a combination of any number of the aspects listed in Table 1. Each aspect requires a native implementation, but having a clear idea of common practices for each aspect and determining beforehand how your application should deal with each aspect is a fundamental step in the direction of seamless development.
In the rest of this article, we'll drill down into each aspect.