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.
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).
Maybe also have a synchronize icon that is cut or greyed out, or a yellow triangle with an exclamation mark as identifier symbols to the records that are not yet synced.
Regardless, if something happens with the webdav server, currenlty there is no way to add records, unless we disable webdav. Not sure what happens with the data if we switch to local and then to remote again.
Maybe also have a synchronize icon that is cut or greyed out, or a yellow triangle with an exclamation mark as identifier symbols to the records that are not yet synced.
Regardless, if something happens with the webdav server, currenlty there is no way to add records, unless we disable webdav. Not sure what happens with the data if we switch to local and then to remote again.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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
Small improvements along the way
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).
Maybe also have a synchronize icon that is cut or greyed out, or a yellow triangle with an exclamation mark as identifier symbols to the records that are not yet synced.
Regardless, if something happens with the webdav server, currenlty there is no way to add records, unless we disable webdav. Not sure what happens with the data if we switch to local and then to remote again.