Implement caching in case of WebDAV synchronisation #3

Open
opened 2025-07-01 10:08:26 +02:00 by chepycou · 1 comment
Contributor

Rationale

The user should be able to read past logs and input some log even without internet connection / when the WebDAV server is down.

Proposed change

  • The app should keep the last synchronized JSON file on device as a cache,
  • This JSON should be displayed/edited in place of the remote JSON when waiting for the server to be reached (if for instance a timeout of .5 or 1 second is reached).
  • When the remote JSON is fetched, both should be merged (for instance by taking the concatenation of both JSONs and removing duplicate timestamps, but there should be a better way of merging)

Small improvements along the way

  • Add a small "not yet uploaded" icon next to the not yet synchronized logs
  • And/or add a header at the top warning that all changes have not yet been synchronized. This way, one parent can be reminded to turn off airplane mode, so the other gets the data too, for instance.
## Rationale The user should be able to read past logs and input some log even without internet connection / when the WebDAV server is down. ## Proposed change - The app should keep the last synchronized JSON file on device as a cache, - This JSON should be displayed/edited in place of the remote JSON when waiting for the server to be reached (if for instance a timeout of .5 or 1 second is reached). - When the remote JSON is fetched, both should be merged (for instance by taking the concatenation of both JSONs and removing duplicate timestamps, but there should be a better way of merging) ## Small improvements along the way - Add a small "not yet uploaded" icon next to the not yet synchronized logs - And/or add a header at the top warning that all changes have not yet been synchronized. This way, one parent can be reminded to turn off airplane mode, so the other gets the data too, for instance.
Owner

Merging is always tricky to implement correctly. But yes, when I decided the format, I thought the timestamp to be the unique identifier and the way to merge two datasets (because it also defines ordering).

Merging is always tricky to implement correctly. But yes, when I decided the format, I thought the timestamp to be the unique identifier and the way to merge two datasets (because it also defines ordering).
Sign in to join this conversation.
No Label
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: penguin86/luna-tracker#3
No description provided.