which importantly is on a field level, not an object/row level
Field level conflict resolution just means that if two “actors” are updating the same object but not the same field then there is no conflict to resolve. Not all systems work this way, some systems do a row/object level resolution, which means if two different actors work on the same object, then even if they are updating completely different fields the system will see this as a conflict to resolve.
developers can implement their own custom conflict resolution strategy. We have seen manual (ie end user driven) and automatic (ie logic driven) custom conflict resolution strategies.
In order to accomplish this most developers create a separate model which stores the temporary/pending changes. These temporary objects either store the entire state of the object at the time of the change or just the fields that were changed (and yes, having a copy of the object in LocalDB is a good way to figure out what has changed). They then use webhooks and a single threaded CC task to determine if those temporary changes should be applied to the master object. The logic that is used to determine if the changes need to be applied depends on the use case and desired outcome, but one example would be to compare the time of the temporary change vs the last time that object or field was updated and then basing the decision off of that.
Because it says that ‘Application data Upload’ has priority 1, so let’s imagine that device has a spotty connection and only upload data from the JA Cloud with the new item changes. And there is also a change from the offline device.
What will be shown on the device - item from the JA Cloud or offline DB item?
I think you misunderstood the order or definition of those priorities. The device will always upload first before downloading new data. Or said in a different way, the offline device changes will be synched, applied and taken into consideration before changed data is downloaded to the device.
Application Data Synchronization
1 - Container uploads data changes from the device to the cloud (this will also apply these changes to the Cloud DB)
2 - Container receives App Logic updates
3 - Container downloads updated data from the Cloud to the device
When the device will go online again and reaches the moment of sending data (Application data Download), will the offline device change overwrite the JA Cloud change and then the final version, after all resolution conflicts, will get back to the device?
Yes.
(In most of our examples though the final version will already be on the device and will not be required to get downloaded again. For example if offline changes the name field from A → C, but online the name was changed from A → B, then once the offline change is synched it would change the name from B → C, and since the name on the device is already C it does not need to download that data again. Obviously there may be other changes that it does need to sync, but if that was the only change then no need to sync)
I hope this helps