Eight lessons on mobile development
What you need to know to build capable mobile apps
By Paul Krill | InfoWorld | Published: 12:04, 23 April 2011
Smartphones and, more recently, tablets are increasingly becoming the computer of choice for more and more people, leaving software developers used to PC-sized application interfaces to grapple with a whole new outlook. While many developers already have made the transition, others need to get with the program.
Despite the attention paid to mobile development in the last two years, a lot of developers still lack the basics when it comes to building mobile applications, says Anthony Fabbricino, developer marketing manager for Forum Nokia. Many developers are just used to the desktop, he explains: "There, they have a lot of screen."
Even if it may be easy to make an application, it's hard to construct a "good experience," Fabbricino adds. Indeed, the emergence of mobile devices and their smaller screens means some serious adjustments in perspective. Instead of building for 8-by-13-inch or larger PC screens, developers could be dealing with a 2-by-2-inch Android, iPhone, or BlackBerry screen.
"What we find, especially in the smartphone world, is because of the screen size constraint, every pixel counts to some degree," says Tyler Lessard, vice president of BlackBerry global alliances and developer relations at Research in Motion.
Even the iPad's larger screen, which measures 7.3 by 9.5 inches, need to be considered differently because its 1,024-by-768-pixel resolution is still less than that of most desktop monitors. Developers must also make accommodations for smaller keyboards, touch interfaces and battery usage.
Experts in the mobile arena, including vendors and developers, have advice for developers navigating this new realm of computing, covering aspects ranging from navigation to screen size to memory consumption. Mobile developers, especially new ones, should pay special attention to these eight lessons.
Mobile app dev lesson 1: Focus on user experience
"The first [guideline] is reduce navigation that the users have to do by taking them directly to the content that they're working with," says Adam Blum, CEO of Rhomobile, makers of the Rhodes development framework for mobile applications. In a CRM application, for example, take users right to their contacts instead of making them wade through lists and tasks. Also, try basing the application's navigation on what users did the last time. Go with defaults.
Nokia, which has built smartphones based on the Symbian platform and is switching to Windows Phone 7, offers templates to assist in putting icons on screens. "[The icons] scale to the different screen sizes," Fabbricino says. Developers must be concerned with integrating UI and application logic, as well as remain mindful of what an application is trying to do. "You don't want to overload information, overload user interactions."
At Callaway Digital Arts, which builds multimedia storytelling software for Apple's iPhone and iPad, applications are tweaked for the different devices, such as offering shopping lists on the iPhone, which tends to be used in more on-the-go settings than the iPad.
"We're not just creating a single experience across all iOS platforms," says Nicholas Callaway, president of the company. Callaway focuses on optimising its applications in the rich media space. "That's part of our art: knowing how to deliver the richest UX and to push the boundaries of what the devices can do but still have them be [usable and reliable]."
Mobile app dev lesson 2: Deal upfront with memory and bandwidth constraints
Memory and network bandwidth issues abound with mobile devices.
"The biggest [difference] that we see with our customers and with people doing the transition from desktop to mobile is that these mobile devices really do not have a lot of memory," says Miguel de Icaza, vice president of developer platforms at Novell, which offers tools for building Google Android and Apple iOS applications.
Although a typical PC can have 8GB of memory, a smartphone might have just 128MB, he says. Thus, developers loading 100 images onto a phone would run out of memory. "One hundred images would require you to have a smartphone that doesn't exist yet." But accommodations can be made: "Instead of having full resolution images, what [developers] need to do is have smaller resolution images," he says.
Network connectivity for smartphones and tablets incurs limits on downloading, de Icaza says, including data caps typically. "The application developer really shouldn't be saturating the network connection with thousands of requests for images," Callaway says. The bottom line: "Memory and space and battery life are some of the parameters within which you have to develop all your apps."
Mobile app dev lesson 3: Choose carefully between native and web development
Developers must decide whether to build applications leveraging native capabilities and have the application downloaded onto the device or to create web apps that run via the mobile OS's WebKit facility. With the latter, they appear to be standalone apps even though they use the WebKit browser services.
"This is something [in which] a lot of vendors look very carefully at the trade-offs," says RIM's Lessard. Web-based development is often less expensive and not as complex. "However, the trade-off tends to be that you may not be able to deliver the kind of experience a user might expect."
For example, in web development, location-based services and touch interfaces might be shortchanged. It is difficult to achieve fine grain control over touch events when doing web development, he notes.
Mobile app dev lesson 4: Think about how to take advantage of location
Location services are becoming widespread in smartphones, giving developers something new to think through. "Leveraging location isn't something that most vendors would take into account when building desktop or web applications," Lessard says.
But location services enable developers to offer a more customised experience, such as with a search application that already knows where the user is or offering locally relevant advertising. Programming for location services is "fairly straightforward," says Lessard, developers just have to learn the new interfaces.
Mobile app dev lesson 5: Rely on server-side data synchronisation
Proper data synchronisation also is critical. "The way you look at synchronisation is trying to rely on server-side policy," says Nokia's Fabbricino. "You really don't try to take care of synchronisation from a mobile side because that's where you get corrupt data." Caching data on the device is another option.
Mobile app dev lesson 6: Design and code for touch interfaces
Developers and designers building applications for small devices have to grasp touch interfaces, which requires "more of an understanding from a design and UX perspective" than it does understanding code, says Tina Unterlaender, director of mobile at AKQA Mobile, which makes iOS applications.
Developers need to understand user flows first, then translate the basis of touch interfaces into coding language.
Mobile app dev lesson 7: Don't get too dependent on hardware performance
Handheld devices are increasingly using faster chips and are beginning to support graphics processors and hardware acceleration, boosting animation rendering. But Fabbricino tells developers not to be overzealous: "You have to understand when a user will benefit from that experience and take advantage of the hardware that's underneath it."
Applications could, for example, use animation to bolster screen transitions. But developers must be careful not to slow down an application through excessive or unnecessary use of such processor hungry techniques.
Mobile app dev lesson 8: Expect users to make mistakes
Developers also should anticipate users pressing the wrong buttons, says Martin Wrigley, who chairs the Unified Testing Initiative, a consortium of mobile device and application makers.
The smaller size of smartphones and the unfamiliarity most users have with touchscreens all but guarantee they'll make input mistakes, so applications need to both be more tolerant of slipups and help users recover without undue extra effort. To that end, the consortium has published best practice guidelines (PDF) to aid developers in avoiding what Wrigley calls "schoolboy errors."