ListView Customizations

ListView is one of the most useful Android layout classes, but customizing it can be tricky. Part of that is simply glossing over some of the nice features that are already included. It is easy to simply extend BaseAdapter; it is easy and takes care of most the abstract methods for you. But doing so may make you miss some of the nifty built-in features. Below are 3 features you may be missing out on.

1) Custom Types
It turns out that most really good looking ListView’s aren’t just a simple list. The items contain headers, sub-headers, different layouts for different children and so on. But if you extend BaseAdapter you lose all the ability to use custom types.

If you override:
public int getItemViewType(int position) {
return position % 4;

public int getViewTypeCount() {
return 4;

And like magic you have multiple types. The above simply iterates over each type, but real examples would have complex criteria for which type a position is. Then inside your getView simply inflate different layouts for each type and the ListView handles the data for you.

public int getView(int position View convertView, ViewGroup parent) {
int type = getItemViewType(position);
switch (...) {
case 0:
// Inflate type 0.
case 1:
// Inflate type 1.
return view;

2) Custom Separators
Next it may be useful to create custom dividers. But if you do this using items then your dividers will also be selectable. Another nifty method to override is isEnabled. By returning false the item will be visible, but will not be treated like an item but rather a divider.

public boolean getEnabled() {
return false;

public boolean areAllItemsEnabled() {
return false;

3) Setting Stable Ids
The main advantage of stable ideas is the ability to do multi-selection on an ListView, GridView or other View. As long as your ids are unique, you can easily enable this feature by overriding:
public boolean hasStableIds() {
return true;

So while it may seem convenient to simply override the BaseAdapter, don’t forget all the nifty features you may be missing out on!

Android Scene Transitions

One of the less published features of Android KitKat 4.4 was the addition of a new animation framework for Scene Transitions. This is a really nifty framework for developers, because it allows easily providing two layouts and letting the system handle the animations between them. This can be a powerful but simple way to change views around with beautiful animations. While animations in general have been around forever (and they saw a great update with honeycomb) this just makes it even easier. Now you simply provide scenes via xml and let the system do its magic.

Of course with all the new features of Android there is always the question: “When will it be available?”. Since it will probably be years before Android KitKat+ is over 50% of the devices, it is easy to quickly discount the code and move on. Fortunately, though, all the code is Open Source, so I made an attempt to backport the code in a Scene Transitions support library.

In the end the refactoring wasn’t too difficult. Most of the code moved over with minimal problems. But I did run into two big snags, both due to new code.

1) Missing suppressLayout.
New to KitKat ViewGroup’s have a hidden method called suppressLayout. The code is fairly simple, it essentially prevents a layout from being called for some duration of time. The hope was to be able to copy this code over, but my attempt was ruined when I found out that ViewGroup’s layout method is declared as final (which is where the suppression code is). So in order to get this to compile I simply stripped the suppress layout feature.

2) Missing setTransitionAlpha.
New to KitKat View’s have a transition alpha that is composited with their view alpha. The original idea was once again to extend a custom View for this feature. But, since this is applied to all the children in the layout it would be super painful to create a custom view for each of them. Once again the code is stripped. I believe this means views with an alpha less than one won’t work correctly. But if they are few and far between the code could be retrofitted such that only those would have to be replaced.

The result was a mostly working scene transitions. Because of the missing features it is clear to me there will be cases where this won’t work correctly. So use at your own risk.

The final product can be found here: