Learning the Android Software Development Process - Publishing and Distributing Android Applications - Introduction to Android Application Development, Fourth Edition (2014)

Introduction to Android Application Development, Fourth Edition (2014)

Part V. Publishing and Distributing Android Applications

Chapter 15. Learning the Android Software Development Process

The mobile development process is similar to the traditional desktop software process, with a couple of distinct differences. Understanding how these differences affect your mobile development team is critical to running a successful project. This insight into the mobile development process is invaluable to those new to mobile development and veteran developers alike, to those in management and planning, as well as to the developers and testers in the trenches. In this chapter, you learn about the peculiarities of mobile development as they pertain to each stage of the software development process.

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 mobile development team must overcome include

Image Choosing an appropriate software methodology

Image Understanding how target devices dictate the functionality of your application

Image Performing thorough, accurate, and ongoing feasibility analyses

Image Mitigating the risks associated with preproduction devices

Image Keeping track of device functionality through configuration management

Image Designing a responsive, stable application on a memory-restrictive system

Image Designing user interfaces for a variety of devices with different user experiences

Image Testing the application thoroughly on the target devices

Image Incorporating third-party requirements that affect where you can sell your application

Image Deploying and maintaining a mobile application

Image Reviewing user feedback, crash reports, and ratings, and deploying timely application updates

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, such as 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, 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 (see Figure 15.1). Changes to target devices (especially preproduction models, though sometimes shipping devices can have substantial software changes), ongoing feasibility, and performance concerns and the need for quality assurance (QA) to test early and often on the target devices themselves, (not just the emulator) make it difficult for strict waterfall approaches to succeed with mobile projects.

Image

Figure 15.1 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 gives developers and QA personnel ample opportunity to evaluate the feasibility and performance of the mobile application on the target devices and adapt as needed to the changes that inevitably occur over the course of the project.

Gathering Application Requirements

Despite the relative simplicity of a mobile application’s feature set compared to a traditional desktop application, requirements analyses for a mobile application can be more complex. The mobile user interface must be elegant and the application must be fault tolerant, not to mention responsive in a resource-constrained environment. You must often tailor requirements to work across a number of devices—devices that might have vastly different user interfaces and input methods. Having great variation in target platforms can make development assumptions tricky. It’s not unlike the differences Web developers might need to accommodate when developing for different Web browsers (and versions of Web browsers).

Determining Project Requirements

When multiple devices are involved (which is almost always the case with Android), we have found several approaches to be helpful for determining project requirements. Each approach has its benefits and its drawbacks. These approaches are

Image The lowest common denominator method

Image The customization method

Using the Lowest Common Denominator Method

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 for which you develop is the device configuration with the fewest features—basically, the most inferior device. Only requirements that can be met by all devices are included in the specification in order to reach the broadest range of devices—requirements such as input methods, screen resolution, and the platform version. With this method, you’ll often put a stake in the ground for a specific Android API level and then tailor your application further using Android manifest file settings and Google Play filters.

Image Note

The lowest common denominator method is roughly equivalent to developing a desktop application with these minimum system requirements—Windows 2000 and 128MB 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 with the lowest common denominator method. 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 for all devices. You can also easily add other devices 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 device-specific features, nor can it take advantage of new platform features. Also, if a device-specific problem arises or you misjudge the lowest common denominator and later find that an individual device 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.

Image Tip

The Android SDK makes it easy for developers to target multiple platform versions within a single application package. Developers should take care to identify target platforms early in the design phase. That said, over-the-air firmware updates to users do occur, so the platform version on a given device is likely to change over time. Always design your applications with forward compatibility in mind, and make contingency plans for distributing application upgrades to existing applications as necessary.

When using more modern SDK features, such as fragments or loaders, one of the easiest ways to get your application to support more devices is by using the Android Support Package and the support libraries. Using the support libraries will allow you to write your application following best practices such as supporting single-pane and multipane layouts, while allowing your application to also work on older devices that do not have built-in support for those modern SDK features. Increasing the market size for your application could be as simple as importing the support libraries into your application’s code, rather than importing the standard SDK libraries.

Using the Customization Method

Google Play provides management capabilities to implement a customized application for particular devices by leveraging multiple APK support. Multiple APK support allows you to create multiple APKs of your application, each of which targets a specific set of device configurations, or even a specific device. The different configurations that you are able to target are as follows:

Image Different API levels

Image Different GL textures

Image Different screen sizes

Image Any combination of different API levels, different GL textures, and/or different screen sizes

This customization method gives you complete control over how your application functions on a specific set of target devices, or even one particular device, if you desire to have that level of fine-grained control over the capabilities your application provides. Google Play allows developers to tie multiple APK files together under a single product name. This allows developers to create optimal packages that don’t contain a lot of resources not needed by every device. For example, a “small-screen package” wouldn’t need resources for tablets and televisions.

Image Tip

To learn more about how to implement and manage multiple APK support for your application, see the following URLs: http://d.android.com/training/multiple-apks/index.html and http://d.android.com/google/play/publishing/multiple-apks.html.

This method works well for specialized applications with a small number of target devices but does not scale easily from a build or product management perspective.

Generally, developers will come up with 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 device features, when they are available. The primary benefit of this technique is that users receive an application that leverages all the features their device (or API level) has to offer. 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 devices in the future.

For customization, you should also think about which screen sizes you will support. You may have an application that should work only on small screens, such as smartphones, or you may want to support only tablets or TVs. Regardless, you should provide screen-specific layouts, adding to your application manifest the types of screens your application supports for Google Play filtering, and packaging different drawable resource files.

Taking Advantage of the Best of Both Methods

In truth, mobile development teams usually use a hybrid approach, incorporating some aspects from both methods. It’s pretty common to see developers define classes of devices based on functionality. For example, a game application might group devices based on graphics performance, screen resolution, or input methods. A location-based service (LBS) application might group devices based on the available internal sensors. Other applications might develop one version for devices with built-in front-facing cameras and one version for those without. 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. In many cases, these features can be detected at runtime as well, but add enough of them together and the code paths can become overly complex when having two or more applications would actually be easier.

Image Tip

A single, unified version of an application is usually cheaper to support than multiple versions. However, a game might sell better with custom versions that leverage the distinct advantages and features of a specific class of devices. A vertical business application would likely benefit more from a unified approach that works the same, is easier to train users across multiple devices, and would thus have lower support costs for the business.

Developing Use Cases for Mobile Applications

You should first write use cases in general terms for the application before adapting them to specific device classes, which impose their own limitations. For example, a high-level use case for an application might be “Enter Form Data,” but the individual devices might use different input methods, such as hardware versus software keyboards, and so on. Following this approach allows you to chart application user flows independent of specific user interface components or user experience best practices most appropriate for a given device, form factor, or even platform. Considering that the most successful mobile applications these days need to have both Android and iOS versions, starting your use case development independent from the platform can help keep your app’s identity in parity, while still recognizing and embracing platform differences upon implementation.

Image Tip

Developing an application for multiple devices is much like developing an application for different operating systems and input devices (such as handling Mac keyboard shortcuts versus those on Windows)—you must account for subtle and not-so-subtle differences. These differences might be obvious, such as not having a keyboard for input, or not so obvious, such as device-specific bugs or different conventions for soft keys. See Chapter 14, “Designing Compatible Applications,” for a discussion of device compatibility.

Incorporating Third-Party Requirements and Recommendations

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

Image Android SDK License Agreement requirements

Image Google Play requirements (if applicable)

Image Google Cloud Messaging API License Agreement requirements (if applicable)

Image Other Google license requirements (if applicable)

Image Other third-party API requirements (if applicable)

Image Other application store requirements (if applicable)

Image Mobile carrier/operator requirements (if applicable)

Image Application certification requirements (if applicable)

Image Android design guidelines and recommendations (if applicable)

Image Other third-party design guidelines and recommendations (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 an afterthought, which can be risky.

Managing a Device Database

As your mobile development team builds applications for a growing number of devices, it becomes more and more important to keep track of your application’s target devices and related information for revenue estimation and maintenance purposes. Creating a device database is a great way to keep track of both marketing and device specification details for target devices. When we say database, we mean anything from a Microsoft Excel spreadsheet to a little SQL database. The point is that the information is shared across the team or company and kept up-to-date. It can also be helpful to break devices into classes, such as those that support OpenGL ES 2.0 or those without camera hardware.

Image Tip

Depending on the resources available to you, you may not be able to keep track of every single device you plan to target. In that case, you should instead keep track of the class of devices that you plan to target and gather and maintain statistics of common device characteristics rather than specific device characteristics.

The device database is best implemented early, when project requirements are just determined and target devices are determined. Figure 15.2 illustrates how you can track device information and how different members of the application development team can use it.

Image

Figure 15.2 How a development team uses the device database.

Image Tip

Readers have asked us for our take on using personal devices for testing purposes. Is it safe? Is it smart? The short answer is that you can use your personal device for testing safely in most cases. It’s highly unlikely that you will “break” or “brick” your device to the point where a factory reset won’t fix it. However, protecting your data is another problem entirely. For example, if your application acts on the Contacts database, your real contacts may be messed with, by bugs or other coding mistakes. Sometimes using personal devices is convenient, especially for small development teams without a big hardware budget. Make sure you understand the ramifications of doing so.

Determining Which Devices to Track

Some companies track only the devices they actively develop for, whereas others also track devices they might want to include in the future, or lower-priority devices. You can include devices in the database during the requirements phase of a project but also later as a change in project scope. You can also add devices as subsequent porting projects long after the initial application has been released.

Storing Device Data

You should design the device database to contain any information about a given device 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 carriers and manufacturers. Still, this information can be useful for all mobile projects at a company. This data should include the following:

Image Important device technical specification details (screen resolution, hardware details, supported media formats, input methods, and localization).

Image Any known issues with devices (bugs and important limitations).

Image Device carrier information (any firmware customizations, release and sunset dates, and expected user statistics, such as if a device is highly anticipated and expected to sell a lot, or is well received for vertical market applications, and so on).

Image API level data and firmware upgrade information. (As information becomes available, changes might have no impact on the application or warrant an entirely separate device entry; keep in mind that different carriers roll out upgrades on different schedules, so keeping track of this information at a too-fine-grained level may not be feasible.)

Image Actual testing device information (which devices have been purchased or loaned through manufacturer or carrier loaner programs, how many are available, and so on).

You can also cross-reference the device carrier information with sales figures from the carrier, application stores, and internal metrics. Your application’s ratings and reviews, as well as any crash reports by device, should also be documented.

The actual testing device information is often best implemented as a library checkout system. Team members can reserve devices for testing and development purposes. When a loaner device needs to be returned to the manufacturer, it’s easy to track. This also facilitates sharing devices across teams.

Using Device Data

Remember that the database can be used for multiple mobile development projects. Device resources can be shared, and sales statistics can be compared to see on which devices your applications perform best. Different team members (or roles) can use the device database in different ways:

Image Product designers use the database to develop the most appropriate application user interface for the target devices.

Image 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 devices.

Image Project managers use the database to determine the devices that must be acquired for development and testing purposes on the project and development priorities.

Image Software developers use the database to design and develop applications compatible with target device specifications.

Image QA personnel use the database to design and develop the target device specifications for test plans and to test the application thoroughly.

Image 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 device availability drops.

The information in the database can also help determine the most promising target devices for future development and porting. Android devices have built-in ways for users to report when your application crashes. When users report a crash, the information is sent to Google, and Google then presents it to you from within the Google Play Developer Console. Tracking this information will help you improve the quality of your applications over the long term.

Using Third-Party Device Databases

There are third-party databases for device 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 device database with only the devices they are interested in and the specific data they need for each device, which is often absent from open and free databases. WURFL (http://wurfl.sourceforge.net), for instance, is better for mobile Web development than for application development.

Assessing Project Risks

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 devices and continually reassessing application feasibility.

Identifying Target Devices

Just as most sane software developers wouldn’t write a desktop application without first deciding what operating systems (and their versions) the application would run on, mobile developers must consider the target devices their application will run on. Each device has different capabilities, a different user interface, and unique limitations.

Target devices are generally determined in one of two ways:

Image There’s a popular “killer” device you want to develop for.

Image You want to develop an application for maximum coverage.

In the first instance, you have your initial target device (or class of devices) figured out. In the second instance, you want to look at the available (and soon-to-be-available) devices on the market and adjust your application specifications to cover as many as is reasonably feasible.

Image Tip

On the Android platform, you normally do not target individual devices specifically, but device features or classes (for example, those running a specific platform version or having specific hardware configurations). You can limit the devices upon which your application will be installed using Android manifest tags, which act as market filters.

There may be instances when your application is targeting only a specific niche, such as Google TV or Google Glass. In this case, your application would probably not be useful for a smartphone or tablet; on the other hand, if your application is more general, such as a game, you should make every effort to determine the different targets and types of devices your application will work on, such as smartphones, phablets, tablets, and TVs.

Understanding How Manufacturers and Operators Fit In

It is also important to note that we’ve seen popular product lines, such as the Droid, Galaxy, One, Desire, EVO, or Optimus line of Android devices, customized by a number of manufacturers. A carrier often ships its custom version of a device, including a different user experience or skin, as well as big bundles of custom applications (taking up a bunch of space on the device). The carrier might also disable specific device features, which could effectively make it impossible for your application to run. You must take all these factors into account when considering your application requirements and capabilities. Your application’s running requirements must match the features shared across all target devices and handle optional feature use appropriately in all cases.

Understanding How Devices Come and Go over Time

New devices are developed all the time. Carriers and manufacturers retire (sunset) devices all the time. Different carriers might carry the same (or similar) device but might sunset (retire) the device at different times. A carrier may also release a particular device much sooner than other carriers, for various reasons.

Image Tip

Developers 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 device. This policy might need to be different for various carriers because carriers impose their own support requirements.

Developers need to understand how different kinds of device models can move through the worldwide marketplace. Some devices are available (or become popular) only in certain geographic regions. Sometimes devices are released worldwide, but often they are released regionally.

Historically, it has been common for a device (or new generation of devices) to become available initially in market-driving regions of eastern Asia, including South Korea and Japan, and then show up in Europe, North America, and Australia, where device users often upgrade every year or two and pay premium rates for applications. Finally, these same devices become available in Central and South America, China, and India, where subscribers often don’t have landlines or the same levels of income. Regions such as China and India must often be treated as entirely separate mobile marketplaces—with more affordable devices requiring vastly different revenue models. Here, applications sell for less, but revenue is instead derived from the huge and growing subscriber base.

Acquiring Target Devices

The earlier you can get your hands on the target devices, the better off you are. Sometimes this is as easy as going to the store and buying a new device.

It is quite common for an application developer to target upcoming devices—devices not yet shipping or available to consumers. There is a great competitive advantage to having your application ready to run the moment consumers have the device in their hands for the first time. For preproduction devices, you can join manufacturer and operator developer programs. These programs help you keep abreast of changes to the device lines (upcoming models, discontinued models). Many of these programs also include preproduction device loan programs, enabling developers to get their hands on the device before consumers do.

Image Tip

If you are just getting started acquiring Android devices, consider a Google Experience device, such as one of the Nexus handsets like the Nexus 4, 7, or 10. See http://www.google.com/nexus/ for more information.

There are risks for developers writing applications for specific preproduction devices because device shipment dates often slide and the platform might have unstable or bug-prone firmware. Devices are delayed or canceled. Device features (especially new and interesting ones) are not set in stone until the device ships and the developer verifies that those features work as expected. Exciting new devices are announced all the time—devices you might want your application to support. Your project plan must be flexible enough to change and adapt with the market as necessary.

Image Tip

Sometimes you don’t need to acquire specific devices to test with them. Various online services allow you to remotely install and test on real devices that are accessible and controllable through remote services. Most of these services have some sort of charge that must be weighed against the cost of actually owning the device outright.

Determining the Feasibility of Application Requirements

Mobile developers are at the mercy of the device limitations, which vary in terms of memory and processing power, screen type, and platform version. Mobile developers do not really have the luxury traditional desktop application developers have of saying an application requires “more memory” or “more space.” Device limitations are pretty much fixed, and if a mobile application is to run, it runs within the device’s limitations, or not at all. Technically speaking, most Android devices have some hardware flexibility, such as the ability to use external storage devices such as SD cards, but we’re still talking about limited resources.

You can do true feasibility assessment only on the physical device, not the software emulator. Your application might work beautifully in the emulator but falter on the actual device. Mobile developers must constantly revisit feasibility, application responsiveness, and performance throughout the development process.

Understanding Quality Assurance Risks

The QA team has its work cut out for it because the testing environment is generally less than ideal.

Testing Early, Testing Often

Get those target devices in hand as early as possible. For preproduction devices, it can take months to get the hardware in hand from the manufacturer. Cooperating with carrier device loaner programs and buying devices from retail locations is frustrating but sometimes necessary. Don’t wait until the last minute to gather the test hardware. We have seen many developers wonder why their applications run slow on certain older devices only to realize that testing on a fast development computer or brand-new device with a dedicated network connection is not the same as testing on the actual device.

Testing on the Device

It cannot be said enough: Testing on the emulator is helpful, but testing on the device is essential. In reality, it doesn’t matter if the application works on the emulator—no one uses an emulator in the real world.

Although you can perform factory resets on devices and wipe user data, there is often no easy way to completely “wipe” a device and return it to a clean starting state, so the QA team needs to determine and stick to a testing policy of what is considered a clean state on the device. Testers might need to learn to flash devices with different firmware versions and understand subtle differences between platform versions, as well as how underlying application data is stored on the device (for example, SQLite databases, private application files, and cache usage).

Mitigating the Risk of Limited Real-World Testing Opportunities

In some ways, every QA tester works within a controlled environment. This is doubly true for mobile testers. They often work with devices that are not on real networks and preproduction devices 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 device signal strength, availability of data services, LBS information, and locale information) is fixed. The QA 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 device 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. A variety of testing tools, some better suited to developers and white-box testers, are available to assist in application development. Some of the most suitable tools include Exerciser Monkey, monkeyrunner, and JUnit.

Testing Client/Server and Cloud-Friendly Applications

Make sure the QA team understands its responsibilities. Mobile applications often have network components and server-side functionality. Make sure thorough server and service testing is part of the test plan—not just the client portion of the solution that is implemented on the device. This might require the development of desktop or Web applications to exercise network portions of the overall solution.

Writing Essential Project Documentation

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 from good documentation, it serves a variety of purposes in mobile development. Consider documenting the following for your project:

Image Requirements analysis and prioritization

Image Risk assessment and management

Image Application architecture and design

Image Feasibility studies, including performance benchmarking

Image Technical specifications (overall, server, device-specific client)

Image Detailed user interface specifications (general, service specific)

Image Test plans, test scripts, test cases (general, device specific)

Image Scope change documentation

Much of this documentation is common in the 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 of cutting 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.

Developing Test Plans for Quality Assurance Purposes

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. Test plans need to provide complete coverage of the application user interface, yet be flexible enough to address higher-level user experience issues that may meet the requirements of the test plan but just aren’t positive experiences.

Understanding the Importance of User Interface Documentation

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. You must thoroughly document application workflow (application state) at the screen-by-screen level and can include detailed specifications for key usage patterns and how to gracefully fall back when certain keys or features are missing. You should clearly define usage cases in advance.

Leveraging Third-Party Testing Facilities

Some companies opt to have QA done offsite by a third party; most QA teams require detailed documentation, including use case workflow diagrams, to determine correct application behavior. If you do not provide adequate, detailed, and accurate documentation to the testing facility, you will not get deep, detailed, and accurate test results. 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.

Providing Documentation Required by Third Parties

If you are required to submit your application for review to a software certification program, or in some cases to a mobile application store, part of your submission is likely to be 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.

Providing Documentation for Maintenance and Porting

Mobile applications are often ported to additional devices and other mobile platforms. This porting work is frequently done by a third party, making the existence of thorough functional and technical specifications even more crucial.

Leveraging Configuration Management Systems

Many wonderful source control systems are out there for developers, and most that work well for traditional development work fine for a mobile project. Versioning your application, on the other hand, is not necessarily as straightforward as you might think.

Choosing a Source Control System

Mobile development considerations impose no surprise requirements for source control systems. Some considerations for developers evaluating how to handle configuration management for a mobile project are

Image Ability to keep track of source code (Java) and binaries (Android packages and so on)

Image Ability to keep track of application resources by device configuration (graphics and so on)

Image Integration with the developer’s chosen development environment (the Android IDE, Android Studio, or Eclipse)

One point to consider is integration between the development environment (such as the Android IDE) and your source control system. Common source control systems, such as Subversion, CVS, Git, and Mercurial, work well with Eclipse and Android Studio. Git source control is integrated with the Android IDE as the default source control software. Check to see if your favorite source control system works with your chosen Android development environment.

Implementing an Application Version System That Works

Developers should also make an early decision on a versioning scheme that takes into account the device 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 device configuration or device class supported (Version 1.0.1.Important Characteristic/Device Class Name). This helps QA, technical support personnel, and end users who might not know the model names or features of their devices or know them only by marketing names developers are often unaware of. For example, an application developed with camera support might be versioned 1.0.1.Cam, where Cam stands for “Camera Support,” whereas the same application for a device without camera support might have a version such as 1.0.1.NoCam, where NoCam stands for the “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 whom to assign bug fixes.

Just to make things a tad more confusing, you need to plan your upgrade versions as well. If an upgrade spawns a rebuild of your application, you might want to version it appropriately: Version 1.0.1.NoCam.Upg1, and such. Yes, this can get out of control, so don’t go overboard, but if you design your versioning system intelligently up front, it can be useful later when you have different device builds floating around internally and with users. Finally, you also have to keep track of the versionCode attribute associated with your application.

Also, be aware of what distribution methods support multiple application packages or binaries as the same application and which require each binary to be managed independently. There are several good reasons not to have all of your code and resources in a single binary. Application package size, for example, can get large and unmanageable when the application attempts to support multiple device resolutions using alternative resources.

Designing Mobile Applications

When designing an application for mobile, the developer must consider the constraints the device imposes and decide what type of application framework is best for a given project.

Understanding Mobile Device Limitations

Applications are expected to be fast, responsive, and stable, but developers must work with limited resources. You must keep in mind the memory and processing power constraints of all target devices when designing and developing mobile applications.

Exploring Common Mobile Application Architectures

Mobile applications have traditionally come in two basic models: standalone applications and network-driven applications.

Standalone applications are packaged with everything they require and rely on the device to do all the heavy lifting. All processing is done locally, in memory, and is subject to the limitations of the device. Standalone applications might use network functions, but they do not rely on them for core application functionality. An example of a reasonable standalone application is a basic Solitaire game. A user can play the game when the device is in airplane mode without issue.

Network-driven applications provide a lightweight client on the device but rely on the network (or the cloud) to provide a good portion of their content and functionality. Network-driven applications are often used to offload intensive processing to a server. They also benefit from the ability to deliver additional content or functionality on the fly, long after the application has been installed. Developers also like network-driven applications because this architecture enables them to build one smart application server or cloud service with device clients for many different operating systems to support a larger audience of users. Good examples of network-driven applications include

Image Applications that leverage cloud-based services, application servers, or Web services

Image Customizable content such as ringtone and wallpaper applications

Image Applications with noncritical process- and memory-intensive operations that can be offloaded to a powerful server and the results delivered back to the client

Image 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). If your application is truly network based, such as a Web app, and does not need access to any device-specific features, you may not even need to build a native application with an installable APK. In that case, you may prefer to have users access your application through a browser.

Designing for Extensibility and Maintenance

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 standalone version, partially network driven, or completely network driven. Regardless, your application has two required functions:

Image Display a set of images and allow the user to choose one.

Image Take the chosen image and set it as the wallpaper on the device.

A super-simple standalone wallpaper application might come with a fixed set of wallpapers. If they’re a generic size for all target devices, you might need to reformat them for the specific device. 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 enable 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 device. As the developer, you can add new wallpaper images to the server anytime, but you need to build a new application every time you want to add a new device configuration or screen size. If you want to change the menu to add live wallpapers at a later date, you need to write a new version of your application. This application design is feasible, but it isn’t using its resources wisely either and isn’t particularly extensible. However, you could use the single application server and write applications for Android, iPhone, Windows RT, BREW, J2ME, and BlackBerry 10 clients, so you are still in a better position than you were with the standalone wallpaper application.

The fully network-driven version of the wallpaper application does the bare minimum on the device. The client enables the server to dictate what the client user interface looks like, what menus to display, and where to display them. The user browses the images from the application server just as with the partially network-driven version, but when the user chooses a wallpaper, the mobile application just sends a request to the server: “I want this wallpaper and I am this kind or type of device, with such-and-such screen resolution.” The server formats and resizes the image (any process-intensive operations) and sends the perfectly tailored wallpaper down to the application, which the application then sets as the wallpaper. Adding support for more devices is straightforward—simply deploy the lightweight client with any necessary changes and add support for that device configuration to the server. Adding a new menu item is just a server change, resulting in all devices (or whichever devices the server dictates) getting that new category. You need to update the client only when a new function requires the client to change, such as to add support for live wallpapers. The response time of this application depends on network performance, but the application is the most extensible and dynamic. However, this application is basically useless when the device is in airplane mode.

Standalone applications are straightforward. This approach is great for one-shot 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 and provide users with fresh content and features for the long run.

Designing for Application Interoperability

Mobile application designers should consider how they will interface with other applications on the device, including other applications written by the same developer. Here are some issues to address:

Image Will your application rely on other content providers?

Image Are these content providers guaranteed to be installed on the device?

Image Will your application act as a content provider? What data will it provide?

Image Will your application have background features? Act as a service?

Image Will your application rely on third-party services or optional components?

Image Will your application use publicly documented Intent mechanisms to access third-party functionality? Will your application provide the same?

Image How will your application user experience suffer when optional components are not available?

Image Will your application require substantial device resources such as battery life? Will it play nice?

Image Will your application expose its functionality through a remote interface such as Android Interface Definition Language (AIDL)?

Developing Mobile Applications

Mobile application implementation follows the same principles as other platforms. The steps mobile developers take during implementation are fairly straightforward:

Image Write and compile the code.

Image Run the application in the software emulator.

Image Test and debug the application in the software emulator or test device.

Image Package and deploy the application to the target devices.

Image Test and debug the application on the target devices.

Image Incorporate changes from the team and repeat until the application is complete.

Image Note

We talk more about development strategies for building solid Android applications in Chapter 16, “Designing and Developing Bulletproof Android Applications.”

Testing Mobile Applications

Testers face many challenges, including device fragmentation (many devices, each with different features—some call this “compatibility”), defining device states (what is a clean state?), and handling real-world events (device calls, loss of coverage). Gathering the devices needed for testing can be costly and difficult.

The good news for mobile QA teams is that the Android SDK includes a number of useful tools for testing applications on both the emulator and the device. There are many opportunities for leveraging white-box testing.

You must modify defect-tracking systems to handle testing across device 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. Mobile QA involves a lot of edge case testing. Again, a preproduction model of a device might not be exactly the same as what eventually ships to consumers.

Image Note

We discuss testing Android applications in detail in Chapter 18, “Testing Android Applications.”

Controlling the Test Release

In some situations, you may wish to take complete control of to whom your application will be released for testing. Rather than making your application available to the entire world all at once, releasing your application on a smaller scale may be the ideal test plan. Here are the common ways for controlling the test release of an application:

Image Private controlled testing: In this situation, developers invite users to a controlled setting, such as an office. They observe users interacting with the application, and then make changes based on feedback from those test users. The developers then implement any updates, invite more testers to interact with the application, and so on, until the design receives positive feedback. Only then would they release the application to more users. Private testing usually involves not allowing the application to leave the facilities on a test user’s device; sometimes you may even want to provide your own testing device to ensure that the application never leaves your facilities.

Image Private group testing: In this situation, developers prove their APK file to a very small set of test users, and then collect feedback in a manner suitable for the situation. They then use the feedback to make the necessary changes, rerelease the APK to the same test users, or new test users, and continue receiving feedback and updating accordingly, until they begin receiving positive responses from users. The application is usually not on a strict lockdown policy, such as never leaving the building, but rather has a more limited but semi-open test distribution. One new feature of Google Play that may help you facilitate this type of test release is a Private Channel Release. If you have a Google Apps domain, you can launch your application in a controlled and private way to users of your particular domain.

Image Google Play Staged Rollouts: Google Play provides many new features for controlling to whom your application is released. Using these facilities may ease how you test your application with real users. Staged Rollouts is a new feature of Google Play that allows you to offer your application to alpha and beta test groups for collecting early feedback, prior to releasing your application to all Google Play users.

Deploying Mobile Applications

Developers need to determine what methods they use to distribute applications. With Android, you have a number of options. You can market applications yourself and leverage marketplaces such as Google Play. Consolidated mobile marketplaces, such as Handango, also have Android distribution channels of which you can take advantage.

Image Note

We discuss publication of Android applications in detail in Chapter 19, “Publishing Your Android Application.”

Determining Target Markets

Developers must take into account any requirements imposed by third parties offering application distribution mechanisms. Specific distributors might impose rules for what types of applications they distribute on your behalf. They might impose quality requirements such as testing certifications (although none specific to Android applications existed at the time this book went to print) and accompanying technical support, documentation and adherence to common user interface workflow standards, and performance metrics for responsive applications. Distributors might also impose content restrictions such as barring objectionable content.

Image Tip

The most popular distribution channels for Android applications have been changing over time. Google Play remains the first stop in Android app publication, but both the Amazon Appstore and Facebook App Center have become effective hubs for Android app distribution. Other app stores are also available; some cater to special user groups and niche application genres, whereas others distribute for many different platforms.

Supporting and Maintaining Mobile Applications

Developers cannot just develop an application, publish it, and forget about it—even the simplest of applications likely requires some maintenance and the occasional upgrade. 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 device numbers and such. In fact, the bulk of application maintenance can fall on the server side and be limited to content maintenance—for example, posting new media such as ringtones, wallpapers, videos, or other content. This may not seem obvious at first. After all, you’ve provided your email address and website when the user downloaded your application, right? Although that may be the case, your average user still calls the company on the bill first (in other words, the carrier) for support if the device is not functioning properly.

That said, the device firmware 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.

Track and Address Crashes Reported by Users

Google Play—the most popular way to distribute Android applications—has built-in features enabling users to submit crash and bug reports regarding an application. Monitor your developer account and address these issues in a timely fashion in order to maintain your credibility and keep your users happy.

Testing Firmware Upgrades

Android handsets receive frequent (some say too frequent) firmware upgrades. This means that the Android platform versions you initially tested and supported become obsolete and the handsets on which your application is installed can suddenly run new versions of the Android firmware. Although upgrades are supposed to be backward compatible, this hasn’t always proven true. In fact, many developers have fallen victim to poor upgrade scenarios, in which their applications suddenly cease to function properly. Always retest your applications after a major or minor firmware upgrade occurs in the field.

Maintaining Adequate Application Documentation

Maintenance is often not performed by the same engineers who developed the application in the first place. Here, keeping adequate development and testing documentation, including specifications and test scripts, is even more vital.

Managing Live Server Changes

Always treat any live server and Web or cloud service with the care it deserves. This means you need to appropriately time your backups and upgrades. You need to safeguard data and maintain user privacy at all times. You should manage rollouts carefully because live mobile application users might rely on the app’s availability. Do not underestimate the server-side development or testing needs. Always test server rollouts and service upgrades in a safe testing environment before “going live.”

Identifying Low-Risk Porting Opportunities

If you’ve implemented the device database we talked about previously in the chapter, now is the ideal time to analyze device similarities to identify easy porting projects. For example, you might discover that an application was originally developed for a specific class of device, but now several popular devices are on the market with similar specifications. Porting an existing application to these new devices is sometimes as straightforward as generating a new build (with appropriate versioning) and testing the application on the new devices. If you defined your device classes well, you might even get lucky and not have to make any changes at all when new devices come out.

Application Feature Selection

When determining what features your application will support, make sure to think about the costs versus the benefits of supporting a particular feature. Adding new features is always the easy part, but removing them from your application is not. Once users become accustomed to a feature, if that feature goes missing, your users may never use your application again. They may even go as far as writing a negative review and giving your app an extremely low rating. Always make sure that a particular feature is of use to the users of your application, rather than just cluttering a user interface with things for users to do, only to realize that you should not have added a given feature in the first place.

Summary

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 for adapting traditional software processes to mobile—from identifying target devices to testing and deploying your application to the world. There’s always room for improvement when it comes to software processes. Ideally, some of these insights can help you to avoid the pitfalls new mobile companies sometimes fall into or simply to improve the processes of veteran teams.

Quiz Questions

1. True or false: The waterfall software methodology is preferable to the iteration and rapid prototyping approach for Android development.

2. What are the approaches the authors have found helpful for determining project requirements?

3. When is the best time to implement a device database?

4. True or false: Since the Android emulator has been made available, testing on real devices is not essential.

5. What are the steps mobile developers take during implementation?

Exercises

1. Come up with an idea for an application, then determine and explain the best approach to take for determining project requirements.

2. Create a list of requirements for the application idea you came up with in the previous exercise.

3. Identify the target devices for the application idea that you came up with in the first exercise, and create a simple device database outlining the important features that are relevant to your application idea.

References and More Information

Wikipedia on the software development process:

http://en.wikipedia.org/wiki/Software_development_process

Wikipedia on the waterfall development process:

http://en.wikipedia.org/wiki/Waterfall_model

Wikipedia on rapid application development (RAD):

http://en.wikipedia.org/wiki/Rapid_application_development

Wikipedia on iterative and incremental development:

http://en.wikipedia.org/wiki/Iterative_and_incremental_development

Extreme Programming:

http://www.extremeprogramming.org

Android Training: “Designing for Multiple Screens”:

http://d.android.com/training/multiscreen/index.html

Android Training: “Creating Backward-Compatible UIs”:

http://d.android.com/training/backward-compatible-ui/index.html

Android API Guides: “Supporting Multiple Screens”:

http://d.android.com/guide/practices/screens_support.html

Android API Guides: “Supporting Tablets and Handsets”:

http://d.android.com/guide/practices/tablets-and-handsets.html

Android Google Services: “Filters on Google Play”:

http://d.android.com/google/play/filters.html