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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 checkout 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.
Remember that the database can be shared across multiple mobile development projects. Handset resources can be shared, and sales statistics can be compared to see on which handsets your applications perform best. Different team members can use the handset database in different ways.
• Product designers use the database to develop the most appropriate application user interface for the target phones.
• Media artists use the database to generate application assets such as graphics, videos, and audio in supported media file formats and resolutions appropriate for the target phones.
• Project managers use the database to determine the handsets that must be acquired for development and testing purposes on the project and development priorities.
• Software developers use the database to design and develop applications compatible with target handset device specifications.
• Quality assurance personnel use the database to design and develop test plans target handset device specifications and to test the application thoroughly.
• Marketing and sales professionals use the database to estimate sales figures for released applications. For example, it is important to be aware that application sales will drop as handset availability drops.
The information in the database can also help determine the most promising target handsets for future development and porting.
There are third-party databases for phone information including screen size and internal device details and carrier support details, but subscribing to such information can be costly for a small company. Many mobile developers instead choose to create a custom phone database with only the phones they are interested in and the specific data they need for each phone, which is often absent from open and free databases.
In addition to the normal risks any software project must identify, mobile projects need to be aware of the outside influences that can affect their project schedule and whether the project requirements can be met. Some of the risk factors include identifying and acquiring target handsets and continually reassessing application feasibility.
Just as most sane software developers wouldn’t write a desktop application without deciding what operating systems (and their versions) the application would run on first, mobile developers must consider the target handsets their application will run on. Each handset will have different capabilities, a different user interface, and unique device limitations.
Target handsets are generally determined in one of two ways:
• There’s a popular “killer” phone you want to develop for.
• You want to develop an application for maximum coverage.
In the first instance, you have your initial target handset figured out; in the second instance, you want to look at the available (and soon to be available) phones on the market and adjust your application specification to cover as many as is reasonably feasible.
It’s also important to note that we’ve seen popular phones, such as the Motorola RAZR, customized by a number of operators. An operator might ship its custom version of a handset, including big bundles of custom applications (taking up a bunch of space on the device) and disabling specific handset features (such as Bluetooth or WiFi), which effectively makes it impossible for your application to run. All these factors must be taken into account when considering your application requirements and abilities. Your application’s running requirements must match the features shared across all target handsets and handle optional feature use appropriately in all cases.
New handsets are developed and carriers and manufacturers retire (sunset) handsets all the time. Handsets also leave the market all the time. Note that different carriers might carry the same (or similar) phone but might sunset (retire) the phones at a different time.
Tip
Companies should set a policy, made clear to users, of how long an application will be supported after the carrier or manufacturer stops supporting a specific handset. This policy might need to be different for various carriers because carriers impose their own support requirements.
You need to determine how different kinds of phone models can move through the worldwide marketplace. Some phones are available (or become popular) only in certain geographic regions. Sometimes phones are released worldwide, but often they are released regionally. The T-Mobile G1, for example, was first released in the United States but is available now in other markets as the HTC Dream.
Historically, it’s common for a phone to become available in market-driving Asia first and then show up in Europe, North America and Australia where phone users often upgrade every year or two and will pay premium rates for applications. Finally, these same phones become available in Central and South America, and China and India, where subscribers often don’t have landlines nor do they have the same levels of income. Regions such as China and India must often be treated like entirely separate mobile marketplaces—with more affordable handsets requiring vastly different revenue models. Here applications sell for less, but revenue is instead derived from the huge and growing subscriber base.
The earlier you can get your hands on the target handsets, the better off you’re going to be. Sometimes this is as easy as going to the store and grabbing a new phone.
It is quite common for an application developer to target upcoming phones—phones not yet shipping or available to consumers. There is a great competitive advantage to have your application ready to run the moment consumers have the handset in their hand for the first time. For preproduction handsets, you can join manufacturer and operator developer programs. These programs help you keep abreast of changes to the handset lines (upcoming models, discontinued models). Many of these programs also include preproduction phone loan programs, allowing developers to get their hands on the phone before consumers do.
Tip
Google has made available the Android Dev Phone 1, a phone compatible with Android 1.0 and 1.1, for registered Android developers.
There are risks for developers writing applications for specific preproduction handsets because handset shipment dates often slide. Handsets are delayed or canceled. Handset features (especially new and interesting ones) are not set in stone until the handset ships and the developer verifies that those features work as expected. Exciting new handsets are announced all the time—handsets you might want your application to support. Your project plan must be flexible enough to change and adapt with the market as necessary.
Mobile developers are at the mercy of the handset limitations, which vary in terms of memory and processing power. Mobile developers do not have the luxury traditional desktop application developers have of saying an application requires “more memory” or “more space.” Handset limitations are fixed, and if a mobile application is to run, it runs within the handset’s limitations, or not at all.
True feasibility assessment can be done only on the physical handset, not the software emulator. Your application might work beautifully in the emulator but falter on the actual device. Mobile developers most constantly revisit feasibility, application responsiveness, and performance throughout the development process.
The quality assurance team has its work cut out because the testing environment is generally less than ideal.
Get those target handsets in-hand as early as possible. For preproduction handsets, it can take months to get the hardware in hand from the manufacturer. Cooperating with carrier handset loaner programs and buying handsets from retail locations is frustrating but sometimes necessary. Don’t wait until the last minute to gather the test hardware.
It cannot be said enough: Testing on the emulator is helpful, but testing on the handset is essential. In reality, it doesn’t matter if the application works on the emulator—no one uses an emulator in the real world.
There is often no easy way to “wipe” a phone and return it to a clean starting state, so the quality assurance team needs to determine what a clean state on the phone is as a testing policy and stick to it. Testers might require the skills and capability to flash handsets with different firmware versions.
In some ways, every quality assurance tester works within a controlled environment. This is doubly true for mobile testers. They often work with phones not on real networks and preproduction phones that might not match those in the field. Add to this that because testing generally takes place in a lab, the location (including primary cell tower, satellite fixes and related phone signal strength, availability of data services, LBS information, locale information) is fixed. The quality assurance team needs to get creative to mitigate the risks of testing too narrow a range of these factors. For example, it is essential to test all applications when the phone has no signal (and in airplane mode, and such) to make sure they don’t crash and burn under such conditions that we all experience at some point in time.
Make sure the quality assurance team understands its responsibilities. Mobile applications often have network components and server-side functionality. Make sure thorough server testing is part of the overall test plan—not just the phone client portion of the overall solution. This might require the development of desktop or web applications to exercise network portions of the overall solution.
You might think that with its shorter schedules, smaller teams, and simpler functionality, mobile software project documentation would be less onerous. Unfortunately, this is not the case—quite the opposite. In addition to the traditional benefits any software project enjoys, good documentation serves a variety of purposes in mobile development.
Some documentation you should consider including in your project includes
• Requirements Analysis and Prioritization
• Risk Assessment and Management
• Application Architecture and Design
• Feasibility Studies including Performance Benchmarking
• Technical Specifications (Overall, Server, Handset-Specific Client)
• Detailed User-Interface Specifications (General, Handset-Specific)
• Test Plans, Test Scripts, Test Cases (General, Handset-Specific)
• Scope Change Documentation
Much of this documentation is common in your average software development project. But perhaps your team finds that skimping on certain aspects of the documentation process has been doable in the past. Before you think to cut corners in a mobile development project, consider some of these documentation requirements for a successful project. Some project documentation might be simpler than that of larger scale software projects, but other portions might need to be fleshed out in finer detail—especially user interface and feasibility studies.
Quality assurance relies heavily on the functional specification documentation and the user interface documentation. Screen real estate is valuable on the small screens of mobile devices, and user experience is vital to the successful mobile project.
There’s no such thing as a killer application with a poorly designed user interface. Thoughtful user interface design is one of the most important details to nail down during the design phase of any mobile software project. Application workflow (application state) must be thoroughly documented at the screen-by-screen level and can include detailed specifications for key usage patterns and how to gracefully fallback when certain keys or features are missing. Usage cases should be clearly defined in advance.
Some companies opt to have quality assurance done offsite by a third party; most quality assurance teams require detailed documentation including use case workflow diagrams to determine correct application behavior. If you do not provide adequate and detailed documentation to the testing facility, you will not get deep and detailed testing. By providing detailed documentation, you raise the bar from “it works” to “it works correctly.” What might seem straightforward to some people might not be to others.
If you are required to submit your application to a software certification program or even, in some cases, to a mobile application store, part of your submission is likely to require some documentation about your application. Some stores require, for example, that your application include a Help feature or technical support contact information. Certification programs might require you to provide detailed documentation on application functionality, user interface workflow, and application state diagrams.
There are many wonderful source control systems out there for developers, and most that work well for traditional development will work fine for a mobile project. Versioning your application, on the other hand, is not necessarily as straightforward as you might think.
Mobile development considerations impose no surprise requirements for source control systems. Some considerations for developers evaluating how they handle configuration management for a mobile project are
• Ability to keep track of source code (Java) and binaries (Android packages, and so on)
• Ability to keep track of application resources by handset configuration (Graphics, and so on)
• Integration with the developer’s chosen development environment (Eclipse)
One consideration is integration between the development (IDE) (such as Eclipse) and the source control system. Common source control systems such as Perforce, Subversion, and CVS work well with Eclipse.
Developers should also decide early on a versioning scheme that takes into account the handset particulars and the software build. It is often not sufficient to version the software by build alone (that is, Version 1.0.1).
Mobile developers often combine the traditional versioning scheme with the target handset configuration (Version 1.0.1.HandsetModel). This helps quality assurance, technical support personnel, and end-users who might not know the model names of their handsets or only know them by marketing names developers are often unaware of. Be aware that handset configuration can include carrier-specific handset customizations, such as the T-Mobile G1.
If you use the hybrid model for grouping project requirements that we previously discussed in the chapter, you can add this information to the version as well. For example, the application developed with camera support might be versioned 1.0.1.C.HandsetName where C stands for “Camera Support,” whereas the same application for a handset without camera support might have a version such as 1.0.1.NC.HandsetName, where NC stands for “No Camera Support” source branch. If you had two different maintenance engineers supporting the different source code trees, you would know just by the version name who to assign bugs to.
Just to make things a tad more confusing, you might need to plan for different versions of the firmware on a specific handset. For example, the T-Mobile G1 has received firmware upgrades. If an upgrade spawns a rebuild of your application, you might want to version it appropriately:Version 1.0.1.N.G1.Upg1.1, and such.
Yes, this can get out of control, so don’t go overboard, but if you design your versioning system intelligently upfront, it can be useful later when you have different handset builds floating around internally and with users. It’s not uncommon to field a support call for a particular handset identified by users only to find out based on a great version numbering scheme that they either don’t have the handset they thought they had or have the wrong version on the handset.
When designing an application for mobile, the developer must consider the constraints the handset imposes and decide what type of application framework is best for a given project.
Applications are expected to be fast, responsive, and stable, but developers must work with limited resources. The memory and processing power constraints of all target handsets must be kept in mind when designing and developing mobile applications.
Mobile applications have traditionally come in two basic models: stand-alone applications and network-driven applications.
Stand-alone applications are packaged with everything they require and rely on the handset to do all the heavy lifting. All processing work is done locally, in memory, and is subject to the limitations of the device. Stand-alone applications might use network functions, but they do not rely on them for core application functionality. An example of a reasonable stand-alone application is a Solitaire game.
Network-driven applications provide a lightweight handset client but rely on the network to provide a portion of its content and functionality. Network-driven applications are often used to offload intensive processing to the server, but they can also be used to add functionality long after the application has been installed. They also have the added benefit of allowing developers to build one smart server and a large number of handset clients across many different mobile operating systems to support a larger audience of users. Good examples of network-driven applications include
• Customizable content such as ringtone and wallpaper applications
• Applications with noncritical process and memory intensive operations that can be offloaded to a powerful server and the results delivered back to the client
• Any application that provides additional features at a later date without a full update to the binary
How much you rely on the network to assist in your application’s functionality is up to you. You can use the network to provide only content updates (popular new ringtones), or you can use it to dictate how your application looks and behaves (for instance, adding new menu options or features on-the-fly).
Applications can be written with a fixed user interface and a fixed feature set, but they need not be. Network-driven applications can be more complex to design but offer flexibility for the long term—here’s an example.
Let’s say you want to write a wallpaper application. Your application can be a stand-alone version, partially network-driven or completely network-driven. Regardless, your application will have two required functions:
• Show a bunch of images and allow the user to choose one.
• Take the chosen image and register it as the wallpaper on the phone.
A super simple stand-alone wallpaper application might come with a set of wallpapers. If they’re a generic size for all target handsets, you might need to reformat them for the specific handset. You could write this application, but it would waste space and processing. You can’t update the wallpapers available, and it is generally just a bad design.
The partially network-driven wallpaper application might allow the user to browse a fixed menu of wallpaper categories, which show images from a generic image server. The application downloads a specific graphic and then formats the image for the handset. You can add new wallpapers to the server anytime, but you would need to build a new application every time you want to add a new handset configuration. If you want to change the menu, for example to add animated wallpapers at a later date, you would need to write a new version of your application. This application is feasible, but it isn’t using its resources wisely either and isn’t particularly extensible. However, you could use the single server to write clients for Android, BREW, J2ME, and Blackberry clients, so we are still in a better position than we were with the stand-alone wallpaper application.
The fully network-driven version of the wallpaper application does the bare minimum it needs to on the phone. It asks the server what menus to display and where they go. The user browses the image server just like the partially network-driven version does, but when the user chooses a wallpaper, the mobile application just sends a request to the server:“I want this image and I am this kind of handset.” The server keeps track of what formatting requirements each handset has. The server reformats and resizes the image (process intensive operations) and sends the perfect tailored image down to the application, which the application then sets as the wallpaper. Adding support for more handsets is straightforward—deploy the lightweight client with any necessary changes and add support for that handset configuration to the server. Adding a new menu item for animated wallpapers is just a server change, resulting in all handsets (or whichever handsets the server dictates) getting that new category. The response time of this application depends upon network performance, but the application is the most extensible and dynamic.
Stand-alone applications are straightforward and great for one-shot, one-handset applications and those that are meant to be network-independent. Network-driven applications require a bit more forethought and are sometimes more complicated to develop but might save a lot of time in the long run.
Mobile application designers should consider how they will interface with other applications on the handset, including other applications written by the same developer. Some issues to address are
• Will your application rely on other content providers?
• Are these content providers guaranteed to be installed on the phone?
• Will your application act as a content provider? What data will it provide?
• Will your application have background features? Act as a service?
• Will your application rely on third-party services or optional components?
• Will your application expose its functionality through a remote interface (AIDL)?
Mobile application implementation follows the same design principles as other platforms. The steps mobile developers take during implementation are fairly straightforward:
- Write and compile the code.
- Run the application in the software emulator.
- Test and debug the application in the software emulator.
- Package and deploy the application to the target handset.
- Test and debug the application on the target handset.
- Incorporate changes from team and repeat until application is complete.
We talk more about development strategies for building solid Android applications in Chapter 19, “Developing and Testing Bulletproof Android Applications.”
There is a mobile quality assurance mantra:
Test early, test often, test on the actual device.
It’s unfortunate, but even now, most quality assurance (QA) testing is done manually on the handset. Testers face many challenges, including handset fragmentation (many handsets, each with different features), defining device states (what is a clean state?), and handling real-world events (phone calls, loss of coverage). Gathering the handsets needed for testing can be costly and difficult, so there is an active market for mobile testing houses.
The good news for mobile QA teams is that the Android SDK includes a number of useful tools for testing applications both on the emulator and the handset. There are many opportunities for leveraging white box testing. Automation of handset testing might not be an option (although there are companies working in this direction), but do seize the opportunities to use traditional QA automation software such as Borland SilkTest for performing emulator testing for build validation, smoke testing, and any early testing when handsets are not readily available.
Defect tracking systems must be modified to handle testing across handset configurations and carriers. For thorough testing, QA team members generally cannot be given the device and told to “try to break it.” There are many shades of gray for testers, between black box and white box testing. Testers should know their way around the Android Emulator and the other utilities provided with the Android SDK.
Tip
In Chapter 7, “Designing Android User Interfaces with Layouts,” we explain how to use the Hierarchy View utility to design and validate user interface design and take pixel-perfect screenshots on the handset. In Part VII, “Appendixes,” of this book, you’ll find Quick-Start Guides for the Android emulator (Appendix A), the DDMS utility (Appendix B), and Android Debug Bridge (Appendix C). These tools are valuable not just to developers, but allow testers much more control over the handset configuration.
Mobile quality assurance involves a lot of edge case testing and, again, a preproduction model of a handset might not be exactly the same as what eventually ships to consumers. We talk more about testing Android applications in Chapter 19.
Developers need to determine what methods they use to distribute applications. With Android, you have several options. You can market applications yourself and leverage third-party marketplaces like the Android Market. Consolidated mobile marketplaces, such as Handango, also have Android distribution channels you can take advantage of.
Developers must take into account any requirements imposed by third parties offering application distribution mechanisms such as the Android Market and Handango.
Specific distributers might impose rules for what types of applications they distribute on your behalf. They might impose quality requirements such as testing certifications (although there are none specific to Android applications at the time this book went to print) and accompanying technical support, and documentation and adherence to common user interface workflow standards (that is, the Back button should behave like this) and performance metrics for responsive applications. Distributers might also impose content restrictions such as barring objectionable content.
We talk more about selling Android applications in Chapter 20, “Selling Your Android Application.”
Generally speaking, mobile application support requirements are minimal if you come from a traditional software background, but they do exist. Carriers and operators generally serve as the front line of technical support to end users. As a developer, you aren’t usually required to have 24/7 responsive technical support staff or toll-free phone numbers and such. In fact, the bulk of application maintenance can fall on the server side and be limited to content maintenance—such as posting new media such as ringtones, wallpapers, videos, or alerts.
That said, the hardware on the market changes quickly, and mobile development teams need to stay on top of the market. Here are some of the maintenance and support considerations unique to mobile application development.
Maintenance is often not done by the same engineers who developed the initial application. Here, keeping adequate development and testing documentation, including specifications and test scripts, is even more vital.
Always treat any live server with the care it deserves. This means backups and upgrades need to be timed appropriately. Data needs to be safeguarded and user privacy maintained at all times. Rollouts should be managed carefully because live mobile application users might rely on its availability. Do not underestimate the server-side development or testing needs. Always test server rollouts in a safe testing environment before “going live.”
If you’ve implemented the handset database we previously talked about in the chapter, now is the ideal time to analyze handset similarities to identify easy porting projects. For example, you might discover the following: An application was originally developed for a specific handset, but now there are several popular handsets on the market with similar specifications. Porting an existing application to these new handsets sometimes is as straightforward as generating a new build (with appropriate versioning) and testing the application on the new handsets.
Mobile software development has evolved over time and differs in some important ways from traditional desktop software development. In this chapter, you gained some practical advice to adapting traditional software processes to mobile, from identifying target handsets to testing and deploying your application to the world. There’s always room for improvement when it comes to software process. Hopefully some of these insights can help you avoid the pitfalls new mobile companies sometimes fall into or simply improve the processes of veteran teams.
Wikipedia on Software Process: http://en.wikipedia.org/wiki/Software_development_process
Wikipedia on Rapid Application Development (RAD): http://en.wikipedia.org/wiki/Rapid_application_development
Wikipedia on Iterative Development: http://en.wikipedia.org/wiki/Iterative_and_incremental_development
Wikipedia on Waterfall Development Process: http://en.wikipedia.org/wiki/Waterfall_model
Extreme Programming: www.extremeprogramming.org/