Requirements analyses for mobile applications can be more complex than that of traditional desktop applications. 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 makes 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), here are two approaches we have found to be helpful for determining project requirements:
- The lowest common denominator method
- 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 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.
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.
Using the customization method, the application is tailored for specific devices or a class of devices (such as all devices capable of OpenGL ES 2.0, for example).This method works well for specialized applications with a small number of target devices 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 device 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 devices 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 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.
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.
Incorporating Third-Party Requirements
In addition to the requirements imposed by your internal requirements analyses, your team needs to incorporate any requirements imposed by others. Third-party requirements can come from any number of sources, including
- Android License Agreement Requirements
- Google Maps API License Agreement Requirements (if applicable)
- Third-Party API Requirements (if applicable)
- Android Market Requirements (if applicable)
- Mobile Carrier/Operator Requirements (if applicable)
- Other Application Store Requirements (if applicable)
- Application Certification Requirements (if applicable)
Incorporating these requirements into your project plan early is essential not only for keeping your project on schedule but also so that these requirements are built into the application from the ground up, as opposed to applied as afterthoughts that can be risky.
Managing a 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 the target device 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.
The device database is best implemented early, when project requirements are just determined and target devices are determined. The following figure illustrates how you can track device information and how different members of the application development team can use it.
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 carrier and manufacturers. Still, this information can be useful for all mobile projects at a company. This data should include
- Important device technical specification details (screen resolution, hardware details, supported media formats, input methods, localization)
- Any known issues with devices (bugs and important limitations)
- Device carrier information (any firmware customizations, release and sunset dates, expected user statistics, such as if a device 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 device entry)
- Actual testing device information (which devices have been purchased or loaned through manufacturer or carrier loaner programs, how many are available)
You can also cross-reference the device carrier information with sales figures from the carrier, application store, and internal metrics.
The actual testing device information is often best implemented as a library check-out 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.
How a development team uses the device database.
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 upon which devices your applications perform best. Different team members (or roles) can use the device database in different ways:
- Product designers use the database to develop the most appropriate application user interface for the target devices.
- 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.
- Project managers use the database to determine the devices 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 device specifications.
- Quality assurance personnel use the database to design and develop test plans’ target 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 device availability drops.
The information in the database can also help determine the most promising target devices for future development and porting.
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.