Android Development Series, Part 1: Proper Design Constructs

I’m going to be doing something a bit different on LockerGnome for a while. In quite a few of my posts, I might have mentioned that I develop Android applications (namely Hubroid, a GitHub app). I also have seen quite a few people pop up from time to time asking questions regarding getting started in app development, so perhaps more posts like this will be beneficial to them.

Anyway, for this first post, I think I am doing something a bit out of the norm for development series and such. Rather than jumping into how Android apps work and whatnot, I’m going to touch on a much, much more important hurdle first: UI Patterns.

Android Development Series, Part 1: Proper Design ConstructsGoogle unveiled the Android Design site a while ago, and its inception has spurred lots of changes in the developer community. Developers have a firm idea of how their applications should look, feel, and behave in particular situations, which is probably more important than what the app does in the first place. Before you pick up a code editor and being coding, I ask — no, beg — you to read through the design recommendations. Not only will you have a strong sense of where your application’s UI and UX (that is, user experience) will go, but also a host of prepared patterns and building blocks ready to go, courtesy of Google.

I often hear Chris complain about the inconsistencies in Android’s user experience. Most of these inconsistencies, however, are the result of app developers failing to build quality apps that flow with the rest of the system’s design. Of course, some blame does fall on Google and the Android team in that they should have been on top of this from the get go, but the Android Design site is definitely a step in the right direction. Ice Cream Sandwich is definitely a whole new, clean experience. If anyone complains about problems with the Android experience now, I think it will be pretty safe to assume that lazy app developers are to blame.

With all that said, here are a few “must haves” for your Android application’s structure and design:

  • The Action Bar – Replacing the traditional Android menu construct, the Action Bar is where users should go to get stuff done. That is, the Action Bar is the central hub of navigation and contextual actions for your app.The Action Bar
    As more applications fall into line and implement this pattern, more users will come to expect this area as the place to look to work with the app. Implementing is simple to do on Honeycomb and Ice Cream Sandwich, but still easy to do on previous versions with a little help from Jake Wharton’s ActionBarSherlock library.
  • Fragments – Quite an intimidating beast when you first dig into them, Fragments are part of Google’s answer to the growing number of screen configurations available on Android devices. Think of Fragments as tiny pieces of UI or logic that exist within your app. You can then mix and match Fragments on a single screen to optimize the experience for any configuration.
  • Consider tablet configurations – While a few developers have begun to pick up on the basics of the new Android design guidelines, many still fail to consider the massive increase in screen real estate that becomes available when a user hops onto their tablet. Your app might rock on a phone, but if the tablet simply adds 100x more white space, you need to sit down and organize a more efficient layout.

Above all, you should never, ever try to mimic the look or feel of another OS on Android. The official Twitter app on Android is one example. It originally fit quite well with the design guidelines when it was originally released (as part of a Google I/O event a few years ago, I believe with Google in control of the app’s design). However, once Twitter had some time alone with it, it became an ugly mix of patterns and whatnot, taking a bit too much from the iOS app. So there’s that point: iOS looks incredibly ugly on Android. Especially the pull-to-refresh pattern. Yuck.

I suppose that is all for part one of this series, which may or may not ever see a continuation. Perhaps next time we’ll get around to some code or fancy Android wizardry. I shall leave it up to you all: more of this, or move on to something else?