Organization of client-server data synchronization for a mobile application

Architecturally possible two solutions.

•   passed parameters (fields)
    1.data- line in json format
   
    
     Description:
    
   1. data in the data field is transmitted in a string in json format 
    In them we transfer data which needs to be synchronized.
    It uses:
   
     a) the unique local creation time (change) "ut" (each entry)
     b) and a unique local id (for each entity) (id must be unique, have a - sign).
      c) transmission without a minus sign for the id, if id global. 

• example

•   data =
    [
       {
           "cmd": 1,
           "ut": 134256789088,
           "tb": "product",
           "dt": [-6341,134,13,12,12312,12]
        },
       {"cmd": 2,
          "ut": 4578678789876,
          "tb": "product",
          "dt": [1,12,162,124,142,12,12, -341, 126,12,122,122]
       },
  	 {"cmd": 3,
          "ut": 45678908765,
          "tb": "product",
          "dt": [1]
       }
  
   ]
   
    Where 
   
      cmd - command (1,2,3) for details see below.
      ut - unictstaym (in seconds) of each record on the device
     (the time of the last local work with this object)
      dt- data array without field names 
      tb - table name for synchronization
      see values ​​below
   
   
   
   
    2. transfer no more than N records in one request, if there are more than N records, then transfer first the read records to the record, then everything else in portions (page by page) 

• Comments
  
  1. if the device received a negative response from the server (other than 200 and after a retransmission without synchronization)
  or the device does not have access to the Internet then write all data to the local database
  
  after the appearance of the Internet or in the presence of such data to determine the difference previously synchronized data
  and new data collected offline
  
  the result of these comparisons should be the objects and the three operations on them add, update, delete
  necessary for the bases to be the same
  
  2. send the following data
  --with id <0 (application stores all records created offline with global id = 0,
  but you need to transfer with a local ID with a minus sign) - if a new object is used, it can be used in the associated data
  (after sending the command for synchronization and if successful, the application should update the global ids for server values)
  - with a sign of update (the application must have an update flag for each entry of synchronized entities)
  This flag can be reset only after sending the command to synchronize and if it was successful.
  --with an id in the deletion table (the application must store all id records and the name of entities that are deleted offline)
  after sending the command to synchronize and if it is successful, the application clears the list of deleted entries
  
  
  
  3. send kommandu on synchronization
  if successful, we load all the data or load the modified data and delete the sequential data in the application
  (at this moment a deferred recording is formed for synchronization in linked accounts via PUSH)
  
  4. Customer stores
  1. new entries must have id <0 and equal to unique local number
  2. Remote records should be stored in the deletes table.
  3. It is advisable to mark updated records in offline mode with a sign of updates.
  
  5. Names of operations
  ins = 1
  upd = 2
  del = 3
  
  
  6.Name of entities and fields available for insertion or update (if you need to delete a record, you need only an id):
  It is necessary to transfer the data in this order without the name of the fields;
  
  entity1 [id field id .....]
  Entity2 [id field id .....]
  Entity3 [id field id .....]
  
  so synchronization from the device to the server consists of such actions
  1. transfer data (in this case, a complex of checks on the server is released)
  
  2. save changes (changes are made sorted by unixtime)
  and changes are made (synchronization via push) in a queue for related
  with this account devices (accounts)
  
  3. if the server has an entry with unixtime more than the device,
  then changing or deleting this entry is ignored and such entry
  the device needs to be downloaded from the server already
  
  4. after transfer and fixation of data on the server you need to get
  data (from p3) from the server and transfer to the local database of the device
  5. because there is no backward synchronization, it is desirable to perform a full data load at the end
  (to update the id), this is necessary if you don’t deliver, or push back with a request for reverse synchronization, or the data transferred is not taken into account
  to push
  
  notes
  1. negative local id is used in three cases
  if new record is added - always
  (must be transmitted before its use in other records)
  if the record created locally is updated or deleted, at the same time, such a record is not transmitted in case of synchronization using method 2
  if the existing record is updated but with indication in the field to the local record