Kostya Vasilyev's software blog

Android’s ListView has a built-in way to implement fast (indexed) scrolling.

As useful as it is, it has two limitations that sometimes can be critical:

- A section name is assumed to be a single letter.
- If the list content changes over time, it’s difficult to update the section list on the go.

The fast scroller helper class in the framework is closely integrated with AbsListView, and so it does not seem possible to just replace it with another implementation, or change the way it behaves.

I needed one of these for my current project, and found a fast scroller that was posted on Google Code by Android’s Dianne Hackborn.

This code is from 2008, before there was a fast scroller implementation in the framework, and so its way of interacting with the list is different. This class is derived from FrameLayout and should be used in the layout XML file as the list view’s parent.

I combined this code with the fast scroller from the Ice Cream Sandwich sources. The result looks like this:

This class is used the same way as the FastScrollView linked to above – it should be inserted into the layout XML as the list view’s parent.

It has a method for updating the section index, which can also optionally reset the current drag tracking state (or not, specified as a parameter).

The section overlay’s size and its font size are specified as dimension resources. Long (over 1 character) section names are displayed correctly.

Finally, I also fixed some rendering issues on Android 3.0 when running with hardware acceleration enabled.

The code is too large to post here, so I uploaded it to Google Code. A sample / test project is included.

You can get it here: a wiki page is here and the code is here.

Here is another compatibility tip for Honeycomb and previous versions. This one has to with custom ListView item layouts inside alert dialogs.

Ok, so I have a few places in my app that display an AlertDialog with a ListView inside, backed up by a adapter that provides custom item layouts. Getting the text color inside those layouts is a little tricky.

Prior to Honeycomb, dialogs always use a dark background and light text, regardless of which theme (light or dark) is used by their parent activity. This is true for AlertDialogs and plain Dialogs. However, lists inside AlertDialogs use an inverted (light) background. This is usually enabled automatically, or you can enable it yourself by calling AlertDialog.setInverseBackgroundForced. Now TextViews inside item views returned by your adapter can use black text, or, preferably, just in case the color is customized by the device manufacturer, a theme attribute reference (one of textAppearanceMediumInverse, or textColorPrimaryInverse, etc.).

Here is an alert dialog with a list view, running on the Sony Ericsson Xperia Arc. The background is not quite white, it’s a bit greyish (purplish?), and the text is pure black.

The item layout looks like this (only text views are shown):

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
	xmlns:android="http://schemas.android.com/apk/res/android"
	android:id="@+id/pick_attachment_root"
	android:layout_width="fill_parent"
	android:layout_height="wrap_content">

	<TextView
		android:textAppearance="?android:attr/textAppearanceMediumInverse"
		android:id="@+id/pick_attachment_main_title"
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		android:layout_toRightOf="@id/pick_attachment_icon"
		android:layout_toLeftOf="@id/pick_attachment_toggle"
		android:singleLine="true"
		android:ellipsize="middle"
		android:textStyle="bold" />

	<TextView
		android:textAppearance="?android:attr/textAppearanceInverse"
		android:id="@+id/pick_attachment_sub_title"
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		android:layout_toRightOf="@id/pick_attachment_icon"
		android:layout_toLeftOf="@id/pick_attachment_toggle"
		android:layout_below="@id/pick_attachment_main_title" />

</RelativeLayout>

On Honeycomb and later, if you use the native, Holographic, themes, dialogs can be light or dark, matching the parent activity’s theme. AlertDialogs with lists look the same as regular dialogs with text, so this is what the above layout looks like on an Sony Tablet S running Android 3.2:

The text views turned invisible, white on white. How did this happen? The dialog’s background is no longer inverted, as the dialog’s theme matches the parent activity’s, but our text appearance references still assume inverted background: for a light parent theme, it’s “whatever text color is appropriate over the inverse of a light background”, in other words, “whatever is appropriate for a black background”, which is white. Switching the parent activity to a dark theme produces black text on black background by the same logic.

Ok, so for Honecomb, we’re supposed to use non-inverted theme attribute references. How to do this without duplicating our layouts inside res/layout-v11? My solution is this:

First, define these styles inside res/values-v4/list_styles.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>

	<!-- Text for listboxes, inverted for Andorid prior to 3.0 -->

	<style name="MyListTextAppearanceSmall">
		<item name="android:textAppearance">?android:attr/textAppearanceSmallInverse</item>
	</style>

	<style name="MyListTextAppearanceDefault">
		<item name="android:textAppearance">?android:attr/textAppearanceInverse</item>
	</style>

	<style name="MyListTextAppearanceMedium">
		<item name="android:textAppearance">?android:attr/textAppearanceMediumInverse</item>
	</style>

</resources>

Then use these styles inside the layouts returned by the adapter backing up the listview inside the AlertDialog (… that Jack built…). The layouts themselves don’t need to be duplicated, mine are in the “basic” res/layout:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
	xmlns:android="http://schemas.android.com/apk/res/android"
	android:id="@+id/pick_attachment_root"
	android:layout_width="fill_parent"
	android:layout_height="wrap_content">

	<TextView
		style="@style/MyListTextAppearanceMedium"
		android:id="@+id/pick_attachment_main_title"
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		android:layout_toRightOf="@id/pick_attachment_icon"
		android:layout_toLeftOf="@id/pick_attachment_toggle"
		android:singleLine="true"
		android:ellipsize="middle"
		android:textStyle="bold" />

	<TextView
		style="@style/MyListTextAppearanceDefault"
		android:id="@+id/pick_attachment_sub_title"
		android:layout_width="fill_parent"
		android:layout_height="wrap_content"
		android:layout_toRightOf="@id/pick_attachment_icon"
		android:layout_toLeftOf="@id/pick_attachment_toggle"
		android:layout_below="@id/pick_attachment_main_title" />

</RelativeLayout>

Now all that’s left to do is to redefine these three styles inside res/values-v11/list_styles.xml and to use regular, not inverted, text appearance references:

<?xml version="1.0" encoding="utf-8"?>
<resources>

	<!-- Text for listboxes, non-inverted starting with Android 3.0 -->
	
	<style name="MyListTextAppearanceSmall">
		<item name="android:textAppearance">?android:attr/textAppearanceSmall</item>
	</style>
	
	<style name="MyListTextAppearanceDefault">
		<item name="android:textAppearance">?android:attr/textAppearance</item>
	</style>

	<style name="MyListTextAppearanceMedium">
		<item name="android:textAppearance">?android:attr/textAppearanceMedium</item>
	</style>

</resources>

The same dialog now looks like this:

And when the parent activity uses a theme dervied from @android:style/Theme.Holo, the dialog items will turn black, with light text.

Here is a couple of things I learned while recenly updating my apps to have the native look on tablets running Android Honeycomb (3.*).

My app lets the user select a UI theme (there are two: light and dark), so I had something like this in my res/values/styles.xml:

<declare-styleable name="WifiTheme">
	<attr name="radar_text" format="color" />
	<attr name="radar_alpha" format="color" />
</declare-styleable>

<style name="WifiTheme.Light" parent="@android:style/Theme.Light">
	<item name="radar_text">#FF202020</item>
	<item name="radar_alpha">#80000000</item>
</style>

<style name="WifiTheme.Dark" parent="@android:style/Theme">
	<item name="radar_text">#FFFFFFFF</item>
	<item name="radar_alpha">#A0000000</item>
</style>

I would then apply one of these themes, from inside onCreate, to my activities.

Now, Honeycomb has new “Holographic” UI themes that look different from 2.* themes, and users expect an application running on a tablet to use those. The two new themes are @android:style/Theme.Holo.Light and @android:style/Theme.Holo.

It’s possible to duplicate the XML snippet above in res/values-11/styles.xml, replacing the parent themes, but that would mean duplicating all the values for those themes. The snippet above has just two extra attributes, but there could be many more of them.

Ok, so here is a trick I came up with. Just like with program code, what we need to get out of a tight spot is an extra level of abstraction.

First, I defined the following themes in res/values/theme_compat.xml:

<style name="ThemeCompat">
</style>

<style
	name="ThemeCompat.Dark"
	parent="@android:style/Theme">
</style>

<style
	name="ThemeCompat.Light"
	parent="@android:style/Theme.Light">
</style>

The first one is just to keep the Android style hierarchy system happy, the other two are where the real work is. You can think of them as defining a base class (in programming terms) for my custom themes. My custom theme declarations are now derived from the themes shown above, and look like this:

<style name="WifiTheme.Light" parent="@style/ThemeCompat.Light">
	<item name="radar_text">#FF202020</item>
	<item name="radar_alpha">#80000000</item>
</style>

<style name="WifiTheme.Dark" parent="@style/ThemeCompat.Dark">
	<item name="radar_text">#FFFFFFFF</item>
	<item name="radar_alpha">#A0000000</item>
</style>

And for when the application runs on Android 3.*, I have the following declarations in res/values-11/theme_compat.xml:

<style
	name="ThemeCompat.Dark"
	parent="@android:style/Theme.Holo">
</style>

<style
	name="ThemeCompat.Light"
	parent="@android:style/Theme.Holo.Light">
</style>

What this does is replaces the “base class” of my custom themes with those native to Honeycomb. Now my custom theme declarations don’t need to be duplicated, and are automatically derived at runtime from the most appropriate system themes.

Here is another thing. AlertDialogs with custom content views.

AlertDialogs can be sometimes tricky, because they have their own styling and can even impose it on their content. But I feel that using them in place of regular dialogs makes an application’s UI better. The light panel behind the buttons, the title bar with the icon, the separator line below that – those may seem insignificant little things, but I feel they really make an app look better. Some manufacturers (Samsung, Sony Ericsson, perhaps others) make changes to stock Andorid UI to add their own color and graphics accents, and so it becomes even more important to use AlertDialog to better blend in with the device’s UI.

And this is another thing where Honeycomb is different from previous Android versions. Prior to 3.0, AlertDialogs always use a dark background (unless overriden for lists), even if the parent activity’s theme is light. Starting with 3.0, alert dialogs have the same overall light/dark color scheme as the base activity.

If your alerts use custom content views, it becomes tricky, because those views need to be inflated using an appropriate Context, so they match the dialog’s color scheme.

It’s really easy to end up with white text on white background, unless you use the following method, new with API level 11: AlertDialogBuilder.getContext().

Since this method doesn’t exist prior to API level 11, it’s possible to use Java reflection to stay compatible with older Android versions. Turns out there is another way: by subclassing AlertDialog, and overriding onCreate(), it’s possible to call getContext() for the AlertDialog itself. That method exists since API level 1, and returns a correctly themed Context for both 3.* and prior versions of Android. A further shortcut is to call getLayoutInflater(), which also exists since API level 1.

With this in mind, here is a simple alert dialog:

public class DlgAbout extends AlertDialog {

	public DlgAbout(Context context) {
		super(context);
	}

	@Override
	protected void onCreate(Bundle savedInstanceState) {

		setTitle(R.string.about_title);
		setCancelable(true);

		LayoutInflater inflater = getLayoutInflater();

		View contentGroup = inflater.inflate(R.layout.about_content, null);
		setView(contentGroup);

		super.onCreate(savedInstanceState);
	}
}

The dialog’s layout can use views without any specific color customizations:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
	xmlns:android="http://schemas.android.com/apk/res/android"
	android:orientation="vertical"
	android:layout_width="wrap_content"
	android:layout_height="wrap_content"

.....

<!-- Note the absence of android:textColor, etc -->
		<TextView
			android:layout_width="wrap_content"
			android:layout_height="wrap_content"
			android:text="@string/about_1"
			android:gravity="center_horizontal" />
......

The code to use this dialog is below. Not really that much different from using AlertDialog.Builder, and is actually somewhat better because the code for the dialog is placed in its own class (above).

@Override
protected Dialog onCreateDialog(int id) {
	if (id == DIALOG_ID_ABOUT) {
		/*
		 * About the app
		 */
		return new DlgAbout(this);
	}
.........
}