On Thu, May 17, 2012 at 10:04 AM, David Flanagan <
dfla...@mozilla.com> wrote:
> On 5/9/12 2:16 PM, Jonas Sicking wrote:
>>
>> Additionally there needs to be a way for an application to declare
>> where it wants incoming messages to be delivered. An application can
>> consist of many pages, but most likely wants to display a specific
>> page for a given type of incoming messages. So for example an
>> AlarmClock application could consist of several different pages for
>> setting up alarms, configuring synchronizing alarms over multiple
>> devices and the page which is displayed when an actual alarm fires. If
>> the application is already running, but displaying the "setting up
>> alarms" page, when an alarm fires, the application would likely want
>> to switch to the "alarm fires" page and send the notification to that
>> page.
>
> What happens if after setting an alarm, the user installs another alarm
> clock app whose manifest declares an interest in the same type of message?
> Do both apps get woken up? Is the user prompted? Or will the alarm api
> provide some way of specifying a custom message type that only it knows
> about?
Don't think of the Alarm API as an "alarm-clock API", think of it as a
"application wake-up API".
When an application schedules an alarm using the Alarm API, we will
wake *that* app up at the specified time. This way the API can be used
to implement many more things than alarm clocks. It also lets an app
wake itself up every 2 hours and sync data with the server. Or be used
for a calendar app to schedules callbacks such that it can notify the
user about an approaching appointment.
Also note that the "data" argument to AlarmManager.add is completely
application specific, so it wouldn't make much sense to send the
notification to another app.
> When an app is started to receive a message, will it be made into the active
> app and pop up over whatever the user is doing at the time? I'm not sure
> that's the right thing. In the case of an alarm clock app, it might just
> want to use a notification api of some sort to display the alarm to the user
> rather that displaying any of its own UI.
Originally I had hoped that we could require applications that didn't
want to pop up over the current app to direct the message to a worker
rather than to a page. I talked about this in the original email in
this list.
However we don't have nearly as many APIs available in workers as we
need for that to be really useful, and we don't yet have shared
workers, so I think for now we need to start applications in the
background and have an API which enable them to pop open if needed.
>> To solve this we propose to add the ability to declare in an
>> application manifest which page should be the receiver of different
>> types of incoming messages. So you can say that a given page or worker
>> is the one that should receive messages of a specific type. If we need
>> to start an app to deliver a message we'll open the app to this page
>> directly. If the app is already running, we'll navigate the app to
>> this page and wait for a message handler to be registered using
>> setMessageHandler.
>
> I don't understand how this would work for workers. Would you really list
> the URL of the worker's .js file?
Yes.
> We don't have shared workers, do we?
No.
> So starting a worker to receive the message means opening the page that creates
> the dedicated worker, doesn't it?
No, the solution is to implement shared workers.
>> Below are some of the reasons why we arrived at this design.
>
> Your reasoning for setMessageHandler() instead of events and
> addMessageListener() seems completely solid. I don't really understand how
> hasPendingMessage() would be used in practice. Some example code would be
> useful here.
Consider the camera app, which will provide the ability to use
WebActivities (which use system messages) to allow applications to
take still pictures.
When the camera app runs normally it has a button to toggle between
still picture mode and video mode. When the app runs as a result of a
still-picture-WebActivity it does not display this button.
The app would contain the following markup:
<button hidden id="mode-toggle" onclick="toggleCameraMode()"><img
src="toggle.png"></button>
<script>
if (!navigator.hasPendingMessage("webactivity")) {
document.getElementById("mode-toggle").hidden = false;
}
navigator.setMessageHandler("webactivity", function(activity) {
// Also unhide if a non-still-picture activity
document.getElementById("mode-toggle").hidden =
activity.data.type == "image";
});
</script>
If we didn't have the hasPendingMessage function, the app wouldn't
know when to unhide the toggle since it wouldn't know if it was going
to get a message handler callback. So it's only choice would be to
render the button by default and only hide it later, which could cause
ugly visual glitches during startup.
/ Jonas