Best Practices in Designing Bulletproof Mobile Applications Android

The “rules” of mobile application design are straightforward and apply across all platforms. These rules were crafted to remind us that our applications play a secondary role on the device. Often Android devices are, at the end of the day, phones 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 Software Development Kit (SDK) License Agreement and those of third-party application marketplace terms and conditions.

These “rules” are as follows:

  • Don’t interfere with device phone and messaging services.
  • 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.
  • Don’t abuse the user’s trust.

Now perhaps these rules sound like no-brainers, but even the most well-intentioned developer can accidentally fall into some of these categories if they aren’t careful and don’t test the application 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

  • Be responsive, stable, and secure
  • Have straightforward, intuitive user interfaces that are easy to get up and running
  • Get the job done with minimal frustration to the user
  • Be available 24 hours a day, 7 days a week (remote servers or services always on, always available)
  • Include a Help and/or About Screen for feedback and support contact information

Designing User Interfaces for Mobile Devices

Designing effective user interfaces for mobile devices, especially 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 forever, and a good experience can win a user’s loyalty for the long term. It can also give your application an edge over the competition, even if your functionality is similar. A great user interface can win over users even when the functionality is behind the competition. 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. Consider the device norms with this consistency, as well.
  • Make Touch Mode “hit areas” large enough and spaced appropriately.
  • 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 quick Contact badge, content providers, and search adapters.
  • Keep localization in mind when designing text-heavy user interfaces. Some languages are lengthier than others.
  • Reduce keys or clicks needed as much as possible.
  • Do not assume that specific input mechanisms (such as specific buttons or the existence of 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 graphics appropriately for phones. Do not include oversized resources and assets because they use valuable device resources and load more slowly, even if they resize appropriately. Also consider stripping out unnecessary information, such as EXIF or IPTC metadata, using tools such as ImageMagick or PNGOptimizer. You can also use the Draw 9 Patch tool to help optimize your Android graphics files.
  • 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 the user to incur significant fees or shares private information, consider informing them again (as appropriate) when your application performs such actions.

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 such as phones. Android users can, however, take advantage of removable storage devices such as SD cards to provide some “extra” space for application and media storage. Spending some time upfront 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 operations on the main UI thread. Always use asynchronous tasks or threads 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. Android activity stack makes this work well, but you should take extra care to go above and beyond.
  • Save your state 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 these operations might drain battery life beyond the limits users are willing to accept.
  • Ensure that long operations are likely to succeed before embarking upon them. For example, if your application downloads large files, check for network connectivity, file size, and available space before attempting the download.
  • Minimize use of local storage, as 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 phone charging.

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 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 upon 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 of four categories:

  • Free applications (including those with advertising revenue)
  • Single payment (pay once)
  • Subscription payments (pay on a schedule, often seen with productivity and service applications)
  • In-application payment for content (pay for specific content, such as a ringtone, a Sword of Smiting, or a new level pack)

Applications can use multiple types of billing, depending on which marketplaces and billing APIs they use (Android Market, for example, limits billing methods to Google Checkout). Although there are currently no billing APIs in the Android framework, there are rumblings that this might change in a future version. With Android in general, third parties can provide billing methods or APIs, so technically the sky’s the limit.

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.

Leveraging Third-Party Standards for Android Application Design

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 could impose quality requirements and certainly programs could be created with some recognized body’s endorsement or stamp of approval. Developers with an eye on financial applications would do well to consider conformance requirements.

It can be highly beneficial to examine the certification programs available in other mobile platforms and adjust them for Android. You might also want to examine the certification programs for desktop applications and other mobile platforms; consider how the requirements from these programs can be applied to Android applications. For example, if a specific type of encryption is recommended to meet certification requirements, and that type of encryption is feasible within Android, you should consider using it within your application.

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 Network Diagnostics

In addition to developing adequate documentation and easy-to-decipher code, you can leverage some tricks to help maintain and monitor mobile applications in the field. Many of these tricks work best with mobile applications leveraging an application server, but you can sometimes gather information from third-party reports, such as application sales figures from mobile marketplaces or by including optional feedback gathering features in your application. Developers can also gather statistics from the bug reports that users can send in when a crash occurs on the device.

For networked applications, it can be highly useful to build in some lightweight auditing, logging, and reporting on the server side to keep your own statistics and not rely solely on third-party information. For example, you can easily keep track of

  • How many users launch the application for the first time?
  • How many users regularly use the application?
  • What are the most popular usage patterns and trends?
  • What are the least popular usage patterns and features?
  • 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 make more efficient the most popular usage. You can review and improve the least popular features. 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.

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. By update, we’re talking about modifying the Android manifest version information and re-deploying the updated application on users’ devices. By upgrading, we’re talking about creating an entirely new application package with new features and deploying it as a separate application that the user needs to choose to install.

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 in which you deploy updates—you need to schedule updates such that they come up frequently enough to be truly useful, but not so often that the users are constantly updating their application.

When considering upgrades, decide what manner you will migrate users from one version of your application to the next. Will you leverage Android backup features so that your users can transition seamlessly from one device to the next or will you provide your own solution? Consider how you will inform users of existing applications that a major new version is available.

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 emulator is a good place to start for rapid proof of concept, before you have specific devices. You can use different Android Virtual Device (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 View enables accurate user interface design.
  • The Draw Nine Patch tool can create stretchable graphics for mobile use.
  • Use real devices for feasibility research and application proof-of-concept work, whenever possible. Do not design solely using the emulator.
  • The technical specifications for specific devices, often available from manufacturers and carriers, can be invaluable for determining the configuration details of target devices.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Android Topics