Skip to content
Snippets Groups Projects
Commit 538abfd2 authored by Tor-Einar Skog's avatar Tor-Einar Skog
Browse files

Storing old docs

This is was was pushed to the old documentation branch
parent ef737891
No related branches found
No related tags found
No related merge requests found
File added
# VIPS Field Observation App
This is some old documentation - kept in case we need it for reference
## Misc
* [First draft of application state management](./docs/Application_state.pdf)
### Synchronization management
The basic design of synchronization is illustrated below
![Synchronization design](./docs/synchronization.png "Synchronization design")
There are two modes of synchronization
#### One-way synchronization
This is information that flows only from VIPSLogic and to the app:
* Crop categories
* Pests
* Crops
* crop-pest combinations
##### Triggers
* LocalStorage does not have the requested resource (e.g. the CropCategory list). Typically when the app is launched for the very first time and the user logs in
* A different user logs in. The user may come from another organization, where there are different lists
* The timestamp on the server indicates that the information has changed. For crop categories, pests, crops and crop-pest combinations, the latest update of the info on the server happened at the time stamp served by the web service endpoint `[VIPSLOGIC]/rest/observation/organismsystemupdated`. This timestamp should be checked every time the app starts (and there is a valid login)
#### Two-way synchronization
These objects may change both in the app and through editing using the VIPSLogic admin system. Therefore, updates in the app must be propagated to the other place
* Observations
* Places (POIs)
##### Synchronization process
TODO: The Observation and PointOfInterest (place) entities must both get a "lastUpdated" property
The synchronization process is simply put a POST request from the app to the server. All objects of one type (Observations or POIs) are represented by a list in LocalStorage. The list is POSTed to a server endpoint. The server handles all the changes and return the updated state to the app, which then in turn updates its list in LocalStorage.
![2-way sync](./docs/sync_2way.png "2-way sync")
In addition to the existing properties of Observation and PointOfInterest, the following are specific to the synchronization process
* lastUpdated (Date) - stored in DB
* synchronized (Boolean) - used in the app and on the server when synchronizing
* force to sync (Boolean) - sync will break the rules. Apply force
* force update (Boolean) - used to update the object in DB when lastUpdated on server > lastUpdated in the app
* delete (Boolean) indicates that the object should be deleted on the server
Let's assume that this list of observations is on the app
Observation |id |lastUpdated|Synchronized|ForceToSync | Force |Delete
----------- |----|-----------|------------|-------------|----- |------
Apple scab in apple | 43 |2020-05-01 | True | |NULL | False
Septoria in wheat | 101|2021-02-12 | False | NULL |NULL | False
Blight in potato |NULL|2021-02-18 | False | NULL |NULL | False
And let's say that on the server the state is:
Observation |id |lastUpdated|
----------- |----|-----------|
Apple scab in apple | 43 |2020-05-01 |
Septoria in wheat | 101|2021-02-18 |
* The observation with id=43 will not be stored, since it's already synchronized. However, if the lastUpdated on the server is after 2020-05-01, the updated version of it will be returned And the lastUpdated locally will be updated too.
* The observation with id=101 will not be updated, since the lastUpdated in the app is before the lastUpdated on the server. However, the updated version will not be returned either, since the local state is NOT SYNCED. It will be returned unchanged but with the ForceToSync set to True
* The observation with id=NULL is a new observation, and will therefore be created and returned with a freshly generated database id
So the returned result is this:
Observation |id |lastUpdated|Synchronized|ForceToSync | Force |Delete
----------- |----|-----------|------------|-------------|----- |------
Apple scab in apple | 43 |2020-05-01 | True | NULL |NULL | False
Septoria in wheat | 101|2021-02-12 | False | True |NULL | False
Blight in potato |563 |2021-02-18 | True | NULL |NULL | False
Now, the user will see that the obs 101 has not been updated, and the ForceToSync=True should make it highlighted. The user should actively choose whether to force save the app version or to pull the updated version from the server. So if the user ticks of "Force" in his list for obs 101, a sync will take place and the database version will be overriden by the one in the app.
document/archive/sync_2way.png

29.4 KiB

document/archive/synchronization.png

66.6 KiB

0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment