Confirm
716
edits
Changes
→Lessons Learned
Pocket also has dome some really great research [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].
This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.
=== UX issues if the handler app is already running when the activity is launched ===
In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the ''does not return a value'' flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.
'''Recommended solutions'''
If we follow the recommendation above for [[#UX issues with activities that return a value|UX issues with activities that return a value]] that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.
Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.
For other activity handlers a good solution might be to fire an event in the handlers ServiceWorker and let the worker decide if a new page should be opened, or if an existing page could be used.
=== Lack of ability to save intermediate results ===
Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file. Once the user is done editing the picture the photoshop page could return the edited picture to the Google Drive page and Google Drive could save the edited picture using application specific logic.
There are a couple of issues with this flow though. First off given that a return
One flow that is currently not supported by neither WebActivities or Web Intents is the ability for a
=== Ability to switch from inline to full-page handler ===
=== Should activity launcher have a say in disposition of the handler? ===
For activities that does not return a value, the initiating page might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".
