Why Do Motorola's ListViews Look Different

There was a helpful article "Why Does My ListView Look Different?" that Motorola posted a few years ago.  Unfortunately it has disappeared from the internet, as you might tell by clicking on the link.  It had some crucial information on fixing a weirdness for Motorola devices that I wanted to preserve for posterity (in case anyone else starts looking for it).

Essentially, when you're on some Motorola devices, the bottom of the ListView has a shadow on it by default.  In addition to that, if the ListView is supposed to take up the entire screen (even if it's not full), it doesn't.  Here's a screenshot of the bug in action:

The problem is android:overScrollFooter.  Motorola has a default one set and it causes sadness.  To get rid of it, set android:overScrollFooter="@null" in your ListView.  For bonus points, set it in a style and set that as your theme's default ListView so you never have to deal with this problem again.

The Unknown Style: actionBarWidgetTheme

One of the cooler features I've found in the Android Action Bar is grouped menu items.  If you group together a series of menu items in a submenu, you get a pretty popup of those items.  For example, if you set a submenu with android:checkableBehavior="single" then it'll have a radio button next to each item in the popup menu:

I wanted to reskin the RadioButton so that they all looked Holo, even on versions using ActionBarSherlock.  Naturally, I turned to my theme and set the radioButtonStyle.  However, the code below did not work:

<style name="MyTheme" parent="@android:style/Theme.Holo.Light.DarkActionBar">
    <item name="android:radioButtonStyle">@style/MyRadioButtonStyle</item>
</style>

<style name="MyRadioButtonStyle" parent="@android:style/Widget.CompoundButton.RadioButton">
    <item name="android:button">@drawable/my_radio_button</item>
</style>

I was fairly lost for a few hours because radioButtonStyle was clearly working on everything except for the widget popup.  I could insert RadioButtons into my Activity and they'd pick up the new style, but the old style would remain for the action bar.  What was going on?

The culprit is android:actionBarWidgetTheme.

Introduced in API 14, what it does is let you style Views inflated by the action bar separately from the rest of your Application or Activity.  This is a neat trick, but if you don't know it exists, you could easily get lost on why your styles aren't applying to action bar Views.

If android:actionBarWidgetTheme is undefined, it falls back to the current theme's values.  For most Android themes, that means you're fine.  But in the case of Theme.Holo.Light.DarkActionBar, it does set the actionBarWidgetTheme to "@android:style/Theme.Holo".  As a result, it will not fallback to your theme's default value.

I solved the problem by setting my own actionBarWidgetTheme that is a sub-style of the original actionBarWidgetTheme:

<style name="MyTheme" parent="@android:style/Theme.Holo.Light.DarkActionBar">
    <item name="android:actionBarWidgetTheme">@style/MyActionBarWidgetTheme</item>
</style>

<style name="MyActionBarWidgetTheme" parent="@android:style/Theme.Holo">
    <item name="android:radioButtonStyle">@style/MyRadioButtonStyle</item>
</style>

It's important to properly parent the actionBarWidgetTheme with whatever the theme was previously setting as its parent; otherwise you may miss out on some styling elsewhere.

Styling an AutoCompleteTextView

I ran into some confusion recently styling some AutoCompleteTextViews.  An AutoCompleteTextView is a compound View - it's got both an EditText component and a floating dropdown component.  The former is rather straightforward to style, by the dropdown is difficult because it's a mixture of attributes on the AutoCompleteTextView itself and styles set in the theme via android:dropDownListViewStyle.

For example, if you want to setup a custom background on the dropdown, you do it in the AutoCompleteTextView:

<AutoCompleteTextView
  android:layout_width="match_parent"
  android:layout_height="wrap_content"
  android:popupBackground="@drawable/bg_autocomplete" />

But if you want to change the dividers, you have to create a theme and point that to a style, which isn't an immediately obvious solution:

<style name="MyTheme">
  <item name="android:dropDownListViewStyle">@style/DropDownListViewStyle</item>
</style>

<style name="DropDownListViewStyle">
  <item name="android:divider">#4F4F4F</item>
  <item name="android:dividerHeight">1dp</item>
</style>

The worst is when attributes in the AutoCompleteTextView and normal ListView styles collide.  I made the mistake of assuming that since it adopts a ListView-like style, it would adopt all ListView attributes - like android:listSelector.  The below, however, does not work:

<style name="DropDownListViewStyle">
  <item name="android:listSelector">@drawable/list_selector</item>
</style>

Instead, AutoCompleteTextView has its own attribute, android:dropDownSelector.  You have to set it like this:

<AutoCompleteTextView
  android:layout_width="match_parent"
  android:layout_height="wrap_content"
  android:dropDownSelector="@drawable/list_selector" />

The Case of the Twin onSurfaceChanged() and the Split Action Bar

There's a funny little timing problem I ran into recently I'd like to share regarding window size and split action bars.

In an app I've got a loading screen that displays as we're making network requests.  It's a cute SurfaceView with some animation to keep users amused.  I'd written most of the initialization of assets inside of onSurfaceChanged() because I wanted to pre-scale everything to the exact size of the surface.

But a problem arose - for some reason onSurfaceChanged() was being called twice (and only when in portrait, not in landscape).  This was troublesome because it's somewhat a substantial method due to all the initialization.  What was happening?

It turns out that the split action bar was the culprit.  Here's how things went down:

1. In onCreate(), add the SurfaceView to the view hierarchy.

2. SurfaceView.onSurfaceChanged() would be called.

3. onCreateOptionsMenu() would then be called.  Since I had splitActionBarWhenNarrow set for the Activity, this would create the split action bar.

4. Due to the split action bar, the window size would change.  SurfaceView.onSurfaceChanged() would be called a second time.

The solution was to move the addition of the Fragment with the SurfaceView somewhere after onCreateOptionsMenu().  I put it in onPostResume() (but make sure to call it only once on initialization).

There is one alternative solution, which is to call invalidateOptionsMenu() (or supportInvalidateOptionsMenu(), if you're using the support library) during onCreate().  This will force onCreateOptionsMenu() to be called early.  I dislike this answer because it screws up the normal lifecycle for menu creation and can therefore readily cause confusing issues down the line.

Manually Adding the Legacy Overflow Button when targetSdkVersion >= 14

My company is in the process of converting our apps to use action bars, but we're not quite there yet.  In the meantime, we've depended on the legacy overflow button on devices without a dedicated menu button:

A problem has arisen because we've bumped our targetSdkVersion up to 16 (Jelly Bean).  It turns out there is a specific set of rules for when the legacy overflow button appears.  Our app was depending on the fact that our minSdkVersion was less than 10 and that our targetSdkVersion was between 11 and 13.  By bumping our targetSdkVersion up to 16, we no longer got the legacy overflow button.

This situation wouldn't be a problem if we showed an action bar, since the overflow menu would just appear there.  However, we're using a theme that disables the title, so our menu items disappeared completely.

I want to emphasize that the correct solution is to use an action bar with an overflow button.  But we're not done with the conversion to action bars yet and during development we'll want that menu to be accessible (all of our debug options go in there).  So I came up with a small hack that lets us enable the legacy overflow button manually.

It turns out there is a hidden Window flag - WindowManager.LayoutParams.FLAG_NEEDS_MENU_KEY - that determines whether the legacy overflow button is shown or not.  By using reflection, we can retrieve this field and add it to the Window's flags:

public static void addLegacyOverflowButton(Window window) {
  if (window.peekDecorView() == null) {
    throw new RuntimeException("Must call addLegacyOverflowButton() after setContentView()");
  }

  try {
    window.addFlags(WindowManager.LayoutParams.class.getField("FLAG_NEEDS_MENU_KEY").getInt(null));
  }
  catch (NoSuchFieldException e) {
    // Ignore since this field won't exist in most versions of Android
  }
  catch (IllegalAccessException e) {
    Log.w(TAG, "Could not access FLAG_NEEDS_MENU_KEY in addLegacyOverflowButton()", e);
  }
}

I added the RuntimeException above because you need to call this after the decor View is set (or else it does nothing).

Android Emulator Keyboard Support in ADT 20+

If you've upgraded to ADT 20, you may have noticed that your keyboard no longer works on inputs on your emulator.  That is, when you have an EditText on the screen, typing characters into your physical keyboard doesn't register anything in the emulator; you need to open the soft keyboard to do anything.

The problem is that the emulator no longer assumes you have keyboard support by default.  You'll need to add it yourself to the emulator and your keyboard will work again:

Fragment Transactions Reference

I recently found myself looking at Fragment transactions and wondering precisely what each Fragment state meant.  I vaguely had an idea of what added, attached, shown, hidden, detached and removed meant, but not the specific behaviors of each.  I spent a morning looking through Android's code to better understand what happens to Fragments.

Here's a reference manual for what I learned.  I looked into two aspects of Fragments: fragment states, and animations in transactions.  This research was done primarily on the compatibility library.  It's possible that some of the details below will differ for the 3.x+ implementation of Fragments.

Fragment States

All of the below support animations.  Terminology note: when I say "configuration change", I mean when the device changes configuration (for example, from portrait to landscape) and the Activity must be destroyed/recreated.

FragmentTransaction.add()/remove() - These add and remove a Fragment from the FragmentManager.  By default, it will begin showing the Fragment as well.  During the transaction the returns of Fragment.isAdded() and Fragment.isRemoved() will be modified.  These states are preserved on configuration change, so a Fragment that's added will remain added and can be retrieved again from the FragmentManager.  Since a removed Fragment is no longer part of the FragmentManager, it will not be retrievable after a configuration change either.

FragmentTransaction.attach()/detach() - These attach/detach a Fragment from the Activity (e.g., make it an active Fragment that can be seen).  During the transaction the returns of Fragment.isAdded() and Fragment.isDetached() will be changed.  These states are preserved on configuration change, which means that (unlike removing a Fragment) it is possible to detach a Fragment but then retrieve it later after configuration change (even if it's not actively being displayed).  Even in a detached state, the Fragment runs through all lifecycle methods (except the ones that are related to being attached to an Activity) - for example, onSaveInstanceState() will still be called even if the Fragment is detached (which is quite useful for maintaining state).

FragmentTransaction.show()/hide() - These show or hide a Fragment (in particular, it calls View.setVisibility() on the Fragment's root View).  During the transaction the returns of Fragment.isHidden() will be modified.  Showing/hiding Fragments states are NOT maintained on configuration change, meaning that if you hide a Fragment it will reappear on config change (for example, if the user rotates the screen).

FragmentTransaction.replace() - Theoretically it is the exact same as removing all Fragments associated with a particular View, then adding a new Fragment in its place.  I did not research this much (since I'm more interested in manual control of which Fragments are shown).

Fragment Animations

There are three different ways to animate Fragment transactions.  These are ordered by precedence (in other words, the first method, if available, will be used; then the second, then the last).

One thing to note between the compatibility library and the standard Fragment library is that the standard library uses property animators, whereas the compatibility library uses tween Animations.

1. Override your Fragment's onCreateAnimator() method and return an animation.  This is the only way to dynamically generate an animation in code (the other two methods rely on pre-configured animations from your resources directory).  In the compatibility library, the method is onCreateAnimation() (since the compatibility library uses animations instead of animators).

2. Call FragmentTransaction.setCustomAnimations(), referencing either animators or animations (depending on whether you're using the compatibility library or not).  What is interesting is that setCustomAnimations() affects all fragment transitions added to the transaction after it is called.  So you need to call setCustomAnimations() before you want it used, and you can actually setup multiple different custom animations for each part of a transaction (with a call to setCustomAnimations() before each add()/remove()/attach()/detach()/show()/hide()/replace()).

3. Setup a style that defines window animations (from this style), then call FragmentTransaction.setTransition() and FragmentTransaction.setTransitionStyle() to specify that style and target the correct animation.

#3 works different in the compatibility library.  FragmentTransaction.setTransitionStyle() is completely ignored.  Instead, it uses the specified transition to select a stock animation.  So if you want custom animations in the compatibility library, you must use #1 or #2.