The idea of this blog post came from this stackoverflow question. Since I just updated my app using most of them, I wrote how and why did I change stuff. Here we go...
One year ago or so I was releasing my first android app to the market. A Traffic status application for my home city, Buenos Aires, Argentina.
Just to place you in the correct time frame, the Google IO 2010 was just finished, the twitter app was release and a lot of new android UI patterns were out. Unfortunately there were no third parties to apply this UI patterns so I basically did what I could.
I recently updated this application and instead of using my approach I migrated most of my code to third parties. I will try to show how it look in the past and how it looks today.
The home screen is was the user sees the first time. It's usually a combination of an ActionBar and a DashBoard with all the possible actions for the user. We can compare the old and the new one in figures 1 and 2.
Figure 1: Old Home screen.
Figure 2: New Home screen.
Quite different, huh?
Let's see how I changed that.
This UI pattern was introduced by The GoogleIO and the Twitter app.
As usual, no source code, no library.
In estadoDelTransito it was implemented as a custom title bar. It was an ugly hack. After the google IO app source code was released, I noticed that the correct way to do it was removing the title bar and adding a widget in your layout which would work as a title bar.
Now adding an ActionBar to your application is very easy thanks to Cyril Mottier, author of GreenDroid. You can download GDCatalog and see how it's used.
The dashboard pattern is about showing the user what the app can do.
Lot's of apps use this: GoogleIO, Twitter, Facebook, Hubdroid.
In the past, I just did a RelativeLayout and I placed different items in the screen.
Nowadays you just need to place an extension of ViewGroup created by Roman Nurik. You just need to place this DashboardLayout as your parent view and place some Buttons with the android:drawableTop property.
You can notice that my version centers the items while Roman's use the whole screen. Roman's version also fixed how it was viewed in ldpi displays.
Long press vs Quick Actions
The long press actions and the menu options was something I hated in Android. It was hard for the user to notice there was more functionality behind a long press or contextual menus when hitting menu. Fortunately, they are disappearing. For instance, in Android Honeycomb I don't remember seeing any of them.
Where I used them in estadoDelTransito?
a) All activities have a menu option to go back to the Home Screen. The explanation for that functionality is simple. If you travel throughout the app going back to the home screen would require a lot of back button press.
The menu option was replaced by an ActionBar button. Every screen has a HOME button on the upper left.
b) Long press in ListView's items get a contextual menu providing additional actions for that particular item. Most of the people that used the app didn't notice the existence of the long press functionality. They clicked on an item but nothing happened. You can argue that they were not android users but even myself missed some app's functionality just because I didn't try a long press in certain items. You can see how the long press menu looked like in Figure 3.
Figure 3: Long press menu in the old version
QuickActions to the rescue
GreenDroid also provides quick actions.
I don't like the fact that you need to extend GDActivity to provide quick actions. In the case of estadoDelTransito it works fine because I am using the ActionBar but now I am working in an android 3.0 app and I don't want to extend GDActivity. What if I want quickActions in a Fragment?
If you just need quick actions I would recommend you to use this.
I didn't notice an issue with this until I listen to a talk by Reto Meier. He basically mentioned that, why would you use a ProgressDialog? Freezing the UI thread and placing a ProgressDialog feels the same, get rid of them.
In estadoDelTransito when you enter a screen, a ProgressDialog screen will show up until the info is updated. What's even worst, by default the ProgressDialogs are not cancelable, so if the user's internet connection was slow, he was stuck there. You can see how they looked in figure 4.
Solution? Use the ActionBar. Make the refresh widget spin there while the data is being loaded. If the user wants to go back, he can.
Figure 4: ProgressDialogs in action.
Adding map overlays for this kind of app it's a must but showing custom views when the user clicks on the map is not as simple as I would like it to be. In Figure 5 you can see how I did it in the past.
In the new version I am using a cool third party lib by Jeff Gilfelt called android-mapviewballons. I guess you can imagine what's for :)
Figure 5: Old popup for GMaps.
With the creation of Android libraries a lot of third party libraries came out. You just need to visit github, search for android and get an android library for what you are willing to do.
Nowadays, making your app look good is just a matter of seconds. There are no excuses :)