Building, Testing And Distributing Android Apps

In this article, we’ll explain parts of the application-building process and ecosystem for Android that could cause problems if misunderstood. We’ll talk about an approach to building a scalable app that looks and feels right at home on Android, and we’ll cover how to test it and your options for distributing it. The following topics would each need a full article to be explained fully, but this article should provide a good overview. After reading this article, you should have a good understanding of what kinds of decisions and challenges you will face when creating an Android app.

Make The App Scalable

Android devices come in many forms and sizes. The last official count is that 600 Android devices are available, and that number is growing every day. Building an app that runs on all of them is more difficult than building for just one or two screen sizes and one set of hardware. Fortunately, Android was built from the ground up with this in mind. The framework provides tools to help developers tackle the problem. But as with all tools, they only work if used correctly.

Large preview.

An iOS app is designed and built by placing pixels at the proper coordinates until the UI looks just right. Not so on Android! Android designers must think about the scalability of each component and the relationships between components. The philosophy is much closer to Web app design than to iOS app design.

A Continuum Instead Of A Separate Tablet UI

About half a year ago, Google rushed out the Android version named Honeycomb (3.0). Honeycomb was aimed at tablets and was never meant for anything else. The source code of Honeycomb was never released, and it never officially appeared on any phones. At the time, Apple had already established a practice by which developers provided two separate versions of their app, one for iPhone and one for iPad. Because of Apple’s model and the separate Android version for tablets, everyone seemed to assume that two separate versions of an app are needed on Android, too. Soon, the Internet was full of blog posts complaining that Android didn’t have enough tablet apps and that there was no way to search for them on the Google Play store.

Now, as Android Ice Cream Sandwich (4.0) is unifying all Android devices to run the same version of the OS, it all makes sense. Android is a continuum, and drawing a clear line between tablets and phones is impossible. In fact, checking whether an app is running on a tablet or phone is technically impossible. Checking the screen size (and many other features) at runtime, however, is possible.

This is where Android design starts to remind us of Web design. New technologies have enabled us to build websites that adapt automatically to the user’s browser size by scaling and moving components around as needed. This approach is called responsive Web design. The very same principles can be used on Android. On Android, however, we are not bound by the limits of the browser. Responsive design can be taken even further.

Responsive Android Design

Android developers can define multiple layouts for every screen of their app, and the OS will pick the best-fitting one at runtime. The OS knows which one fits best by using definitions that developers add to their layout (and other) folders in the app’s project resource tree.

An example of the structure of layout folders, which distinguish between screen sizes and Android versions.

Starting from Android version 3.2 — and, therefore, also on Ice Cream Sandwich — a more fine-grained approach was introduced. Developers may now define layouts based on the screen’s pixel density, independent of size, instead of using only the few categories that were available before.

An example of the new layout specifications based on screen size. It is very similar to CSS’ media queries. Android’s documentation has more details.

Using Fragments to Implement Responsive Design

Fragments are the building blocks of Android UIs. They can be programmed either to be standalone screens or to be displayed with other fragments; but the most powerful ones are both, depending on the device that the app is running on. This enables us not only to rearrange the fragments but to move them deeper into the activity stack. Dan McKenzie has written about issues related to designing for big Android screens.

Each component is itself stretchable and scales to screens with similar sizes.

When a screen’s size is drastically different, the components need to be rearranged. They can be rearranged on the same level or moved deeper into the activity stack.

Make The App Look And Feel Android-Like

Consistency with other apps on the same platform is more important for an app’s look and feel than consistency with the same developer’s apps on other platforms. Having the look and feel of apps from a different platform will make the app feel foreign and make users unhappy.

(Remember to read Google’s Android Design guidelines.)

Tabs

In Android apps, tabs should always be on top. This convention was established and is driven by Google’s design of its apps and by guidelines from advocates of Android development. Putting the tabs on top makes scaling an app to larger screen sizes easier. Putting tabs at the bottom of a tablet-sized UI wouldn’t make sense.

Large preview.

Navigating between top-positioned tabs on a phone with a large screen can be difficult, especially when the person is using only one hand. The solution is to enable the user to swipe between tabs. This interaction model is not new, but in its latest release, Google has made it commonplace in Android apps. All bundled apps now support this interaction on tabbed UIs, and users will expect it to work in your app’s tabbed screens, too.

Android UI Patterns Can Put Users at Ease

Some UI patterns have become popular on Android — so much so that they are starting to define the look of Android apps. The action bar, one of the most popular patterns, is now part of Android’s core libraries and can be used in any app running on Android 3.0 and up.

Good third-party libraries are available to bring the action bar to apps that run on older versions of Android. ActionBarSherlock is very stable and supports multiple versions and even automatically uses the native action bar when it detects a supported version of Android.

Another popular UI pattern is the dashboard. Many apps with a lot of functionality use the dashboard as their landing screen to give users a clear overview of and easy access to the app’s most important functionality.

Large preview.

Google Play (left) and Evernote (right) both put an action bar at the top of their screens to provide quick access to contextually relevant actions. Evernote’s landing screen clearly tells the user what they can do with the app, while providing easy access to those actions every time the app launches.

See Dan McKenzie’s article “Designing for Android” for more on the look and feel of Android apps.

Integrate The App With Other Apps

The Android platform provides a powerful mechanism for apps to extend each other’s functionality. This mechanism is called “intents.” Apps can register to receive and launch intents. When an app registers to receive intents, it must tell the system what kind of intents it can handle. Your app could, for example, tell the system that it can show pictures or open Web page URLs. Now, whenever another app launches an intent to view an image or a Web page, the user has the option to choose your app to complete the action.

Large preview.

Social Network Integration

On other mobile platforms, if an app wants to share something to Twitter, Facebook or another social network, it implements the sharing mechanisms internally in the app. Sharing requires a separate operation for each social network. On Android, this can be achieved more easily using intents. An app may launch an intent telling the system that it wants to share an image or text. Depending on which apps the user has installed, the user will be provided with a list of apps that can handle the operation. If the user chooses a Twitter or Facebook client, the client will open to its sharing screen with the text or image prefilled.

Large preview.

There are many benefits to integrating with social networks using intents rather than implementing sharing directly from your app:

1. Close to zero effort is required to build the functionality.
2. Users don’t have to log into a separate application. The social network’s app takes care of logging in.
3. You don’t have to limit the social networks that users may use to share from your app. All apps installed on the user’s device are available to be used.
4. If a social network’s sharing protocol changes, you don’t have to worry about it. That service’s app will be updated to reflect the changes.
5. Users might be using an unofficial app for a social network. Using intents, they may continue using their app of choice with the interface they are familiar with.
6. The intents mechanism offers only options that the user actually uses (i.e. the apps that they have installed). No need to offer Facebook sharing to someone who doesn’t have a Facebook account.

Think of Other Opportunities

Extending the functionality of other apps via the intents system will benefit your app, too. Perhaps your app wouldn’t get used every day and would get buried under apps that are used more often. But if your app extends the functionality of other apps and keeps popping up as an option every time the user wants to perform an action that your app can handle, then it will be thought of more by users.

Intents have limitless possibilities. You can build your own intents hierarchy to extend certain functionality to other apps, in effect providing an API that is easy to use and maintain. You are essentially recommending to users other apps that complement yours and, in turn, extending your app’s features without having to write or maintain any code. The intents system is one of the most powerful features of the Android platform.

Quality Control

With the massive number of devices, testing an Android app is much more difficult than testing an iOS app. This is where the fragmentation causes the most problems. Testing on one or two devices is not enough; rather, you have to test on a variety of screen sizes, densities and Android versions.

In addition to what you would normally test on any other platform, you should the following:

• Test your app thoroughly on the lowest Android version that it runs on. Accidentally using an API that isn’t actually available at runtime on some devices is easy.
• Test that the search button works on all relevant screens.
• Make sure that the D-pad and trackball navigation work on all screens.
• Test all supported screen densities, or at least extra-high, high and medium. Low-density devices can be difficult to find.
• Test on at least one tablet device. But try to test on as many screen sizes as possible.

Testing in the Cloud

New services are popping up to ease the pain of testing on multiple devices. Services such as Testdroid enable developers to test their apps on multiple real devices through a Web interface. Simply upload your app’s package and automated testing script, and the service executes your scripts on dozens of devices. Results can be viewed in a Web browser. Examining screenshots from different devices is even possible, to ensure pixel-perfect UIs.

Testdroid is a cloud service for testing Android apps on multiple devices. Large preview.

Distribute The App

Once your app is tested and ready, you need to get it to users. You’ll have to choose how to do it. Very few Android devices are restricted to one app store. The overwhelming majority of Android devices ship with Google Play, which is the most important route to reaching users on the platform.

Google Play

The Google Play store doesn’t have a formal process for approving apps. Any application package uploaded to Play will appear in the store’s listings to users. App guidelines do exist, but they are enforced only if there are complaints, and even then pretty randomly. This means that your app will be swamped by hundreds of other apps of varying quality.

So, how to rise above the masses and get the attention of users?

The first 30 days are important! Your app will appear in the listing for new paid or free apps during that time. Ranking relatively high in this listing during this time is much easier than ranking high in the overall top lists. Make sure that your app’s website links to Google Play from the start, and use all social networks to tell people about your app’s launch.

Getting recognized as a trusted brand is difficult. Google Play contains many apps that use registered trademarks without permission. Users have come to learn that a logo is no indication that an app was actually produced by that logo’s company. To increase trust, make sure the “Visit Developer’s Website” link points to the official website, and if possible link back to your app from there.

Top new apps on Google Play. Large preview.

Making an app work on all devices is sometimes impossible. Some devices lack the required hardware or simply run an old version of Android for which the required APIs don’t exist. You can list all of the requirements in the app’s manifest file, telling Google Play which devices the app is meant for and, thus, hiding it from listings that are being viewed on incompatible devices. But sometimes even that isn’t enough. In these cases, Google Play allows developers to prevent certain devices from downloading their app. While this option should be used only as a last resort, it is still better than allowing users to download something that you know does not work on their device.

Alternative App Stores

Google Play is not the only place to distribute your app. Amazon’s Appstore has lately gained attention due to the launch of Amazon’s Android-based Kindle Fire tablet. Amazon’s approach is fairly similar to Apple’s in that it has a formal review process. The Appstore is also accessible to non-Amazon devices, but currently only in the US.

Multiplatform app store GetJar also distributes Android apps. GetJar has a lot of users and is a well-known and trusted source, especially among people with not-so-smart phones.

Barnes & Noble’s app store is a US-only eBook-based app store. Unlike Amazon’s, it is accessible only to B&N’s Android hardware.

Multiple App Stores, Just One, or None?

Many people’s first instinct is to try to get their app into all stores. This decision should not be made lightly, though. Distributing through multiple stores might make the app reach more potential users. However, being spread across multiple app stores could prevent the app from ranking as high as it could in the listings for downloads and ratings. Having a thousand installations across three app stores might sound better than having two thousand installations in one store, but maybe those two thousand would push the app into a more visible spot in the store and help it rocket to tens of thousands of installations later.

An app doesn’t have to be in a store at all in order to be installed on devices. Android apps can be installed directly from websites or by transferring them from computer to phone. While you wouldn’t reach the same audience and wouldn’t benefit from the update mechanisms in app stores, there is definitely a place for direct distribution. Using forums and websites, developers can distribute their apps to alpha and beta communities without having to risk their reputation or low ratings in an app store. Distributing a major update or an unstable build to a limited number of dedicated testers and fans might be worth the extra effort.

Conclusion

Building a scalable and functional Android app is not impossible, but it requires careful planning and an understanding of the target platform. A blind approach or simply borrowing a design from another platform would likely end in failure. Achieving a successful end requires that you use Android’s tools correctly and follow the right design approach. Writing an Android app takes effort, but if done right, the app could reach a massive numbers of users.

Further Resources

Intents:

• OpenIntents: Registry of Intents Protocol

Supporting multiple screen sizes:

• “Supporting Multiple Screens,” Android Developers
• “Thinking Like a Web Designer,” Android Developers
• “Deep Dive Into Responsive Mobile Design,” Pushing Pixels
• Styling Android

Android design:

• Android Design, official guidelines
• Android UI Patterns
• Android Niceties
• Android Patterns

Useful libraries:

• ActionBarSherlock
• GreenDroid
• “Support Package,” Android Developers