20. Delivering Quality Applications
In this chapter, we cover tips and techniques from our years in the trenches of mobile software design and development. We also warn you—the designers, developers, and managers of mobile applications—of the various and sundry pitfalls you should do your best to avoid. Reading this chapter all at one time when you’re new to Android development might be a bit overwhelming. Instead, consider reading specific sections when planning the parts of the overall design process. Some of our advice might not be appropriate for your particular project, and processes can always be improved. Ideally, this information about how Android development projects succeed (or fail) will give you some insight into how you might improve the chances of success for your own projects.
Best Practices in Delivering Quality Applications
The “rules” of Android application design are straightforward and apply across all device platforms. These rules were crafted to remind us that our applications often play a secondary role on the device. Many Android devices are, at the end of the day, smartphones. These rules also make it clear that we do operate, to some extent, because of the infrastructure managed by the carriers and device manufacturers. These rules are echoed throughout the Android SDK License Agreement and third-party application marketplace terms and conditions.
The “rules” are as follows:
Don’t abuse the user’s trust.
Don’t interfere with device telephony and messaging services (if applicable).
Don’t break or otherwise tamper with or exploit the device hardware, firmware, software, or OEM components.
Don’t abuse or cause problems on operator networks (if applicable).
Now, perhaps these rules sound like no-brainers, but even the most well-intentioned developers can accidentally break them if they aren’t careful and don’t test their applications thoroughly before distribution. This is especially true for applications that leverage networking support and low-level hardware APIs on the device, as well as for those that store private user data such as names, locations, and contact information.
Meeting Android Users’ Demands
Android users also have their own set of demands for applications they install on their devices. Applications are expected to
“Enchant me,” “simplify my life,” and “make me amazing” (from the Android design documentation found here: http://d.android.com/design/get-started/creative-vision.html)
Have straightforward, intuitive user interfaces that are easy to get up and running
Get the job done with minimal frustration to the user (provide visual feedback and follow common Android design patterns) and minimal impact on device performance (battery usage, network and data usage, and so on)
Be available 24 hours a day, 7 days a week (remote servers or services that are always on, always available, and not running in someone’s closet)
Include a Help and/or About screen for feedback and support contact information
Honor private user information and treat it with care
Designing User Interfaces for Android Devices
Designing effective user interfaces for Android devices, especially for applications that run on a number of different devices and form factors, is something of a black art. We’ve all seen bad Android application user interfaces. A frustrating user experience can turn a user off your brand while a good experience can win a user’s loyalty. Great experiences give your application an edge over the competition, even if your functionality is similar. An elegant, well-designed user interface can win over users even when the application functionality is behind that of the competition. Said another way, doing something really well is more important than cramming too many features into an app and doing them badly.
Here are some tips for designing great Android user interfaces:
Fill screens sparingly; too much information on one screen overwhelms the user.
Be consistent with user interface workflows, menu types, and buttons. Also, consider making the user interface consistent with Android and Material Design patterns.
Design your applications using fragments, even if you aren’t targeting devices larger than a smartphone. (The Android Support Package makes this possible for nearly all target versions.)
Make touch target sizes (“hit areas”) large enough (48dp) and space them appropriately (8dp).
Streamline common use cases with clear, consistent, and straightforward interfaces.
Use big, readable fonts and large icons.
Integrate tightly with other applications on the system using standardized controls, such as the QuickContactBadge, content providers, and search adapters.
Keep localization in mind when designing text-heavy user interfaces. Some languages are lengthier than others.
As much as possible, reduce the number of keys or clicks needed.
Do not assume that specific input mechanisms (such as specific buttons or keys) are available on all devices.
Try to design the default use case of each screen to require only the user’s thumb or index finger. Special cases might require other buttons or input methods, but encourage “thumbing” by default.
Size resources such as graphics appropriately for target devices. Do not include oversize resources and assets because they bulk up your application package, load more slowly, and are generally less efficient.
In terms of “friendly” user interfaces, assume that users do not read the application permissions when they approve them to install your application. If your application does anything that could cause users to incur significant fees or it shares private information, consider informing users again (as appropriate) when your application performs such actions. Basically, take a “no surprises” approach, even if the permissions and your privacy policy also state the same thing.
Note
We discussed how to design Android applications that are compatible with a wide range of devices, including how to develop for different screen sizes and resolutions, in Chapter 13, “Designing Compatible Applications.” We also discussed designing for the user experience in Chapter 19, “Planning the Experience.”
Designing Stable and Responsive Android Applications
Android device hardware has come a long way in the past few years, but developers must still work with limited resources. Users do not usually have the luxury of upgrading the RAM and other hardware in Android devices. Android users may, however, take advantage of removable storage devices such as SD cards to provide some extra space for application and media storage, but some manufacturers use only built-in storage devices, preventing removable storage as an option. Spending some time up front to design a stable and responsive application is important for the success of the project. The following are some tips for designing robust and responsive Android applications:
Don’t perform resource-intensive or lengthy operations on the main UI thread. Always use asynchronous tasks, threads, or background services to offload blocking operations.
Use efficient data structures and algorithms; these choices manifest themselves in app responsiveness and happy users.
Use recursion with care; these functional areas should be code reviewed and performance tested.
Keep application state at all times. The Android Activity back stack makes this work well, but you should take extra care to go above and beyond.
Save your state using appropriate lifecycle callbacks, and assume that your application will be suspended or stopped at any moment. If your application is suspended or closed, you cannot expect a user to verify anything (click a button and so on). If your application resumes gracefully, your users will be grateful.
Start up fast and resume fast. You cannot afford to have the user twiddling thumbs waiting for your application to start. Instead, you need to strike a delicate balance between preloading and on-demand data because your application might be suspended (or closed) with no notice.
During long operations, keep users informed by using progress bars. Consider offloading heavy processing to a server instead of performing these operations on the device because they might drain battery life beyond the limits users are willing to accept.
Ensure that long operations are likely to succeed before embarking on them. For example, if your application downloads large files, check for network connectivity, file size, and available space before attempting the download.
Minimize the use of local storage because most devices have very limited amounts. Use external storage only when appropriate because some devices do not have external storage available. Be aware that SD cards (the most common external storage option) can be ejected and swapped; your application should handle this gracefully.
Understand that data calls to content providers and across the AIDL barrier come at a cost to performance, so make these calls judiciously.
Verify that your application resource consumption model matches your target audience. Gamers might anticipate shorter battery life on graphics-intensive games, but productivity or fitness applications should not drain the battery unnecessarily and should be lightweight for people “on the go” who do not always have their device charging.
Tip
Written by the Google Android team, the Android Developers Blog (http://android-developers.blogspot.com) is a fantastic resource. This blog provides detailed insight into the Android platform, often covering topics not discussed in the Android platform documentation. Here, you can find tips, tricks, best practices, and shortcuts on relevant Android development topics. Savvy Android developers visit this blog regularly and incorporate these practices and tips into their projects. Keep in mind that Google’s Android Developer guys and gals are often focused on educating the rest of us about the latest API-level features; their techniques and advice may not always be suitable for implementation with older target platforms.
Designing Secure Android Applications
Many Android applications integrate with core applications such as the Phone, Camera, Location-Based Services, and Contacts. Make sure you take all the precautions necessary to secure and protect private user data such as names, locations, and contact information used by your application. This includes safeguarding personal user data on application servers and during network transmission.
Tip
If your application accesses, uses, or transmits private data, especially usernames, passwords, or contact information, it’s a good idea to include an End User License Agreement (EULA) and a privacy policy with your application. Also keep in mind that privacy laws vary by country.
Handling Private Data
To begin with, limit the private or sensitive data your application stores as much as possible. Don’t store this information in plain text, and don’t transmit it over the network without safeguards. Do not try to work around any security mechanisms imposed by the Android framework. Store private user data in private application files, which are private to the application, and not in shared parts of the operating system. Do not expose application data in content providers without enforcing appropriate permissions on other applications. Use the encryption classes available in the Android framework when necessary. Consider using SQLCipher, an encrypted version of SQLite, where appropriate. SQLCipher is not built into Android, but you may download and configure this for inclusion in your application. To learn more about SQLCipher, see https://guardianproject.info/code/sqlcipher.
Transmitting Private Data
The same cautions about handling private data should apply to any remote network data storage (such as application servers or cloud storage) and network transmission. Make sure any servers or services that your application relies on are properly secured against identity or data theft and invasion of privacy. Treat any servers your application uses like any other part of the application: test these areas thoroughly. Any private data transmitted should be secured using typical security mechanisms such as SSL. The same rules apply when enabling your application for backups using services such as Android Backup Service or Auto Backup for Apps.
Designing Android Applications for Maximum Profit
For billing and revenue generation, Android applications generally fall into one or more of the following categories:
Free applications (including those with advertising revenue)
Single payment (pay once)
In-app products (pay for specific content, such as a wallpapers, a Sword of Smiting, or a new level pack)
Subscription billing (payments recurring on a schedule, often seen with productivity and service applications)
Outside billing and membership supplementation (access to content such as premium TV for current paying subscribers)
Applications can use multiple types of billing, depending on which marketplaces and billing APIs they use. No specific billing APIs are built into the Android framework. With Android in general, third parties can provide billing methods or APIs, so technically the sky’s the limit. There is an optional Google Play In-app Billing API add-on for use with Google Play (and only Google Play). Google Play provides support for accepting various payment methods for Google Play, including credit cards, PayPal, direct carrier billing, gift cards, and Google Play balance values.
When designing your Android applications, consider the functional areas where billing can come into play and factor this into your design. Consider the transactional integrity of specific workflow areas of the application for which the user can be charged. For example, if your application has the capability to deliver data to the device, make sure this process is transactional in nature so that if you decide to charge for this feature, you can drop in the billing code, and when the user pays, the delivery occurs or the entire transaction is rolled back.
Note
You will learn more about the different methods currently available to market your application in Chapter 22, “Distributing Your Applications.”
Following the Android Application Quality Guidelines
Users’ expectations of application quality rise with every new iteration of Android. Luckily, Google has invested a great deal of effort researching what a quality application is like, its employees have designed quite a few quality applications themselves, and the best part is that they have designed a set of standards that you can use to measure your application’s quality.
There are six quality guidelines recommended in the Android documentation that you should seriously consider:
Core app quality: Core app quality guidelines are the most basic standards that all of your applications should follow, and they should also be validated on each and every device that you plan on targeting. The core app quality guidelines include criteria for how to assess your application’s visual design and user interaction, criteria for functional behavior, criteria for stability and performance criteria, and criteria for Google Play promotions. The guidelines also provide a sort of step-by-step procedural approach to testing your application to determine if it meets these recommended criteria. You can learn more about how to meet the core app quality guidelines here: http://d.android.com/distribute/essentials/quality/core.html.
Tablet app quality: If you are building an application for tablets, you still need to make sure that you meet the core app quality criteria. In addition, Google provides an additional set of quality criteria for developers writing applications for tablets. You can learn more about the guidelines for tablet app quality here: http://d.android.com/distribute/googleplay/quality/tablet.html.
Wear app quality: If you are building an application for Wear, there are different quality considerations you need to be aware of, but you should familiarize yourself with the core app quality criteria first. Wear apps have a minimum set of requirements to meet before they are made available in Google Play. You can learn more about how to meet the quality guidelines for Wear here: http://d.android.com/distribute/essentials/quality/wear.html.
TV app quality: If you are building an application for TV, in addition to following the core app quality guidelines, you also aim to meet all of the TV app quality criteria. TV apps have a minimum set of requirements to meet before they are made available in Google Play. You can learn more about the TV app quality guidelines here: http://d.android.com/distribute/essentials/quality/tv.html.
Auto app quality: If you are building an application for Android Auto, you need to meet the core app quality criteria before moving onto meeting the Auto app quality guidelines. Auto apps have a minimum set of requirements to meet before they are made available in Google Play. You can learn more about the Auto app quality guidelines here: http://d.android.com/distribute/essentials/quality/auto.html.
Education guidelines: If you are building an Educational app, you need to meet the core criteria and basic educational requirements. In addition to app quality and these basic requirements, you must also meet strict educational value parameters. Education apps have a minimum set of requirements to meet before they are made available in Google Play. You can learn more about the educational quality guidelines here: https://developers.google.com/edu/guidelines.
Even if your application meets the criteria and recommendations for creating a quality application, your efforts should not end there. User demand and application competition are setting the bar for quality higher and higher. To keep up with demand and to outshine your competition, the Android documentation provides a set of strategies that you can begin thinking about and implementing in your application quality analysis. To learn more about the strategies for continuously optimizing your application’s quality, visit
http://developer.android.com/distribute/essentials/optimizing-your-app.html.
Unless you are building a Wear, TV, Auto, or Education application, there are no requirements that your application actually adheres to these quality guidelines to be made available in Google Play, but if you would like your application to achieve success, these guidelines are where to begin focusing your efforts. For applications that require meeting a minimum set of standards, make sure you follow the suggested guidelines. In addition, Google provides many tools and resources useful for helping you meet these criteria in your application. You can learn more about those features here: http://d.android.com/distribute/essentials/index.html#tools.
Leveraging Third-Party Quality Standards
Android marketplaces other than Google Play may implement and impose their own quality requirements, and certainly programs have been created with some recognized body’s endorsement or stamp of approval. The Amazon Appstore for Android puts apps through some testing before they are made available for sale.
Warning
With Android, the market is expected to manage itself to a greater extent than in some other platform markets. Do not make the mistake of interpreting that as “no rules” when it really means “few rules imposed by the system.” Strong licensing terms are in place to keep malware and other malicious code out of users’ hands, and applications do indeed get removed for misbehavior, just as they do when they sneak through onto other platform markets.
Designing Android Applications for Ease of Maintenance and Upgrades
Generally speaking, it’s best to make as few assumptions about the device configurations as possible when developing an Android application. You’ll be rewarded later when you want to port your application or provide an easy upgrade. You should carefully consider what assumptions you make.
Leveraging Application Diagnostics
In addition to adequate documentation and easy-to-decipher code, you can leverage some tricks to help maintain and monitor Android applications in the field. Building lightweight auditing, logging, and reporting into your application can be highly useful for generating your own statistics and analytics. Relying on third-party information, such as that generated with market reports, could cause you to miss some key pieces of data that are useful to you. For example, you can easily keep track of
How many users install the application
How many users launch the application for the first time
How many users regularly use the application
What the most popular usage patterns and trends are
What the least popular usage patterns and features are
What devices (determined by application versioning or other relevant metrics) are the most popular
Often, you can translate these figures into rough estimates of expected sales, which you can later compare with actual sales figures from third-party marketplaces. You can streamline and, for example, make the most popular usage patterns the most visible and efficient in terms of user experience design. Sometimes you can even identify potential bugs, such as features that are not working at all, just by noting that a feature has never been used in the field. Finally, you can determine which device targets are most appropriate for your specific application and user base.
You can gather interesting information about your application from numerous sources, including the following:
Google Play sales statistics, ratings, and bug/crash reports, as well as those available on other distribution channels.
Application integration with statistics-gathering APIs such as Google Analytics or other third-party application monitoring services.
For applications relying on network servers, quite a lot of information can be determined by looking at server-side statistics.
Feedback sent directly to you, the developer, through email, user reviews, or other mechanisms made available to your users.
Tip
Never collect personal data without the user’s knowledge and consent. Gathering anonymous diagnostics is fairly commonplace, but avoid keeping any data that can be considered private. Make sure your sample sizes are large enough to obfuscate any personal user details, and make sure to factor out any live QA testing data from your results (especially when considering sales figures).
Designing for Easy Updates and Upgrades
Android applications can easily be upgraded in the field. The application update and upgrade processes do pose some challenges to developers, though. When we say updating, we mean modifying the Android manifest version information and redeploying the updated application on users’ devices. When we say upgrading, we mean creating an entirely new application package with new features and deploying it as a separate application that the user must choose to install and that does not replace the old application.
From an update perspective, you need to consider what conditions necessitate an update in the field. For example, do you draw the line at crashes or at feature requests? You also want to consider the frequency with which you deploy updates—you need to schedule updates so that they come up frequently enough to be truly useful, but not so often that users are constantly updating their application.
Tip
You should build application content updates into the application functionality as a feature (often network driven) as opposed to necessitating an over-the-air actual application update. By enabling your applications to retrieve fresh content on the fly, you keep your users happy longer and applications stay relevant.
When considering upgrades, decide the manner in which you will migrate users from one version of your application to the next. Will you leverage the Android Backup Service features so that your users can transition seamlessly from one device to the next, or will you provide your own backup solution? Consider how you will inform users of existing applications that a major new version is available.
Tip
Google provides a service known as the Android Backup Service that allows developers to make user application data persistent in the cloud for easy restoration. This service is used for storing application data and settings and is not meant to be a database back end for your application. To learn more about the Android Backup Service, see http://d.android.com/google/backup/index.html.
Leveraging Android Tools for Application Design
The Android SDK and developer community provide a number of useful tools and resources for application design. You might want to leverage the following tools during this phase of your development project:
The Android Studio Layout Editor is a good place to start for rapid proof of concept. You can find more about the Layout Editor here: http://d.android.com/sdk/installing/studio-layout.html.
Use the Android emulator before you have specific devices. You can use different AVD configurations to simulate different device configurations and platform versions.
The Android Device Monitor tool is very useful for memory profiling.
The Hierarchy Viewer in Pixel Perfect mode enables accurate user interface design. Along with lint, it can also be used to optimize your layout designs.
The Draw Nine-Patch tool can create stretchable graphics for mobile use.
The uiautomatorviewer tool can help you determine how your user interface is actually structured.
Real devices are your most important tool. Use real devices for feasibility research and application proof-of-concept work whenever possible. Do not design solely using the emulator. The Developer Options within the Settings application are useful tools for developing and debugging on actual hardware.
The technical specifications for specific devices, often available from manufacturers and carriers, can be invaluable for determining the configuration details of target devices.
Avoiding Silly Mistakes in Android Application Design
Last but not least, here is a list of some of the silly mistakes Android designers should do their best to avoid:
Designing or developing for months without performing feasibility testing on the device (basically “waterfall testing”)
Designing for a single device, platform, language, or hardware configuration
Designing as if your device has a large amount of storage and processing power and is always plugged into a power source
Developing for the wrong version of the Android SDK (verify the device SDK version)
Trying to adapt applications to smaller screens after the fact by having the device “scale”
Deploying oversize graphics and media assets with an application instead of sizing them appropriately
Best Practices in Delivering Quality Android Applications
Developing applications for Android is not that different from traditional desktop development. However, developers might find developing Android applications more restrictive and, especially, resource constrained because mobile devices are not yet as powerful as desktop machines. Again, let’s start with these best practices or “rules” for Android application development:
Test assumptions regarding feasibility early and often on the target devices.
Keep application size as small and efficient as possible.
Choose efficient data structures and algorithms appropriate to Android devices with constrained resources.
Exercise prudent memory management.
Assume that devices are running primarily on battery power.
Designing a Development Process That Works for Android Development
A successful project’s backbone is a good software process. It ensures standards and good communication, and it reduces risks. We talked about the overall Android development process in Chapter 18, “Learning the Development Workflow.” Again, here are a few general tips for successful Android development processes:
Use an iterative development process.
Use a regular, reproducible build process with adequate versioning.
Communicate scope changes to all parties—changes often affect testing most of all.
Testing the Feasibility of Your Application Early and Often
It cannot be said enough: you must test developer assumptions on real devices. There is nothing worse than designing and developing an application for a few months only to find that it needs serious redesign to work on an actual device. Just because your application works on the emulator does not, in any way, guarantee that it will run properly on the device. Some functional areas to examine carefully for feasibility include
Functionality that interacts with peripherals and device hardware
Network speed and latency
Memory footprint and usage
Algorithm efficiency
User interface suitability for different screen sizes, resolutions, and form factors
Device input method assumptions
File size and storage usage
We know, we sound like a broken record—but, truly, we’ve seen this mistake of inadequate feasibility testing made over and over again. Projects are especially vulnerable to this when target devices aren’t yet available. What happens is that engineers are forced closer to the waterfall method of software development with a big, bad surprise that comes after weeks or months of development on some vanilla-style emulator.
We don’t need to explain again why waterfall approaches are dangerous, do we? You can never be too cautious about this stuff. Think of this as the preflight safety speech of Android software development.
Using Coding Standards, Reviews, and Unit Tests to Improve Code Quality
Developers who spend the time and effort necessary to develop efficient Android applications are rewarded by their users. The following list is representative of some of the efforts you can make:
Centralizing core features in shared Java packages. (If you have shared C or C++ libraries, consider using the Android NDK.)
Developing for compatible versions of the Android SDK (know your target devices).
Using the right level of optimization, including coding with RenderScript or using the NDK, where appropriate.
Using built-in controls and widgets appropriate to the application, customizing only where needed.
You can use system services to determine important device characteristics (screen type, language, date, time, input methods, available hardware, and so on). If you make any changes to system settings from within your application, be sure to change the settings back when your application exits or pauses, if appropriate.
Defining Coding Standards
Developing a set of well-communicated coding standards for the development team can help drive home some of the important requirements of Android applications. Some standards might include
Implementing robust error handling as well as handling exceptions gracefully.
Moving lengthy, process-intensive, or blocking operations off the main UI thread.
Avoiding creating unnecessary objects while running critical sections of code.
Releasing objects and resources you aren’t actively using.
Practicing prudent memory management. Memory leaks can render your application useless.
Using resources appropriately for future localization. Don’t hard-code strings and other assets in code or layout files.
Avoiding obfuscation in the code itself unless you’re doing so for a specific reason (such as using the Google Play Licensing service). Comments are worthwhile. However, you should consider obfuscation later in the development process to protect against software piracy using built-in ProGuard support.
Considering the use of standard document generation tools such as javadoc.
Instituting and enforcing naming conventions—in code and in database schema design.
Performing Code Reviews
Performing code inspections can improve the quality of project code, help enforce coding standards, and identify problems before QA gets its hands on a build and spends time and resources testing it.
It can also be helpful to pair developers with the QA personnel who test the developers’ specific functional areas in order to build a closer relationship between the teams. If testers understand how the application and Android operating system function, they can test the application more thoroughly and successfully. This might or might not be done as part of a formal code review process. For example, a tester can identify defects related to type safety just by noting the type of input expected (but not validated) on a layout’s form field or by reviewing the Submit or Save button-handling functions with the developer. This would help circumvent the time spent to file, review, fix, and retest validation defects. Reviewing the code in advance doesn’t reduce the testing burden but rather helps reduce the number of easily caught defects.
Developing Code Diagnostics
The Android SDK provides a number of packages related to code diagnostics. Building a framework for logging, unit testing, and exercising your application to gather important diagnostic information, such as the frequency of method calls and performance of algorithms, can help you develop a solid, efficient, and effective mobile application. It should be noted that diagnostic hooks are almost always removed prior to application publication because they impose significant performance reductions and greatly reduce responsiveness.
Using Application Logging
In Chapter 3, “Creating Your First Application,” we discussed how to leverage the built-in logging class android.util.Log to implement diagnostic logging, which can be monitored via a number of Android tools, such as the logcat utility (available within Android Studio and the Android Device Monitor).
Developing Unit Tests
Unit testing can help developers move one step closer to the elusive 100% of code coverage testing. The Android SDK includes extensions to the JUnit framework for testing Android applications. Automated testing is accomplished by creating test cases, in Java code, that verify the application works the way you designed it. You can do this automated testing for both unit testing and functional testing, including user interface testing.
Basic JUnit support is provided through the junit.framework and junit.runner packages. Here, you find the familiar framework for running basic unit tests with helper classes for individual test cases. You can combine these test cases into test suites. There are utility classes for your standard assertions and test result logic.
The Android-specific unit-testing classes are part of the android.test package, which includes an extensive array of testing tools designed specifically for Android applications. This package builds upon the JUnit framework and adds many interesting features, such as the following:
Simplified hooking of test instrumentation (android.app.Instrumentation) with android.test.InstrumentationTestRunner, which you can run via adb shell commands
Performance testing (android.test.PerformanceTestCase)
Single Activity (or Context) testing (android.test.ActivityUnitTestCase)
Full application testing (android.test.ApplicationTestCase)
Services testing (android.test.ServiceTestCase)
Utilities for generating events such as touch events (android.test.TouchUtils)
Many more specialized assertions (android.test.MoreAsserts)
The Android Testing Support Library with AndroidJUnitRunner (android.support.test.runner.AndroidJUnitRunner), UI testing with Espresso (android.support.test.espresso), and UI Automator (android.support.test.uiautomator)
Mock and stub utility classes (android.test.mock)
View validation (android.test.ViewAsserts)
Handling Defects Occurring on a Single Device
Occasionally, you have a situation in which you need to provide code for a specific device. Google and the Android team tell you that when this happens, it’s a bug, so you should tell them about it. By all means, do so. However, this won’t help you in the short term, nor will it help you if they fix it in a subsequent revision of the platform but carriers don’t roll out the update and fix for months, if ever, to specific devices.
Handling bugs that occur only on a single device can be tricky. You don’t want to branch code unnecessarily, so here are some of your choices:
If possible, keep the client generic and use the server to serve up device-specific items.
If the conditions can be determined programmatically on the client, try to craft a generic solution that enables developers to continue to develop under one source code tree, without branching.
If the device is not a high-priority target, consider dropping it from your requirements if the cost-benefit ratio suggests that a workaround is not cost-effective. Not all markets support excluding individual devices, but Google Play does.
If required, branch the code to implement the fix. Make sure to set your Android manifest file settings such that the branched application version is installed only on the appropriate devices.
If all else fails, document the problem only and wait for the underlying “bug” to be addressed. Keep your users in the loop.
Leveraging Android Tools for Development
The Android SDK comes with a number of useful tools and resources for application development. The development community adds even more useful utilities to the mix. You might want to leverage the following tools during this phase of your development project:
Android Studio
The Android emulator and physical devices for testing
The Android Device Monitor tool for debugging and interaction with the emulator or device
The ADB tool for logging, debugging, and shell access tools
The sqlite3 command-line tool for application database access (available via the adb shell)
Android Support Packages for including the support libraries to avoid writing custom case code
The uiautomatorviewer tool for helping you test and optimize your user interfaces.
The Hierarchy Viewer for user interface debugging of views
Numerous other tools also are available as part of the Android SDK. See the Android documentation for more details.
Avoiding Silly Mistakes in Android Application Development
Here are some of the frustrating and silly mistakes Android developers should try to avoid:
Forgetting to register new activities, services, and necessary permissions to the AndroidManifest.xml file
Forgetting to display Toast messages using the show() method
Hard-coding information such as network information, test user information, and other data into the application
Forgetting to disable diagnostic logging before release
Forgetting to remove test-configured email addresses or websites in code before release
Distributing live applications with debug mode enabled
Summary
Be responsive, stable, and secure—these are the tenets of Android development. In this chapter, we armed you—the software designers, developers, and project managers—with tips, tricks, and best practices for Android application design and development based on real-world knowledge and experience from veteran Android developers. Feel free to pick and choose which information works well for your specific project, and keep in mind that the software process, especially the mobile software process, is always open to improvement.
Quiz Questions
1. What are some application diagnostics that you should consider keeping track of?
2. What is the difference between designing for updates and designing for upgrades?
3. What are some of the Android tools recommended to leverage during application design?
4. True or false: One best practice is to assume that devices are primarily running while plugged in.
5. What are some of the Android tools recommended to leverage during development?
6. True or false: It is a good practice to enable diagnostic logging before release.
7. True or false: Always distribute your live applications with debug mode enabled.
Exercises
1. Read the Android documentation training titled “Best Practices for Security & Privacy”: (http://d.android.com/training/best-security.html).
2. Read the Android documentation training titled “Best Practices for Interaction and Engagement”: (http://d.android.com/training/best-ux.html).
3. Read the Android documentation training titled “Best Practices for Background Jobs”: (http://d.android.com/training/best-background.html)
References and More Information
Android Training: “Performance Tips”:
http://d.android.com/training/articles/perf-tips.html
Android Training: “Keeping Your App Responsive”:
http://d.android.com/training/articles/perf-anr.html
Android Training: “Designing for Seamlessness”:
http://d.android.com/guide/practices/seamlessness.html
Android API Guides: “User Interface”:
http://d.android.com/guide/topics/ui/index.html
Android Design: “Android Design Principles”:
http://d.android.com/design/get-started/principles.html
Android Distribute: Essentials: “Essentials for a Successful App”:
http://d.android.com/distribute/essentials/index.html
Analytics SDK for Android: “Add Analytics to Your Android App”:
https://developers.google.com/analytics/devguides/collection/android/v4/