While developing the Galaxy Zoo app for Android, I experienced problems with UI responsiveness while the app was downloading from, or uploading to, the remote server. I don’t mean just the usual problems caused by doing network I/O or file system access in the UI thread – mistakes that can often be caught by using Strict Mode. I mean that buttons didn’t respond to presses if the app happened to be doing I/O in an AsyncTask.doInBackground().

I solved this problem, but it was an incredibly frustrating journey. These notes might help the next person. So many Android apps are just a fancy way to interact with a website’s data, caching it locally, but the regular Android API doesn’t make that easy enough.

My app uses a ContentProvider, because the Android API seems to point us towards doing so, as I found while creating my experimental Android Glom app. The ContentProvider usually runs in the same process (and thread) as the main UI, so I don’t think this architecture was a cause of the UI responsiveness problem.

Thread+ResponseHandler versus AsyncTask

My ContentProvider needed to communicate with the remote server via REST messages, downloading images from the URLs that it then discovered and caching those images locally as well as storing data in its SQLite database. At first, I used the Thread class directly, with a UriRequestTask class derived from Runnable, that used HttpClient and accepted a (HttpClient) ResponseHandler. This was based on the example code in O’Reilly’s Programming Android (2nd Edition) book, in its “A Content Provider as a Facade for a RESTful Web Service” chapter (which you can see some of here).

Later, before I found the UI responsiveness problem, I replaced this Thread and RequestTask idea with AsyncTask because that seemed more robust and made it easier to get a result back to the main thread. I didn’t understand why the “Programming Android” book didn’t use AsyncTask in its ContentProvider. Yet later, I found that Strict Mode didn’t allow that use of AsyncTask in a SyncAdapter’s non-UI thread on some older devices (API version <15), causing an ExceptionInInitializerError with “Can’t create handler inside thread that has not called Looper.prepare()”. Maybe the authors found the same problem.

HttpURLConnection instead of HttpClient

Incidentally, I later realized that the Android developers now discourage use of HttpClient, because their version of HttpClient is buggy and they can’t update it without breaking compatibility. So I changed from HttpClient to HttpURLConnection (and here and here). Luckily, this fixed the endless redirect problem I (like others) was having with my uploads.

Again, I felt led astray by the “Programming Android” book, but books get out of date very quickly and the Android documentation apparently gives us new clues only reluctantly. Hopefully the 3rd edition will improve this.

Avoiding the user

This is when I noticed the UI responsiveness problem. I tried using Thread directly in various ways instead of AsyncTasks, fearing my own changes had caused it, but it made no difference.

I tried all kinds of tricks to avoid doing any I/O, even in the AsyncTasks, when the user was likely to be using the UI, trying to wait until it seemed that the user was idle and then doing some quick I/O before getting out of the way again. But the user is unpredictable and would still try to press a button now and then exactly when my app was doing some sneaky I/O.

After lots of imprecise testing, I was fairly sure that the problem was worse when the app happened to be doing some filesystem I/O, even just writing to the SQLite database, but it was definitely caused too by doing network I/O of even small JSON files. We should expect disk I/O to be worse than network I/O, of course.

SyncAdapter

I wanted to learn about Android’s SyncAdapter framework anyway, so I spent a week figuring that out despite its awful hand-wavy documentation. Luckily, it fixed the UI responsiveness problems. I think it helped partly because the I/O was now in a separate process, though that doesn’t feel like it should be necessary. Also, the SyncAdapter framework can decide when best to let the SyncAdapter do its work, based on the whole system. Presumably it can then prevent unrelated processes from making the UI responsiveness even worse.

Unfortunately, using SyncAdapter does mean that I lose control over when I may download items in advance. For instance, I often find that a new install of the app doesn’t fill up its initial list of ten items until five or ten minutes after the first start. In the meantime, the app requests the items directly when necessary. I call ContentProvider.requestSync(), with SYNC_EXTRAS_MANUAL, when I’m sure there’s work for the SyncAdapter to do, but it just seems to take this as a suggestion that it’s free to ignore.

Authenticator and Account

To use the SyncAdapter, I had to create an Authenticator, for which I needed an Account type, even if you are accessing your server anonymously. This account type will show up in the Settings->Accounts UI. Presumably this is why some other apps show up in the Accounts Settings, even though they don’t need any login. Maybe they are doing it just so they can use SyncAdapter.

SyncAdapter versus SharedPreferences/PreferenceFragment

So I started by storing the login details via the AccountManager instead of via SharedPreferences. I later discovered that the app’s SharedPreferences (such as how many items to download) were unavailable to the SyncAdapter’s separate process. That is documented as “currently this class does not support use across multiple processes“. So I later put other preferences in the account too. Unfortunately, the standard settings/preferences UI only uses SharedPreferences, so I have hacky code to keep the SharedPreferences and the Account in sync – see my onSharedPreferencesChange() override in my PreferenceFragment, so the account’s UserData is changed when the standard settings UI is used, via my hacky copyPrefToAccount method.

AccountManager versus main/UI thread

I also later found that you can’t use the AccountManager API from the main UI thread even though the documentation says things like “It is safe to call this method from the main thread”. The Firefox on Android developers discovered this too (1, 2, 3). So I moved that code to an AsyncTask (for example). If you don’t then you’ll get StrictMode exceptions at least on API level 15 and 16 – maybe others. StrictMode seems to have been on for Android Honeycomb, and some users seem to enable StrictMode, so you will see this as crash reports on some devices.

Volley

I also wanted to try out the Volley library. This isn’t an official part of the Android API. For instance, there’s not even an official way to add it as a dependency – I used the Volley package that mcxiaoke helpfully published to maven central. But Google use Volley in some of their own apps and they recommend Volley in the Android documentation. The video linked from there is well worth watching.

When I rewrote my HttpURL Connection-using code with Volley it seemed to make my downloads noticeably faster, probably because it avoids doing I/O in too many threads simultaneously. This was an easy win.

I couldn’t use Volley for my uploads, unfortunately, because Volley uses HttpClient on older Android versions whose HttpUrlConnection wasn’t good enough yet, causing the old endless-redirect problem again. So I use HttpURLConnection directly for that.

Picasso

I also switched to using Picasso to fill ImageViews with bitmaps from our ContentProvider or directly from the internet, instead of my own AsyncTask. This simplified the code and gave me some extra caching, particularly simplifying my ListView/RecyclerView adaptor that previously had its own custom LruCache. For instance 1, 2, 3. Image loading just generally felt much faster everywhere that I used Picasso, though I don’t know exactly why.

Just filling an ImageView without blocking the UI seems like something unexciting that the Android API should already make easy.

Android 5.0 (Lollipop), which is API version 21, supports tinting of drawables. So now you don’t need to recreate your monochrome action icons (in multiple sizes) just to show them in a different color in your app bar (ActionBar or ToolBar).

Unfortunately, drawable tinting isn’t available via the AppCompat library. That makes it useless for now unless you want to target only Android 5.0 devices, but here’s how to use it anyway. One day Android 5.0 might be old enough.

This is another part of my adventure in changing the color of stuff in Android’s app bar, after already figuring out how to change the color of the app bar’s text and standard icons.

Regular Drawables

Normally you’d just have the regular multiple .png files for your action item like so:

res/drawable-hdpi/ic_action_something.png
res/drawable-mdpi/ic_action_something.png
res/drawable-xhdpi/ic_action_something.png
res/drawable-xxhdpi/ic_action_something.png
res/drawable-xxxhdpi/ic_action_something.png

You would use these in your layout XML like so:

<item
    android:id="@+id/option_menu_item_something"
    android:icon="@drawable/ic_action_something"

Or you would use them in code like this:

menutem.setIcon(android.R.drawable.ic_action_something);

Tinted Drawables

You can now add a tinted version of the existing drawable like so:

res/drawable/ic_action_something_tinted.xml

With XML contents such as this:

<?xml version="1.0" encoding="utf-8"?>
<bitmap
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/ic_action_something"
    android:tint="@color/color_action_icons_tint"/>

That color_action_icons_tint could be hardcoded, but you’ll want to use the same one repeatedly via a color resource, like so:

res/values/color.xml

With XML contents like this:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="color_action_icons_tint">#5a6518</color>
</resources>

You can then refer to that tinted drawable just like any other drawable,

in your layout XML like so:

<item
    android:id="@+id/option_menu_item_something"
    android:icon="@drawable/ic_action_something_tined"

or in code like this:

menutem.setIcon(android.R.drawable.ic_action_something_tinted);

Light on Dark and Dark on Light.

Android’s has normal (dark) and light themes, though it’s actually the light themes which are normally show in examples of the new Material design.

The light theme expects your App Bar¹ (Toolbar or ActionBar) to have a light background color, so it gives you a dark title and dark overflow menu icon (the three vertical dots):

The dark theme expects your App Bar to have a dark background color, so it gives you a white title and white overflow menu icon:

This is true of both the Holo themes and the new Material themes.

If you want to use the light theme but want your App Bar to have a dark background, or use a dark theme and want your toolbar to have a light background, things get awkward. Arguably this might be unwise design anyway, but there’s nothing in the Material design guidelines advising against it.

It’s fairly easy to change the ActionBar‘s text color, but changing the color of its overflow icon is harder. It seems normal to provide a whole new overflow icon for your app, replacing the standard one, just to get the right color.

Android’s new Toolbar, which replaces ActionBar (with some awkward code), makes it easier to change the title text color and the color of the menu overflow icon (and the Up/Back icon). So now I finally have dark text and icons on my light background in the dark theme:

Toolbar theme and popupTheme

It took me ages to figure out how to do this, so hopefully the following explanation saves someone some time. I’d welcome any corrections.

My main theme derives from Theme.AppCompat (not Theme.AppCompat.Light), which is the dark Material theme for older devices, because I want most of the UI to be dark.

<style name="AppTheme" parent="AppTheme.Base" />
<!-- Base application theme.
     Defining this lets values-v21/styles.xml reuse it with changes. -->
</style>
<style name="AppTheme.Base" parent="Theme.AppCompat.NoActionBar">  
  <!-- colorPrimary is used, for instance, for the default ActionBar
       (but not Toolbar) background.
        We specify the same color for the toolbar background in 
        toolbar.xml.. -->
  <item name="colorPrimary">@color/color_primary</item>

  <!-- colorPrimaryDark is used for the status bar (with the
       battery, clock, etc). -->
  <item name="colorPrimaryDark">@color/color_primary_dark</item>

   <!-- colorAccent is used as the default value for
        colorControlActivated which is used to tint widgets. -->
  <item name="colorAccent">@color/color_accent</item>
</style>

(Update: I originally used Theme.AppCompat, manually setting windowActionBar to false, before learning of Theme.AppCompat.NoActionBar here, but I don’t notice any difference)

But that dark theme gives me light text and icons on the my light background of the App Bar:

I want to use a light color for the toolbar background even while using the dark theme.  So I’ll need to make the text and icons on my toolbar dark instead of the default white from the light theme. Incidentally, the Material Design Color Palette page seems to agree with me, using dark title text on the Lime color I’ve chosen, but using white on almost all other colors.

So my Toolbar’s XML layout specifies a different theme (android:theme, or app:theme when using appcompat versions before 22.1.0), like so:

<android.support.v7.widget.Toolbar
  xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:app="http://schemas.android.com/apk/res-auto"
  android:id="@+id/toolbar"
  android:layout_width="match_parent"
  android:layout_height="wrap_content"
  android:background="@color/color_primary"
  android:theme="@style/GalaxyZooThemeToolbarDarkOverflow"
  app:popupTheme="@style/Theme.AppCompat.NoActionBar" />

That toolbar theme specifies a textColorPrimary and textColorSecondary to change the color of the title text and of the menu overflow button. You could just specify the standard Theme.AppCompat.Light.NoActionBar theme for the toolbar, to get the dark text and overflow icon,  but I wanted to derive from my own theme and make only small changes, because I have no idea what else might be affected.

<style name="GalaxyZooThemeToolbarDarkOverflow" parent="Theme.AppCompat.NoActionBar">
  <!-- android:textColorPrimary is the  color of the title text
       in the Toolbar, in the Theme.AppCompat theme:  -->
  <item name="android:textColorPrimary">@color/abc_primary_text_material_light</item>

  <!-- android:textColorPrimaryInverse is the  color of the title
       text in the Toolbar, in the Theme.AppCompat.Light theme:  -->
  <!-- <item name="android:textColorPrimaryInverse">@color/abc_primary_text_material_light</item> -->

  <!-- android:actionMenuTextColor is the color of the text of
        action (menu) items in the Toolbar, at least in the
        Theme.AppCompat theme.
        For some reason, they already get the textColorPrimary
        when running on API 21, but not on older versions of
        Android, so this is only necessary to support older
        Android versions.-->
        <item name="actionMenuTextColor">@color/abc_primary_text_material_light</item>
  <!-- android:textColorSecondary is the color of the menu
       overflow icon (three vertical dots) -->
  <item name="android:textColorSecondary">@color/abc_secondary_text_material_light</item>

  <!-- This would set the toolbar's background color,
        but setting this also changes the popup menu's background,
        even if we define popupTheme for our <Toolbar> -->
  <!-- <item name="android:background">@color/color_primary</item> -->
</style>

This gives me the dark text and icons in my App Bar while using the dark theme:

That’s actually gray rather than black, and the white icons are really off-white, so you might want to use a custom color to have real black or white standard icons:

<item name="android:textColorSecondary">@color/my_black_icon_color</item>

Notice that the <Toolbar> also uses popupTheme (app:popuptheme when using AppCompat, or android:popupTheme when targetting SDK >=21). Without this, the overflow menu’s appearance is affected by the Toolbar’s style, leading to dark text on a dark background:

By specifying the Toolbar’s popupTheme, we can make its menu use our normal theme instead:

[1] “App Bar” seems to be the new official terminology. It’s used here and some other places I can’t find now.

Also see my entry about changing the colors of your own action icons with Android 5.0’s drawable tinting feature.