Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finer grained transport/ambience selection than on/off #142

Open
Solzhenitsyn opened this issue Jun 6, 2017 · 4 comments
Open

Finer grained transport/ambience selection than on/off #142

Solzhenitsyn opened this issue Jun 6, 2017 · 4 comments

Comments

@Solzhenitsyn
Copy link

Solzhenitsyn commented Jun 6, 2017

[It is my "understanding" that Background Fetch is designed for retrieving data from server to client and Background Synch is designed to handle large transmissions from client to the server as well as it does small. If I'm wrong then let me know and I'll delete this.]

Is there any merit in providing a finer-grained access to Background Sync than the current binary "Network available?" Yes/No?

For example, uploading a file might be desirable only if WiFi is available or if the phone is currently connected to the mains/recharging.

@jakearchibald
Copy link
Collaborator

jakearchibald commented Jun 6, 2017

@Solzhenitsyn

It is my "understanding" that Background Fetch is designed for retrieving data from server to client and Background Synch is designed to handle large transmissions from client to the server as well as it does small

Not really. See https://github.com/WICG/background-fetch for details on background fetch, specifically:

Background-fetch is intended to be very user-visible, via OS-level UI such as a persistent notification, as such background-sync remains a better option for non-massive transfers such as IM messages.

@Solzhenitsyn

For example, uploading a file might be desirable only if WiFi is available or if the phone is currently connected to the mains/recharging.

I'm not against looking at options here, but background fetch feels like a better fit for anything that large.

@docluv
Copy link

docluv commented Nov 1, 2017

Dean references a periodic sync - https://ponyfoo.com/articles/backgroundsync
But that seems a bit dated. I don't see any reference to these options in the spec, but I have seen another reference to these options, the MDN documentation. https://developer.mozilla.org/en-US/docs/Web/API/SyncManager/register

Has this been abandoned? Seems like this is what you would want. I think you alluded to a way for the consume to control this behavior, which I would be all for, but the reality is 99% would never know they could do this or what to do with it.

@jakearchibald
Copy link
Collaborator

@rolivo

commercial or political interests, perhaps

What does this mean?

This is a fundamental feature that every developed platform should have, why android, windows phone have it and we do not?

https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW56
https://developer.android.com/reference/android/app/job/JobInfo.Builder.html?utm_campaign=adp_series_job_scheduler_092216&utm_source=medium&utm_medium=blog#setPeriodic%28long%29

Note that these platforms provide very few guarantees about periodic syncing, and treat it as a battery concern. This is for apps that are guarded by an app store, which isn't true for the web.

If this feature ever comes to the web, it'll provide even fewer guarantees.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@jakearchibald @docluv @Solzhenitsyn and others