Add in API for callback.

[PaulKinlan]

It should be possible to launch the API with a callback to a URL that will post the results there

Ideal UI

• When URL detected, open up the dialog with the OPEN, CANCEL, SHARE button in
• Include a new button with the name of the app and the domain of the callback
• Ideally we should validate the callback against the referrer. So we only share back to the same domain (for now)

  Some additional research

• x-callback-url http://x-callback-url.com/ (Zxing seems to use this), useful way to call back directly into the APP - we can't check the referrer though because it uses a custom scheme
• Could use an intent URL on Android and target and app, we probably want to disable this for now unless we know it is going back directly into the calling app.
• window.open and postMessage are options to send back data, it has a relatively complex API and it won't work with out JS. with x-callback-url, I could do it on the server.

  Issues

x-callback-url:

• It's incrediblly hard to workout which web site called you and directly get back into the running instance of the site that invoked your app, instead you can only manage forward only requests. App->QR->App and that might mean a new page load etc, network round trips and also offline issues.

[mahemoff]

Maybe some whitelabelling support too (custom, restricted, CSS)

[PaulKinlan]

@mahemoff interesting. so you could theme it to look like your existing app?

[PaulKinlan]

Open question: Chrome Custom Tabs and SafariViewController, how do easily get data out instead of using a custom scheme and opening that url

[PaulKinlan]

Note: add in navigator.share API, currently does not support a way of getting data back into the calling app.

[mahemoff]

@PaulKinlan Right. I think some optional theming like colors and logo is important for UX. Could even be done automatically via manifest.json if the client exposes it w/ CORS or provider (QR Snapper) provides a proxy (hmmm CORS-enabled manifest jsons as a service).

[PaulKinlan]

..... interesting!

[bryanrieger]

@PaulKinlan one of the difficulties is being able to provide the user with a list of services they are already actively using rather than making assumptions of 'the usual suspects' (this only reinforces the incumbents).

I'm not sure that theming the UI to the site is necessary (or even a good idea). Having a consistent, browser-based UI to intermediate sharing (much like we find on iOS and Android) provides users with familiarity and some peace of mind that they are interacting with the share UI and not some 3rd party code that may have ulterior motives.

One area where existing intents often fail is performing any subsequent direct action(s) immediately from the share target. For instance, sharing (saving) a URL to Pocket provides the user with a UI (on Android only) to further share that URL socially when the initial action has completed. This 'callback UI extension' could be used to create really interesting workflows between apps without requiring the user to go back and share the content again to different targets.

[PaulKinlan]

@bryanrieger I agree about the workflow idea, I tried to create a chaining system with web intents a while ago to emulate ifttt, but it didn't work as there were user gesture issues.

One area that I am exploring right now is that whilst x-callback-url kinda works, it doesn't actually get you back into the same instance of the running web site, it makes a new window with a custom that has the result in the url. This is incredibly hard to sort out on the web at this point.

The idea in my head is to at least document App A knows it wants to call App B (it's a web url after all) how do you get the data back. The App A to App C, D or E is next ;)

[PaulKinlan]

Added note about forward only navigations in x-callback-url

[PaulKinlan]

Look into exposing the API via comlink.

https://github.com/GoogleChromeLabs/comlink/blob/master/docs/examples/02-callback-example/index.html