{"id":1855,"date":"2013-10-08T20:15:05","date_gmt":"2013-10-08T08:15:05","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1855"},"modified":"2013-10-10T18:03:07","modified_gmt":"2013-10-10T06:03:07","slug":"well-behaved-widgetry","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1855\/","title":{"rendered":"Developing an AppWidget – Part 3"},"content":{"rendered":"[Estimated Reading Time: <\/span> 9<\/span> minutes]<\/span><\/span>

Well Behaved Widgetry<\/h2>\n

When we left it, my battery widget was working but wasn’t particularly well behaved<\/a>. There was nothing much wrong with the functionality, but plenty wrong with the implementation.<\/p>\n

<\/p>\n

Despite their impressive specifications, mobile devices have one very limiting factor. Battery Life.<\/p>\n

Indeed, the impressive specifications are part of the reason that battery life can be a problem, but as application developers targeting mobile platforms there are things we can – and should – do, to ensure that we don’t make the problem worse than it needs to be.<\/p>\n

So let’s look at the problems with my battery widget.<\/p>\n

System Scheduled Updates<\/h3>\n

For simplicity and convenience, I declared an update interval in the meta-data for my widget.<\/p>\n

This is bad for two reasons:<\/p>\n

    \n
  1. Declared update intervals are subject to a maximum frequency (i.e. they cannot be schedule more frequently than a prescribed limit). There is a good reason for this, which is the second problem with such declared updates<\/li>\n
  2. For updates scheduled in this way, the system will wake the device in order to perform the requested update. For my widget this is pointless – if the device is asleep the screen is off, so having an up-to-date battery %’age displayed is neither here nor there. But it’s worse than that. Not only will my widget wake up the device needlessly, but also when it does any other apps or widgets that were waiting patiently for the user<\/em> to wake the device will also potentially take this as their cue to do some work that they otherwise needn’t<\/li>\n<\/ol>\n

    All in all, my simple widget is a real trouble maker.<\/p>\n

    Fortunately there is an alternative to scheduling updates in this way. Alarms.<\/p>\n

    Be Alarmed<\/h3>\n

    Not to be confused with an “alarm clock<\/strong><\/em>“, on Android<\/strong> there is a system AlarmManager<\/a><\/strong> which can be used to scheduled recurring (or one off) events.<\/p>\n

    Even better, when setting up an alarm using AlarmManager<\/strong>, we can specify whether or not our alarm is important enough to wake up the device. If not, and if the device is asleep when our alarm would have been triggered, it will instead be triggered immediately that the device is first awoken after our alarm had elapsed.<\/p>\n

    And even better still, with the AlarmManager there are no constraints on the frequency of any recurring alarm we may wish to set (other than our own common sense and consideration for others).<\/p>\n

    Perfect.<\/p>\n

    So, let’s adapt the battery widget to use an alarm.<\/p>\n

    First of all, we set the update period in the meta-data to “0” to indicate that we do not wish to receive any system generated updates:<\/p>\n

    \r\n    android:updatePeriodMillis="0"\r\n<\/pre>\n
    Next, we add a class var (static member) to our BatteryWidgetProvider<\/strong> class, to hold a reference to the AlarmManager<\/strong>.  As we shall see, this will both act as a cache for the reference to the AlarmManager<\/strong> and also serve as a flag that we have an alarm set.<\/p>\n
    \r\n    private\r\n      class var fAlarm: AlarmManager;\r\n<\/pre>\n
    Now we need to extend BatteryWidgetProvider further.  Previously we only responded to ACTION_APPWIDGET_UPDATE<\/strong> intents, but now we need to respond to two other intents in the widget lifecycle:<\/p>\n