Understanding proper Android alarm "flow"

Question

I've been working on a practice Android application to familiarize myself with the platform. Specifically, the app I'm trying to implement allows the user to select a sound file (MP3 or WAV) to play at a specific date and time showing a dialog with a progress bar and an OK/Cancel button allowing the user to stop the playing of the sound file. I want it to behave something like the countdown apps I've seen or even the built-in alarm clock app. As I'm implementing this simple (I thought!) app, I'm trying to better understand the platform and make the application conform to the Android way.

As I've been writing the app, I learn more about how things are supposed to work on the Android platform. And here's where I'm getting a bit confused. During my attempts to get the alarm to fire and display, I'm learning that properly formed Android applications are not supposed to show dialogs as a result of a background service or broadcast receiver being invoked through Android's alarm service. Instead, I think, the app is supposed to use a notification on the status bar to alert the user. The user then has the option to look at the notification to see what the app is trying to tell them.

I’ve managed to get the dialog I wanted to bring up to appear by launching a new activity from a service that was launched by Android’s alarm service. However, it appears that I’ve broken an Android rule by doing so. I knew this first because I saw a message in the DDMS LogCat window that asked if I was sure I wanted to start a new activity from a Service. Second, I read in several places that it was not nice to do so. One statement that comes to mind was from a Google developer that said he’d certainly uninstall an app that did something like that.

The app is instead, if I understand correctly, supposed to use the status bar and notification to get the user’s attention and allow them to see what the app wants at their leisure. This seems counter-intuitive to what my app is trying to do. Again, I’m trying to get it to behave, essentially, like the countdown apps I’ve seen or the built-in alarm clock application that comes on the Android phones. If my app is not behaving correctly, is the alarm clock app behaving? Obviously I’d say the alarm clock app is doing exactly what I’d expect. And a user of my app, I think, would expect the sound file to play with a dialog showing allowing the playing of the sound file to be stopped without having to go through the status bar.

Am I understanding the Android platform correctly? Any opinions on how an app like this could be implemented without being naughty by bringing up the dialog I mentioned? I’d like the application to be regarded as a well-formed Android app, but I’m having a difficult time seeing how my app is so different from others I’ve seen or even the built-in alarm clock application.

Thanks! Jeff

Answer 1

Users generally do not expect random stuff to pop up on-screen, particularly while they are in the middle of doing something. After all, if they are playing a game or typing in a text message or something, the popped-up activity will wreck what they're doing.

Some applications are supposed to do this by design, regardless. Incoming phone calls, for example, should pop up the in-call screen, no matter what the user is doing. One can certainly argue that an alarm-style app, like yours, has some reasonable rights to do the same.

However, there are some developers out there who think that users are piles of fecal matter. Such developers feel they have the right to pop up stuff from the background with impunity, because it is their right as developers to do what they want, users be damned. I imagine that it is with this audience in mind that LogCat issues the warning.

If I were writing your app, I would make it a user preference whether they want the alarm to simply raise a Notification or actually pop up an Activity. But no matter how you handle this, your objective should be to do what the users will expect and appreciate, even if that runs counter to what you as a developer feel should be done.