Re: Web Alarm API - idiomatic check

On Wed, May 15, 2013 at 6:44 AM, Mounir Lamouri <> wrote:
> On 09/05/13 21:42, Christophe Dumez - SISA wrote:
>> Hi,
>> I commented on that bug. If I remember correctly, clear() was added for consistency with the Contact API.
>> It is merely a convenience function so I don't have strong feeling either way.
>> However, I do think that clear() is a lot more readable than getPendingAlarms().then(alarms=>alarms.forEach(x=>x.cancel()));
> .clear() has a performance advantage compared to
> .getPendingAlarms().then(alarms=>alarms.forEach(x=>x.cancel())): when
> you use .clear() there will be only one DB access that will remove every
> alarm that belongs to the caller. Using .cancel() for each alarm might
> do as much calls to the DB which is going to be significantly slower. It
> is possible to argue that a clever implementation could delay the DB
> access so it can perform multiple operations at the same time but I
> think having a .clear() method is a syntax sugar that could make life
> easier for developers and implementations and it is worth taking.

How common is it for applications to need to cancel all alarms though?
I can't think of any use cases other than "complete system reset",
which I don't think is a common UI to expose to users from within an

The only reason that I think we ended up with .clear() in the contacts
API (which as I understand it this was copied from) was that it was
useful during testing and development of the API itself. Hardly
something we should optimize for.

/ Jonas

Received on Wednesday, 15 May 2013 22:19:26 UTC