2009-12-09

[Android] Complaints about BroadcastReceiver - Minor but uncomfortable

When the time format is changed in the device, for example, 12-hour format to 24-hour format, the registered BroadcastReceiver gets executed. This sounds plausible in the first place. But in the process of implementing my BroadcastReceiver to monitor these two actions,

android.intent.action.TIME_SET
android.intent.action.TIMEZONE_CHANGED 

I also discover this functionality is limited in some degree.

I am writing an alarm application with a feature that shows am/pm label according to user's time format settings. Alarm settings are stored in SQLite database and AdapterView is used to bind these settings with UI views. It is conceivable that SQLite database must be updated inside BroadcastReceiver in order for AdapterView to update associated UI views when time format is changed. Everything looks ok. But, the missing and uncomfortable parts are the ability of registering listeners for TIME_SET and TIMEZONE_CHANGED actions.

Consider this, when an TimePickerDialog is brought up for users to select time, an boolean primitive is24HourView is passed into constructor. This means existing TimePickerDialog objects have no ways to reflect the time format change.


An user can now press HOME button and go to change time format. The cached TimePickerDialog doesn't know it at all.


This happens to not only TimePickerDialog but also classes you write. It seems the only good way to make BroadcastReceiver talk to my UI views is through AdapterView. For UI views that is not monitored under AdapterView but is time format sensitive, this problem happens.

Maybe I am too picky about always showing up-to-date information. But, if Android can support some mechanism of registering listeners for TIME_SET and TIMEZONE_CHANGED actions, I will be much satisfied.