[mwill]

I'm planning on queuing up updates when offline for my app. On the technical side of things, it's incredibly easy when done from the ground up. In fact I think it's made the entire thing much cleaner and far easier to develop.

The harder part seems to be communicating with the user. If/how to let them know they've gone offline, and what that means for their experience, and if they're allowed to create/update content, what will happen when they reconnect.

For example, the next question for me is what to do with conflicting updates, ie when a user updates a document offline and reconnects, and the document has been updated by a different client while they were offline. Discarding or merging isn't a problem from a technical stand point, the problem is presenting it to the user, and striking a balance between doing what the user wants/expects, and not bothering the user with a ton of questions about which of their changes they want to keep/merge.

[joelambert]

It's still quite tricky to to detect a reliable 'offline' state with HTML5. Using navigator.onLine tells you that you 'might have' internet access but even then you may actually be offline. Bu I agree that the most important issue is how to communicate the degradation to the end user.

[mwill]

Yeah, I saw a lib the other day that tried to offer this but was pretty hit and miss, and checking into the methods available didn't fill me with confidence. Right now I'm only considering the client offline if an attempt to hit the server fails. If they're trying to save something, queue it up to do later, if they're trying to retrieve something, check if theres a copy locally, if not let them know what's going on.

The problem with this method is ideally you'd like the client to know it's reconnected as soon as possible, and start working through the queue. I figured the most foolproof way was just periodically trying to talk to the server when you think you're offline. It'd probably be better if you had a solid method of receiving actual network related events like disconnecting and reconnecting, but the lazy 'just keep checking' method is workable.

The bonus of it is it works the same if it's a problem on the servers end.

[svachalek]

This is the right approach; there are all kinds of reasons a server API might fail and being offline is only one of them.

[jchrisa]

Have you looked at PouchDB? http://pouchdb.com/ Offline database that handles cloud sync for you.