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:
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.
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
“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, seven days a week (remote servers or services always on, always available, 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 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:
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 design patterns.
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.)
Make touch mode “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.
Reduce the number of keys or clicks needed as much as possible.
Do not assume that specific input mechanisms (such as specific buttons or a keyboard) are available on all devices.
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.
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.
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:
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 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.
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.
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, when appropriate. 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 applications should not drain the battery unnecessarily and should be lightweight for people “on the go” who do not always have their device charging.
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.
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:
Free applications (including those with advertising revenue)
Single payment (pay once)
In-app products (pay for specific content, such as a ringtone, 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 (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.
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:
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.
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.
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.
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
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
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.
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.
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.
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:
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.
Use the Android emulator before you have specific devices. You can use different AVD configurations to simulate different device configurations and platform versions.
The DDMS 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.
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.
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 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:
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 mobile.
Exercise prudent memory management.
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:
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
User interface suitability for different screen sizes and resolutions
Device input method assumptions
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:
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 mobile 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 during critical sections of code or user interface behavior, such as animations and response to user input.
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 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.
Considering using 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 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:
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)
User interface testing with uiautomator, the API for which is included by adding the uiautomator.jar to your project (com.android.uiautomator.*)
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:
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:
The Android IDE, Eclipse with the ADT plugin, or Android Studio
The Android emulator and physical devices for testing
The Android DDMS 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)
The Android Support Package for including the support libraries to avoid writing custom case code
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
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.
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.
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”:
Android Training: “Keeping Your App Responsive”:
Android Training: “Designing for Seamlessness”:
Android API Guides: “User Interface”:
Android Design: “Design Principles”:
Android Distribute: “App Quality”:
Google Analytics: “Google Analytics SDK for Android v2 (Beta)—Overview”: