Android introduces different ways to use your tablet device. To help you build a User Interface that looks great and accomplishes your goals, we’ve developed these guidelines. Read through them, watch the videos, and read the additional documentation found in the included links and you’ll be well on your way to understanding the Android User Interface goals. Some of this information is also found in documents provided by Google. This is intentional since the goal is to remain consistent with the intended Google design and evolving usage models for Android.
With the freedom as an open platform that Android provides, comes the responsibility to learn and follow the applicable guidelines. This helps your application benefit from consistency of design and thus your application will react to your user’s actions in ways they are comfortable and expected.
Google has published a rich set of User Interface Guidelines for icons, widgets, activities, and menus, and more. Reading and understanding the guidelines is one key to delivering expected functionality. Start with these guidelines and build from there and your application will be well on the way to feeling comfortable and familiar to your users.
To train developers Google has placed many of their Google I/O session videos online. This Google Video is a beginner’s guide to Android from the 2010 Google I/O.
While the mobile devices we have today and incredibly powerful compared to computers of just a few years back, they don’t compare to the memory and processor power your desktop computer has. Because your users are mobile and using your application as they move about, you need to keep your application fast and responsive. Your users could be on a bus or train in a moving environment and need to be able to reliably use the UI (can they press a small button when the screen is moving around?). Additionally you need to account for the possibility of drops in network coverage.
Your users should ever see the Application Unresponsive dialog, which appears if your application does not respond to a user action within 5 seconds. Users will typically notice a delay of even half a second.
A powerful technique for keeping your UI responsive is to use threading. When a user starts an Android application, Android creates the main thread, called the UI thread. Be careful not to do long processing in the UI thread. This main thread needs to be responsive so it can dispatch widgets to do the bulk of the processing. Brad Fitzpatrick of Google explains how to keep your UI Zippy in this video:
How to respond to touch is one of the key aspects of the Android UI framework. Android devices have touch screens, and you’ll need to design your application to support touch well. Touch mode usually has no focus and no selection, and moving between touch and other modes (lists for example) can make focus and selection disappear or reappear. There is an exception called focusable in touch mode.
Make sure your buttons and widgets are large enough to be touched when needed. It’s very frustrating for a user to touch a widget only realize they actually touched an adjacent item. Along the same line of thinking is that you need to provide a way for your users to back out of an accidental press. Verify that your buttons look and fit well on screens with different resolutions and densities. Design your layouts to adapt to multiple devices.
This Google I/O session talks about Android UI design issues and consistency with the Dashboard, Action Bar, Search Bar, Suick Actions and Companion Widget:
One of the great benefits of using handheld and portable devices is the sensors they support. Applications that respond to the sensors in ways that make sense, work and feel as natural extensions to the actual devices. Possibilities include a wireless keyboards, navigation devices such as stylus, air tracking and other inputs. Compelling UI can also use the positional sensors, gyros and accelerometers in various ways as the application allows. As you review the possibilities consider the existing sensors on current devices and ponder ways you could use and support them. This includes location aware support.
You are designing your application without knowing which exact device your application will be supporting, what user actions, assumptions and behaviors will be, including both touch and non touch devices. Be certain that a given sensor is working on the current device before assuming you can get input from it. Don’t lock your user into an action they won’t be able to get past. The on screen keyboard can be awkward to generate certain multi-key combinations, avoid those.
The Android overall design is based on structuring your application using the Android framework, then modeling the desired behaviors your application supports and then expressing that via the UI so the user can accomplish the goals you are designing around. Just what does all this mean? This Google I/O session discusses interaction and visual design with Android
How do you apply this to your application? Understanding your users, their tasks and what your application provides and why they are using it. Remember that Android is a multi-tasking platform; a user can be in the middle of one task and quickly switch into another. As we have all experienced, we’re browsing and get a phone call, or an email or instant message. Save your state when you receive the onStop call. As shown in the Activity Lifecycle diagram below, while the Activity is stopped, the process could be killed so saving state is necessary to avoid losing user state and or data. Melding what your user expects your app to do for them with the realities of Android development as shown will keep your users happy. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle
Android has been built to allow applications to share both functionality and data. Functionality is shared using intents and data is shared using content providers. This sharing of functionality and data helps Application developers build in each other’s work and avoid redundancy. To see some demos of this in action and help understand how it works, here’s a video, “Apps without Borders” shared by Google to demonstrate the functionality:
This ability to share functionality and data also means you have to be careful in designing your application. The previous Application Lifecycle shows how you need to respond to events due to situations such as low memory where your app could be shut down to allow another activity to gather data for you. Your application becomes dynamic and works correctly even if several other applications were run as you were waiting to get started again.
Android devices allow their screen orientation to change from Portrait to Landscape and back. The implementation can vary by device and application. Many devices have a setting to enable their users to choose if applications rotate when the user turns the device or remain fixed at a given orientation.
Often an application can override the user settings based on the design of the individual application. If the device has a physical keyboard, applications can change orientation when the physical keyboard is opened or closed for use. All of these varied abilities demonstrate why your application must be prepared for an orientation change. It is possible to design your application to remain in our mode but make sure your users will be happy with that choice for their needs. What about the next as yet unreleased device?
In the Application design, the orientation change is handled in layouts, via either XML or Java*. Most of the time you need to design separate layouts for portrait and landscape modes. Google refers to the Amazon MP3* application is a good example of separate layouts. Here’s a screen shot from the video. Notice that in the vertical orientation the 4 buttons are stacked. On horizontal orientation there are 2 columns of buttons.
The flood of new Android devices being released continues. What is the default screen size? What is the default orientation? These questions aren’t easy to answer, so Android provides support for adaptable layouts. Use the adaptable layout methods in your application design to make sure you support the current and evolving devices. Use the layouts to support screens of differing sizes, resolutions, densities and orientations. As far as possible, try to develop your layouts so they adapt to multiple devices.
This Google video gives many great examples for supporting multiple devices with one binary:
Choose a layout that adapts, like LinearLayout or RelativeLayout, avoid AbsoluteLayout, it will lead to problems. Use the scalable High, Medium and Low density facilities to provide icons and objects you have scaled in advance to support devices of varying densities. Using the XML layout design abilities instead of hard coding your design in Java will help your code adapt to the evolving nature of devices.
Battery life and performance have long required a fine balance in hand held devices. To assure that your devices can last a full day, each application needs to be a good citizen on the device. There are many ways your application can waste power. Assure you only use sensors and connected devices that make sense. Here are a few specific optimization examples
Google has some additional guidance on this topic which can be found in this video titled “Coding for Life, Battery Life that is”.
To learn more about Intel tools for the Android developer, visit Intel® Developer Zone for Android.
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804