Mobile Application Development : Design and Tools

In late 1990s and early 2000s, developers as well as users  were confused about the choice of the platform  for their applications. They had to decide a solution from two choices – (1) An installable PC based software or (2) a Web application. Web applications was the unpopular choice for a few reasons – among them, Bandwidth limitations and a general insecurity about how safe using a software on internet would be.

But as the years passed by, the requirements too changed. When people started working collaboratively, (which was made much easier with the internet and with bandwidth growth) people slowly started moving into web based applications. Web based Emails are possibly the first web applications used widely. Software companies started developing cross-browser compatible web applications. Now Web 2.0 has changed the perspective of ’software’ totally. And Hybrid applications became possible with APIs etc.

Likewise, in Mobile development, there are three ways to create  applications. (1)Installable (or Native) Mobile applications. (2)Mobile browser based applications – which are websites optimized for Mobile browsers and (3) Hybrid mobile applications.

Three Design Approaches – Native, Web or Hybrid(blended)

Native – Performance, offline mode, findability, device attributes and monetization

Native design builds the code using the code library provided by the phone vendor.  Four primary targets are IPhone, Android, MS Windows Mobile and Blackberry. Native (installable) applications resides in your cell phone, and you  launch it directly from there, with whatever search parameters  are stored within your mobile (E.g.. The names of the 50 states in the USA, your favorite locations, daily weather, etc.). Except for free text search, all of  the search parameters can be stored in the mobile – OR they can be updated just one time.  The communication between the Data/Web server and the mobile phone could be drastically reduced. An application like a stock portfolio can be created within your Phone and stored. Every day you just need to update the stock prices. You need not download the entire portfolio each day. Also, the application resides within the phone, and can access your phone’s features such as your camera, phone book /contacts, etc. The disadvantage is obviously the development cost. No two mobile platforms can share the same mobile application, and there are too many Mobile operating systems (or platforms) existing in the market. If you develop a mobile application to market it widely, you need to develop that in J2ME (for phones that support only Java with no loaded OS), Symbian, Mac iPhone, Android, RIM, WebOS( for Palm pre), LinMo and Windows mobile.

Pros:

• Application runs faster
• Able to run offline (provided that all the needed data can exist on the device)
• Able to use all the phone capabilities – e.g. Shake, Accelerometer, Camera,

Cons:

• Need to build for each target platform
• Must deploy like Client server.
• IPhone Apple Store is controlled by Apple

Web

Web based applications are built using a web toolkit.  Nothing is loaded on the device.  It uses the device browser to load and run the application.  It can be shown as an icon on the desktop that links the web server. The advantage of a mobile browser based application is the low development cost, and the disadvantage is the bandwidth limitations and the limitations of Mobile websites, which does not access your Phone’s components like your Address book, Camera, etc. Mobile Brower based applications are slow due to the bandwidth limitations and will eat up your data usage in your phone plan. Also, the user needs to remember the URLs and type it, which every cell phone user knows is just plain  hard. One advantage is that the development cost is low since the developer only needs to consider how to make it compatible with most mobile browsers, and not each type of cell phone. Also, now that many Mobile browsers support HTML and smart phones come with bigger screens to see full sized websites, and users can zoom in and out. We have keyboards too to manage this. But, if you want to browse websites, you can do that in your tiny Netbook, which you always carry with you, right?

Pros:

• Build once for multiple target platforms
• Deploy changes on the server side with no client changes

Cons:

• Some limitations on functionality and features.
• Lower performance
• Cant run offline

Hybrid

They are Applications that use BOTH browser interfaces and native mobile components. The blended model builds a native application but uses HTML to provide some content and features. With HTML5 and JQuery, now the browsers are becoming capable of accessing a phone’s built in features like contacts, camera etc. Finally, what would be the disadvantages of  hybrid mobile applications? Two things comes to my mind…(1) Application security, and (2) the learning curve for the developers. Mobile developers need to know HTML and Web developers need to know mobile phone APIs.

Pros:

• Existing web content (IF implemented properly) can be reused to reduce costs of native development
• Maintenance overhead potentially reduced by less frequent updates

Cons:

• It has all the drawbacks of native development, although potentially diminished (this depends on how much of the functionality is in the native portion of the app and how much is in the web content portion)
• Properly designed web apps that can be reused without overhead are more of an ideal than reality

Following is the chart of different mobile development approaches used in the industry.

Some of the concerns for the business managers are:

• Disconnected operation IS a big deal. Not for the business traveler so much, but for the people at the jobsite and the people working away from the office on a regular basis. On the jobsite, wireless coverage is often limited, particularly in remote areas and inside structures. For mobile workers (FedEx delivery people, telecoms workers, etc.) wireless access might not be guaranteed. With web-based mobile apps, no connectivity means the applications just won’t run. With proper design, native apps can always be accessible, even though the user may have to defer connectivity until he returns to the office.
• The mobile apps will have narrow functionality. The best approach is to have a large number of small apps, rather than the traditional model of large applications with tons of functionality. This narrow functionality in turn results in a very narrow user base for each app, which in turn minimizes the need for apps than run on any device. There won’t be many apps that will have wide spread usage.
• Designing for the lowest common denominator will mean that all applications will have limited functionality. To me, it makes a lot more sense to evaluate each app on an individual basis, rather than trying to come up with a one size fits all model. For an app with a broad user base, it makes sense to build something that will run on any device. But to say that an app used by 1% of the workforce has to sacrifice functionality and usability just so everyone can run it from their own personal devices doesn’t make sense.

The bottom line –

• Go native on apps with narrow (small user base) functionality, and issue standard devices (one or two standard device types) to the users that run those apps
• Go web on apps with a large user base, and let the users install the apps on their own devices
• Hybrid apps are yet to see the light but I believe this is where the future is…

The choice of platform solely depends on your goals. You need a UI that is either:

1. truly usable
2. inexpensive

For option 1, native is the best solution; web is ruled out by its inability to optimally exploit the device.
For option 2, web is the best solution; native is ruled out by its costs; it is to be mentioned though, the price for this is a very austere UI.

Native Application are comparatively easier to maintain, whereas application written to run across multiple platforms may have complex code thus maintenance may not be that simple and testing will have to be intense to ensure a fix for particular platform does not impact anything else.

The advantage of non-native applications is one code base. one iteration of fix will take care of multiple platforms.

The very essence of leadership is that you have to have vision. You can’t blow an uncertain trumpet. – Theodore M. Hesburgh