...
| Responsible Person: | |||||||||||
| Other parties to review/input: | |||||||||||
| FYI: | |||||||||||
| Targeted release date: |
| ||||||||||
| Jira Status: |
|
*Note opensrp code for opensrp generic peer-to-peer sync: https://github.com/OpenSRP/android-p2p-sync
*For Reveal we have to build the ability to sync structures and task and filter by plans
Process
- Prepare rough business analysis/reqs doc (Derek Pollard: Complete) Pierre Dane, please review before requesting CHAI team to review.
- Get CHAI review
- Get Akros Review
- Get Ona feedback
- One iteration
- Ona sign off
- Ona tech spec scoping
- Ona LOE
- Ona scheduling
Assumptions
Each user would have to pre-download the plan, maps etc for each area as those cannot be synced.
- Query running sync will first look at which plans are shared by the two users trying to sync.
- Two tablets sync to each other at a time.
- A sync from one sender device to another receiver device will send all data to the receiver that does not already exist on the receiving tablet.
- All synced data should have a sync id.
Definitions
- Peer-to-peer sync in the process by which, two or more tablets sync data across themselves without a "master tablet" syncs one by one to each of the other tablets of interest without syncing to the server first. This would be done through some local network mechanism (bluetooth, hotpsot) from the devices. The outcome will be to provide offline coverage indicators for the "master tablet."
Requirements
Sync data within a specific operational area between tablets that collected data in that operational area.
Ensure data is not sent back to a tablet that it was already synced from (sync unique ids)
Get confirmation of what data was synced between tablets to ensure all data was sent and received.
...
See workflow in this google doc as I can't load the document directly.
Examples of how this previously worked in mSpray
...