This is next post related to Oracle Offline Persistence Toolkit. Check my previous writing on same subject - Implementing Handle Patch Method in JET Offline Toolkit. Read more about toolkit on GitHub repo.
When application goes online, we call synchronisation method. If at least one of the requests fails, then synchronisation is stopped and error callback is invoked, where we can handle failure. In error callback, we check if failure is related to the conflict - then we open dialog, where user will decide what to do (to force client changes or take server changes). Reading latest change indicator value from response in error callback (to apply it, if user decides to force client changes in the next request):
Dialog is simple - it displays dynamic text for conflicted value and provides user with a choice of actions:
Let's see how it works.
User A editing value Lex and saving it to backend:
User B is offline, editing same value B and saving it in local storage:
We can check it in the log - changes value was stored in local storage:
When going online, pending requests logged offline, will be re-executed. Obviously above request will fail, because same value was changed by another user. Conflict will be reported:
PATCH operation fails with conflict code 409:
User will be asked - how to proceed. To apply changes and override changes in the backend, or on opposite take changes from the backend and bring them to the client:
I will explain how to implement these actions in my next post. In the meantime you can study complete application available on GitHub repo.
When application goes online, we call synchronisation method. If at least one of the requests fails, then synchronisation is stopped and error callback is invoked, where we can handle failure. In error callback, we check if failure is related to the conflict - then we open dialog, where user will decide what to do (to force client changes or take server changes). Reading latest change indicator value from response in error callback (to apply it, if user decides to force client changes in the next request):
Dialog is simple - it displays dynamic text for conflicted value and provides user with a choice of actions:
Let's see how it works.
User A editing value Lex and saving it to backend:
User B is offline, editing same value B and saving it in local storage:
We can check it in the log - changes value was stored in local storage:
When going online, pending requests logged offline, will be re-executed. Obviously above request will fail, because same value was changed by another user. Conflict will be reported:
PATCH operation fails with conflict code 409:
User will be asked - how to proceed. To apply changes and override changes in the backend, or on opposite take changes from the backend and bring them to the client:
I will explain how to implement these actions in my next post. In the meantime you can study complete application available on GitHub repo.
No comments:
Post a Comment