Few developers would ever admit it, but developing for the PC has become relatively simple. CPU cycles are plentiful, bandwidth is abundant (at least on the LAN) and screen real estate plentiful.
The prevalence of Windows makes it easy to make assumptions about the user environment, while numerous standards mean moving to and from client applications is no longer a painful experience.
The reverse is true in the mobile world. Mobile devices can use operating systems from Palm, Microsoft or Symbian, each with their own peculiarities. Others use no OS at all. Screens are tiny, CPU cycles are scarce and RAM is a rare luxury. User interfaces are weedy.
So what must developers do to understand the new world and meet the opportunity?
Daryl Wilding-McBride, Practice Lead for Enterprise Services at Object Consulting, believes developers must go back to basics before they tackle mobile development.
“Software developers have forgotten the skills needed to fit applications into really small spaces,” he says. “You need to relearn or rediscover those skills because resources are a serious consideration.”
But relearning those skills may also mean un-learning reliance on IDEs that automate coding. Such tools of course offer portability of code from desktop to mobile device, a useful trait given that mobile computing embraces devices as varied as laptops with 3G connectivity at over 300Kbps, WiFi powered computers and smartphones on relatively anemic connections. But this diversity also means that reliance on auto-coding features creates the possibility that code may introduce unwelcome bloating to an application and rob it of power or usability once transferred to one class of mobile device, a situation that may requires multiple “streams” of code for the one application.
The alternatives to IDEs are scarcely more palatable. Adopting SDKs or other tools tailored to mobile development or even to individual devices introduces complexity to projects and starts to reach project management territory not found in textbooks. Working with mobility tools offered by application vendors will help to develop a mobile solution, but may waste effort by taking one application mobile without using that effort to create an enterprise-wide framework that can be reused and scaled as mobile computing needs grow.
Deciding on the tools to develop mobile applications therefore requires pragmatic business skills to judge how much integration and complexity a project can bear before the drive for technical elegance and specific tools begins to compromise the ability to deliver within deadlines and budgets.
Another, more prosaic, skill that needs attention is user interface design, according to Gartner analyst Robin Simpson. “The worst thing you can do is let a VB programmer loose with a handheld,” he says. “There’s a whole different user paradigm to master,” with ease of use critical as customers will ignore a mobile application that does not make a task easier and faster.
Meta analyst Bjarne Munch believes mobile applications’ need for especially productive GUIs may require “forms which perhaps predefine a number of answers on the screen,” so users can quickly identify the options on offer and respond meaningfully without the need for extra network connection time. “This is a technique that is just maturing,” he says, adding another layer of complexity to mobile development.
Architectural assumptions must also be overturned. “It is unfortunate that some people are approaching mobile commerce from a client/server perspective,” says Gartner’s Simpson. “Wireless links are unreliable so the device is useless without the connection in a client/server configuration.” Store-and-forward or synchronisation features are therefore important ingredients in the mobile development mix, but the decision about how to use these techniques must take into account the cost of connectivity over a mobile network, a consideration LAN-bound developers have not had to worry about for years.
“If you do a Web service over GPRS and are paying cents per kilobyte you need to think about whether to do the operation on the device and the whole end to end architecture,” says Daryl Wilding-McBride, Practice Lead for Enterprise Services at Object Consulting.
A tool that can help make that decision is a mobile device emulator, available in most IDEs and also offered by device manufacturers.
Wilding-McBride, however, feels that emulators have limited usefulness.
“Emulators are good because they force you to think about the size of the screen and tackle the different user interface,” he says, but lack other features.
“I remember the early versions of Microsoft’s Front Page [Web development tool] had an indicator telling you how long a page would take to load over internet connections of different speeds. That was very important and useful. But emulators don’t do that.”
Wilding-McBride also believes emulators also struggle to simulate the true processing power of a mobile device. “You don’t know the real CPU cycle cost until you deploy,” he says.
Davyd Norris of IBM Rational believes developers should take this process a step further and test their wares on mobile networks too.
“You need to do target deployment,” he says.” Get out onto a real network.”