Коли ти чимось пишаєшся, то хочеться про це розповідати знову і знову. Ми вже писали про наш проєкт 5Star Service у блозі, де зачепили маркетинговий бік (ідеї, завдання і рішення тощо) - тут, звісно, ми все і всіх перемогли. додаток вийшов унікальним у своєму роді, при цьому залишається універсальним і адаптується під будь-який B2C-бізнес. Але в цій статті ми поговоримо про технічний бік процесу і відкриємо таємниці розробників.
Що важливо для додатку, який займається збором відгуків? Відповідаємо: швидка робота і чуйний інтерфейс, що налаштовує на взаємодію. Щоб поставити оцінку, користувач повинен залишити власні дані (номер телефону та оцінку) - так, не "найпростіший" нюанс! Тому ми постаралися настільки прискорити роботу і опрацювати дизайн, щоб все пройшло миттєво.
Проблема № 1: Швидкість понад усе
Початковий алгоритм був таким: дані на сервер надсилатимуться після кожної дії користувача, до того ж тільки в разі успішної відповіді від сервера відбувався перехід на новий екран.
Але що робити, якщо виникнуть неполадки на сервері або буде поганий інтернет (ситуація відома)? Користувач не зможе залишити відгук і піти чимшвидше від нав'язливих очей персоналу, він чекатиме на відповідь сервера, знову вводитиме дані тощо. Цього ми допустити не могли, тому змінили логіку роботи програми.
Уся основна робота 5Star Service виконується "у фоновому режимі", тому користувачеві не потрібно вичікувати - його взаємодія із додатком здійснюється паралельно, а відокремлення модуля із сервером від головного потоку забезпечило швидкість.
Проблема № 2: Дійде чи ні?
Нестабільне підключення до інтернету - це не проблема, а умова, з якою потрібно миритися. Через це тестовий запуск додатку показав, що деякі запити можуть не доходити до сервера і, як наслідок, частина оцінок була просто загублена. Вихід із цієї ситуації тільки один - реалізація offline-режиму. Якщо дані на сервері не збережуться з якихось причин, то вони опиняться в локальній базі програми. Подбали і про безпеку - шифрування бази даних увімкнено!
Проблема № 3: А якщо все-таки не дійде?
Після реалізації бази даних і відстеження невідправлених даних з подальшим їх збереженням, знадобилося реалізувати перевірку статусу мережі. Для цього було створено механізм, який відстежував підключення до мережі Wi-Fi. Щойно пристрій під'єднується до Wi-Fi, відбувається перевірка наявності не надісланих даних у нашій базі даних, які надсилаються на сервер. У разі успішного збереження даних здійснюється видалення з локального сховища. Це все дало змогу звести до мінімуму проблему з втратою даних, спричинену перебоями в роботі мережі або сервера.
Замість резюме
Для всіх, хто цікавиться, вказуємо інтерфейси та бібліотеки, які використовувалися під час розроблення програми:
- SQLite для роботи з базою даних
- Retrofit для роботи з мережею
- ResultReceiver для збереження невідправлених даних у базу даних
- IntentService для надсилання запитів на сервер із використанням Retrofit
- Fabric.io для відстеження помилок у роботі програми.
