As a user, once I confirm an app's installation, if that app requires a download in order to complete installation, and I subsequently cancel that download, I want to be able to easily restart that download at a later time from it's Home screen icon, so that I can easily complete the installation at any point.
This is requirement AppInstall-009 https://docs.google.com/a/tola.me.uk/spreadsheet/ccc?key=0AtuYwL8qXqZmdGQtNHJ6S2NxZXlmYVctRS1xbEh3V0E#gid=73
blocking-basecamp: --- → ?
Remaining required feature work listed at http://j.mp/VWpueM is now blocking+ to ensure visibility and tracking, per drivers' decision.
blocking-basecamp: ? → +
We're marking this bug with the C1 milestone since it follows the criteria of "unfinished feature work" (see https://etherpad.mozilla.org/b2g-convergence-schedule). If this work is not finished by Nov19, this bug will need an exception and will be called out at the upcoming Exec Review.
Target Milestone: --- → B2G C1 (to 19nov)
Assignee: ben → francisco.jordano
Summary: [Apps] Restart App Download → [Apps] Restart app download from homescreen icon
Josh we will need info for this bug: - When we tap on the icon to perform the retry should we present any message? - The download should appear in the notification area? Thanks!
Hi guys, yes to both questions. Per the page 12 of the spec, here: https://www.dropbox.com/sh/b0kyykhzcfkpm8b/ReFTX_E72X
As discussed with Josh, after the user confirmed the download, we should be in the same state (from the user point of view of course) than if the download wasn't interrupted.
Created attachment 684097 [details] sequence diagram of the stop and resume feature I've made this to help clearing the remaining questions we have. We have to answer all the (?) points.
fabrice, could you have a look on this diagram and give your advice ?
Discussed a lot with Vivien and Etienne, and basically I see 2 solutions : Solution 1 ---------- - the homescreen displays the confirmation dialog to the user - we need a new platform API to restart an install. The existing API seems insufficient. The badly-named WebApps.download method is only used for updating. The homescreen calls the new platform API. As far as Gaia is concerned, this API could be either on DOMApplication, IDOMApplicationMgmt or IDOMApplicationRegistry. - the system would only receive new progress events, as if the download was never stopped (except ATM the progress is resetted). This solution needs a new public API and some changes in the way the notification is shown in system. It means we couldn't display a notification before the first progress event. We would still have a user feedback in the homescreen so it may be acceptable. Solution 2 ---------- We'll reuse all the code and APIs already used for the first install. This means reusing : - use mozApps.install to restart an install - webapps-ask-install, webapps-ask-denied, webapps-ask-granted for user confirmation (therefore, the system would display the user confirmation dialog) - oninstall event -> be really careful here, as then we may get this event several times for one app. - onprogress/ondownloadsuccess/ondownloaderror as today This solution makes sense because at the moment when there is a cancel or an error, we removes everything and we're in a state very similar to where we were before the first installation command. My view is that it would make sense even if we could really restart the download. However, the semantics on the "install" event would be more disturbing. Also, we do/display a lot of things in the install confirmation dialog that we might want not to do/display in the restart dialog. There could be a mix of solutions 1 and 2, as the confirmation dialog problem and the restart process are really 2 different problems. However, I think these combinations work better. IMHO to be decided in next week's meetup as everybody will be here.
Discussed with Fabrice, we decided on the following solution (3) : - homescreen displays the confirmation screen to the user - homescreen calls |download| on the app object - system listens for |progress| events to display the notification in the notificaton center - system must keep its listeners on the app object on |downloaderror| event - system must set listeners at init - platform must |applyDownload| when the download finishes successfully and |app.installState == 'pending'| I'll open several bugs to separate these tasks.
Whiteboard: [LOE:S][label:story] → [LOE:S][label:story][work in dependent bugs]
Target Milestone: B2G C1 (to 19nov) → B2G C2 (20nov-10dec)
Why are we 'pausing' when the user is 'canceling' the download of the app? Josh, can you comment here? I don't know if this is an accurate user story. Can someone explain to me the logic behind this? Does this include the case where a download is initiated and then fails and the icon appears on the home screen and the user is allowed the option to restart the download?
Chris> I'm trying to answer your questions here : - When the user is canceling, we're removing everything that was downloaded. But the icon is still on the homescreen in case he wants to restart the download. The application is still in our registry but in a "pending" state. The application can be uninstalled though using the normal UX (long press to trigger the delete mode + tap on the red cross + home). - this actually include the case where the download fails because of an error. Actually, the "cancel" use case is handled using the "downloaderror" mechanism.
(In reply to Julien Wajsberg [:julienw] from comment #11) > - homescreen calls |download| on the app object Fabrice, I have a doubt here. The spec says that we must check for storage space before downloading, does the |download| check this ? I suspect we should do this for the update use case as well so it might make sense to check this in |download| anyway, right ?
my bad, we do this in |downloadPackage| so this seems right. Forget about it.
(In reply to Chris Lee [:clee] from comment #12) > Why are we 'pausing' when the user is 'canceling' the download of the app? > > Josh, can you comment here? > > I don't know if this is an accurate user story. Can someone explain to me > the logic behind this? Does this include the case where a download is > initiated and then fails and the icon appears on the home screen and the > user is allowed the option to restart the download? Chris, are you looking for an explanation of the implementation decisions described by Julien, or for the original user stories? Julien has provided some answers in comment#13. Let me know if more explanation would be helpful.
Not blocking on meta-bug.
blocking-basecamp: + → ---
Priority: P1 → --
Whiteboard: [LOE:S][label:story][work in dependent bugs] → UX-P1
Done, all the bugs that were blocking the meta bug are resolved
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
\o/ App Install feature complete!
You need to log in before you can comment on or make changes to this bug.