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:
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
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
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:
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.
Setting Up Your Android Development Environment
Writing Your First Android Application
Understanding The Anatomy Of An Android Application
Defining Your Application Using The Android Manifest File
Managing Application Resources
Exploring User Interface Screen Elements
Designing User Interfaces With Layouts
Drawing And Working With Animation
Using Android Data And Storage Apis
Sharing Data Between Applications With Content Providers
Using Android Networking Apis
Using Android Web Apis
Using Location-based Services (lbs) Apis
Using Android Multimedia Apis
Using Android Telephony Apis
Using Android 3d Graphics With Opengl Es
Using The Android Ndk
Using Android’s Optional Hardware Apis
Working With Notifications
Working With Services
Extending Android Application Reach
Managing User Accounts And Synchronizing User Data
Handling Advanced User Input
Targeting Different Device Configurations And Languages
The Mobile Software Development Process
Designing And Developing Bulletproof Android Applications
Testing Android Applications
Selling Your Android Application
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.