Use Push and a Background Fetch/XHR instead of background sync

[jkarlin]

Given our use cases: periodic refresh, background upload/download of messages and bulk data, we might be better served by breaking the cases apart into the following:

1. Periodic refresh (twitter, mail, news articles): Use the push API like native apps already do today.

2. Retry upload of message when next online: SW.fetch (or perhaps XHR) with background capability that fires a SW event (or writes to indexedDB?) when done.

Background fetch would support resumable downloads immediately and resumable uploads would come in the future as we made progress on that.

[annevk]

2. sounds a bit like sendBeacon().

[johnmellor]

1. Periodic refresh (twitter, mail, news articles): Use the push API like native apps already do today.

Actually, on both Android and iOS, native apps use a mix of polling and push for syncing. Apple's gives nuanced advice[1] to developers on when to use their two APIs (introduced simultaneously in iOS 7):

	Background Fetch	Remote Notifications
Content Importance	Interesting, but not critical	Immediate
Content Availability	Very frequent	Infrequent or sporadic
Examples	News; Social networking feeds; Photo sharing	Instant messaging; Synced content; Read this later

[1]: from WWDC 2013 "What's New with Multitasking"

Android tends to lean slightly more towards Push, because GCM has more advanced features like delay_while_idle meaning it can be more efficient if you send a lot of low-priority push messages; but it's still more appropriate to use polling on Android (preferably as a Sync Adapter that can be batched together with other syncs) for frequently updating streams of information.

For example, I would expect a well-written Twitter client to use background syncs to periodically update the feeds you subscribe to, but use push messaging to receive private messages (and perhaps @ mentions) you get sent, so that it can show you immediate notifications for the latter.

2. Retry upload of message when next online: SW.fetch (or perhaps XHR) with background capability that fires a SW event (or writes to indexedDB?) when done.

That could be a very reasonable alternative to non-repeating syncs. Need to think about that more.

2. sounds a bit like sendBeacon().

Except:

1. you often want a response back
2. you want the browser to retry once it's next online, whereas IIRC beacons get dropped if the browser can't connect(?).
3. the payload may be much larger.

[jkarlin]

Thanks John, that convinces me that sync is needed. Large background down/uploads will be for another api.