Alarms, Timers, and Reminders Proposal
We'd like to add Alarms to Chandler for the 0.5 release. An Alarm is basically an alert that pops up a few minutes before a Calendar Event is scheduled to occur, which reminds you that Event is about to happen.
I propose we build Alarms from two parts:
- A general Timer Item that can be used for timed triggering of Notifications
- An Alarm mechanism in MainView to put up an Alert for the Reminder
A Timer Item is a persistent object that can be associated with a Content Item, and sends Notifications periodically. If you specify a firing time, it will trigger when that time occurs. If you specify an interval, it will fire repeatedly using that interval. When it fires, it triggers the Notification specified in the event attribute. If you specify a description attribute, it will package that message in the notification when it's triggered.
A Timer Item has the following attributes:
| Attribute | Type | Description |
|---|
| firingTime | DateTime | optional start time for the Timer |
| interval | long int | optional milliseconds between repeated firings |
| event | BlockEvent | the notification to trigger when the Timer fires |
| description | String | a description to pass along with the event |
| item | Content Item | optional Item that this Timer is associated with |
When a Timer fires, it sends a Notification using the Notification manager. I'm assuming that in most cases the actual Notification used will probably be a CPIA Block Event to leverage their flexible dispatch.
If a Timer has no "interval" attribute it fires only once, and then deletes itself.
We can use Timers to do lots of things. For example, if we want to do a "Sync All" periodically, we just need to create a Timer object with the right interval, and connect it to the same Block Event that we are currently using for the "Sync All" menu item. We can also use Timers for Alarms associated with Reminders. When a Calendar Event needs a Reminder, the Detail View will create a Timer set for several minutes before the Event is scheduled. This Timer will have a Block Event that is wired to the Main View's Alarm mechanism. When the Timer goes off, it packages the description string with the Block Event notification and sends that notification. The Block Event will be directed to the Main View's Alarm mechanism. For release 0.5, the Alarm mechanism is just a method which extracts the description string from the event and puts the description in an Alert to notify the user.
Issues
There are a few issues to work out:
- What low-level timer mechanism will we use? I recommend using wx.Timer
- How does the low-level timer get created when we relaunch Chandler? We can either use the onItemLoad() hook, or make Timer a kind of Block and use instantiateWidget()
- If Timers are not Blocks, which block should be used to send the Block Event notification? Without a block to use for the "sender" some forms of dispatch won't work.
- How do we associate Recurrances of a Calendar Event with the Timer.interval? Maybe we need to create a new Timer when the Event has passed and the Recurrence is reprocessed
- When do we delete Timer Items, if they are set to fire repeatedly? Maybe never, which makes sense for system services like the periodic "Sync All" Timer
- How do we associate a Timer with a Content Item or Calendar Event? I suggest we have the Timer point to the CalendarEvent in its "item" attribute.
The big issue is whether to make a Timer a kind of Block or not. One factor in this decision is the reliability of the onItemLoad hook. It's not clear to me what causes an independent item like a Timer to be loaded, which triggers the hook. Making it a Block solves this problem. This makes some sense because a Timer block would act somewhat like a Menu block - they are typically attached to the Main View, have wx events bound to them, and they trigger a Block Event when a low-level wx event occurs. The thing I don't like about making a Timer a Block, is that this may create a connection from a Content Model object to a CPIA UI object. We don't want to just have a "reminder" attribute of a Content Item which points to the Timer Block, because that's data pointing to UI. Maybe the best solution is to have the Timer point to the Content Item, but have no inverse pointer. Since non-repeating Timers delete themselves they will clean themselves up. Only when you
change a reminder will we need to go find the old Timer, which has not gone off, and update it. We can use a query to find it even if we don't have a "reminder" attribute, by looking for a Timer which points to our Item.
--
DonnDenman - 13 Nov 2004
