tk
| Excerpt from Android Wireless Application Development. | |
By Shane Conder and Lauren Darcey Published by Addison-Wesley Professional ISBN-10: 0-321-62709-1 ISBN-13: 978-0-321-62709-4 | |
The mobile development process is much like the traditional desktop software process with a couple of distinct differences. Understanding how differences affect your development team is critical to running a successful mobile development project. This information and insight into the mobile development process is invaluable to veterans and those new to mobile development, to those in management and planning and the developers and testers in the trenches. In this chapter, we take a look at each step in the mobile software development process and discuss some of the peculiarities of mobile development.
An Overview of the Mobile Development Process
Mobile development teams are often small in size and project schedules are short in length. The entire project lifecycle is often condensed, and whether you’re a team of one or one hundred, understanding the mobile development considerations for each part of the development process can save you a lot of wasted time and effort.
Some hurdles a successful mobile development team must overcome include
Choosing an appropriate software methodology for your mobile project
Understanding how target handsets dictate the functionality of your application
Performing thorough, accurate, and ongoing feasibility analyses
Mitigating the risks associated with preproduction handsets
Keeping track of handset functionality through configuration management
Designing a responsive, stable application on a memory restrictive system
Designing user interfaces for a variety of devices with different user experiences
Testing the application thoroughly on the target handsets
Incorporating third-party requirements that affect where you can sell your application
Deploying and maintaining a mobile application
Choosing a Software Methodology
Developers can easily adapt most modern software methodologies to mobile development. Whether your team opts for traditional Rapid Application Development (RAD) principles or more modern variants of Agile Software Development like Scrum, mobile applications have some unique requirements.
Understanding the Dangers of Waterfall Approaches
The short development cycle might tempt some to use a Waterfall approach, as shown in Figure 18.1, but developers should beware of the inflexibility that comes with this choice. It is generally a bad idea to design and develop an entire mobile application without taking into account the many changes that tend to occur during the development cycle. Changes to target handsets (especially preproduction models), ongoing feasibility, and performance concerns, and the need for quality assurance to test early and often on the target devices (not just the emulator) make it difficult for strict waterfall approaches to succeed with mobile projects.
The Dangers of Waterfall Development. (Graphic courtesy of Amy Tam Badger).
Understanding the Value of Iteration
Because of the speed at which mobile projects tend to progress, iterative methods have been the most successful strategies adapted to mobile development. Rapid prototyping enables developers and quality assurance personnel ample opportunity to evaluate the feasibility and performance of the mobile application on the target handsets and adapt as needed to the change that inevitably occurs over the course of the project.
Gathering Application Requirements
Requirements analyses for mobile applications can be more complex than that of traditional desktop applications. Requirements must often be tailored to work across a number of handsets—handsets that might have vastly different user interfaces and input methods. This makes development assumptions tricky.
Determining Project Requirements
When multiple handsets are involved, there are generally two approaches to determining project requirements: the lowest common denominator method and the customization method. Each method has its benefits and its drawbacks.
With the lowest common denominator method, you design the application to run sufficiently well across a number of devices. In this case, the primary target handset is typically the device with the fewest features—basically, the most inferior handset. Only requirements that can be met by all devices are included in the specification to reach the broadest range of devices—requirements such as input methods, screen resolution, and the Software Development Kit (SDK) version.
Note - The lowest common denominator method is roughly equivalent to developing a desktop application with the following minimum system requirements: (1) Windows 2000 and (2) 128 megabytes of RAM, on the assumption that the application will be forward compatible with the latest version of Windows (and every other version in between). It’s not ideal, but in some cases, the trade-offs are acceptable.
Some light customization, such as resources and the final compiled binary (and the version information) is usually feasible. The main benefit of this method is that there is only one major source code tree to work with; bugs are fixed in one place and apply across the board. You can also easily add other handsets without changing much code, provided they too meet the minimum hardware requirements. The drawbacks include the fact that the resulting generalized application does not maximize any phone-specific features. Also, if a device-specific problem arises or you misjudge the lowest common denominator and later find that an individual handset lacks the minimum requirements, the team might be forced to implement a workaround (hack) or branch the code at a later date, losing the early benefits of this method but keeping all the drawbacks.
What’s New in Android 1.5 - The tool suite introduced in Android 1.5 allows developers to write for multiple target Android SDK versions from a single Android SDK installation. Developers should take care to identify target platforms early in the design phase and not rely on backward compatibility when it comes to supporting individual devices.
Also, firmware updates have been a fairly regular occurrence, so the Android SDK version on a specific device might change after an over-the-air update in the field. The upgrade from Android SDK 1.1 to 1.5 compelled many Android developers to publish compatible updates to existing applications.
Using the customization method, the application is tailored for specific handsets. This method works well for projects targeting a small number of target handsets but does not scale well from a resource management perspective. There is generally a core application framework (classes or packages) shared across all versions of the application. All versions of a client-server application would likely share the same server and interact with it in the same way, but the client implementation is tailored to take advantage of specific phone features. That is the key benefit of this approach. Some drawbacks include source code fragmentation (many branches of the same code), increased testing requirements, and the fact that it can be more difficult to add new handsets in the future.
In truth, mobile development teams usually use a hybrid approach incorporating some of the aspects from both methods. It’s pretty common to see sets of handsets grouped together based on functionality. For example, a game application might group handsets based on graphics performance, screen resolution, or input methods. A Location Based Service (LBS) application might group handsets based on the available internal sensors. Other applications might develop one version of an application for phones with built-in cameras and one version for those without cameras. These groupings are arbitrary and set by the developer to keep the code and testing manageable. They will, in large part, be driven by the details of a particular application and any support requirements.
Tip -
A single, unified version of an application is cheaper to support than distinctly different versions. However, a game will probably sell better with custom versions that leverage the distinct advantages and features of a specific handset. A vertical business application would likely benefit more from a unified application design that works the same, is easier to train users across multiple handsets, and would thus have lower support costs for the business.
Use cases should be first written in general terms for the application before adapted to specific handsets, which impose their own limitations. For example, a high-level use case for an application might be this: “Enter Form Data” but the individual handsets might use different methods to perform this on the specific phone hardware, whether the phone has a keyboard, and so on.
Tip -
Developing an application for multiple handsets is much like developing an application for different operating systems and input devices (such as handling Mac keyboard shortcuts versus those on Windows)—subtle and not-so-subtle differences must be accounted for. These differences might be obvious, such as not having a keyboard for input, or not so obvious, such as handset-specific bugs or different conventions for right and left soft keys.
Incorporating Third-Party Requirements
In addition to the requirements imposed by your internal requirements analyses, your team needs to incorporate any requirements imposed by others. Third-party requirements can come from any number of sources, including
Android License Agreement Requirements
Google Maps API License Agreement Requirements (if applicable)
Third-Party API Requirements (if applicable)
Android Market Requirements
Mobile Carrier/Operator Requirements
Other Application Store Requirements (if applicable)
Application Certification Requirements (if applicable)
Incorporating these requirements into your project plan early is essential not only for keeping your project on schedule but also so that these requirements are built into the application from the ground up, as opposed to applied as afterthoughts that can be risky.
Managing a Handset Database
As your mobile development team builds applications for a growing number of handsets, it becomes more and more important to keep track of the target handset information for revenue estimation and maintenance purposes. Creating a handset database is a great way to keep track of both marketing and device specification details for target handsets. When we say “database,” we mean anything from a Microsoft Excel spreadsheet to a little local database. The point is that the information is shared across the team or company and kept up to date.
The phone database is best implemented early, when project requirements are just determined and target handsets are determined. Figure 18.2 illustrates how handset information can be tracked and used by different members of the application development team.
How a development team uses the handset database.
Determining Which Handsets to Track
Some companies track only the handsets they actively develop for, whereas others also track handsets they might want to include in the future, or lower priority handsets. Handsets can be included in the database during the Requirements phase of a project but also later as a change in project scope. They can also be added as subsequent porting projects long after the initial application has been released.
Storing Handset Data
The handset database should be designed to contain any information about a given handset that would be helpful for developing and selling applications. This might require that someone be tasked with keeping track of a continual stream of information from carrier and manufacturers. Still, this information can be useful for all mobile projects at a company. This data should include
Important handset technical specification details (screen resolution, hardware details, supported media formats, input methods, localization)
Any known issues with handsets (bugs and important limitations)
Handset carrier information (any firmware customizations, release and sunset dates, expected user statistics, such as if a phone is highly anticipated and expected to sell a lot, or well received for vertical market applications, and so on)
Firmware upgrade information (as it becomes available, changes might have no impact on the application or warrant an entirely separate handset entry)
Actual testing handset information (which handsets have been purchased or loaned through manufacturer or carrier loaner programs, how many are available)
The handset carrier information can also be cross-referenced with sales figures from the carrier, application store, and internal metrics.
The actual testing handset information is often best implemented as a library check-out system. Team members can reserve handsets for testing and development purposes. When a loaner phone needs to be returned to the manufacturer, it’s easy to track. This also facilitates sharing handsets across teams.