Uniquely identifying an intent

[Tom Gibara]

Now that I'm having my first go at writing a simple web intent service, it occurs to me that there's no way to uniquely identify a web intent.

This isn't something that's ever troubled me when writing Android apps (where afaik there's no unique identifier for intents either). However, using a browser, a user can repeat the intent (probably inadvertently) by simply refreshing the page; I don't think there is an analogue to this on Android.

This arose because the first service I'm writing is a simple "snooper" that displays the fields of the intent it was launched with together with a 'history' (stored using indexeddb). My naive implementation is subject to the problem that refreshing the page 'replays' the intent, creating dupes in the database.

Post/Redirect/Get would be a typical way to overcome this server-side, and I guess that location.replace is probably a suitable alternative client-side, but it's not clear to me that, as things stand, web services could ever completely reliably avoid duplicated intents (which might be a significant issue for some services).

At least superficially, introducing an opaque identifier to every Intent would make avoid dupes much easier for those services for this matters.

[Rachel Blum]

 

This isn't something that's ever troubled me when writing Android apps (where afaik there's no unique identifier for intents either). However, using a browser, a user can repeat the intent (probably inadvertently) by simply refreshing the page; I don't think there is an analogue to this on Android.

You shouldn't be able to - according to the spec " User Agents should restrict this method to only be successfully callable within the context of an explicit user gesture". (http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html - section 3.3)

And unless I'm off in my interpretation, Refresh doesn't count as an explicit user gesture. 

 

 

This arose because the first service I'm writing is a simple "snooper" that displays the fields of the intent it was launched with together with a 'history' (stored using indexeddb). My naive implementation is subject to the problem that refreshing the page 'replays' the intent, creating dupes in the database.

Are you experiencing this with the Intents implementation in Chrome, or is that an issue with the JS shim? If it's the Chrome implementation, please file a bug at http://crbug.com - at least according to my reading of the spec, this should not happen. 

 

Rachel

[Tom Gibara]

This is chrome - on a chromebook actually since my dev. machine is Linux, and I don't fancy compiling Chromium right now :)

I reread that part of the spec, but I don't think it says anything explicit about delivery of the intent to the service; only that when an application raises an intent that it must be done "in the context of an explicit user gesture".

The spec seems silent on the subject of what happens in the event that the service page is refreshed (though I may have missed it because I haven't read it closely), but to not redeliver the intent strikes me as a much greater fault. Certainly, redelivery of the intent matched my expectations.

Tom

[Rachel Blum]

The spec seems silent on the subject of what happens in the event that the service page is refreshed (though I may have missed it because I haven't read it closely), but to not redeliver the intent strikes me as a much greater fault. Certainly, redelivery of the intent matched my expectations.

Ah, I misunderstood and thought you meant refresh on the invokation source. 

Rachel

[Paul Kinlan]

If the service page is refreshed, the passed in intent data will still be present.

--
You received this message because you are subscribed to the Google Groups "Web Intents discuss" group.
To post to this group, send email to web-inten...@googlegroups.com.
To unsubscribe from this group, send email to web-intents-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/web-intents-discuss?hl=en.

[Tom Gibara]

If the service page is refreshed, the passed in intent data will still be present.

Which is good, but the concern remains: that implementing services which avoid processing duplicate intents may prove difficult; perhaps unnecessarily so.

Tom.