When iOS started to gain momentum, soon after the first iPhone launched, many businesses started to pay attention to apps. The number of apps for iOS grew exponentially, and every company, big and small, rushed to create their own app to support their business.

For some time, iOS was the only platform you really had to care about. The audience was there. For a few years now, there has been another player in the market. Android’s marketshare growth has been phenomenal, and it simply cannot be ignored anymore. There are over 200 million Android users in the world—almost double the numer of iOS users. For businesses, reaching the Android crowds is potentially a very lucrative investment.

Android as a platform can appear intimidating to new players. Blogs and media are littered with articles about Android fragmentation and malware. The Android platform can feel complex, although it is very flexible. However, before getting started with an Android project, understanding the platform and ecosystem is imperative. Trying to apply the methods and tools that work on other platforms could lead to disaster.

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.

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.

3An 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.

4An example of the new layout specifications based on screen size. It is very similar to CSS’ media queries. Android’s documentation5 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 written6 about issues related to designing for big Android screens.

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

8When 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.

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.

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

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.

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.

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.

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

Close to zero effort is required to build the functionality.

Users don’t have to log into a separate application. The social network’s app takes care of logging in.

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.

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.

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.

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

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

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.

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

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.

Juhani is an Android developer with more than ten years of experience in Java development in different business domains. He has always been a keen supporter of good design. He writes a blog about Android UI Design Patterns at www.androiduipatterns.com and tweets with focus on Android and Android design.

Ivica

Great article. Which frameworks would you reccomend for us working more with the design than Java. in fact, i do not know Java, I am pro in HTML, CSS, I know some JavaScript and PHP. What should I use?

0

6

Juhani Lehtimaki

My recommendation is to take the time to learn Java if you want to create Android app. There are frameworks that do turn HTML code into Android apps but I haven’t seen a single app that is up to par with design standards of app’s written with Android SDK (or NDK). I actually wrote a post about this some time ago into my blog: http://www.androiduipatterns.com/2012/03/multi-platform-frameworks-destroy.html

If you don’t want to learn Java I recommend that you approach the platform from web app point of view. The Android browser is getting better all the time and people do use web apps on Android.

0

7

GoodBytes

Thanks for your article and your write-up about phonegap/Titanium. I’m currently experimenting with Titanium and have loved it so far, but like you said, only for not having to dive into objective C for a simple app. When it comes to building great experiences for both ios and android, things do get tricky indeed.

With Android, you’re not designing for 200 million consumers; you’re designing for bits and pieces of them. Either for some with certain devices or OS versions or both. It’s a headache that won’t end anytime soon.

-2

11

Juhani Lehtimaki

I’m afraid that you’re not very well informed on the matter of developing for Android.
To your first point, Android versions isn’t a big problem to tackle in the development. In the current environment you should support all versions from Froyo (2.2) up. The update curve on Android is slower than on tightly controlled platforms but devices are pushed up to newer versions all the time. That is the nature of the development process. The current model is that Google opens up the new version to manufacturers the same time it goes open to developers. New features can easily be brought to apps without breaking backwards compatibility in most cases. This could be a good topic for another article.

As for you claims for Android not being profitable I need to call BS. For the Mika mobile’s decision you should really read the update at the end of the post. If you’ve followed the platform development in the last year you’d seen almost all of the big name iOS developers jump to Android: Instagram, Readability, turntable, flipboard etc. Also, big time developers like EA and Rockstar are both releasing Android versions of their games on the same schedule they do on iOS. Do you think that they would be doing that if the platform would not be profitable?

So to your point. Writing apps on Android you will target the overwhelming majority of the devices if you know what you are doing. Your claim is factually wrong.

Daniel McCormack

Juhani Lehtimaki

Hey Daniel,
You can build apps using Flash on Android. The problem is that Flash just isn’t a very good platform for mobile apps. A flash app will not feel right on Android. It will not follow the design guidelines. Another problem is also that Adobe discontinued Flash on mobile which means that it won’t get any updates anymore.

Daniel McCormack

I have wondered why we cannot load Adobe Flash program into our IPads or other Android products. I have it on my computer and it is a great program. Please help me to understand why it cannot be used on my IPad 2.?

They’re about to release Jelly Bean Android 5.0 while only 7.1 % of devices have the 7 month old ICS. Also, while major app developers are releasing apps for android on the same schedule, most are released only for certain devices HANDPICKED for compatability (see flipboard, gta 3). Here’s what one developer has to go through: http://m.techcrunch.com/2012/05/11/this-is-what-developing-for-android-looks-like/

If you want to develop for Android, then do it. It may be a learning experience. You may enjoy it. But it may be alot of work with no payoff. That’s all I’m saying but to dismiss my comment with all the evidence coming out? That’s blind.

0

20

Juhani Lehtimaki

You have chosen to look for evidence supporting your opinion and ignore all of the other evidence. You also have misunderstood many of the articles you quote. I’m not dismissing the evidence, instead I’m looking it with more wide view. Do you know that both, flipboard is currently in beta testing for all devices? The S III launch was a marketing tool for Samsung which Samsung paid for. GTA is compatible with all modern phones. Surely it’s not a surprise that games don’t run on devices that don’t have enough power to run them. You say ” most are released only for certain devices HANDPICKED” which is simply not true.

I’ve worked for a company building some of the most downloaded Android apps in Europe. The apps run on ALL Android devices and have millions of users. The QA process does take time but is nowhere near the quoted tech crunch article. You need to have 6-10 devices which you test with to ensure compatibility. That number is very close to the number of devices required on iOS for example (4-7).

0

21

Drummertist

joey

6-10 Android devices vs 4-7 iOS devices : I say “bullshit”.
iOS : one screen size, 3GS as base, iPad 1 or 2 as tablet base.
Android : 3″, 4.2″, 7″, 10″ screen sizes, big OS fragmentation, very different RAM amouts, processing power, graphic power, space available… do you really think you can have the same level of confidence with just 3 more Android devices ?
The fact is : when you use 7 iOS devices, you’re testing what 95% of iOS users have. With 10 Android devices, you test a fraction of what users have and cross fingers hoping that everything will turn out ok. Which won’t be the case, cf Mikamobile’s blog.
You can deny this, but that’s what small developers have to face. it’s easier to manage for bigger companies because the developers time isn’t sucked up by all the bad sides of Android.

compare this to the web : iOS is Chrome plus Safari on a fixed monitor size, Android is Webkit plus Firefox plus IE9 plus Opera on different monitor size forcing to be “responsive”. Not really the same amount of work.

Joseph Jaramillo

Pretty good stuff. I recently wrote an overview of Android from the perspective of dying technology, and how it can take quite a while for users to move to new Android releases. Check it out: http://copio.us/#/view-blog/dying-technology

1

28

Louie

If android 4.0 is unifying tablet and mobile based on screen scalability then the tablet will look like mobile only which i think its not natural resulting to bad experience unlike with ipad they know that they need to seperate the UI of ios iphone compare to ios ipad. This seperates the experience between tablet to mobile. So what is the use of unifying if it fails to meet the goal in presenting apps in tablet form which for me is kinda awkward

1

29

Juhani Lehtimaki

ICS did unify the underlying operating system version on tablets and phones. The all now run exactly same Android 4.0 (the new ones do). While the OS is the same it doesn’t mean that the apps look the same or that the user interface is the same. On Android, the apps mus adapt to screen sizes. Look for example the Tasks app (there are thousands more but it is a very good example) in this post I posted some time ago http://www.androiduipatterns.com/2012/04/holo-new-look-of-android.html
The app UI utilises the phone screen perfectly but when it has a larger screen available it expands its UI to utilise that screen. That is the principle Android app design. It is the same app (ie. no separate app for tablets and phones) but the app UI is responsive. The design approach on Android is different from iOS but the results are the same. Android apps just have a capability to adapt their UI to more than just two screen sizes.

3

30

Jang

Wow. This is very informational. Good to know! Most of my apps don’t register well with my Android device. Hopefully I can apply most of these info to my device so my kid can better enjoy this educational kid app called Maddie and Matt’s Happy Earth which sends a very good “Go Green” message to kids. Thanks for this! It’s a nice Android app. Here: http://www.maddieandmatt.com

-2

31

Christa Joe

Android has definitely changed the software development practices of organization and companies. Where initially the functionality of the app was considered a major keynote for its success, iOS and Android has introduced the non-functional elements in the applications as well.
Now it’s about the look, user-friendliness and visuals of the app as well along with the functionality of the application. Ignoring these parameters is just unavoidable for a software development organization to build itself as a brand.

Subscribe to our email newsletter for useful tips and valuable resources, sent out every second Tuesday.

Meet Smashing Book #5, our new book on real-life responsive design. With front-end techniques and patterns from actual projects, it's a playbook to master all the tricky facets and hurdles of responsive design. Save 25% today.

Fixing RWD issues can be quite easy — once you understand exactly why they come up. The Mobile Web Handbook will help you understand technical issues on mobile and how to deal with them effectively.

Hungry for more content? Over 60 eBooks are waiting to be discovered in our lovely Smashing Library. And guess what? You can watch Smashing Conference talks there, too.

SmashingConf isn't the eighth wonder of the world, but we are pretty close. Join us at at the shores of Santa Monica for SmashingConf LA on April 27–30 or at SmashingConf NYC on June 15–18. You won't be disappointed.