I'm developing an application that takes the user through an exercise plan. It's a running trainer that uses audio cues to let the user know when to walk, run, etc. at different points during their exercise.
It's very likely that the phone will be locked and in someone's pocket while the app is running, so I'm looking into the ways I can keep the audible cues coming. At the moment I'm just testing using a Handler in a local Service to schedule the next cue along. That's working better than I expected on some devices, but, on others, the Service seems to stop when the phone is locked.
I know there are a variety of options open to me -- keep a wake lock on the phone, schedule alarms, (perhaps? Not sure on this one) changing the priority of the Service, and maybe more.
So, what do people think would be the best approach? Bear in mind that this is not a "normal" Service -- it will be typically be running for at most half an hour, three times a week, and many of its users will be playing music while they run, so the phone is fairly unlikely to be asleep anyway. I'm thinking, therefore, that the usual caveats about battery-draining wake-locks may not apply so much in this case?
Currently I'm targeting API level 8 as my minimum.
Depends on how much you have to do. If it's just playing some audio occasionally at certain intervals you could likely get away with an alarm that repeats. If you're also doing other things -- tracking things over GPS or some other mechanism, or anything that requires reasonable CPU -- a partial wake lock is likely the best option.