iPhone Developers, Meet Android – Part II : Look at other Android apps.

Now, that you’ve had the time to empty your mind of all things beautiful and Apple, I want you to get yourself an Android Phone and start looking at Android applications. I know, there aren’t a whole lot of them out there that are actually good, but do some digging, you’re bound to find at least a couple. Look into some of the ones that developers have talked about at the I/O conferences. Study the good ones; learn what design patterns make sense, and what ones don’t. Delve into the architecture of an Android application, use your development phone and get used to the way it behaves. Also, don’t, and I mean DON’T look at any iPhone apps. You do not want to be attempting to mimic iPhone behavior on the Android. Here are a few UI patterns that should either always be implemented or avoided on Android:

The back button is an actual physical button on every single Android phone. Use it. There’s no need for the standard iPhone back button in the navigation bar, or the back button at the bottom of the screen, like in web. So don’t take up the extra screen real estate for one. Let the back button on the device itself handle this. If you need the back button to not kill the current activity, but instead do some other form of stepping back you can do it programmatically: like this

In Android there’s this thing called an Action Bar. Similar to the iPhone’s Navigation Bar, it’s a bar at the top of your screen that adds a bit of continuity to your application, but that’s where the similarities end. On the left hand side, you should always put an Up Button. The Up Button can be your company logo, name, or a form of the app icon, and is used to take the user back to the starting Activity of your application; in the same way an image or button like this would be used on the web. It can also contain buttons, on the right hand side, for common actions used across the entire app, e.g.: Search Action, Account Access, Post New Content, or even a Search Bar.

For the most part, this is a UI Pattern to completely avoid on Android. This is because Android is very much like a website, it’s completely linear. So, from any point in the application if you want to go to a different part of the app and do something else entirely, you either have to backtrack to where you want to change paths or start over from the beginning of the app, losing anything else you’ve done in the process. So, the only way that a Tab Bar can work is if it’s only on a single activity and not retained in the deeper levels of the app. It cannot be implemented in the same way that it is on the iPhone. I could go on for about three more paragraphs explaining why you should avoid the Tab Bar and the appropriate way to implement this UI Pattern, but I won’t. Instead I will leave it at this. Don’t use a Tab Bar unless the data you are displaying and the actions that need to be performed on it require one.

The Menu Button is an actual physical button on every single Android phone, just like the Back Button. Implementation of the Menu Button, unlike the previous three, is not a necessity, but it can be very helpful when needed. The Menu Button, is functionally very similar to the “More…” Tab on an iPhone app’s Tab Bar. When pressed it brings up a list of possible actions, e.g.: Settings, Help, Refresh/Reload Content. The Menu Button acts as a convenient way to access many less prominent, but still necessary actions of your application, without taking up any extra screen real estate.

Alright, I know that I said, in Part I, to clear your mind of all things iPhone. I also know that that’s nearly impossible for you to achieve, and that’s fine. That’s good, actually! Apple’s design is fantastic, it’s a great thing to model your own design after. The main thing to understand is that Java and C are two entirely different languages. Therefore, Android and iOS are two completely different platforms, so you have to build every aspect of your app based around the strengths and weaknesses of Java, not Objective-C.

So, just remember, this is not iPhone.  As long as you’re careful to treat it as such, to pay attention to what makes Android what it is, you’ll be fine. Just like Apple enforces their own UI Patterns and specific design principles, you have to enforce Googles UI Patterns and design principles.  You want your app to feel as much like a part of the device itself as the very OS that it runs, as soon as you start breaking away from that look and feel you start to lose your users’ interaction.  It starts to feel like an entirely separate activity that they’re required to use their phone to interact with, instead of one of the many impressive functions of their phone.  So, study your Android device, learn what those patterns and principles are so that you can enforce them yourself, because, unlike Apple, Google gives you the freedom to completely ignore the boundaries of good design.