a handy object is hard to persist on the server or persist in local storage between page refreshes. .remove() should take a string or numeric id if you can use .remove() between page refreshes On Wed, May 8, 2013 at 12:29 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > On Wed, May 8, 2013 at 12:14 PM, Jake Verbaten <raynos2@gmail.com> wrote: > >> which means that it's impossible > >> to know what the alarm id is for cancelling until it's too late to > >> cancel it. > > > > I've actually interpreted the API wrongly. add returns once the device > > succesfully tells you that the alarm has been registered. > > > > You actually listen to the actual alarm going of by using > > `navigator.setMessageHandler("alarm", onAlarmFired);` which I missed on > my > > first scan. > > Oh, I see! Yes, that's very unclear, though this is partially due to > my ignorance of "system messages". It negates several of my issues, > though. > > In that case, scratch my comments about cancellable futures. Instead, > keep .remove(), but just let it accept the future returned by .add(). > No reason to abstract through a string when you've got a handy object > already there. That way you can kill the .id property entirely. > > My comments about potentially killing .clear() stand, though. It may > be convenient to keep, but we can drop it if it can't justify itself. > > ~TJ >Received on Wednesday, 8 May 2013 21:17:25 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC