> * Why have Palm departed from broadcasting launch codes for
> notifications? Instead, the Notification Manager SysNotifyRegister
> function requires a call back of type SysNotifyProcPtr. I would
> have thought it better to have some notification launch code with a
> param block pointing to a SysNotifyParamType.
Actually, we _didn't_ depart from it. The callback parameter to
SysNotifyRegister is OPTIONAL. If you pass NULL for this paramater, then the
NotifyMgr will send your application a 'notify' launchcode. (Read the docs, if
they're available yet ;-)) The callback feature is present so that
non-application entities (like hacks, libraries, and PalmOS itself) can use the
NotifyMgr as well. You can use callbacks from within an application, but we
reccomend that you use the NotifyMgr's launchcode mechanism instead (by simply
not supplying a callback procedure). An added bonus is that you will get all
the normal launch flags if you use the launchcode mechanism, so you can tell if
you have globals available, etc...
David is also correct in that we are trying to move away from
_globally_broadcast_ launchcodes. For example, when the time changes a
launchcode is currently sent to every application on the device... if you have a
lot of apps, this can be pretty time consuming. Much better if everyone just
uses the notification and then we can just send the message to the few apps that
care.
>> * Can we expect to see Palm provide a registry for custom notifyType
>> values just as they do for creator IDs?
>
>Just use the creator id registry for the notification codes.
Yep... note that if you want to broadcast a notification that is specific to
your application, its probably okay to use the app's creator code (even though
that's technically using the same creator code for two different things...).
> Other than the above, I welcome the Notification Manager as a good move.
Glad you like it!! :-)
Jesse
