Thursday, January 26, 2012

Another App Widget Compatibility Trick

I've written previously on the issue of preventing app widgets from appearing on particular versions of Android.  This is useful, for example, when you have a Honeycomb-style widget but support pre-Honeycomb devices.

I've got a second version of this trick which I think is a bit easier now.  Instead of preventing the system from seeing your AppWidgetProviderInfo, you can actually enable/disable the widget receiver itself based on configuration resource selectors.

First, setup your app widget receiver thus (important part bolded):
<receiver
    android:enabled="@bool/widget_enabled"
    android:name="com.company.appwidget.MyAppWidgetProvider" >
    <intent-filter >
        <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
    </intent-filter>

    <meta-data
        android:name="android.appwidget.provider"
        android:resource="@xml/appwidget_info" />
</receiver>

Then all you need to do is create a config.xml (in your /res/values/ directory) file that sets "widget_enabled":
<resources>
    <bool name="widget_enabled">true</bool>
</resources>

You can then leverage the resource qualifier system to enable or disable the widget as necessary for different configurations.  For example, if you wanted your widget enabled on all versions of Android except for v11 through v13, you could set it up like this:

/res/values/config.xml <-- widget_enabled=true
/res/values-v11/config.xml <-- widget_enabled=false
/res/values-v14/config.xml <-- widget_enabled=true

The main advantage this provides over my last solution is that you need only modify a bool; the other solution required you to create duplicate versions of the AppWidgetProviderInfo XML file (if you supported, say, v3 through v10 and v14+).

3 comments:

  1. I've seen this trick used by Reto Meier in some of his open source work.

    It's also useful for working with platform resources, where you define a boolean for large devices or some other factor. Then you can simply reference the boolean rather than guessing at a dimension or dpi using runtime information.

    ReplyDelete
  2. Exactly what I was looking for! You sir receive many thanks from me!

    ReplyDelete