Web Activities v0

[Mounir Lamouri]

Hi,

I've been working on designing an alternative/counter-proposal to the
Web Intents specification [1] in order to be able to use Activies in B2G.

This version (v0) aims to solve the use cases of installed applications.
That means it is not handling registering story for non-installed
applications. Adding this part shouldn't change the general API. It is
mostly a matter of choosing between a <meta> directive and/or JS
methods. I'm not including this in this version so consensus will be
easier to reach.

** The name **

I named this API Web Activities instead of Web Intents because I think
"activity" is a better name than "intent". I don't know if "intent" is a
clear name for native English speaker but it's kind of vague for me.
Note that the Web Intents specification is coming from Google so we can
imagine that they just took the name from Android APIs and in Android,
intents have actually a very vague meanings: they can mean activity or
events.
In addition, the scope of this API is different from the scope of Web
Intents as proposed by Google [1]. Given that, picking a different name
seems less confusing.

** The scope **

NOTE: as said above, the v0 of this API doesn't take into consideration
non-installed web applications which might want to handle activities. It
will be handled in the v1 but that is still in the scope of the API.

This API is trying to solve simple use cases like:
- SHARE something from APP A; APP A will put in |data| the stuff it
wants to share and send it to APP B which is going to handle the sharing.
- EDIT something from APP A; APPP A will put in |data| the stuff it
wants to edit and send it to APP B which is going to handle the edition.
APP B will then send back the edited |data| in |request.result| to APP A.
- PICK something from APP A; APP A will start an activity and APP B will
handle the file picking and return it to APP A.
- etc.

Basically, an activity can be started from an application which is going
to attach data or not and the application handling the activity can pass
back data when done.

The major difference with Web Intents is that I do not believe we need
to handle a situation where APP A and APP B have to dialog. All examples
I've seen seem to be out of scope of Activities/Intents. For example,
this one [2] should be changed to have APP A asking to VIEW a video and
APP B handling the control of the video and the communication with the
device. There is no reason to have APP A handling the controlling. If
APP B wants to expose an API for that, I don't think there is any reason
why Intents should be involved.
I've seen another use case for application dialog: APP A asking APP B to
edit an image but instead of letting APP B to handle the edition, APP A
actually send messages to APP B to say what it should do. That seems
pretty weird. That also means APP A is in foreground and has the focus
while as I see it, APP B should be bring to foreground when APP A starts
the activity...

** Activity **

An activity is defined by:
- an action which is a string that can be "share", "view", "edit" or
even "foobar". The specification should define a few actions but any
string should be allowed except the empty string;
- a type which is a mime type like "foo/bar", "image/png";
- some |data| that can be an URL, an object or anything.

Action and data are related. That means an application handling action A
will except |data| to be in a specific format. The specification will
have to define how |data| should look like for pre-defined actions.

Web Intents defines an |extra| attribute which comes directly from
Android. Given that we can pass whatever we want in |data| that seems a
bit weird to have |extra|.

** Starting an activity **

Starting an activity can be done in two ways:
startActivity(action, type, data)
or
startActivity(activity)

The method will return a |DOMRequest|. When the activity will be done,
the |result| attribute on the request will contain the data sent back if
the activity has been successful. If there was an issue, the |error|
attribute will be filed with a string.

** Handling activities **

When an application will be opened to handle an activity, an "activity"
event will be sent to the |window|. This approach seems better than
adding a new property on the |window| object. However, we will have to
define clearly when this event should be sent (before or after the load
event for example).

The event will contain an object with an |activity| property which is
going to contain the activity object as created by the startActivity
method. Also, the object will have two methods: |postResult| and
|postError| that will have to be called to send back data to the calling
application.

** Registering activity handling **

For the moment, this part concerns only installed applications. We
should add a new property to the OWA Manifest to be able to declare that
the application handles some activities. It would look like this:

"activities": {
"share": {
"type": ["foo/bar", "image/png"],
"href": "foo.html",
"disposition": "window" // or "inline"
}
}

** Overview of the API **

interface Activity {
readonly attribute DOMString action;
readonly attribute DOMString type;
readonly attribute any data;
};

[NoInterfaceObject]
interface NavigatorActivity {
// .result contains the data sent back.
DOMRequest startActivity(action, type, data);
DOMRequest startActivity(activity);

// COMMENT:
// We could add registerActivityHandler, unregisterActivityHandler and
// isActivityHandlerRegistered methods later if needed.
};

Navigator implements NavigatorActivity;

[NoInterfaceObject]
interface WindowActivity {
attribute Function onactivity;
};

DOMWindow implements WindowActivity;

[Constructor(Activity activity)]
interface ActivityEvent : Event {
readonly attribute Activity activity;

// COMMENT: data will go to request.result.
void postResult(any data);

// COMMENT: data will go to request.error.
void postError(DOMString data);
};

As usual, feedback is welcome! :)

[1] http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
[2]
http://www.w3.org/wiki/WebIntents/Home_Discovery_and_Web_Intents#Use_case:_push_play

Cheers,
--
Mounir

[Shane Caraveo]

On 12-03-23 12:18 PM, Mounir Lamouri wrote:
> Hi,
>
> I've been working on designing an alternative/counter-proposal to the
> Web Intents specification [1] in order to be able to use Activies in B2G.

We've had a web activities addon for a while, focusing on share for
desktop, and I've been working in bits to get code closer to being a
landable patch. The addon is at https://github.com/mozilla/activities
specifically in the features/detox branch. From a share perspective,
this is a complete departure from the previous fx-share-addon and f1,
relying entirely on activities as the share mechanism.

The API in the addon is a modified version of the Web Activities API
that Michael Hanson proposed some time ago. It's not far from what you
are proposing, also not that far from intents. During the initiation of
the activity, I use postmessage in place of a dom event, but have no
opinion of one over the other. I don't see anything in your API
proposal that I couldn't easily adopt into the addon.

> This version (v0) aims to solve the use cases of installed applications.
> That means it is not handling registering story for non-installed
> applications. Adding this part shouldn't change the general API. It is
> mostly a matter of choosing between a<meta> directive and/or JS
> methods. I'm not including this in this version so consensus will be
> easier to reach.

I've yet to hook up install from app, but it does use a link-rel tag to
find a manifest and allow install of an activity handler. I prefer some
kind of tag over js methods, discovery is easier.

The argument I have heard against a manifest file (and pro-intent tag)
is that it is harder for some organizations to add files into their
infrastructure than it is to add a tag to a page. I feel that a
manifest is better for updating at a later time if necessary.

> ** The scope **

> The major difference with Web Intents is that I do not believe we need
> to handle a situation where APP A and APP B have to dialog.

Some of the use cases I've seen, such as the device controlling, uPNP
support, etc feel overboard for this API. However having the API design
be capable of (even if at a later date) providing a postMessage or
message port conduit could allow for creative use cases.

Shane

[JOSE MANUEL CANTERA FONSECA]

>
>** Handling activities **
>
>When an application will be opened to handle an activity, an "activity"
>event will be sent to the |window|.

I assume that if more than one app can handle an activity, the user will
be asked to choose the app, right? If so we would need to solve the
problem of customizing the dialog the user is gonna see

>This approach seems better than
>adding a new property on the |window| object. However, we will have to
>define clearly when this event should be sent (before or after the load
>event for example).

Or after DOMContentLoaded ...

>
>_______________________________________________
>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

[Jason Miller]

Presumably you'd want to defer it a bit after DOMContentLoaded, unless it
would be limited to apps that do their whole setup synchronously.
Isn't an "initial activity" something that would be better suited to some
object hanging off window.activity? (ie: activity.current) That way an
application developer doesn't have to worry about having their event
handlers set up before the single event fires.


Jason Miller
519.872.0797 // developIT <http://developit.ca/> // Jason Miller
Design<http://jasonmillerdesign.com/>
*Developer of amoebaOS <https://amoebaos.com/>,
Shutterborg<http://shutterb.org/> &
more

*

[Shane Caraveo]

On 12-03-26 1:50 PM, Jason Miller wrote:
> Presumably you'd want to defer it a bit after DOMContentLoaded, unless it
> would be limited to apps that do their whole setup synchronously.

I've been using the load event as the moment I send a postmessage, that
allows the app to listen for postmessage before I send it.

> Isn't an "initial activity" something that would be better suited to some
> object hanging off window.activity? (ie: activity.current) That way an
> application developer doesn't have to worry about having their event
> handlers set up before the single event fires.

The problem I have with an object off the window is that it requires a
reload of the page to handle another activity. My preference is to have
the ability to handle multiple activities, as well as an ability to
offline queue activities.

Another problem that was explained to me once, is that in the case where
we might want to supply a backwards compatibility shim for older/other
browsers, using an object off window is insecure. I'm personally less
interested in that backwards compat, but others may be.

Shane

[Mounir Lamouri]

On 03/23/2012 01:41 PM, Shane Caraveo wrote:
> On 12-03-23 12:18 PM, Mounir Lamouri wrote:
>> Hi,
>>
>> I've been working on designing an alternative/counter-proposal to the
>> Web Intents specification [1] in order to be able to use Activies in B2G.
>
> We've had a web activities addon for a while, focusing on share for
> desktop, and I've been working in bits to get code closer to being a
> landable patch.

Is there a bug with that patch?

>> This version (v0) aims to solve the use cases of installed applications.
>> That means it is not handling registering story for non-installed
>> applications. Adding this part shouldn't change the general API. It is
>> mostly a matter of choosing between a<meta> directive and/or JS
>> methods. I'm not including this in this version so consensus will be
>> easier to reach.
>
> I've yet to hook up install from app, but it does use a link-rel tag to
> find a manifest and allow install of an activity handler. I prefer some
> kind of tag over js methods, discovery is easier.
>
> The argument I have heard against a manifest file (and pro-intent tag)
> is that it is harder for some organizations to add files into their
> infrastructure than it is to add a tag to a page. I feel that a
> manifest is better for updating at a later time if necessary.

Manifest and <intent> are two different things. The manifest property
would only be for OWA and doesn't have anything to do with regular
content who might have to use (<intent>,) <meta> or JS methods.

--
Mounir

[Mounir Lamouri]

On 03/26/2012 02:59 AM, JOSE MANUEL CANTERA FONSECA wrote:
>> ** Handling activities **
>>
>> When an application will be opened to handle an activity, an "activity"
>> event will be sent to the |window|.
>
> I assume that if more than one app can handle an activity, the user will
> be asked to choose the app, right? If so we would need to solve the
> problem of customizing the dialog the user is gonna see

Yes, we will have to solve that issue for a Gaia point of view. I mean,
a way or another, anyone making an UI for B2G should be able to style
that dialog but I don't think any website should be able to do so.

--
Mounir

[Shane Caraveo]

On 12-03-26 4:03 PM, Mounir Lamouri wrote:
> On 03/23/2012 01:41 PM, Shane Caraveo wrote:
>> On 12-03-23 12:18 PM, Mounir Lamouri wrote:
>>> Hi,
>>>
>>> I've been working on designing an alternative/counter-proposal to the
>>> Web Intents specification [1] in order to be able to use Activies in B2G.
>>
>> We've had a web activities addon for a while, focusing on share for
>> desktop, and I've been working in bits to get code closer to being a
>> landable patch.
>
> Is there a bug with that patch?

It's not a patch right now, it's more of a code review to fixup the code
first. The code is currently on github.

https://bugzilla.mozilla.org/show_bug.cgi?id=727126

>>> This version (v0) aims to solve the use cases of installed applications.
>>> That means it is not handling registering story for non-installed
>>> applications. Adding this part shouldn't change the general API. It is
>>> mostly a matter of choosing between a<meta> directive and/or JS
>>> methods. I'm not including this in this version so consensus will be
>>> easier to reach.
>>
>> I've yet to hook up install from app, but it does use a link-rel tag to
>> find a manifest and allow install of an activity handler. I prefer some
>> kind of tag over js methods, discovery is easier.
>>
>> The argument I have heard against a manifest file (and pro-intent tag)
>> is that it is harder for some organizations to add files into their
>> infrastructure than it is to add a tag to a page. I feel that a
>> manifest is better for updating at a later time if necessary.
>
> Manifest and<intent> are two different things. The manifest property
> would only be for OWA and doesn't have anything to do with regular
> content who might have to use (<intent>,)<meta> or JS methods.

I used a manifest because I feel it is more reliable to later check for
changes, compared to refetching a page and parsing for a tag again. The
link-rel tag is only there for convenient discovery of the manifest
while browsing. I feel the intent tag suffers from management issues
unless you have a search engine to keep track of changes.

Shane

[Alberto Pastor]

Hi all, Alberto from Telefonica speaking. Don't think I had the pleasure to meet you all of you guys in the Paris event, so nice to meet you now :)

@Mounir, we have been thinking in Telefonica about the following use case:

APP A wants to INSERT/GET/UPDATE/DELETE some information from the APP B, but without any UI delegation. For example, imagine an APP that wants to mix Calendars from different sources. That APP A would need to check the Calendar info without opening the native Calendar UI.

I don't think that use case is covered by Web Intents and don't really like the way how scales the idea of creating a new specific API for each content to be shared between apps.

Do you think that use case would be covered by your Web Activities specification? Is something you guys think could be useful?

Thanks!

[Alberto Pastor]

Hi all, Alberto from Telefonica speaking. Don't think I had the pleasure to meet you all of you guys in the Paris event, so nice to meet you now :)

@Mounir, we have been thinking in Telefonica about the following use case:

APP A wants to INSERT/GET/UPDATE/DELETE some information from the APP B, but without any UI delegation. For example, imagine an APP that wants to mix Calendars from different sources. That APP A would need to check the Calendar info without opening the native Calendar UI.

I don't think that use case is covered by Web Intents and don't really like the way how scales the idea of creating a new specific API for each content to be shared between apps.

Do you think that use case would be covered by your Web Activities specification? Is something you guys think could be useful?

Thanks!


El martes 27 de marzo de 2012 00:23:46 UTC+1, mixedpuppy escribió:

[Mounir Lamouri]

On 04/02/2012 11:17 PM, Alberto Pastor wrote:
> Hi all, Alberto from Telefonica speaking. Don't think I had the pleasure to meet you all of you guys in the Paris event, so nice to meet you now :)

Hi Alberto,

> APP A wants to INSERT/GET/UPDATE/DELETE some information from the APP B, but without any UI delegation. For example, imagine an APP that wants to mix Calendars from different sources. That APP A would need to check the Calendar info without opening the native Calendar UI.
>
> I don't think that use case is covered by Web Intents and don't really like the way how scales the idea of creating a new specific API for each content to be shared between apps.
>
> Do you think that use case would be covered by your Web Activities specification? Is something you guys think could be useful?

In my opinion, that use case shouldn't be covered by Web Activities.
Doing specific actions should require specific APIs. Currently, most
service providers will give you an API to interact with the service.

However, I'm thinking of *specific* actions. That means, "adding an
event to a calendar" should clearly be a Web Activity. The user will
then be prompted to ask which calendar service he/she wants to use. What
is not a Web Activity is "Get me the first event of the week" or "Change
event X to start at 10am". For those, you will require the provider API
or the native API (Calendar API here).

--
Mounir

[Alberto Pastor]

Hi Mounir,

Totally agree with you. What I was trying to say is that a "Content Provider" API could be useful in some cases and easier to scale than specific APIs.

> However, I'm thinking of *specific* actions. That means, "adding an
> event to a calendar" should clearly be a Web Activity. The user will
> then be prompted to ask which calendar service he/she wants to use. What
> is not a Web Activity is "Get me the first event of the week" or "Change
> event X to start at 10am". For those, you will require the provider API
> or the native API (Calendar API here).

You mentioned "provider API". What did you mean with that? Is an already specified API or something you are thinking on start working?

Thanks!

[Alberto Pastor]

Hi Mounir,

Totally agree with you. What I was trying to say is that a "Content Provider" API could be useful in some cases and easier to scale than specific APIs.

> However, I'm thinking of *specific* actions. That means, "adding an
> event to a calendar" should clearly be a Web Activity. The user will
> then be prompted to ask which calendar service he/she wants to use. What
> is not a Web Activity is "Get me the first event of the week" or "Change
> event X to start at 10am". For those, you will require the provider API
> or the native API (Calendar API here).

You mentioned "provider API". What did you mean with that? Is an already specified API or something you are thinking on start working?

Thanks!

El miércoles 4 de abril de 2012 15:58:39 UTC+1, Mounir Lamouri escribió:

[Mounir Lamouri]

On 04/05/2012 11:12 AM, Alberto Pastor wrote:
>> However, I'm thinking of *specific* actions. That means, "adding an
>> event to a calendar" should clearly be a Web Activity. The user will
>> then be prompted to ask which calendar service he/she wants to use. What
>> is not a Web Activity is "Get me the first event of the week" or "Change
>> event X to start at 10am". For those, you will require the provider API
>> or the native API (Calendar API here).
>

> You mentioned "provider API". What did you mean with that? Is an already specified API or something you are thinking on start working?

If the user gave the app access to his/her Google Calendar, the app
should be able to use Google's APIs to access and modify the user's
calendar.

--
Mounir