Channels ▼
RSS

Web Development

A Whole New Ball Game: Aspects of Mobile Application Development


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.

Instead of writing a native application for each platform to support, you can consider writing a Web application optimized for some mobile devices. But from what I can see, this is a remedy that may quickly become worse than the disease. You will likely end up with HTML and JavaScript that distinguish between different mobile browsers. You can't extensively leverage caching on the client side. And you have just the window object of the browser as the interface to the outside world — the device.

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.

Another alternative to writing truly native applications is using cross-platform frameworks such as Appcelerator's Titanium. You're not going through a browser here, but you're still writing your code in JavaScript. With Titanium, however, you use a set of specific extensions to handle gestures, file system, networking, UI, maps, geolocation, media, and more. You are also allowed to bring in distinct modules of native code for each platform you intend to support. Titanium currently supports iOS, Android, and BlackBerry. A desktop tool lets you package the JavaScript code as a resource into a native application for the target platform. At run time, however, the JavaScript code is interpreted in the host environment.

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.

Voices from the Trench

Generally, one of the arguments for native applications across mobile sites or cross-platform solutions is the need to control hardware and leverage some platform-specific facilities. This is definitely true, but there's more to it. Another point that is often mentioned in the debate is performance. However, I don't honestly think that you are going to lose valuable bits of performance by choosing a product like Appcelerator's Titanium. It is a different story if we move to consider Web sites and Web-based solutions like PhoneGap's. In such cases, you have an extra layer of abstraction, an extra application in the middle (the browser), and more than ever, the need to download much more information than with a native application.

Over the past 18 months, I had the opportunity to follow the development of a multi-platform mobile application. The application acts as the client of a sort of NoSQL repository hosted and configured on some Web sites. As you can guess, it is not a hardware-intensive type of application and it is ultimately limited to fetching and organizing data. However, the need for getting the most (and even more) out of caching and offering non-intrusive synchronization capabilities drove the team towards writing multiple native applications. Managing aspects like privacy of data, client-side storage, and background tasks inevitably leads to padding the code with native modules and branches that grow with the application, making the entire codebase hard to manage and evolve.

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.

[Click image to view at full size]
Table 1. Aspects to consider in a generic mobile application.

In the rest of this article, we'll drill down into each aspect.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 
Dr. Dobb's TV