Mendix optimizes this process for you out-of-the-box, by analyzing which objects need te be synched. The first time a user logs into the app, everything will be synchronised, and after that initial startup, only changes will be synchronised. You can use x-path to further limit the amount of objects that will be synched, and if you still want more control, you can set the synchronisation option to 'nothing' in the navigation menu, and use the synchronise activities to handle the synchronisation.

[edit]

 As in the documentation, synchronisation consists of an upload phase and a download phase.

- During the upload phase, mendix analyzes which objects are new or changed on the device, performs a consistency check and syncs the changes to the runtime.

- During the download phase, the latest data from the database is transferred to the device.

If you don't want to sync your entire database during the download phase, you can use x-path constraints, or in your case, can select the option ‘Nothing (preserve data)’ from the navigation configuration .  This is just a suggestion, but in a nanoflow you can check if the data has been initialised and can then call a microflow based on that decision, in which you retrieve either a list of objects that have been changed recently, or a complete list. Then use the ‘synchronise to device’ activity to send that data to the device. 

Hi Lennart

Thanks for your swift reply. Maybe I am missing things but it is hard to believe that this is out of the box logics. We have a native app where a synch button is present. The first time a user logs in to the application, it takes a while to synch all the data ( which is normal, regarding the amount of objects). 

However, when everything is synched and we push the synch button again ( without committing any local objects) it takes around the same time to finish the synchronisation. Is this then the expected behaviour? I would think that synchronisation at that point would be lighting fast, since no objects are comitted and no objects are changed on server. ( Therefor my sceptical view on the out of the box process). Also the next time we launch the app, synchronisation still takes a long time, even if no new objects are committed from server side. ( perhaps this processing time is related to the checks for changes?)

Thanks for your help.

Kind regards

Kevin

This synchronisation method is quite uncommon for me. I thought that whenever you download a database, it will be kept in the local device, regardless of login out and regardless of syncing again. Therefor I also thought that whenever you want to synch again, he would only synch the changed objects ( because the none changed objects would be still in the local database). This seems not the case then.

We have configured a nanoflow that triggers a microflow where we retrieve all the objects we want to synch to the device. The problem  is however that whenever we make a new object offline and afterwards commit and synch, my local database is not kepit entirely, only the objects matching my xpath synch are back in the local DB. This is not what I want.

I want a initial retrieve of the entire database and I want it to be in my local database forever. Only with the synch i want new objects from the server….

Is this not possible then?

HI Lennart

Is my undersanding correct that whenever you do a selective synch in a nanoflow for some specific objects, he will download all objects of the commited entities again to the device? From my testing this seems to be true.