Еще одно мое сообщение, связанное с Oracle Offline Persistence Toolkit. Я уже описывал, как прослушиватель после запроса может быть полезен для чтения данных ответа после синхронизации - Oracle Offline Persistence Toolkit - After Request Sync Listener. Сегодня мы расскажем, когда может быть полезен прослушиватель предыдущих запросов. Как и после прослушивателя запросов, он определяется во время регистрации диспетчера сохраняемости:
Перед обработкой запроса слушатель должен вернуть обещание. Мы можем контролировать решенное действие. Например, если нет необходимости обновлять запрос, мы просто возвращаем continue. Нам нужно будет обновить запрос, если одна и та же строка обновляется несколько раз во время синхронизации. В полезных данных запроса необходимо обновить значение индикатора изменения. Считываем последнее значение индикатора изменения из массива, инициализированного в обработчике запроса. Полезные данные запроса преобразуются в JSON, значение обновляется, а затем мы создаем новый запрос и разрешаем его с помощью воспроизведения. API позволяет предоставить новый запрос, заменив исходный:
Вот пример использования. В автономном режиме - значение обновления:
Оставаясь в автономном режиме, снова обновите то же значение:
Мы должны отслеживать выполненные запросы во время синхронизации, когда мы выходим в сеть. Первый запрос, инициированный первым изменением, использует значение индикатора изменения 292:
Второй запрос использует обновленное значение индикатора изменения 293:
Без логики приемника запросов до и после второй запрос будет выполняться с тем же значением индикатора изменения, что и первый. Это может привести к конфликту данных на сервере.
Пример кода приложения доступен на GitHub.
Первоначально опубликовано на сайте andrejusb.blogspot.com 2 октября 2018 г.
