The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Valujet (1) [Avatar] Offline
The Alarm receiver class is incorrect. The way the code is currently laid out, the onReceiveIntent method does not get hit. The code needs to go inside the onRecieve method instead.
frank.ableson (75) [Avatar] Offline
Re: Chapter 8 - Alarms code doesn't work
Thanks -- we'll have a look.
mejohnsn (22) [Avatar] Offline
Re: Chapter 8 - Alarms code doesn't work
I noticed the same thing. But my fix for it was a little different: I put a call to onReceiveIntent inside the override of onReceive.

What else did I change? I also changed the name 'GenerateAlarm' to match the filename in listing 8.8, But perhaps the OP considered that change to trivial to mention (or easier to make the change the other way around). Of course, this means the same change had to be made wherever that name occurs, e.g. listing 8.6.

These two changes, as I recall, were everything that was absolutely necessary to get the book example (from the book itself, not from the download) to build and run.

But I also noticed that Listing 8.6's alarm_message is unused, since that Toast (in onReceiveIntent in SimpleAlarmReceiver) prints out the app_name instead of using alarm_message. It looks like the author intended to use alarm_message, but then decided to use app_name instead.

And indeed Fig. 8.5 shows the Toast displaying the app_name, NotifyAlarm instead of the alarm_message, "Alarm Fired!".

Finally, what should this example illustrate about best practices for life cycle management? I ask because as the reader tries modifying it to use as an example for his own code, or even just to learn more about the APIs illustrated, he is likely to notice: if you change am.set() to am.setRepeating(), suddenly you need to add am.cancel() at the right point in the life cycle. But this in turn implies that the scope for am and appIntent is too narrow: either onStop() or onPause() or onDestroy() needs access to that Intent and AlarmManagerjust to cancel the alarm.

This in turn suggests that am and appIntent should be fields of the Activity, which is the de facto alarm controller, since the AlarmController class is not used.

Of course, this was hardly even useful for the book example, since the Alarm fired only once: but even there, if the user exits immediately, does he -really- want the Alarm to fire anyway, or should it get canceled? Should it get canceled only when finish() called, or even when shadowed by another application? What if the system kills the hosting process?

I don't claim that the answer to these questions is 100% one way or the other: in real life, the user will sometimes want alarms that get canceled on one or all of these, and sometimes not. But it will help the reader learn the relevance of lifecycle management to using Alarms if this example at least reminds him of the importance of the issue by, for example, canceling the Alarm in only onDestroy() or perhaps also in onStop().