Plan for development of offline support

[keithamoss]

The user believes built-in offline support would be useful. e.g. When truly offline or just when on an unreliable / low bar count connection like in the hills around Kalamunda et cetera.

Relevant links

• [https://medium.com/random-gis-talks/use-openlayers-offline-for-survey-4ded3998d9cc](Use Openlayers in Offline mode for land-survey applications!)
• [https://www.innoq.com/en/blog/2022/07/offline-with-redux/](Offline with redux: A different approach to web applications that work offline)

At the time of writing the two main libraries that used to provide offline support with Redux appear to be entirely abandoned and nothing is rising up to take their place.

There's a GitHub issue (xx) where various people, and the authors of Redux Toolkit and RTK Query, discuss offline support. Again, at the time of writing, no decision is taken to add support into the library, integrate with third party libraries (there are none, per above), nor offer any doco or patterns showing how to implement offline support alongside Redux Toolkit and RTK Query.

The second link above (the Innoq blog post) appears to be our best bet. It's a well thought out argument in favour of its approach and it's a generic pattern we could - seemingly - apply within our architecture.

It's silent on use of local storage (I think?), but that's the logical choice.

Questions for the user to inform the POC and design:

1. Discuss a discrete offline/online toggle vs automatic detection. Should the app be always ready to go offline (arguably yes, and is a more seamless integration) or should it require the user to take an action (like saving lists or creating an offline export of a map). Goes to a question of user behaviour.
2. What is iOS Safari like with localStorage, how much can it hold, for how long, and how reliable is it? Does it play reliably with apps pinned to the home screen?
3. API calls aside, what other web resources/assets do we rely on that we would need to have a local version of to truly enable fully offline functionality (e.g. launching the pinned app fresh from the gold screen on no connection). If so, what's the best way to cache them locally and are there any libraries that'll just do that for us?

Next steps:

1. Discuss with the user per above
2. POC the approach and ensure we can use the Innoq proposal with RTK Query.

Other considerations:

• If we add shared maps later we'll need a way to ensure the local cache stays current of the user hasn't opened the app in a while. On one level, we could just do background syncs, but on another we probably need a smarter strategy that goes and replays requests in the order in which they would have been run if all users had been online at the same time. That could be an interesting design exercise 🤔
• Related, consider designing for a scenario where two users are offline at the same time working on the same map. What options are there for keeping those maps in sync over Bluetooth or NFC or whatever?
• Or, alternatively, the "replay requests from all users in the right order" mechanism above would come into play then too. As part of that, there's an element maybe of letting the user review the offline changes once they've synced to see if there were double ups or other errors.
• We'd also need to handle things like one user deleting a point that another user comes along later and edits. That would need to be reported as either an error - or perhaps far better - the user is given a UI where they need to resolve conflicts like this.
• Hmm, maybe there's something in that idea. Should the user be asked how they wish to handle the syncing of edits where there's no clear automated decision. Like, what if they edit a point offline after someone else edits it online. Should they be making a call on whether to keep the online edit, keep theirs, or merge the two chronologically.
• Shared schemas will be fun too. Like fields and icons being added will have their unique ids that will need to be handled per the Innoq example ('offline-x') and carefully handled during the sync process to keep features hooked up to them.
• Oh, and what if an online user deletes an icon or schema field while an offline user is offline? We'd need to ensure those fields were removed or those icons were defaulted back to whatever during the merge. Could be another user decision point there like the choice above.
• Granted, some of this can be handled by setting strict rules around collaborative maps to only allow one user to have full control.
• Still, even then it applies if the user in control is online and another user with less control is offline we have to handle many of these cases.
• Maybe there's something in having unique and enduring primary keys for fields and icons they ensure we never re-use them once they're allocated.
• Architecturally, there's a big decision to be made here around do we (a) just apply all of the edits when the user goes back into online mode and have it apply from the current live state of the system at that time or (b) are we applying the changes chronologically in order so we almost need to rewind to the point the data was synched to offline and replay both online and offline requests from that point forward and ask the user to take decisions to resolve questions that have more than one answer (and/or let them set defaults before the sync to answer some of the non-destructive and easier question).

Lots of food for thought!

[keithamoss]

This would also be useful for when the connection is poor. Which maybe we could detect too?

Ideally we'd be able to background sync automatically once the user is on a good connection. Not sure if that's possible with a PWA on iOS? Maybe that's where Service Workers come in though?

[keithamoss]

https://vite-pwa-org.netlify.app/

[keithamoss]

Service Workers look like the go for easier offline caching of all of the assets we need. i.e. They're good at intercepting network requests and returned a cached verison.