Alarm API - If an alarm cannot be fired when the device shuts down, it should be fired when powering up.

RESOLVED FIXED in mozilla17

Status

()

defect
RESOLVED FIXED
7 years ago
2 days ago

People

(Reporter: airpingu, Assigned: airpingu)

Tracking

Trunk
mozilla17
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [LOE:S])

Attachments

(1 attachment)

Blocks: alarm-api
Summary: Alarm API - If an alarm cannot be fired when the device shuts down, if should be fired when powering up. → Alarm API - If an alarm cannot be fired when the device shuts down, it should be fired when powering up.
Hi Fabrice,

We encountered an interesting problem when solving this. If we attempt to fire a system message when the device is "powering up", the shell's observer can receive "system-messages-open-app" but cannot further open the Alarm-Colock app because the Gaia's window_manager.js has not yet been ready for catching the "open-app". Under this circumstance, we have to manually open the Alarm-Clock app and then it can response to the pending system message.

Sending the system message in a delayed 10 seconds will work (from Alarm API), but it doesn't sound an optimal approach. Any better solution to tackle the problem?
(In reply to Gene Lian [:gene] from comment #1)

> Sending the system message in a delayed 10 seconds will work (from Alarm
> API), but it doesn't sound an optimal approach. Any better solution to
> tackle the problem?

It looks like we should buffer messages in shell.js until the system app has started.
(In reply to Fabrice Desré [:fabrice] from comment #2)
> (In reply to Gene Lian [:gene] from comment #1)
> 
> > Sending the system message in a delayed 10 seconds will work (from Alarm
> > API), but it doesn't sound an optimal approach. Any better solution to
> > tackle the problem?
> 
> It looks like we should buffer messages in shell.js until the system app has
> started.

Sounds good! But how to detect if the system app has been started or not in shell.js? Can we really do that at the platform level?
(In reply to Gene Lian [:gene] from comment #3)
> (In reply to Fabrice Desré [:fabrice] from comment #2)
> > (In reply to Gene Lian [:gene] from comment #1)
> > 
> > > Sending the system message in a delayed 10 seconds will work (from Alarm
> > > API), but it doesn't sound an optimal approach. Any better solution to
> > > tackle the problem?
> > 
> > It looks like we should buffer messages in shell.js until the system app has
> > started.
> 
> Sounds good! But how to detect if the system app has been started or not in
> shell.js? Can we really do that at the platform level?

Respond to myself: I think we can follow something like http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#121 to listen to an "onload" event. As mentioned by Fabrice, We won't send "open-app" chromEvent until "onload" event is caught.
Depends on: 783149
Posted patch PatchSplinter Review
Hi Vivien,

Changes are super trivial:

1. Fire alarms that should have been fired during power-down and remove it from DB.

2. To decide if alarms are expired by comparing them with a more precise Date.now().

3. Although we still have a potential issue at comment #1, I've already fired another bug to keep track of that. For the Alarm API part, these changes are for sure.

Thanks very much for your review again :)
Assignee: nobody → clian
Attachment #652301 - Flags: review?(21)
Whiteboard: [LOE:S]
https://hg.mozilla.org/mozilla-central/rev/d51a3bf72b9c
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
No longer depends on: 783149
Depends on: 783149
You need to log in before you can comment on or make changes to this bug.