Designing and Developing Bulletproof Android Applications - 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 16. Designing and Developing Bulletproof Android 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 mobile development might be a bit overwhelming. Instead, consider reading specific sections when planning the parts of the overall process. Some of our advice might not be appropriate for your particular project, and processes can always be improved. Ideally, this information about how mobile 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 Designing Bulletproof Mobile Applications

The “rules” of mobile application design are straightforward and apply across all 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 first. 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:

Image Don’t abuse the user’s trust.

Image Don’t interfere with device telephony and messaging services (if applicable).

Image Don’t break or otherwise tamper with or exploit the device hardware, firmware, software, or OEM components.

Image Don’t abuse or cause problems on operator networks.

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, and those that store private user data such as names, locations, and contact information.

Meeting Mobile Users’ Demands

Mobile users also have their own set of demands for applications they install on their devices. Applications are expected to

Image “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)

Image Have straightforward, intuitive user interfaces that are easy to get up and running

Image 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)

Image Be available 24 hours a day, seven days a week (remote servers or services always on, always available, not running in someone’s closet)

Image Include a Help and/or About screen for feedback and support contact information

Image Honor private user information and treat it with care

Designing User Interfaces for Mobile Devices

Designing effective user interfaces for mobile devices, especially for applications that run on a number of different devices, is something of a black art. We’ve all seen bad mobile application user interfaces. A frustrating user experience can turn a user off your brand; 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 mobile user interfaces:

Image Fill screens sparingly; too much information on one screen overwhelms the user.

Image Be consistent with user interface workflows, menu types, and buttons. Also, consider making the user interface consistent with Android design patterns.

Image Design your applications using fragments, even if you aren’t targeting tablet devices. (The Android Support Package makes this possible for nearly all target versions.)

Image Make touch mode “hit areas” large enough (48dp) and space them appropriately (8dp).

Image Streamline common use cases with clear, consistent, and straightforward interfaces.

Image Use big, readable fonts and large icons.

Image Integrate tightly with other applications on the system using standardized controls, such as the QuickContactBadge, content providers, and search adapters.

Image Keep localization in mind when designing text-heavy user interfaces. Some languages are lengthier than others.

Image Reduce the number of keys or clicks needed as much as possible.

Image Do not assume that specific input mechanisms (such as specific buttons or a keyboard) are available on all devices.

Image Try to design the default use case of each screen to require only the user’s thumb. Special cases might require other buttons or input methods, but encourage “thumbing” by default.

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

Image 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 shares private information, consider informing them 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.

Image 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 14, “Designing Compatible Applications.” We also discuss designing for the user experience inChapter 17, “Planning the Android Application Experience.”

Designing Stable and Responsive Mobile Applications

Mobile 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. 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 mobile applications:

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

Image Use efficient data structures and algorithms; these choices manifest themselves in app responsiveness and happy users.

Image Use recursion with care; these functional areas should be code reviewed and performance tested.

Image Keep application state at all times. The Android Activity stack makes this work well, but you should take extra care to go above and beyond.

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

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

Image Inform users during long operations 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.

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

Image Minimize the use of local storage, because most devices have very limited amounts. Use external storage, when appropriate. Be aware that SD cards (the most common external storage option) can be ejected and swapped; your application should handle this gracefully.

Image Understand that data calls to content providers and across the AIDL barrier come at a cost to performance, so make these calls judiciously.

Image Verify that your application resource consumption model matches your target audience. Gamers might anticipate shorter battery life on graphics-intensive games, but productivity applications should not drain the battery unnecessarily and should be lightweight for people “on the go” who do not always have their device charging.

Image 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 such as memory management (Context management), View optimization (avoiding deep View hierarchies), and layout tricks to improve UI speed. 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 Mobile Applications

Many mobile applications integrate with core applications such as the Phone, Camera, 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.

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

Transmitting Private Data

The same cautions 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.

Designing Mobile Applications for Maximum Profit

For billing and revenue generation, mobile applications generally fall into one or more of the following categories:

Image Free applications (including those with advertising revenue)

Image Single payment (pay once)

Image In-app products (pay for specific content, such as a ringtone, a Sword of Smiting, or a new level pack)

Image Subscription billing (payments recurring on a schedule, often seen with productivity and service applications)

Image Outside billing and membership supplementation (mobile 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 (Google Play, for example, will be limiting billing methods to Google Wallet). 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, direct carrier billing, gift cards, and Google Play balance values.

When designing your mobile 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 that can be charged for. 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.

Image Note

You will learn more about the different methods currently available to market your application in Chapter 19, “Publishing Your Android Application.”

Following the Android Application Quality Guidelines

Users’ expectations of application quality rise with every new iteration of Android. Luckily, Google has put in 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 three quality guidelines recommended in the Android documentation that you should seriously consider:

Image Core app quality: Core app quality criteria 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, functional behavior criteria, stability and performance criteria, and Google Play promotional criteria. 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/googleplay/quality/core.html.

Image 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. The guidelines for tablets are presented as a checklist of recommendations. You can learn more about the checklist for tablet app quality here: http://d.android.com/distribute/googleplay/quality/tablet.html.

Image Improving app quality: 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 improving your application’s quality, visithttp://d.android.com/distribute/googleplay/strategies/app-quality.html.

Currently, there are no requirements that your application actually adhere to these quality guidelines, but if you would like your application to achieve success, these guidelines are where to begin focusing your efforts.

Leveraging Third-Party Quality Standards

There are no certification programs specifically designed for Android applications. However, as more applications are developed, third-party standards might be designed to differentiate quality applications from the masses. For example, mobile marketplaces may impose 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. Google Play has an Editors’ Choice category of applications. Developers with an eye on financial applications would do well to consider conformance requirements.

Image Warning

With Android, the market is expected to manage itself to a greater extent than in some other mobile 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 Mobile 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 a mobile 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 mobile 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

Image How many users install the application

Image How many users launch the application for the first time

Image How many users regularly use the application

Image What the most popular usage patterns and trends are

Image What the least popular usage patterns and features are

Image 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:

Image Google Play sales statistics, ratings, and bug/crash reports, as well as those available on other distribution channels.

Image Application integration with statistics-gathering APIs such as Google Analytics or other third-party application monitoring services.

Image For applications relying on network servers, quite a lot of information can be determined by looking at server-side statistics.

Image Feedback sent directly to you, the developer, through email, user reviews, or other mechanisms made available to your users.

Image 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 needs to 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 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.

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

Image Tip

Google provides a service known as the Android Backup Service, which allows developers to persist user application data to 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, refer to the following URL: 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:

Image The Graphical Layout Editor is a good place to start for rapid proof of concept. You can find more about the Graphical Layout Editor here: http://d.android.com/tools/help/adt.html#graphical-editor.

Image Use the Android emulator before you have specific devices. You can use different AVD configurations to simulate different device configurations and platform versions.

Image The DDMS tool is very useful for memory profiling.

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

Image The Draw Nine-Patch tool can create stretchable graphics for mobile use.

Image Real devices may be 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.

Image 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:

Image Designing or developing for months without performing feasibility testing on the device (basically “waterfall testing”)

Image Designing for a single device, platform, language, or hardware configuration

Image Designing as if your device has a large amount of storage and processing power and is always plugged into a power source

Image Developing for the wrong version of the Android SDK (verify the device SDK version)

Image Trying to adapt applications to smaller screens after the fact by having the device “scale”

Image Deploying oversize graphics and media assets with an application instead of sizing them appropriately

Best Practices in Developing Bulletproof Mobile Applications

Developing applications for mobile is not that different from traditional desktop development. However, developers might find developing mobile applications more restrictive, especially resource constrained. Again, let’s start with some best practices or “rules” for mobile application development:

Image Test assumptions regarding feasibility early and often on the target devices.

Image Keep application size as small and efficient as possible.

Image Choose efficient data structures and algorithms appropriate to mobile.

Image Exercise prudent memory management.

Image Assume that devices are running primarily on battery power.

Designing a Development Process That Works for Mobile Development

A successful project’s backbone is a good software process. It ensures standards and good communication and reduces risks. We talked about the overall mobile development process in Chapter 15, “Learning the Android Software Development Process.” Again, here are a few general tips for successful mobile development processes:

Image Use an iterative development process.

Image Use a regular, reproducible build process with adequate versioning.

Image 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

Image Functionality that interacts with peripherals and device hardware

Image Network speed and latency

Image Memory footprint and usage

Image Algorithm efficiency

Image User interface suitability for different screen sizes and resolutions

Image Device input method assumptions

Image File size and storage usage

We know, we sound like a broken record—but, truly, we’ve seen this mistake 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 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 mobile software development.

Using Coding Standards, Reviews, and Unit Tests to Improve Code Quality

Developers who spend the time and effort necessary to develop efficient mobile applications are rewarded by their users. The following is a representative list of some of the efforts you can make:

Image Centralizing core features in shared Java packages. (If you have shared C or C++ libraries, consider using the Android NDK.)

Image Developing for compatible versions of the Android SDK (know your target devices).

Image Using the right level of optimization, including coding with RenderScript or using the NDK, where appropriate.

Image 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 mobile applications. Some standards might include

Image Implementing robust error handling as well as handling exceptions gracefully.

Image Moving lengthy, process-intensive, or blocking operations off the main UI thread.

Image Avoiding creating unnecessary objects during critical sections of code or user interface behavior, such as animations and response to user input.

Image Releasing objects and resources you aren’t actively using.

Image Practicing prudent memory management. Memory leaks can render your application useless.

Image Using resources appropriately for future localization. Don’t hard-code strings and other assets in code or layout files.

Image Avoiding obfuscation in the code itself unless you’re doing so for a specific reason (such as using Google’s License Verification Library, or LVL). Comments are worthwhile. However, you should consider obfuscation later in the development process to protect against software piracy using built-in ProGuard support.

Image Considering using standard document generation tools such as Javadoc.

Image 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 their hands on a build and spends time and resources testing it.

It can also be helpful to pair developers with the QA tester who tests their specific functional areas 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 form field of a layout or by reviewing the Submit or Save button-handling function 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, “Writing Your First Android 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 DDMS, Android Debug Bridge, or ADB, the Android IDE, Android Studio, and the Android Development Plugin for Eclipse).

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 that 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:

Image Simplified hooking of test instrumentation (android.app.Instrumentation) with android.test.InstrumentationTestRunner, which you can run via adb shell commands

Image Performance testing (android.test.PerformanceTestCase)

Image Single Activity (or Context) testing (android.test.ActivityUnitTestCase)

Image Full application testing (android.test.ApplicationTestCase)

Image Services testing (android.test.ServiceTestCase)

Image Utilities for generating events such as touch events (android.test.TouchUtils)

Image Many more specialized assertions (android.test.MoreAsserts)

Image User interface testing with uiautomator, the API for which is included by adding the uiautomator.jar to your project (com.android.uiautomator.*)

Image View validation (android.test.ViewAsserts)

Handling Defects Occurring on a Single Device

Occasionally, you have a situation when 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:

Image If possible, keep the client generic and use the server to serve up device-specific items.

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

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

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

Image 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:

Image The Android IDE, Eclipse with the ADT plugin, or Android Studio

Image The Android emulator and physical devices for testing

Image The Android DDMS tool for debugging and interaction with the emulator or device

Image The ADB tool for logging, debugging, and shell access tools

Image The sqlite3 command-line tool for application database access (available via the adb shell)

Image The Android Support Package for including the support libraries to avoid writing custom case code

Image 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:

Image Forgetting to register new activities, services, and necessary permissions to the AndroidManifest.xml file

Image Forgetting to display Toast messages using the show() method

Image Hard-coding information such as network information, test user information, and other data into the application

Image Forgetting to disable diagnostic logging before release

Image Forgetting to remove test-configured email addresses or websites in code before release

Image 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 mobile application design and development based on real-world knowledge and experience from veteran mobile 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 running primarily 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.

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 User Experience & UI” (http://d.android.com/training/best-ux.html).

3. Read the Android documentation Training titled “Improving App Quality after Launch” (http://d.android.com/distribute/googleplay/strategies/app-quality.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: “Design Principles”:

http://d.android.com/design/get-started/principles.html

Android Distribute: “App Quality”:

http://d.android.com/distribute/googleplay/quality/index.html

Google Analytics: “Google Analytics SDK for Android v2 (Beta)—Overview”:

https://developers.google.com/analytics/devguides/collection/android/v2/