bgFetchJob.pause() and .resume()

[koresar]

Probably not for "v1".

Apps might want to have buttons to pause/resume an upload/download job. At least we can have it now for downloading jobs. Also, these buttons can be part of the browser UI (e.g. in the Android drop down notification).

Maybe also add backgroundFetchPause and backgroundFetchResume events. And allow browser to pause jobs. Reasons to pause a job:

• Not enough space (can happen after the download started)
• User tap to pause via the Android drop down notification or via app UI
• Device goes offline
• etc

---

Some background on the feature necessity.

We are developing an app to report incidents which can and often happen in rural no-coverage areas. The connectivity might be actually present occasionally or the coverage can be weak/slow (Australian thing). The incident media (photos, videos) should be uploaded with fewer possible retries.

Pausing and resuming upload sounds like a dream feature. I wish there was a standard to resume uploads. But as a workaround we can upload a large file contents in smaller chunks.

[beverloo]

One of the premises of background fetch is that such UI is left to the browser - in our implementation (Chrome) we plan to have a pause button on the notification indeed. Similarly, resumption would also be silently supported by our regular download system. The backgroundfetched (or backgroundfetchfail) event would be invoked when the fetch has completed.

Regarding the events: I'm concerned that the cost of firing them will be pretty high. Since a device would have to pause and/or resume on connectivity changes, it may be frequent for users who are using, for example, public transport. (Like the Tube here in London.) What use-cases would you have in mind?

I don't feel too strongly regarding exposing such methods or not. I can see uses (e.g. a progress spinner next to a video player that can be used to pause the fetch), but also complications (it might be confusing to the user unless we restrict it to user gestures since the notification will have to remain visible).

[koresar]

What use-cases would you have in mind?

@beverloo the use-case is described above. I'll expand on it:

We are developing an app to report incidents which often happen in rural no-internet areas. The connectivity might be actually present occasionally or the coverage can be weak/slow (Australian thing). The incident media (photos, videos) should be uploaded with fewer possible retries.

So, the person receives an SMS from his carrier saying: "Please, document your incident (fire damages) using this link: https://incidentpwa.example.com/rural-fire" He/she taps the link - the PWA opens (we'll make it as small as possible). He/she start taking photos/videos of things we tell him - basically damages or similar. In rural areas the signal strength is ofter weak, so we need to make sure all the media are uploaded no matter what. Probably later when he/she gets to a safe place with fast Internet.

PWA is a great option here since the farmer won't need to have the app installed before the bushfire starts.

[jakearchibald]

From the use-case, it doesn't seem like an API is needed, as long as the browser can queue the upload while the connection is absent/weak, and it offers this as a button to the user.

Also, it seems like the ability to resume uploads is more important than a pause API for this use-case, or have I misunderstood?

[koresar]

It's correct @jakearchibald

Basically, we would need to make sure browser can safely and securely upload few dozen megabytes. And the user should know the state (progress) of the upload.

The ability to pause/resume upload is, likely, a nice to have feature.

Feel free to close the issue.