info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
System Intents
1,082 views
Skip to first unread message
Jonas Sicking
May 9, 2012, 5:16:44 PM5/9/12
to dev-webapi
Hi All,
The concept of "system intents" has been discussed quite a bit on this
list, however so far they have been pretty poorly defined. I would
imagine that different people have had different ideas for what
capabilities "system intents" have, and very likely there are
different ideas for their exact API.
Mounir and I sat down today and hammered through different ideas for
concrete proposals. This is intended to be a description of what we
came up with.
I'd like to start with some terminology. The term "intents" is
currently *very* overloaded and has very different meanings to
different people. The term originate from Android where one of the
core ideas of "intents" is that an application can initiate an
"intent" but OS displays UI to the user allowing the user to choose
which application to use to fulfill the intent. Such UI is generally
not something that we want for "system intents". Hence I'd like to
avoid using the term "intents" here.
Instead I'm going to use the term "message handler" here. But I'm all
ears for other ideas of what term to use.
Let's start with what capabilities we want:
* Basic capability is to send messages from the platform (B2G) to an
application.
* The application may or may not be running at the time when we want
to send a message to it.
* If the application isn't running, we want to automatically start it
and then deliver the message.
* In order to reduce the risk of bugs the delivery mechanism should be
as similar as possible for both applications which aren't started as
well applications that were already running.
* If an application wasn't running, we want the application to render
in the "right state" as quickly as possible. I.e. the application
shouldn't first render in its default mode and then suddenly change
once it receives the incoming message.
The basic delivery mechanism we propose is as follows:
the setMessageHandler function sets up a message handler for a
specific type of messages and signals that the application is
navigator.setMessageHandler(type, function(message) { ... });
As soon as you make the above call, if there is a pending message, we
will schedule an asynchronous call to the now-registered handler. The
handler is thus called asynchronously once it is registered.
However if you need to synchronously know if the application was
started in response to a message, for example in order to decide what
UI to show, we should also have a function like
navigator.hasPendingMessage(type)
which returns true if there's a pending message that will be fired. If
this function returns true, you can be confident in that returning to
the event loop will cause the message handler be called very quickly.
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.
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.
Below are some of the reasons why we arrived at this design.
Not using events:
(this is a duplicated description from the Alarm API thread)
The problem with using events to deliver messages is that for the case
when we want to deliver a message to an app which is not running, we
need to start the app and then deliver a message to it. If we use
events, it means that we need to wait with firing the event until all
event handlers have been registered. I.e. it means that we can't fire
the alarm until the page is "fully loaded". However defining "fully
loaded" is a bit tricky on the web. We could fire the alarm event
sometime after DOMContentLoaded has fired. This generally means after
the whole DOM has been parsed and most of the <script>s have executed.
However not all <script>s have executed when DOMContentLoaded fires.
For example any <script>s with the async attribute set might not have
loaded. Also, it's very common today on the web to use various script
loaders which asynchronously load scripts using
createElement("script") and setting .src. Such scripts might also not
have loaded and so haven't had time to register alarm event listeners.
So we could wait until the "load" event is fired on the page. That
will ensure that <script>s with the async attribute set will have
loaded and have executed. But again, scripts loading using script
loaders might not even be started until the "load" event fires.
Additionally, waiting for "load" or DOMContentLoaded firing could in
many cases be waiting too long. An app can have been rendering for a
long time by the time that DOMContentLoaded fires. This could result
in a bad user experience where the app loads and renders in its
default state, and then suddenly changes once the alarm event fires.
Users likely expect the app to render in the correct state right away.
We had exactly this problem when designing the pushState API and ended
up having to do a last-minute change of the API and move away from
delivering data to a loading page using an event. There simply was no
good way to make events work as a delivery mechanism.
Asynchronously delivering messages:
However in order to support the case when we want to deliver a message
to an app which is already running, we need to use some sort of
asynchronous callback mechanism. We don't want applications to have to
continuously poll for incoming messages, instead we want to call a
function in the application as soon as an incoming message arrives.
We were pondering ways of additionally providing a way to deliver
messages synchronously, which could be useful during page load to
allow the application to synchronously get information about what UI
to render. However it felt like there as just too big of a risk that
people would only use the synchronous API, which would work great any
time an application was started in response to a message, but would
fail if the application happened to be running when the message was
delivered since that would only happen through the asynchronous API.
Instead we just added the synchronous hasPendingMessages function.
That way the page can check if there are incoming messages and wait
with making any UI decisions until the message is delivered, which
always happens quickly after setMessageHandler is called.
setMessageHandler rather than addMessageHandler:
To satisfy the desire that messages should be delivered as soon as
possible, but that we don't really know when the application is ready
to receive them, we need a way for applications to signal to the
platform when it is ready to receive messages. That way the
application can do this before it renders anything. It also means that
it doesn't matter if the code that handles incoming messages is loaded
using an async <script>, or using a blocking <script> at the top of
the page. In either case we will deliver the messages as soon as the
application is ready to receive them.
What we propose is that we combine the API for setting the callback
with the API for saying that we're ready to start receiving messages.
So simply doing:
navigator.setMessageHandler("alarm", function(alarm) { ... });
both sets which callback should be called when there is an incoming
alarm message, *and* tells the platform that the application is ready
to receive incoming "alarm" messages. So if we started the application
in order to deliver an alarm message to it, it means that as soon as
the application makes the call above, we can deliver the alarm
message.
However this means that we can't safely have more than one message
handler. I.e. we couldn't create an API similar to
EventTarget.addEventListener where the application can register any
number of message listeners that are all notified. This is because
once the first listener is registered we'll start sending it messages
which would mean that subsequent listeners might not get registered in
time and thus might miss incoming messages.
This would be the case no matter what API we use for the page to
signal that it's ready to start receiving messages. If we have an API
like addMessageHandler it means that the page has to coordinate and
make sure to register all listeners before signaling that it's ready
to start receiving messages. Since coordination is needed, we might as
well use a simple setMessageHandler and let the application create its
own logic for distributing messages to everyone that is interested if
it needs to.
By making the API setMessageHandler we keep the API clear and simple.
It makes it clear that only one message handler can be used and that
it's the responsibility of the application to implement more complex
use cases. And by using the same API to register the message handler
as to signal that the application is ready to receive messages, it
means less code for the application and removes the risk that it turns
on receiving message before a message handler is set up.
Let us know what you think about this proposal!
/ Jonas
The concept of "system intents" has been discussed quite a bit on this
list, however so far they have been pretty poorly defined. I would
imagine that different people have had different ideas for what
capabilities "system intents" have, and very likely there are
different ideas for their exact API.
Mounir and I sat down today and hammered through different ideas for
concrete proposals. This is intended to be a description of what we
came up with.
I'd like to start with some terminology. The term "intents" is
currently *very* overloaded and has very different meanings to
different people. The term originate from Android where one of the
core ideas of "intents" is that an application can initiate an
"intent" but OS displays UI to the user allowing the user to choose
which application to use to fulfill the intent. Such UI is generally
not something that we want for "system intents". Hence I'd like to
avoid using the term "intents" here.
Instead I'm going to use the term "message handler" here. But I'm all
ears for other ideas of what term to use.
Let's start with what capabilities we want:
* Basic capability is to send messages from the platform (B2G) to an
application.
* The application may or may not be running at the time when we want
to send a message to it.
* If the application isn't running, we want to automatically start it
and then deliver the message.
* In order to reduce the risk of bugs the delivery mechanism should be
as similar as possible for both applications which aren't started as
well applications that were already running.
* If an application wasn't running, we want the application to render
in the "right state" as quickly as possible. I.e. the application
shouldn't first render in its default mode and then suddenly change
once it receives the incoming message.
The basic delivery mechanism we propose is as follows:
the setMessageHandler function sets up a message handler for a
specific type of messages and signals that the application is
navigator.setMessageHandler(type, function(message) { ... });
As soon as you make the above call, if there is a pending message, we
will schedule an asynchronous call to the now-registered handler. The
handler is thus called asynchronously once it is registered.
However if you need to synchronously know if the application was
started in response to a message, for example in order to decide what
UI to show, we should also have a function like
navigator.hasPendingMessage(type)
which returns true if there's a pending message that will be fired. If
this function returns true, you can be confident in that returning to
the event loop will cause the message handler be called very quickly.
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.
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.
Below are some of the reasons why we arrived at this design.
Not using events:
(this is a duplicated description from the Alarm API thread)
The problem with using events to deliver messages is that for the case
when we want to deliver a message to an app which is not running, we
need to start the app and then deliver a message to it. If we use
events, it means that we need to wait with firing the event until all
event handlers have been registered. I.e. it means that we can't fire
the alarm until the page is "fully loaded". However defining "fully
loaded" is a bit tricky on the web. We could fire the alarm event
sometime after DOMContentLoaded has fired. This generally means after
the whole DOM has been parsed and most of the <script>s have executed.
However not all <script>s have executed when DOMContentLoaded fires.
For example any <script>s with the async attribute set might not have
loaded. Also, it's very common today on the web to use various script
loaders which asynchronously load scripts using
createElement("script") and setting .src. Such scripts might also not
have loaded and so haven't had time to register alarm event listeners.
So we could wait until the "load" event is fired on the page. That
will ensure that <script>s with the async attribute set will have
loaded and have executed. But again, scripts loading using script
loaders might not even be started until the "load" event fires.
Additionally, waiting for "load" or DOMContentLoaded firing could in
many cases be waiting too long. An app can have been rendering for a
long time by the time that DOMContentLoaded fires. This could result
in a bad user experience where the app loads and renders in its
default state, and then suddenly changes once the alarm event fires.
Users likely expect the app to render in the correct state right away.
We had exactly this problem when designing the pushState API and ended
up having to do a last-minute change of the API and move away from
delivering data to a loading page using an event. There simply was no
good way to make events work as a delivery mechanism.
Asynchronously delivering messages:
However in order to support the case when we want to deliver a message
to an app which is already running, we need to use some sort of
asynchronous callback mechanism. We don't want applications to have to
continuously poll for incoming messages, instead we want to call a
function in the application as soon as an incoming message arrives.
We were pondering ways of additionally providing a way to deliver
messages synchronously, which could be useful during page load to
allow the application to synchronously get information about what UI
to render. However it felt like there as just too big of a risk that
people would only use the synchronous API, which would work great any
time an application was started in response to a message, but would
fail if the application happened to be running when the message was
delivered since that would only happen through the asynchronous API.
Instead we just added the synchronous hasPendingMessages function.
That way the page can check if there are incoming messages and wait
with making any UI decisions until the message is delivered, which
always happens quickly after setMessageHandler is called.
setMessageHandler rather than addMessageHandler:
To satisfy the desire that messages should be delivered as soon as
possible, but that we don't really know when the application is ready
to receive them, we need a way for applications to signal to the
platform when it is ready to receive messages. That way the
application can do this before it renders anything. It also means that
it doesn't matter if the code that handles incoming messages is loaded
using an async <script>, or using a blocking <script> at the top of
the page. In either case we will deliver the messages as soon as the
application is ready to receive them.
What we propose is that we combine the API for setting the callback
with the API for saying that we're ready to start receiving messages.
So simply doing:
navigator.setMessageHandler("alarm", function(alarm) { ... });
both sets which callback should be called when there is an incoming
alarm message, *and* tells the platform that the application is ready
to receive incoming "alarm" messages. So if we started the application
in order to deliver an alarm message to it, it means that as soon as
the application makes the call above, we can deliver the alarm
message.
However this means that we can't safely have more than one message
handler. I.e. we couldn't create an API similar to
EventTarget.addEventListener where the application can register any
number of message listeners that are all notified. This is because
once the first listener is registered we'll start sending it messages
which would mean that subsequent listeners might not get registered in
time and thus might miss incoming messages.
This would be the case no matter what API we use for the page to
signal that it's ready to start receiving messages. If we have an API
like addMessageHandler it means that the page has to coordinate and
make sure to register all listeners before signaling that it's ready
to start receiving messages. Since coordination is needed, we might as
well use a simple setMessageHandler and let the application create its
own logic for distributing messages to everyone that is interested if
it needs to.
By making the API setMessageHandler we keep the API clear and simple.
It makes it clear that only one message handler can be used and that
it's the responsibility of the application to implement more complex
use cases. And by using the same API to register the message handler
as to signal that the application is ready to receive messages, it
means less code for the application and removes the risk that it turns
on receiving message before a message handler is set up.
Let us know what you think about this proposal!
/ Jonas
JOSE MANUEL CANTERA FONSECA
May 10, 2012, 4:09:03 PM5/10/12
to Jonas Sicking, dev-webapi
El 09/05/12 23:16, "Jonas Sicking" <jo...@sicking.cc> escribió:
>
>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.
>
>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 dont't think that's a good idea for various reasons
A/ many apps are implemented as a single page because it is difficult to
implement transitions in a multiple page schema
B/ it will annoy the user if the page changes unexpectedly, for instance,
information can be lost
C/ as a developer I prefer to have the full control of the state of my app
>
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>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.
>
>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.
A/ many apps are implemented as a single page because it is difficult to
implement transitions in a multiple page schema
B/ it will annoy the user if the page changes unexpectedly, for instance,
information can be lost
C/ as a developer I prefer to have the full control of the state of my app
>
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Adrienne Porter Felt
May 10, 2012, 5:13:56 PM5/10/12
to dev-webapi
navigate away from an already-open page.
> C/ as a developer I prefer to have the full control of the state of my app
right? And then you can optionally act on or ignore the messages with your
message handler.
Jonas Sicking
May 10, 2012, 8:50:41 PM5/10/12
to JOSE MANUEL CANTERA FONSECA, dev-webapi
> B/ it will annoy the user if the page changes unexpectedly, for instance,
> information can be lost
strategy. If there is a risk of dataloss when a navigation happens
then the application can simply choose to use a worker as handler for
incoming messages. The worker can then either handle the message
itself, or it can request that the application is navigated once the
relevant data has been saved.
> C/ as a developer I prefer to have the full control of the state of my app
application manifest.
/ Jonas
Jonas Sicking
May 10, 2012, 8:54:25 PM5/10/12
to Adrienne Porter Felt, dev-webapi
>> B/ it will annoy the user if the page changes unexpectedly, for instance,
>> information can be lost
>>
>
>> information can be lost
>>
>
> It seems like receiving a message should open a new page, rather than
> navigate away from an already-open page.
This is problematic in mobile where applications generally can only
> navigate away from an already-open page.
have one page open.
>> C/ as a developer I prefer to have the full control of the state of my app
>
> You could still do that by registering one page for all incoming messages,
> right? And then you can optionally act on or ignore the messages with your
> message handler.
Indeed.
> right? And then you can optionally act on or ignore the messages with your
> message handler.
The alternative is to require that *all* pages in an application uses
the setMessageHandler API. This is both onerous and error prone since
it's easy to forget.
We could allow the manifest to list several pages and if any of them
is the currently open page we simply send the message to that page.
That way if an app consisted of several pages but still never wanted
any unexpected page transitions, it could simply list every page in
the application manifest and make all pages use the setMessageHandler
API. However an easier solution would likely be for the app to
register a worker as the message handler.
/ Jonas
JOSE MANUEL CANTERA FONSECA
May 10, 2012, 10:45:24 PM5/10/12
to Jonas Sicking, dev-webapi
El 11/05/12 02:50, "Jonas Sicking" <jo...@sicking.cc> escribió:
regardless the page is currently loaded', because my app is prepared to
deal with those incoming messages.
>
>/ Jonas
>Then you simply list that page as the page to handle incoming messages.
>
>
>> B/ it will annoy the user if the page changes unexpectedly, for
>>instance,
>> information can be lost
>
>>instance,
>> information can be lost
>
>It's completely the choice of the application if it wants to use this
>strategy. If there is a risk of dataloss when a navigation happens
>then the application can simply choose to use a worker as handler for
>incoming messages. The worker can then either handle the message
>itself, or it can request that the application is navigated once the
>relevant data has been saved.
>
>strategy. If there is a risk of dataloss when a navigation happens
>then the application can simply choose to use a worker as handler for
>incoming messages. The worker can then either handle the message
>itself, or it can request that the application is navigated once the
>relevant data has been saved.
>
>> C/ as a developer I prefer to have the full control of the state of my
>>app
>
>>app
>
>The developer does. The developer chooses what he/she puts in the
>application manifest.
I would like not to put anything. That would be mean, 'send me the message
>application manifest.
regardless the page is currently loaded', because my app is prepared to
deal with those incoming messages.
>
>/ Jonas
Gene
May 15, 2012, 6:42:05 AM5/15/12
to mozilla-d...@lists.mozilla.org
Hi guys,
Currently, I'm working on Alarm API to establish the connections
between DOM interface and 1) hal/gonk (for registering alarm through
IO control) as well as 2) indexedDB (for saving alarms' status to be
restored after restart). We still lack the general architecture of
message handler (system intent) for sending message back. May I ask is
there anyone going to take this part so far?
Thanks,
Gene
Currently, I'm working on Alarm API to establish the connections
between DOM interface and 1) hal/gonk (for registering alarm through
IO control) as well as 2) indexedDB (for saving alarms' status to be
restored after restart). We still lack the general architecture of
message handler (system intent) for sending message back. May I ask is
there anyone going to take this part so far?
Thanks,
Gene
Mounir Lamouri
May 30, 2012, 9:26:34 AM5/30/12
to dev-w...@lists.mozilla.org
On 05/17/2012 07:04 PM, David Flanagan wrote:
> 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?
An alarm clock will mark itself as interested in System Messages type
'alarm' but it will only receive a system message when the alarms it has
registered will fire. More than one application will be interested in
'alarm' System Messages, for example alarm clock applications, calendar
applications, todo list applications and any application that need to do
something at a specific time or do an action regularly (like an email
application).
>> 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.
For example, take the dialer application. When called by an Activity
that wants to make a call, it will have to show a specific UI. However,
when started, it might try to show a default UI that is different. So,
at startup the dialer application can check if there are pending
messages. In that case, it will delay some parts of the UI choices to
when the system message will be received. If there is only one Activity
that can be handled by the app/page, it could even show the UI in
advance. For the case of the dialer app, we could easily imagine that it
show a UI with dial buttons and will wait for the number to call (from
the system message) to show it in the number text field.
Cheers,
--
Mounir
> 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?
An alarm clock will mark itself as interested in System Messages type
'alarm' but it will only receive a system message when the alarms it has
registered will fire. More than one application will be interested in
'alarm' System Messages, for example alarm clock applications, calendar
applications, todo list applications and any application that need to do
something at a specific time or do an action regularly (like an email
application).
>> Below are some of the reasons why we arrived at this design.
> addMessageListener() seems completely solid. I don't really understand
> how hasPendingMessage() would be used in practice. Some example code
> would be useful here.
For example, take the dialer application. When called by an Activity
that wants to make a call, it will have to show a specific UI. However,
when started, it might try to show a default UI that is different. So,
at startup the dialer application can check if there are pending
messages. In that case, it will delay some parts of the UI choices to
when the system message will be received. If there is only one Activity
that can be handled by the app/page, it could even show the UI in
advance. For the case of the dialer app, we could easily imagine that it
show a UI with dial buttons and will wait for the number to call (from
the system message) to show it in the number text field.
Cheers,
--
Mounir
gape
Jun 5, 2012, 10:29:27 AM6/5/12
to mozilla.d...@googlegroups.com, dev-webapi
allow me to register a handler to listen to incoming network data on that socket
gape
Jun 5, 2012, 10:29:27 AM6/5/12
to mozilla-d...@lists.mozilla.org, dev-webapi
On Wednesday, May 9, 2012 11:16:44 PM UTC+2, Jonas Sicking wrote:
A question- if a socket like API were to be introduced in B2G, would this then
allow me to register a handler to listen to incoming network data on that socket
On Wednesday, May 9, 2012 11:16:44 PM UTC+2, Jonas Sicking wrote:
allow me to register a handler to listen to incoming network data on that socket
On Wednesday, May 9, 2012 11:16:44 PM UTC+2, Jonas Sicking wrote:
Jonas Sicking
Jun 6, 2012, 3:27:24 AM6/6/12
to David Flanagan, dev-w...@lists.mozilla.org
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.
>
> 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
> clock app whose manifest declares an interest in the same type of message?
> 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.
>
> 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
> addMessageListener() seems completely solid. I don't really understand how
> hasPendingMessage() would be used in practice. Some example code would be
> useful here.
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
Jonas Sicking
Jun 6, 2012, 3:30:25 AM6/6/12
to gape, dev-webapi, mozilla-d...@lists.mozilla.org
On Tue, Jun 5, 2012 at 7:29 AM, gape <gap...@gmail.com> wrote:
> On Wednesday, May 9, 2012 11:16:44 PM UTC+2, Jonas Sicking wrote:
> On Wednesday, May 9, 2012 11:16:44 PM UTC+2, Jonas Sicking wrote:
> A question- if a socket like API were to be introduced in B2G, would this then
> allow me to register a handler to listen to incoming network data on that socket
*If* we designed an API which would let apps act as "servers", then
> allow me to register a handler to listen to incoming network data on that socket
yes. I.e. if we wanted apps to be able to register to handle incoming
connections to a specific port (or set of ports) then we could use
this API to notify the app that a incoming port was opened.
We currently don't have any plans for such an API though, but it could
be interesting to do later.
In the mean-time I suggest you look at the Push API, which I think we
should extend to use system message to allow pushing messages to an
app.
/ Jonas
Jonas Sicking
Jun 6, 2012, 3:30:25 AM6/6/12
to gape, dev-webapi, mozilla-d...@lists.mozilla.org
On Tue, Jun 5, 2012 at 7:29 AM, gape <gap...@gmail.com> wrote:
> On Wednesday, May 9, 2012 11:16:44 PM UTC+2, Jonas Sicking wrote:
> On Wednesday, May 9, 2012 11:16:44 PM UTC+2, Jonas Sicking wrote:
Gene Lian
Jun 7, 2012, 3:14:50 AM6/7/12
to mozilla.d...@googlegroups.com, dev-webapi, mozilla-d...@lists.mozilla.org
Hi guys! I'd like raise one question that I cannot find an accurate answer in the previous discussion thread, hopping to have a better understanding about the usage of system message :)
Since the Alarm API could be applied on different Apps, like alarm-clock, calendar or auto-update... etc, how can the Alarm API backend decide which app is going to be sent with an "alarm" system message when an alarm is fired? Does it mean we need to let each App register different types of system messages? like setMessageHandler("alarm-clock", ...) or setMessageHandler("alarm-calendar", ...)? If so, do we need a way to save the keyword ("alarm-clock" or "alarm-calendar"... etc) in each alarm when setting it?
Or the Alarm API back-end only needs to uniformly send a single "alarm" system message and let each App that used to call setMessageHandler("alarm", ...) check whether this message belongs to it or not? That is, doing so by matching the alarm ID programmed by AlarmsManager.add()?
Thanks,
Gene
Since the Alarm API could be applied on different Apps, like alarm-clock, calendar or auto-update... etc, how can the Alarm API backend decide which app is going to be sent with an "alarm" system message when an alarm is fired? Does it mean we need to let each App register different types of system messages? like setMessageHandler("alarm-clock", ...) or setMessageHandler("alarm-calendar", ...)? If so, do we need a way to save the keyword ("alarm-clock" or "alarm-calendar"... etc) in each alarm when setting it?
Or the Alarm API back-end only needs to uniformly send a single "alarm" system message and let each App that used to call setMessageHandler("alarm", ...) check whether this message belongs to it or not? That is, doing so by matching the alarm ID programmed by AlarmsManager.add()?
Thanks,
Gene
Message has been deleted
Message has been deleted
Jonas Sicking
Jun 7, 2012, 3:24:35 AM6/7/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
Think of it as an API for an application to schedule getting
automatically started at a particular time.
If app A uses the Alarm API to schedule a notification at 7pm on a
particular day, then we should at that time use the message handler
mechanism to deliver an "alarm" message to app A.
If at the same time app B uses the Alarm API to schedule a
notification at 7:01pm on the same day, then we should at that time
use the message handler mechanism to deliver an "arlam" message to app
B.
In other words the alarm API is very similar to setTimeout. The
callback always happen to the app which scheduled the callback. The
main difference is that the Alarm API can be used to wake an
application up, whereas setTimeout only works while an app is running.
The effect of this is that if a user installs 2 clock applications,
and schedules a wakeup alarm in the first application at 9am and a
wakeup alarm in the second clock application at 10am, then at 9am the
first clock application will ring, and at 10am the second clock
application will ring.
Hope that helps.
/ Jonas
Jonas Sicking
Jun 7, 2012, 3:24:35 AM6/7/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
Gene Lian
Jun 7, 2012, 4:03:34 AM6/7/12
to mozilla.d...@googlegroups.com, dev-webapi, mozilla-d...@lists.mozilla.org, Gene Lian
> Don't think of the alarm API as an API for implementing alarm clocks.
> Think of it as an API for an application to schedule getting
> automatically started at a particular time.
>
> If app A uses the Alarm API to schedule a notification at 7pm on a
> particular day, then we should at that time use the message handler
> mechanism to deliver an "alarm" message to app A.
>
> If at the same time app B uses the Alarm API to schedule a
> notification at 7:01pm on the same day, then we should at that time
> use the message handler mechanism to deliver an "arlam" message to app
> B.
Yes, I understand. But how to deliver an "alarm" message to a specific app? It seems the app can only use navigator.setMessageHandler("alarm", ...) to register the current ageURI and manifestURI where the setMessageHandler() is being called. If both app A and B use navigator.setMessageHandler("alarm", ...) with the same system message type (i.e. "alarm"), when an alarm is fired how can we deliver the same "alarm" message to the right app? Do we need to somehow save the app info when setting alarm?
> Think of it as an API for an application to schedule getting
> automatically started at a particular time.
>
> If app A uses the Alarm API to schedule a notification at 7pm on a
> particular day, then we should at that time use the message handler
> mechanism to deliver an "alarm" message to app A.
>
> If at the same time app B uses the Alarm API to schedule a
> notification at 7:01pm on the same day, then we should at that time
> use the message handler mechanism to deliver an "arlam" message to app
> B.
Sorry for my misunderstanding if any :)
Gene
Message has been deleted
Message has been deleted
Jonas Sicking
Jun 7, 2012, 4:09:21 AM6/7/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
On Thu, Jun 7, 2012 at 1:03 AM, Gene Lian <cl...@mozilla.com> wrote:
>> Don't think of the alarm API as an API for implementing alarm clocks.
>> Think of it as an API for an application to schedule getting
>> automatically started at a particular time.
>>
>> If app A uses the Alarm API to schedule a notification at 7pm on a
>> particular day, then we should at that time use the message handler
>> mechanism to deliver an "alarm" message to app A.
>>
>> If at the same time app B uses the Alarm API to schedule a
>> notification at 7:01pm on the same day, then we should at that time
>> use the message handler mechanism to deliver an "arlam" message to app
>> B.
>
>> Don't think of the alarm API as an API for implementing alarm clocks.
>> Think of it as an API for an application to schedule getting
>> automatically started at a particular time.
>>
>> If app A uses the Alarm API to schedule a notification at 7pm on a
>> particular day, then we should at that time use the message handler
>> mechanism to deliver an "alarm" message to app A.
>>
>> If at the same time app B uses the Alarm API to schedule a
>> notification at 7:01pm on the same day, then we should at that time
>> use the message handler mechanism to deliver an "arlam" message to app
>> B.
>
> Yes, I understand. But how to deliver an "alarm" message to a specific app? It seems the app can only use navigator.setMessageHandler("alarm", ...) to register the current ageURI and manifestURI where the setMessageHandler() is being called. If both app A and B use navigator.setMessageHandler("alarm", ...) with the same system message type (i.e. "alarm"), when an alarm is fired how can we deliver the same "alarm" message to the right app? Do we need to somehow save the app info when setting alarm?
The last part is exactly right. The implementation of the
AlarmManager.add function need to remember which app made the call.
Then we use that information when calling the message-handler
implementation to ensure that the message is sent to the same
application as the one that made the call to .add.
Implementation-wise you should be able to do this by keeping a pointer
to the Window object in the AlarmManager. I believe you can then get
to the application's manifestURI through the Window object though I'm not sure
about the details there.
/ Jonas
Jonas Sicking
Jun 7, 2012, 4:09:21 AM6/7/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
On Thu, Jun 7, 2012 at 1:03 AM, Gene Lian <cl...@mozilla.com> wrote:
>> Don't think of the alarm API as an API for implementing alarm clocks.
>> Think of it as an API for an application to schedule getting
>> automatically started at a particular time.
>>
>> If app A uses the Alarm API to schedule a notification at 7pm on a
>> particular day, then we should at that time use the message handler
>> mechanism to deliver an "alarm" message to app A.
>>
>> If at the same time app B uses the Alarm API to schedule a
>> notification at 7:01pm on the same day, then we should at that time
>> use the message handler mechanism to deliver an "arlam" message to app
>> B.
>
>> Don't think of the alarm API as an API for implementing alarm clocks.
>> Think of it as an API for an application to schedule getting
>> automatically started at a particular time.
>>
>> If app A uses the Alarm API to schedule a notification at 7pm on a
>> particular day, then we should at that time use the message handler
>> mechanism to deliver an "alarm" message to app A.
>>
>> If at the same time app B uses the Alarm API to schedule a
>> notification at 7:01pm on the same day, then we should at that time
>> use the message handler mechanism to deliver an "arlam" message to app
>> B.
>
Fabrice Desré
Jun 7, 2012, 1:28:19 PM6/7/12
to Jonas Sicking, dev-webapi, mozilla-d...@lists.mozilla.org, Gene Lian
On 06/07/2012 01:09 AM, Jonas Sicking wrote:
app. But do we also allow "broadcast" messages that can be received by
any page or app registering for these messages types?
Fabrice
--
Fabrice Desré
b2g Team
Mozilla Corporation
> On Thu, Jun 7, 2012 at 1:03 AM, Gene Lian <cl...@mozilla.com> wrote:
>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>> Think of it as an API for an application to schedule getting
>>> automatically started at a particular time.
>>>
>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>> particular day, then we should at that time use the message handler
>>> mechanism to deliver an "alarm" message to app A.
>>>
>>> If at the same time app B uses the Alarm API to schedule a
>>> notification at 7:01pm on the same day, then we should at that time
>>> use the message handler mechanism to deliver an "arlam" message to app
>>> B.
>>
>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>> Think of it as an API for an application to schedule getting
>>> automatically started at a particular time.
>>>
>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>> particular day, then we should at that time use the message handler
>>> mechanism to deliver an "alarm" message to app A.
>>>
>>> If at the same time app B uses the Alarm API to schedule a
>>> notification at 7:01pm on the same day, then we should at that time
>>> use the message handler mechanism to deliver an "arlam" message to app
>>> B.
>>
>> Yes, I understand. But how to deliver an "alarm" message to a specific app? It seems the app can only use navigator.setMessageHandler("alarm", ...) to register the current ageURI and manifestURI where the setMessageHandler() is being called. If both app A and B use navigator.setMessageHandler("alarm", ...) with the same system message type (i.e. "alarm"), when an alarm is fired how can we deliver the same "alarm" message to the right app? Do we need to somehow save the app info when setting alarm?
>
> The last part is exactly right. The implementation of the
> AlarmManager.add function need to remember which app made the call.
> Then we use that information when calling the message-handler
> implementation to ensure that the message is sent to the same
> application as the one that made the call to .add.
So, if a message is targeted as a given app, we only deliver it to this
>
> The last part is exactly right. The implementation of the
> AlarmManager.add function need to remember which app made the call.
> Then we use that information when calling the message-handler
> implementation to ensure that the message is sent to the same
> application as the one that made the call to .add.
app. But do we also allow "broadcast" messages that can be received by
any page or app registering for these messages types?
Fabrice
--
Fabrice Desré
b2g Team
Mozilla Corporation
Fabrice Desré
Jun 7, 2012, 1:28:19 PM6/7/12
to Jonas Sicking, dev-webapi, mozilla-d...@lists.mozilla.org, Gene Lian
On 06/07/2012 01:09 AM, Jonas Sicking wrote:
> On Thu, Jun 7, 2012 at 1:03 AM, Gene Lian <cl...@mozilla.com> wrote:
>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>> Think of it as an API for an application to schedule getting
>>> automatically started at a particular time.
>>>
>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>> particular day, then we should at that time use the message handler
>>> mechanism to deliver an "alarm" message to app A.
>>>
>>> If at the same time app B uses the Alarm API to schedule a
>>> notification at 7:01pm on the same day, then we should at that time
>>> use the message handler mechanism to deliver an "arlam" message to app
>>> B.
>>
>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>> Think of it as an API for an application to schedule getting
>>> automatically started at a particular time.
>>>
>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>> particular day, then we should at that time use the message handler
>>> mechanism to deliver an "alarm" message to app A.
>>>
>>> If at the same time app B uses the Alarm API to schedule a
>>> notification at 7:01pm on the same day, then we should at that time
>>> use the message handler mechanism to deliver an "arlam" message to app
>>> B.
>>
Jonas Sicking
Jun 7, 2012, 8:18:56 PM6/7/12
to Fabrice Desré, dev-webapi, mozilla-d...@lists.mozilla.org, Gene Lian
On Thu, Jun 7, 2012 at 10:28 AM, Fabrice Desré <fab...@mozilla.com> wrote:
> On 06/07/2012 01:09 AM, Jonas Sicking wrote:
>>
> On 06/07/2012 01:09 AM, Jonas Sicking wrote:
>>
>> On Thu, Jun 7, 2012 at 1:03 AM, Gene Lian <cl...@mozilla.com> wrote:
>>>>
>>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>>> Think of it as an API for an application to schedule getting
>>>> automatically started at a particular time.
>>>>
>>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>>> particular day, then we should at that time use the message handler
>>>> mechanism to deliver an "alarm" message to app A.
>>>>
>>>> If at the same time app B uses the Alarm API to schedule a
>>>> notification at 7:01pm on the same day, then we should at that time
>>>> use the message handler mechanism to deliver an "arlam" message to app
>>>> B.
>>>
>>>
>>>>
>>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>>> Think of it as an API for an application to schedule getting
>>>> automatically started at a particular time.
>>>>
>>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>>> particular day, then we should at that time use the message handler
>>>> mechanism to deliver an "alarm" message to app A.
>>>>
>>>> If at the same time app B uses the Alarm API to schedule a
>>>> notification at 7:01pm on the same day, then we should at that time
>>>> use the message handler mechanism to deliver an "arlam" message to app
>>>> B.
>>>
>>>
>>> Yes, I understand. But how to deliver an "alarm" message to a specific
>>> app? It seems the app can only use navigator.setMessageHandler("alarm", ...)
>>> to register the current ageURI and manifestURI where the setMessageHandler()
>>> is being called. If both app A and B use
>>> navigator.setMessageHandler("alarm", ...) with the same system message type
>>> (i.e. "alarm"), when an alarm is fired how can we deliver the same "alarm"
>>> message to the right app? Do we need to somehow save the app info when
>>> setting alarm?
>>
>>
>> The last part is exactly right. The implementation of the
>> AlarmManager.add function need to remember which app made the call.
>> Then we use that information when calling the message-handler
>> implementation to ensure that the message is sent to the same
>> application as the one that made the call to .add.
>
>
> So, if a message is targeted as a given app, we only deliver it to this app.
> But do we also allow "broadcast" messages that can be received by any page
> or app registering for these messages types?
Hmm... I can't remember off the top of my head if we have the need for
>>> app? It seems the app can only use navigator.setMessageHandler("alarm", ...)
>>> to register the current ageURI and manifestURI where the setMessageHandler()
>>> is being called. If both app A and B use
>>> navigator.setMessageHandler("alarm", ...) with the same system message type
>>> (i.e. "alarm"), when an alarm is fired how can we deliver the same "alarm"
>>> message to the right app? Do we need to somehow save the app info when
>>> setting alarm?
>>
>>
>> The last part is exactly right. The implementation of the
>> AlarmManager.add function need to remember which app made the call.
>> Then we use that information when calling the message-handler
>> implementation to ensure that the message is sent to the same
>> application as the one that made the call to .add.
>
>
> So, if a message is targeted as a given app, we only deliver it to this app.
> But do we also allow "broadcast" messages that can be received by any page
> or app registering for these messages types?
"broadcast" messages right now. I suspect that we'll need it at some
point though. But we could probably punt on it for now if it makes
things easier.
/ Jonas
Jonas Sicking
Jun 7, 2012, 8:18:56 PM6/7/12
to Fabrice Desré, dev-webapi, mozilla-d...@lists.mozilla.org, Gene Lian
On Thu, Jun 7, 2012 at 10:28 AM, Fabrice Desré <fab...@mozilla.com> wrote:
> On 06/07/2012 01:09 AM, Jonas Sicking wrote:
>>
> On 06/07/2012 01:09 AM, Jonas Sicking wrote:
>>
>> On Thu, Jun 7, 2012 at 1:03 AM, Gene Lian <cl...@mozilla.com> wrote:
>>>>
>>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>>> Think of it as an API for an application to schedule getting
>>>> automatically started at a particular time.
>>>>
>>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>>> particular day, then we should at that time use the message handler
>>>> mechanism to deliver an "alarm" message to app A.
>>>>
>>>> If at the same time app B uses the Alarm API to schedule a
>>>> notification at 7:01pm on the same day, then we should at that time
>>>> use the message handler mechanism to deliver an "arlam" message to app
>>>> B.
>>>
>>>
>>>>
>>>> Don't think of the alarm API as an API for implementing alarm clocks.
>>>> Think of it as an API for an application to schedule getting
>>>> automatically started at a particular time.
>>>>
>>>> If app A uses the Alarm API to schedule a notification at 7pm on a
>>>> particular day, then we should at that time use the message handler
>>>> mechanism to deliver an "alarm" message to app A.
>>>>
>>>> If at the same time app B uses the Alarm API to schedule a
>>>> notification at 7:01pm on the same day, then we should at that time
>>>> use the message handler mechanism to deliver an "arlam" message to app
>>>> B.
>>>
>>>
Gene Lian
Jun 7, 2012, 10:33:37 PM6/7/12
to mozilla.d...@googlegroups.com, dev-webapi, mozilla-d...@lists.mozilla.org
1) navigator.setMessageHandler("alarm", ...) to register the current URI where the setMessageHandler("alarm", ...) is being called
2) and navigator.alarms.add(...) to program an alarm with the current URI where the navigator.alarms.add(...) is being called
When an alarm is fired, the Alarm API wants to call something like sendMessage("alarm", URI, ...) to deliver an "alarm" message to a specific app. The URIs in both (1) and (2) must be matched. Right? If so, the system message mechanism itself should be able to internally filter the valid URI based on whether this URI has been registered by setMessageHandler("alarm", ...). Correct?
Thanks,
Gene
Message has been deleted
Message has been deleted
Jonas Sicking
Jun 8, 2012, 6:18:31 PM6/8/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
On Jun 7, 2012 7:33 PM, "Gene Lian" <cl...@mozilla.com> wrote:
When a page calls AlarmManager.add(...) the implementation remember which
app that page belongs to as well as information about when the alarm should
fire. So don't remember the page URL, just the app identifier (manifest
URL).
When the alarm should fire simply call the system message implementation
and tell it which app the message should be sent to, that it's an "alarm"
message, and any data to pass along.
/ Jonas
> So if the app can call:
>
> 1) navigator.setMessageHandler("alarm", ...) to register the current URI
where the setMessageHandler("alarm", ...) is being called
>
> 2) and navigator.alarms.add(...) to program an alarm with the current URI
where the navigator.alarms.add(...) is being called
>
> When an alarm is fired, the Alarm API wants to call something like
sendMessage("alarm", URI, ...) to deliver an "alarm" message to a specific
app. The URIs in both (1) and (2) must be matched. Right? If so, the system
message mechanism itself should be able to internally filter the valid URI
based on whether this URI has been registered by setMessageHandler("alarm",
...). Correct?
Nit quit understanding, but the way it should work is like this.
>
> 1) navigator.setMessageHandler("alarm", ...) to register the current URI
where the setMessageHandler("alarm", ...) is being called
>
> 2) and navigator.alarms.add(...) to program an alarm with the current URI
where the navigator.alarms.add(...) is being called
>
> When an alarm is fired, the Alarm API wants to call something like
sendMessage("alarm", URI, ...) to deliver an "alarm" message to a specific
app. The URIs in both (1) and (2) must be matched. Right? If so, the system
message mechanism itself should be able to internally filter the valid URI
based on whether this URI has been registered by setMessageHandler("alarm",
...). Correct?
When a page calls AlarmManager.add(...) the implementation remember which
app that page belongs to as well as information about when the alarm should
fire. So don't remember the page URL, just the app identifier (manifest
URL).
When the alarm should fire simply call the system message implementation
and tell it which app the message should be sent to, that it's an "alarm"
message, and any data to pass along.
/ Jonas
Jonas Sicking
Jun 8, 2012, 6:18:31 PM6/8/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
Jonas Sicking
Jun 8, 2012, 6:50:09 PM6/8/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
On Fri, Jun 8, 2012 at 3:18 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Jun 7, 2012 7:33 PM, "Gene Lian" <cl...@mozilla.com> wrote:
>>
> On Jun 7, 2012 7:33 PM, "Gene Lian" <cl...@mozilla.com> wrote:
>>
>> So if the app can call:
>>
>> 1) navigator.setMessageHandler("alarm", ...) to register the current URI
>> where the setMessageHandler("alarm", ...) is being called
>>
>> 2) and navigator.alarms.add(...) to program an alarm with the current URI
>> where the navigator.alarms.add(...) is being called
>>
>> When an alarm is fired, the Alarm API wants to call something like
>> sendMessage("alarm", URI, ...) to deliver an "alarm" message to a specific
>> app. The URIs in both (1) and (2) must be matched. Right? If so, the system
>> message mechanism itself should be able to internally filter the valid URI
>> based on whether this URI has been registered by setMessageHandler("alarm",
>> ...). Correct?
>
> Nit quit understanding, but the way it should work is like this.
>
> When a page calls AlarmManager.add(...) the implementation remember which
> app that page belongs to as well as information about when the alarm should
> fire. So don't remember the page URL, just the app identifier (manifest
> URL).
>
> When the alarm should fire simply call the system message implementation and
> tell it which app the message should be sent to, that it's an "alarm"
> message, and any data to pass along.
Ah, I think I understand your question better.
>>
>> 1) navigator.setMessageHandler("alarm", ...) to register the current URI
>> where the setMessageHandler("alarm", ...) is being called
>>
>> 2) and navigator.alarms.add(...) to program an alarm with the current URI
>> where the navigator.alarms.add(...) is being called
>>
>> When an alarm is fired, the Alarm API wants to call something like
>> sendMessage("alarm", URI, ...) to deliver an "alarm" message to a specific
>> app. The URIs in both (1) and (2) must be matched. Right? If so, the system
>> message mechanism itself should be able to internally filter the valid URI
>> based on whether this URI has been registered by setMessageHandler("alarm",
>> ...). Correct?
>
> Nit quit understanding, but the way it should work is like this.
>
> When a page calls AlarmManager.add(...) the implementation remember which
> app that page belongs to as well as information about when the alarm should
> fire. So don't remember the page URL, just the app identifier (manifest
> URL).
>
> When the alarm should fire simply call the system message implementation and
> tell it which app the message should be sent to, that it's an "alarm"
> message, and any data to pass along.
You're almost right. Except that messages go to a particular app, not
a particular page within the app. The system-message API has features
for deciding which particular page the message goes to. So all you
need to remember the app identifier (manifeset URL) rather than the
page URL, and then pass that to the sendMessage("alarm",
appidentifier, ...) (or whatever it'll look like) function.
/ Jonas
Jonas Sicking
Jun 8, 2012, 6:50:09 PM6/8/12
to Gene Lian, dev-webapi, mozilla.d...@googlegroups.com, mozilla-d...@lists.mozilla.org
On Fri, Jun 8, 2012 at 3:18 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Jun 7, 2012 7:33 PM, "Gene Lian" <cl...@mozilla.com> wrote:
>>
> On Jun 7, 2012 7:33 PM, "Gene Lian" <cl...@mozilla.com> wrote:
>>
0 new messages