3.4.2 Синхронізація оновлених даних
Сутність методу полягає в тому, що при першому запиті від клієнта сервер відішле усі дані, які необхідні, а при нових запитах сервер відсилатиме лише оновлені дані, що були добавлені з моменту попередньої синхронізації.
Це досягається введенням додаткового поля до таблиці "updated" в порядку зростання. Пристрій зберігає значення "updated" з моменту останньої синхронізації і при наступному запиті відсилає його серверу в параметрі lastUpdated. Сервер в свою чергу відсилає відповідь за наступною умовою (updated> lastUpdated). На пристрій приходять тільки нові дані, трафік буде невеликим.
Приклад запиту: {lastUpdated: "2013-01-01 00:00:00"}
Рис. 3.6. Схема синхронізації даних за другим методом
Таблиця 3.8
Тестування роботи другого методу
Запит, № |
Кількість переданого трафіку(байт) |
Час виконання операції на сервері(мс) |
Час виконання операції на пристрої(мс) |
Загальний час виконання операції(мс) |
1 |
250 374 |
13 |
13249 |
13262 |
2 |
25 473 |
6 |
1347 |
1353 |
3 |
24 300 |
6 |
1422 |
1428 |
Продовження до табл. 3.8
4 |
25 310 |
7 |
1475 |
1482 |
5 |
25 014 |
6 |
1374 |
1380 |
Рис. 3.7. Кількість переданих байт інформації при кожному запиті
Рис. 3.8. Часова діаграма початку і завершення синхронізації
Загальна кількість переданих байт за 5 запитів дорівнює 350 471.
На рис. 3.7. видно, що кількість переданого трафіку за кожен запит порівняно з першим методом(рис. 3.4.) значно менше. Однак на рис. 3.8. видно, що при першому запиті дані не встигатимуть передаватися до наступної синхронізації, що призведе до створення додаткового потоку і це в свою чергу збільшить навантаження на мобільний пристрій.
Переваги:
логіка на сервері є відносно простою – сервер віддає лише оновлені дані
логіка на пристрої є відносно простою – сервер віддає лише оновлені дані
Недоліки:
якщо кількість даних при першому запиті буде значно великою, то виникають паралельні потоки, що значніше навантажують пристрій
значне використання пам’яті та процесору мобільного пристрою
сервер не знає яка інформація зберіглась(якщо додаток аварійно завершився, то можлива така ситуація коли частина інформації не зберіглась, і пристрій при наступних синхронізаціях не отримає її)
Область застосування:
синхронізація звичайних лінійних списків
передача дуже рідко мінливих даних (список міст, категорій)
3.4.3 Синхронізація порціями
У мобільних пристроїв мало оперативної пам'яті. Якщо за один запит пристрій отримає відповідь від сервера розміром у 3000 рядків з БД, то парсинг такого розміру json-файл в об'єкти на пристрої може викликати недостачу пам'яті. У цьому випадку додаток або аварійно завершиться, або не збереже отриману відповідь. Але навіть якщо пристрій зможе обробити таку кількість даних за один раз, то продуктивність програми в моменти синхронізації буде низька (лаги інтерфейсу, не плавна прокрутка і т.п.) Тому необхідно запитувати список більш дрібними порціями.
На схемі: "last_updated" і "amount" - значення, які зберігаються в мобільному додатку. "Last_item" - остання надіслана з сервера сутність. Саме новіше цього значення буде запитаний наступний список.
Приклад запиту: {lastUpdated: "2013-01-01 00:00:00", amount: 100}
При використання такого типу запиту можлива ситуація, що якщо в таблиці є 250 записів з однаковим "updated" (наприклад, "2013-01-10 12:34:56") і розмір порції дорівнює 100, то прийдуть тільки перші 100 записів. Решта 150 будуть відсічені жорсткою умовою (updated> lastUpdated). При запиті перших 100 записів lastUpdated встановиться в "2013-01-10 12:34:56", і наступний запит матиме умова (updated> "2013-01-10 12:34:56"). Також не допоможе пом'якшення умови (updated> = "2013-01-10 12:34:56"), тому що пристрій тоді буде нескінченно запитувати перші 100 записів.
Наприклад, при імпорті даних з текстового файлу поле "updated" використовувалась функція NOW(), що повертає час. Імпорт файлу з тисячами рядків може зайняти менше секунди. Може статися й так, що весь довідник буде мати однаковий "updated". Щоб виправити таку ситуацію необхідно використовувати унікальне поле у межах одного моменту ("updated"). Поле "id" унікально взагалі по всій таблиці, тому слід додатково в синхронізації використовувати саме його.
Реалізація цього методу є такою. Сервер віддає список відсортований по "updated" і "id", а пристрої запитують дані за допомогою "lastUpdated" і нового параметра "lastId". Умова, що виконується на сервері під час генерування відповіді: ((updated> lastUpdated) || (updated == lastUpdated and id> lastId)).
Рис. 3.9. МС даних за третім методом
Оскільки швидкість передачі через мобільний інтернет є незначною(середня швидкість передачі ~18000 байт/с), то необхідно зробити так, щоб за один запит дані передавались ½ часу проміжку між повторною синхронізацією, тобто 10/2 = 5 секунд. Кількість даних, що може бути передана за 5 секунд дорівнює 18000 * 5 = 90000 байт. Це зумовлене тим, що якість покриття на різних місцевостях може відрізнятись і необхідно для забезпечення надійної роботи додатку.
Таблиця 3.9
Тестування третього методу
Запит, № |
Кількість переданого трафіку(байт) |
Час виконання операції на сервері(мс) |
Час виконання операції на пристрої(мс) |
Загальний час виконання операції(мс) |
1 |
252 374 |
15 |
14259 |
14274 |
2 |
27 473 |
7 |
1647 |
1654 |
3 |
26 300 |
7 |
1722 |
1729 |
4 |
27 310 |
8 |
1875 |
1883 |
5 |
27 014 |
7 |
1474 |
1484 |
Рис. 3.10. Кількість переданих байт інформації при кожному запиті
Рис. 3.11. Часова діаграма початку і завершення синхронізації
Загальна кількість переданих байт за 5 запитів дорівнює 360 471.
Дані передаються майже однаковими малими порціями, що виключає можливої ситуації коли до завершення синхронізації n починається синхронізація n+1.
Переваги:
низьке навантаження на пам’ять та процесор пристрою
Недоліки:
для пристроїв різних характеристик, обмеження для одного пристрою не підходить для іншого пристрою(якщо обмеження низькі – синхронізація відбуватиметься довше ніж є можливість, якщо обмеження вищі – нестабільність роботи додатку)
Область застосування:
для пристроїв однакової характеристики