Use android.R.layout.simple_list_item_1 with a light theme

Question

I have learned that when using android:entries with a ListView, it uses android.R.layout.simple_list_item_1 as the layout for a list item and android.R.id.text1 as the ID of the TextView inside that layout. Please, correct me if I'm wrong.

Knowing this, I wanted to create my own adapter but use the same layout resources, in order to provide UI consistency with the platform. Thus, I tried the following:

mAdapter = new SimpleCursorAdapter(
    getApplicationContext(),
    android.R.layout.simple_list_item_1,
    mSites,
    new String[] { SitesDatabase.KEY_SITE },
    new int[] { android.R.id.text1 }
);

Unfortunately, because I am using a light theme (I have android:theme="@android:style/Theme.Light" in my <application>), the list items appear with white text, making them unreadable.

However, when using android:entries to specify a static list of items, the items appear correctly, with black text color.

What am I doing wrong? How can I make my dynamic adapter use the standard layout but work with a light theme?

Solution

Please, correct me if I'm wrong.

You are at least sorta wrong. It uses com.android.internal.R.layout.simple_list_item_1. While that is nearly identical to android.R.layout.simple_list_item_1, it may be themed differently.

Also, never use getApplicationContext(). Just use your Activity as the Context. See if that helps.

Comments

[Felix]

Indeed, using this instead of getApplicationContext() fixes it. Wow! Thanks!

[CommonsWare]

@Felix: Yeah, getApplicationContext() is a seriously messed-up method. It gives you an Application object, which is a Context, but apparently doesn't do well with any GUI-related stuff related to Contexts. Unless you actually need the Application object (e.g., you have a custom one), I would never use getApplicationContext(). After all, that method is a method...on Context. So, by definition, you already have a perfectly delightful Context. I'm glad this worked!

[Felix]

I was always under the impression that getApplicationContext() was somehow more correct (what if they change how contexts work and this is no longer a Context? getApplicationContext() would probably be updated to reflect the changes in the API and I wouldn't have to refactor my code). Thanks for clearing that up :)