So you want to write an app

So you’ve decided that you want to start programming applications for your mobile phone.

 Be it for money or purely an interest in development, programming on the Android platform is a fun and simple way to get started in mobile development.

If you are like a growing number of people in the world who own a smartphone  you realize that the smartphone has become more than a simple voice communication tool. It is where you can access all your social networks, emails, calendar, music, videos, entertainment and as much reference material as you need. The smartphone has rapidly become one of the most important devices in our lives.

Consider for a moment what you do before you leave your house;  keys, wallet, mobile phone. These are the three things that you will go back to your house even if it means going back through traffic, uphill with a nasty headwind. The only modern entry on that list, the mobile phone represents our ability to connect with the rest of the world. It is an amazing tool. The average smartphone user has access to more information at their fingertips than most of the people throughout the previous 1000 years of human history hand . That is an impressive assertion, that you can wiki on your smartphone if you would like.

So in a sense the smartphone turns an average person into a superhero. For instance with a wave of your wrist your smartphone can;

Never require that you stop and ask for directions. With GPS and digital maps of the world you can drive right past that creaky gas station and on to grandma’s house. This doubles as a marriage counselor for those spouses whom refuse to stop and ask for directions. Now we don’t have to!

Entertain You. Smartphones have the ability to store hours and hours worth of music and videos. Add in high-speed networks and you have a full multimedia complex at your fingertips.

Make you a “Name That Tune” Superhero. Never again will your mates bug you at the pub for not knowing the tune “Welcome To The Jungle”. Applications running on the smartphone can identify the background music playing and send all the information to you. If you like it, the program will also let you download it for a fee.

Answer Any Trivia Question. With high speed access to the internet over the phone you can literally answer any trivia question within seconds.

Play With You. Smartphones are now coming with advanced graphics and computing processors that can let you play many games right on your device.

All of this is just a sampling of what the smartphone can do. The smartphone can do all these things because it enables mobile applications to run on the device. Mobile applications are really what drives the smartphone usage and most importantly why you are reading this article.

So where do you begin? Well the good news is the mobile application development is much easier today than it was before[1]. I started mobile development back in 2003 on the Motorola i710 handset. It was big, clunky heavy device that had a small screen and almost no data connection. It featured a heavy clamshell design useful for propping doors open or beating off potential muggers. But it was a mainstream device that allowed installation of external J2ME applications and opened the door to a lucrative opportunity to build mobile applications. Creating mobile applications for this device was long, laborious and expensive. Our first application took almost a year to complete all the way through development, certification and testing. Once the application was built there was no simple way to get the application to consumers. Each network operator and carrier had to be sold the application separately and managed their own application store or deck. Each had their own requests and requirements for the application which made it even more difficult to succeed.

But by far the most difficult part was the requirement to port to different handsets. You see handset makers and carriers each decided to interpret their own version of the write-once run-anywhere paradigm. This meant that each device and each firmware version of the device had different features and different restrictions. Imagine having to write a different desktop application for someone with a 15” monitor versus a 19” monitor. With so many device nuances it was often much easier to produce a separate build for each device. This resulted in managing somewhere in the range of a couple of hundred different builds for devices. Any changes in the codebase had to be propagated across the builds which made code management a nightmare scenario.

Luckily some very smart people saw this situation and worked very hard to remedy it. The Android operating system grew out of these platform challenges as a way to simplify and optimize the mobile experience for multiple devices. 

 Of course today things are much different. Mobile platforms are more capable, faster and the development environments provide a much wider range of tools for development. Also if you add in the availability of application stores for marketing your product, mobile development has taken some great leaps forward in terms of simplicity and effort.

Even with all the changes in the mobile development arena the core skills to develop a functional and useful mobile application remain the same. This article is designed to not only give you a good understanding of the Android programming process but also teach the art of programming for mobile devices. Over the next couple of articles we will be creating a full Android application from design to deployment. We will walk through what it will take to build a full application and go over some pitfalls to avoid and shortcuts to make your programming easier.

Unlike gambling, programming for the Android platform is easiest to learn by doing it. Feel free to work through your own application along with the book or follow along with the application that I have created. By the end of the book you should be experienced enough to build, deploy and even make money from the Android platform. At least much more than you would have made by gambling.

What makes mobile programming different?

To see how designing a mobile application is different than a desktop or web application we will compare how the users typically interact with the program and what makes a truly useful application.


Consider for a moment the very simple task of navigating through a menu on a desktop or web application. A user will click with their mouse on the menu header and pull down a submenu to highlight the function they are after. In terms of UI design you have to layout the menu components in a logical fashion and make the information easily available. Add some pretty icons and transitions and you are about done, collect $200 advance to go.

The UI model for web and desktop is essentially standardized across the platforms. Whether you run a Windows, Linux or Mac OS they still offer the same windowed application experience. For instance, users have a certain expectation that the close function at the top right (or left) of an active window will close the window and terminate the program. In these applications what you will not see are applications that use as their main input something other than a keyboard or mouse. There are no applications that use an accelerometer for navigating spreadsheets[2] or voice commands for IM.


On mobile things are significantly more complicated. There are no fixed set of input devices like a mouse and keyboard. Devices can take input from a keyboard, trackball, touch screen, light sensors, GPS, accelerometers or other sensors. Some devices are designed for one-handed use some require both hands for input. To further complicate matters, devices are not required to have a standardized minimum set of input sensors. That means any application design that you build has to be adaptable to a variety of input sensors if it is to work across many devices.

Of course making a UI that can utilize a variety of input sensors is challenging enough, but in a mobile device you also have to consider that you are constrained by processing power and screen size. This is the main reason why the mobile industry has no standardized UI design. Different UI interfaces add to the complexity of the application and more often than not will require multiple versions of the application to work around the differences. Applications that are intuitive and designed for one device may be obtrusive and unusable on another device with different input sensors. Entering text into a field can be done by T9, physical keypad, touchscreen or even voice input. Menu navigation is equally complex because there is no assumed protocol for opening menus. You could use a trackball, scroll wheel, navigation pad or touch screen. So even in the most basic of features the mobile application has to consider significantly different UI and input constraints for it to be functional.

Just when you thought it could not be any worse, you also have to consider the users themselves will use different sensors for interaction on the device. Some users will prefer to use a keypad rather than the touch screen and that means you need to ensure multiple forms of input are capable for your application. The best mobile applications have a UI that can utilize all the sensors and have multiple points of access for the information.

That is the bad news.

The good news is that device manufacturers and platform companies are trying hard to create a standardized set of interfaces so that applications will run smoothly across a number of devices. Well that is not strictly true. RIM (Blackberry) is working really hard to ensure their platform is consistent. Apple ensures that all Cocoa apps are seamless across their devices. Nokia supports families of devices with consistent interfaces. Windows new mobile platform will do the same.  So if you as a mobile developer wanted to create an application that runs smoothly across all those platforms you will need to create multiple applications and multiple designs, one for each platform.

This inconsistency is what first drew me towards Android. Android is an open source initiative by a number of handset manufacturers, service providers and application developers that creates an environment that standardizes some of the most common navigation and interface elements. All Android devices will require some fixed navigation elements and that is the key to a consistent UI. By using these standardized elements in your design you can eliminate much of the UI complexities and focus on UI features that will enhance your application. What this means to a developer is that an Android application will run the same on a Motorola device as it will on a Samsung device even if the screen sizes, processing power and input sensors are quite different.

Since the device plays such a large part in the success of your application you should consider how to seamlessly integrate your program into the existing platform. The most successful mobile applications will serve to enhance the experience of the platform and device and not duplicate another environment. 


User Feedback Techniques

Back in 2009, I gave a presentation on user feedback techniques for the London 2009 Symbian Expo. For those that don't know, Symbian was the original smartphone OS. For it's time, it was fast and capable but through a combination of poor management and lagging updates it eventually was phased out of use. 

However the presentation itself is still valuable for understand NPS and how it can be used for driving development in the right direction. 

The absolute minimum Android developers need to know about UX — Part 4 of 5


Constraints is a design principle in which we limit the actions the user can undertake in order to direct them to the most appropriate action. That seems simple enough. The actual definition of constraint extends to the limits of what the system can do. A mobile device is constrained by it’s physical limitations of screen size/resolution, touch inputs(typically) and the array of sensors that help manage the input. In Android, you are also constrained by the OS and some controls (back/home). So the principle of design constraints is quite large but for our purposes we want to limit the constraints to those that are adjustable by our development. So our specific definition of constraint will be left with, What elements can we constrain within our design to encourage the user to take certain actions?

Thinking about constraints in this manner will make things easier.

The most obvious of these constraints on mobile is to toggle active buttons until the user has entered the correct text or another action is completed. For instance, when a user is entering login information we will need to disable the “login” button until such time as we have checked the username and password against being empty or against whatever screwed up password scheme has been foisted upon you.

Instagram does a good job at disabling the functionality until you have entered your information. But here is the important part, it isn’t good enough that you disable the button in your code but you also have to visually indicate to the user that it is disabled. Color State List provides the easiest way to implement this without any complicated code.


<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="">
<item android:state_enabled="false"
android:color="#ffff0000"/> <!-- hidden -->
<item android:state_focused="true"
android:color="#ff0000ff"/> <!-- focused -->
<item android:color="#ff000000"/> <!-- default -->

This layout XML will apply the color list to a View:

android:textColor="@color/button_text" />

Enabling or disabling a button is a good way to constrain the users actions, and restricting those actions is good practice. This also applies to any delayed actions after the button is pressed. On a login page, you may have to verify their credentials with a server and in the meantime you should disable the button until they can act on it. [Hint: Disabling the buttons after they’ve been pressed also prevents the user from mashing away at them because you didn’t implement your Feedback correctly. ]

Dialogs are another method of constraining the users actions to a specific task. They force the users attention to a very narrow task and do a good job of constraining the actions that they can accomplish.

However, I’ve found dialogs are often overused as a crutch for poor architecture or design. Too many developers want to constrain a users actions because they need to handle background tasks. [Hint: Your technical issues are not the users fault. Don’t bother them with it. I’m looking at you working and busy dialogs. ]

Although worthy of it’s own article, dialogs should be used sparingly and with the understanding that you are constraining a users actions regardless of what they were trying to accomplish. Interrupting their current actions for your constraint may not always be the best user experience. (see clippy)

Dialogs can be used effectively if you stick to a couple of heuristics;

  1. Always stick to the Android convention of Cancel button on the left, Action button on the right. No exceptions.
  2. Usually, when there is no Action button, there is no Cancel button. That is if your action is in the dialog like selecting from a list there is no need for a Cancel button, the back button should handle that.
  3. Usually keep your dialogs to a single action. There are cases where you may have a couple actions to complete but try to minimize the number of actions within a dialog.
  4. Never nest dialogs. Dialogs should not open other dialogs. It’s way too confusing for the user.
  5. Never interrupt a user when they are in the middle of an action. Dialogs are distracting enough so they should not force an action where the user doesn’t want it.

Dialogs - Components - Google design guidelines
Dialogs inform users about a specific task and may contain critical information, require decisions, or involve multiple…


(This section has a lot more opinion and personal experience in it than previous sections. Take it with a grain of salt)

The principle of Mapping or Natural Mapping relates to how an application controls translate to the appropriate action. In the real world Natural Mapping is usually based on a physical spatial relationship. Take a simple toaster for example. Pressing down the toast lever to make the toast go down. The action of pressing down on the lever translates into the toast (bread technically) going down as well. It’s a Natural Mapping between the physical action of the lever and action of the toast.

If toast comes out, where did the bread go?

On mobile or digital devices the natural mapping is slightly more subtle with its implementation and relies more on convention over spatial relationships. What I mean by convention is that there are a number of assumed relationships that users of those devices will immediately assume without you having to prompt them. And what I mean by that is that there are “Android” ways of doing things and you should do that.

Content will usually scroll top to bottom, forward buttons on the right, back on the left, Menu on the top left hamburger icon. Those conventions are usually platform specific and while they don’t usually correspond to a physical action they are still “natural” motions for the mobile device user.

Mapping conventions are where users expect actions to be. This may not be the same on Android and iOS and as a result your designs should be adapted for your specific platform. You cannot carry one design between two platforms effectively

On Android, those conventions are loosely documented on the Google material design site, mostly in the form of “Best Practices” or layered deep within a component specification. The problem with those cultural conventions is that they really depend on the user. Like any true Scotsman,cultural conventions are dependant upon the user and it doesn’t help that we’ve migrated from different design patterns in Android since 1.0.

Additionally, your user base may be different in how they expect the device to function and their expectations for mapping will differ than others. There is no easy way to determine this and outside of A/B testing with real users there isn’t much you can do.

But A/B testing doesn’t need to be complicated. In the past I’ve pointed a camera at a device and asked the user to talk through their thinking out loud. It is really enlightening to see how users engage with your app and you will be surprised at how your expectations are wildly different from your users. In one situation I was surprised to find that most users will ignore the Toolbar overflow menu almost entirely during testing. The Google Design spec includes it as a component but for our use case we needed to move those features out of the menu because of the results from testing. The Natural Mapping for this user didn’t include the overflow menu and it would be a poor design on our part to include it.

Of course, as any true Android user knows there are a couple of conventions that shouldn’t be violated. Here are a couple of my personal conventions that I have found that most users like to follow. Feel free to comment in below if you have any others.

Let’s talk about Back.

The soft/hard back button is a confusing combination of back navigation and undo. In my opinion, undo should always take priority over back navigation and you should override the OnBackPressed() function for actions initiated by the user. That means if you pull up a dialog, back should close it. A menu drawer, back should close it. Halfway, through editing a field? Back should revert the changes and stop editing. Only when there was no action does back navigate back through the stack. Intuitively this is how I look at the back button. If anything ever goes wrong, back will fix it.

Gestures and Scrolling Directions

Gestures are a great placebo for Natural Mapping. They seem like a good idea at first but never seem to work out. Unlike normal placebos these can often have the effect of being more detrimental for mapping than beneficial. Quickly, which direction should you swipe to delete an item? Do you scroll the item up or move the content down? I don’t believe there is a convention for swipe gestures so making the assumption that your users have one won’t work. I usually avoid most gestures within an app for this reason.

EditText and Form Field Navigation

While I would prefer to never enter text into any application eventually something will have to go in. I don’t think I’ve ever entered a form (digital or otherwise) and said “That was truly enjoyable” but we can at least strive to make it less painful. Handling Input Types training on the Android developer site should be read and enjoyed. You can setup your form so that you advance to the next field using the keyboard and submit it with the IME_ACTION_DONE feature without ever closing the keyboard. Having to click on a field, edit that field, click on another field is a painful way to enter data.

And if you ever have a user enter data in landscape mode, always include the following option in your EditText field.


Without it the Android keyboard might take over the whole screen. Users will have no idea what they are entering. I can’t imagine a more painful experience than that. (Relevant SO)


  1. Constrain your UI when the user has to perform a series of actions. Like disabling buttons until the text is entered correctly
  2. Always visually indicate when you are constraining an action to prevent confusion
  3. Use dialogs sparingly and only cases where it requires the users immediate attention.
  4. Stick to Android conventions when building your design. When you are unsure test your assumptions on real people.

The absolute minimum Android developers need to know about UX — Part 3 of 5


Design principles from Don Norman’s Design of Everyday Things provide a fantastic overview of the fundamental principles in industrial design. Those same principles apply to any type of design and are especially relevant in digital and mobile design. But like many academic principles, implementing those principles in a practical sense is often difficult. What I hope to learn with these articles is some practical ways of implementing that within Android. Feel free to correct me when I’m wrong, I’m learning this too.

While the first two parts of this series worked on some fairly high level design concepts that are usually part of the design stage. This part will focus on those principles that are more the responsibility of the developer. Yes, even those developers that have the luxury of working with a professional UX team have to be able to assume some of the responsibility for the user experience.

Feedback and Consistency are best described as the “little things” that can be handled by developers. Both are simple concepts but require a little rigour in your development practice to ensure that they are followed. I use a couple of internal rules to ensure that they are followed but the principles are simple enough that with a little foresight and developer can ensure they are implemented with great success.


Probably the easiest and most intuitive concept to understand is the idea that each action should provide appropriate feedback such that the user understands that something is happening or about to happen. A state change happens when the screen updates with new information, typically in response to a user action. Letting a user know about state changes is critically important to your usability. Imagine how frustrating a toaster would be if it didn’t indicate when the toast was done. “Burnt Toast” is probably the same way your users would feel if you lacked appropriate feedback within your app.

Feedback that is poorly implemented is almost always responsible for very frustrated users. Did I click that button, I thought I did? Maybe I didn’t? Should I do it again? Will it break this time? Implementing smart feedback has to be done in a conscientious and purposeful way to make sure the user doesn’t get confused and frustrated by the device.

So how do you know what is appropriate feedback? Primarily it means communicating to the user every time you make a change to the state or perform any action they need to be aware of. In Android the easiest way to think of a state change is anytime you update a View. This means after the initial render you must think about feedback in terms of any further changes you make to the view.

If you are making a change to a View within your application you should consider what feedback needs to be communicated to the user. Rarely is the answer “Nothing”

For instance clicking a Button should change the colour, elevation or even provide haptic feedback. Otherwise the user has no way of knowing the button press even worked. That change should be immediate and visible to the user. That’s the kind of feedback the user is expecting. It gives them the sense of completing an action. It is also one of the easiest to implement. You can theme all your buttons with the following code;

<style name="MyApp" parent="Theme.AppCompat.Light.NoActionBar">
<item name="android:buttonStyle">@style/MyButtonStyle</item>
<style name="MyButtonStyle" parent="Widget.AppCompat.Button">
 <item name="android:background">@drawable/button</item>
<item name="android:foreground">?attr/selectableItemBackground</item>

That’s it. Apply a Drawable State Resource as a background and an animation on the foreground. All your buttons will be theme’d the same way and act the same. Consistent feedback to the user. Without it, users will hammer away on the buttons (you are running a debounce right?) thinking the action is delayed. Honestly, it’s a pretty simple addition. Try it with and without the button feedback and you’ll notice the difference immediately.

Simple animations and transitions work great for immediate feedback and should be used often. But what happens if your state/View change takes a little longer. Your app might do some processing, retrieve data from the network or transitions to a new page. For those actions that are delayed what type of feedback should you be sending to the user? Should you be showing a dialog or progress bar, or maybe nothing at all?

Jakob Nielsen, another pioneer in UX design implemented a set of rules for response time for web users based on digital interface rules.( Those rules haven’t changed since 1968 [Card, 1968] ). I’ll repeat them here (abbreviated) since they provide a great guideline for different types of actions to display.

  • 0.1 second is about the limit for having the user feel that the system isreacting instantaneously
  • 1.0 seconds is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay.
  • 10 seconds is about the limit for keeping the user’s attention focused on the dialogue.

Using those response times as guidelines we can come up with some rules around what types of feedback you should be looking at based on how long the view takes to update after the user performing an action. Like when a user clicks login…

At 0.1 seconds this is the level that is at the limits of the users ability to see the change. If you have a state or view update that happens in less than 0.1 seconds you might want to consider slowing it down with an animation. For instance if you are updating a ListView from a local database, new items can be added very quickly and the user might not see that change. Having a ListView change unexpectedly is jarring to the user. Using anRecyclerView.ItemAnimator is a simple way to implement proper feedback about the state change to the user. Animate the components in when the update time is less than 0.1 seconds.

Up to 1.0 seconds is about the limit that users will wait for feedback on an action without getting annoyed. Greater than this delay you will need to let them know that something is happening. Convention tells us that we need to add a progress bar. My preference is to put the progress bar directly on the content that will be changing (i.e. progress button) but wherever you are putting it should be consistent with what the user expects. (Spoiler! Consistency below)

Up to 10 seconds is about the limit the user will wait without any other feedback. What this means is that even with a progress bar showing an action delay you will have to provide some sort of other feedback showing the progress. At 10 seconds a progress bar will need to display a progress percentage and not just be indeterminate.

Proper feedback within an app is a straight forward and fairly routine to implement. TLDR; for Developers…

for(View view: updatedViews){
if ( delayInSeconds <= 0.1 ){
} else if ( delayInSeconds > 1 && delayInSeconds < 10){
} else{


The second principle in this section is another simple concept although I’m consistently (ha!) surprised at how often it is violated, especially in terms of making an app “unique” and “different”. Consistency refers to the concept that similar actions use similar components. Drawer Button opens a Drawer Menu, Action Bar menu key opens a quick menu, Back button actually goes back. Consistency is important because it allows the user to understand what an action does even if they haven’t seen it before.

For Android, consistency applies in two core ways;

First, is internal consistency. That applies within your own application. You should make sure that actions that the user engages with are consistent. If you have a page where you add content by clicking a floating action button, you should try to maintain that language. Adding any other content should use a floating action button also. That consistency provides a natural mapping for the user and they become proficient in using your application.


Skype, strangely consistent UI

Skype, strangely consistent UI

Skype implements “Add Contact” and “Add Call” in the same fashion on the image above. Users have an easier time understanding the language of the app and can navigate the two screens with relative ease.

Implementing an internally consistent interface is a matter of being lazy. Find simple components for your user interact with and reuse them across your app. As a double bonus, reusing the same UI components for similar actions makes your code easier to manage.

The second, and more problematic consistency issue relates to consistency within the Android ecosystem. I understand app developers want to make a stamp with their new, innovative and different app but changing the interface patterns the user is accustomed to creates a frustrating experience for them.

Jakobs Law, users will spend most of their time with other apps.

On average users engage with roughly 26 or 27 apps per month. That means your app occupies a small portion of their day and attention. If you want to gain the benefits of consistency you have to consider how the other apps implement similar functions. You can see where this is going, Material Design standard.

The Google Design team has created a great product with Material Design. It is built to apply a consistent interface across multiple applications. Whether you agree with the design choices or not, the Material design specification is what the user expects and if you want to be consistent you should implement the interface with religious fervor.

Design | Android Developers
Create beautiful experiences in your

What I’ve seen more than once, is Android developers will port an iOS or Web application over to Android without modifying the UI in any sense. iOS and Web UIs are functional and very good for the the ecosystem they were developed in but Android users need the applications to be consistent on theirplatform and the design language from iOS and Web are not compatible with it.

Tip. Don’t directly port the UI from iOS or Web apps. Their design language is inconsistent with the Android platform and even the best implementation will cause confusion with users


  1. Follow the 0.1–1–10 rule with View updates. Each view that is updated should follow the same algorithm.
  2. Use Material Design. Users will naturally understand your application and it will be consistent with the other apps they use
  3. Don’t use the UI from Web or iOS interfaces. The users of those platforms have different expectations for similar actions.


Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267–277.