diff --git a/content/en/docs/refguide/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md b/content/en/docs/refguide/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md index 0b7534d925a..568240ed96e 100644 --- a/content/en/docs/refguide/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md +++ b/content/en/docs/refguide/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md @@ -64,9 +64,13 @@ The upload phase executes the following operations: 1. As the local database can be modified only by committing or deleting an object, such an object can be either a new object created while offline or an existing object previously synced from the server. The upload phase detects which objects have been committed to the local database since the last sync. The detection logic differs per sync type. For **Synchronize all**, all committed objects in the local database are checked. For **Synchronize objects**, all committed objects from the list of selected objects are checked. 2. There might be objects deleted from the device database since the last sync. The upload phase checks which objects have been deleted. -3. If there are any changed or new file objects their content is uploaded to the server and stored there temporarily. Each file is uploaded in a separate network request. If a file upload fails, the whole sync is aborted without causing any changes to the server or device database. +3. If there are any changed or new file objects their content is uploaded to the server and stored there temporarily. Each file is uploaded in a separate network request. + + File uploads are not incremental—the full file content is uploaded whenever a file object has been modified in the local database, regardless of whether the file content itself has changed. If a file upload fails, the whole sync is aborted without causing any changes to the server or device database. + 4. All the changed and new objects are sent to the server, and the content of the files is linked to the objects. The server performs referential integrity validation of the objects (for more information, see the [Dangling References](#dangling-references) section below). The objects are committed to the server database. Information about deleted objects is also sent to the server so the server can delete them from its database too. This step is performed in a single network request. -5. Any configured before- or after-commit or before- or after-delete event handlers on these objects will run on the server as usual: after the data has been uploaded and before the device database is updated. +5. Any configured before- or after-commit or before- or after-delete event handlers on these objects will run on the server as usual: after the data has been uploaded and before the device database is updated. + This means that any further changes you make to the synced objects in the event handlers will be applied to the device database during the download phase. There is one exception to this rule: changing the contents of a file entity is not applied when you attempt to change them in the event handlers. Before- and after-commit event handlers for new objects will also be executed. @@ -74,7 +78,9 @@ The upload phase executes the following operations: If the upload phase was successful, the download phase starts in which the local database is updated with the newest data from the server database. The behavior of download phase differs per synchronization type: -* **Full synchronization** – A network request is made to the server per entity to retrieve the newest data from the server database. You can manage which entities are synchronized to the local database by customizing your app's synchronization behavior. For more details on this procedure, see the [Customizable Synchronization](#customizable-synchronization) section below. The download process also downloads the file entities' contents and saves that to your device storage. This process is incremental. The app only downloads the contents of a file object if the file has not been downloaded before, or if the file has been changed since it was last downloaded. The changed date attribute of the file entity is used to determine if the contents of a file object have changed. +* **Full synchronization** – A network request is made to the server per entity to retrieve the newest data from the server database. You can manage which entities are synchronized to the local database by customizing your app's synchronization behavior. For more details on this procedure, see the [Customizable Synchronization](#customizable-synchronization) section below. The download process also downloads the file entities' contents and saves that to your device storage. + + Unlike the upload phase, this process is incremental. The app only downloads the contents of a file object if the file has not been downloaded before, or if the file has been changed since it was last downloaded. The changed date attribute of the file entity is used to determine if the contents of a file object have changed. * **Selective synchronization** – Only the objects selected for synchronization are synchronized to the local database. There are no extra network requests made to retrieve these objects. The objects are returned in the response of a network request made during the upload phase. If a file entity is selected for synchronization, its content is also updated on the device storage incrementally. The logic is the same in the full synchronization. ### After Synchronization @@ -113,7 +119,7 @@ For each entity the **Synchronization mode** is shown. A default is automaticall When an entity is configured with one of the **Online**, **Nothing (clear data)**, **Nothing (preserve data)**, or **Never** synchronization modes, the Mendix Runtime will reject any synchronization request from a client that attempts to upload changes for that entity. This prevents unintended data modifications on the server and makes your application more secure. If a client attempts to synchronize changes for a restricted entity, those changes are blocked and a synchronization error is recorded on the server. You can inspect these errors via the `System.SynchronizationError` entity. -**Compatibility Mode** — When you migrate an entity from All Objects or By XPath to **Online**, **Nothing**, or **Never**, older versions of your offline app may still attempt to synchronize changes for that entity. To prevent those clients from receiving synchronization errors during the migration period, you can enable **Compatibility Mode** for the entity by selecting the checkbox in the synchronization configuration. +**Compatibility Mode** – When you migrate an entity from All Objects or By XPath to **Online**, **Nothing**, or **Never**, older versions of your offline app may still attempt to synchronize changes for that entity. To prevent those clients from receiving synchronization errors during the migration period, you can enable **Compatibility Mode** for the entity by selecting the checkbox in the synchronization configuration. When **Compatibility Mode** is enabled for an entity: diff --git a/content/en/docs/refguide10/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md b/content/en/docs/refguide10/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md index e48d7a0a8ba..29884ff2020 100644 --- a/content/en/docs/refguide10/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md +++ b/content/en/docs/refguide10/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md @@ -64,9 +64,13 @@ The upload phase executes the following operations: 1. As the local database can be modified only by committing or deleting an object, such an object can be either a new object created while offline or an existing object previously synced from the server. The upload phase detects which objects have been committed to the local database since the last sync. The detection logic differs per sync type. For **Synchronize all**, all committed objects in the local database are checked. For **Synchronize objects**, all committed objects from the list of selected objects are checked. 2. There might be objects deleted from the device database since the last sync. The upload phase checks which objects have been deleted. -3. If there are any changed or new file objects their content is uploaded to the server and stored there temporarily. Each file is uploaded in a separate network request. If a file upload fails, the whole sync is aborted without causing any changes to the server or device database. +3. If there are any changed or new file objects their content is uploaded to the server and stored there temporarily. Each file is uploaded in a separate network request. + + File uploads are not incremental—the full file content is uploaded whenever a file object has been modified in the local database, regardless of whether the file content itself has changed. If a file upload fails, the whole sync is aborted without causing any changes to the server or device database. + 4. All the changed and new objects are sent to the server, and the content of the files is linked to the objects. The server performs referential integrity validation of the objects (for more information, see the [Dangling References](#dangling-references) section below). The objects are committed to the server database. Information about deleted objects is also sent to the server so the server can delete them from its database too. This step is performed in a single network request. -5. Any configured before- or after-commit or before- or after-delete event handlers on these objects will run on the server as usual: after the data has been uploaded and before the device database is updated. +5. Any configured before- or after-commit or before- or after-delete event handlers on these objects will run on the server as usual: after the data has been uploaded and before the device database is updated. + This means that any further changes you make to the synced objects in the event handlers will be applied to the device database during the download phase. There is one exception to this rule: changing the contents of a file entity is not applied when you attempt to change them in the event handlers. Before- and after-commit event handlers for new objects will also be executed. @@ -74,7 +78,9 @@ The upload phase executes the following operations: If the upload phase was successful, the download phase starts in which the local database is updated with the newest data from the server database. The behavior of download phase differs per synchronization type: -* **Full synchronization** – A network request is made to the server per entity to retrieve the newest data from the server database. You can manage which entities are synchronized to the local database by customizing your app's synchronization behavior. For more details on this procedure, see the [Customizable Synchronization](#customizable-synchronization) section below. The download process also downloads the file entities' contents and saves that to your device storage. This process is incremental. The app only downloads the contents of a file object if the file has not been downloaded before, or if the file has been changed since it was last downloaded. The changed date attribute of the file entity is used to determine if the contents of a file object have changed. +* **Full synchronization** – A network request is made to the server per entity to retrieve the newest data from the server database. You can manage which entities are synchronized to the local database by customizing your app's synchronization behavior. For more details on this procedure, see the [Customizable Synchronization](#customizable-synchronization) section below. The download process also downloads the file entities' contents and saves that to your device storage. + + Unlike the upload phase, this process is incremental. The app only downloads the contents of a file object if the file has not been downloaded before, or if the file has been changed since it was last downloaded. The changed date attribute of the file entity is used to determine if the contents of a file object have changed. * **Selective synchronization** – Only the objects selected for synchronization are synchronized to the local database. There are no extra network requests made to retrieve these objects. The objects are returned in the response of a network request made during the upload phase. If a file entity is selected for synchronization, its content is also updated on the device storage incrementally. The logic is the same in the full synchronization. ### After Synchronization diff --git a/content/en/docs/refguide9/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md b/content/en/docs/refguide9/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md index 03728252560..8401b2f0ca8 100644 --- a/content/en/docs/refguide9/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md +++ b/content/en/docs/refguide9/mobile/building-efficient-mobile-apps/offlinefirst-data/synchronization.md @@ -65,11 +65,15 @@ The upload phase executes the following operations: 1. As the local database can be modified only by committing or deleting an object, such an object can be either a new object created while offline or an existing object previously synced from the server. The upload phase detects which objects have been committed to the local database since the last sync. The detection logic differs per sync type. For **Synchronize all**, all committed objects in the local database are checked. For **Synchronize objects**, all committed objects from the list of selected objects are checked. 2. There might be objects deleted from the device database since the last sync. The upload phase checks which objects have been deleted. - {{% alert color="warning" %}}Deleting an object from the device database is only supported in Studio Pro 9.7 and higher.{{% /alert %}} + {{% alert color="warning" %}}Deleting an object from the device database is only supported in Studio Pro 9.7 and above.{{% /alert %}} -3. If there are any changed or new file objects their content is uploaded to the server and stored there temporarily. Each file is uploaded in a separate network request. If a file upload fails, the whole sync is aborted without causing any changes to the server or device database. +3. If there are any changed or new file objects their content is uploaded to the server and stored there temporarily. Each file is uploaded in a separate network request. + + File uploads are not incremental—the full file content is uploaded whenever a file object has been modified in the local database, regardless of whether the file content itself has changed. If a file upload fails, the whole sync is aborted without causing any changes to the server or device database. + 4. All the changed and new objects are sent to the server, and the content of the files is linked to the objects. The server performs referential integrity validation of the objects (for more information, see the [Dangling References](#dangling-references) section below). The objects are committed to the server database. Information about deleted objects is also sent to the server so the server can delete them from its database too. This step is performed in a single network request. -5. Any configured before- or after-commit or before- or after-delete event handlers on these objects will run on the server as usual: after the data has been uploaded and before the device database is updated. +5. Any configured before- or after-commit or before- or after-delete event handlers on these objects will run on the server as usual: after the data has been uploaded and before the device database is updated. + This means that any further changes you make to the synced objects in the event handlers will be applied to the device database during the download phase. There is one exception to this rule: changing the contents of a file entity is not applied when you attempt to change them in the event handlers. Before- and after-commit event handlers for new objects will also be executed. @@ -77,7 +81,9 @@ The upload phase executes the following operations: If the upload phase was successful, the download phase starts in which the local database is updated with the newest data from the server database. The behavior of download phase differs per synchronization type: -* **Full synchronization** – A network request is made to the server per entity to retrieve the newest data from the server database. You can manage which entities are synchronized to the local database by customizing your app's synchronization behavior. For more details on this procedure, see the [Customizable Synchronization](#customizable-synchronization) section below. The download process also downloads the file entities' contents and saves that to your device storage. This process is incremental. The app only downloads the contents of a file object if the file has not been downloaded before, or if the file has been changed since it was last downloaded. The changed date attribute of the file entity is used to determine if the contents of a file object have changed. +* **Full synchronization** – A network request is made to the server per entity to retrieve the newest data from the server database. You can manage which entities are synchronized to the local database by customizing your app's synchronization behavior. For more details on this procedure, see the [Customizable Synchronization](#customizable-synchronization) section below. The download process also downloads the file entities' contents and saves that to your device storage. + + Unlike the upload phase, this process is incremental. The app only downloads the contents of a file object if the file has not been downloaded before, or if the file has been changed since it was last downloaded. The changed date attribute of the file entity is used to determine if the contents of a file object have changed. * **Selective synchronization** – Only the objects selected for synchronization are synchronized to the local database. There are no extra network requests made to retrieve these objects. The objects are returned in the response of a network request made during the upload phase. If a file entity is selected for synchronization, its content is also updated on the device storage incrementally. The logic is the same in the full synchronization. ### After Synchronization