Currently I have an app that is setup in two sections, the activity portion adds tasks and task completion times to a database and then I have a service that runs in the background polling the database and handling the task when the task completion time is reached.
Currently my service is using a private inner class that extends thread and I am making use of thread.sleep to re-run the task handling methods. This inner class is called from the onStartCommand() in the service class. the thread.sleep is set to either 15 minutes or if the task will need to be handled before that it will sleep until the time this task needs to be handled. At this point everything is working correctly however I have a few issues that I am running into.
The service needs to run at specific times that are always changing depending on when the task needs to be completed even when the phone goes to sleep.
I need to make sure that there is as little impact on battery as possible.
Now through research I found that with the use of alarm manager I can start this service only when I need to, which is great, however because I would be constantly changing the time intervals based on when certain tasks had to be handled I'm not sure this would be the right course of action.
I've also read about wakelocks which I really don't want to have to use unless I absolutely need to.
I am more or less looking for advice on how I should structure the service in my app and how it handles these tasks.
Now through research I found that with the use of alarm manager I can start this service only when I need to, which is great, however because I would be constantly changing the time intervals based on when certain tasks had to be handled I'm not sure this would be the right course of action.
AlarmManager is definitely the correct solution. Keeping a service alive all of the time, mostly watching the clock tick, is embarrassingly wasteful of RAM.
You will not "be constantly changing the time intervals", because you will only have one alarm event, set to whenever the next task is to occur. That will be a one-shot alarm, not a recurring alarm. When the event occurs, in addition to doing the work, you schedule the next event. The only edge case is if the user adds a task that is to be completed sooner than the formerly-soonest task, in which case you will need to cancel and reschedule that alarm event.
I've also read about wakelocks which I really don't want to have to use unless I absolutely need to.
You do not have a choice, with your current or an AlarmManager implementation, if you want to make sure that you can do your periodic work without interruption. The goal is to only have an active WakeLock during the actual pulse of work, and to release the WakeLock and shut down the service when that pulse of work is completed. You can see an implementation of this pattern in WakefulIntentService.