As much as it pains me to admit it, I fell in a rut last week—programmer’s block. Here was the problem:
findAndEnableNextTasksDue is not robust enough. In the worst case scenario, it will slowly fall behind on due alarms.
@Psuedo-code findAndEnableNextTasksDue() dueTime = getNextDueTime() createAlarm(dueTime) //due alarms call findEnableNextTasksDue recursively
The problem is
getNextDueTime(), a database operation. If this operation takes too long for whatever reason (really large database, slow processor, slow network, etc) and there are multiple tasks due back to back,
findAndEnableNextTasksDue() won’ be able to keep up.
In particular, I’m worried about a slow network since Reminderer will eventually support databases over a network (whether its Google drive, Google calendar, Dropbox, or something else).
One solution is to have
getNextDueTime() actually return the next two distinct alarm times. Then check to see if we have fallen behind. If so, schedule the second alarm right away.
Actually, if what we’re worried about is a slow network, this is the simple solution that doesn’t involve rewriting the entire backend. Packing one query with all the relevant information is faster than two separate queries.
The implementation isn’t exactly straightforward:
- The SQL (and we’re using raw queries) is more complex.
- We’ll need to be able to schedule multiple pending intents. A quick hack is to use different request codes. You can use the alarm due time as the request code.
findAndEnableNextDueTaskneeds to be multi-thread safe. A synchronized block is sufficient.
When I finally implement the network database, I’ll likely end up using another solution. A good candiate is the stock Calendar app. What’s important is that I’m thinking about this now and not later.
Checkout the current progress in the newAlarmSystem branch.