Розробка застосунку для нестабільного зв’язку вимагає відповіді на просте питання: що вже збережено, коли користувач бачить повідомлення про успіх? Локальна чернетка може пережити відсутність інтернету, але ще не бути доступною колегам. Якщо інтерфейс не пояснює різницю, людина або довіриться неіснуючому підтвердженню, або повторно виконає ту саму роботу.
У вигаданому прикладі технік оглядає обладнання в підвалі будівлі. Він заповнює форму, додає кілька фотографій і переходить до наступного приміщення. Зв’язок зникає, а операційна система згодом закриває програму. Хороший результат — повернутися до збереженої роботи й зрозуміти, які частини вже прийняв сервер, а які ще очікують передачі.
Складіть карту операцій без мережі
Не кожна дія повинна працювати офлайн однаково. Чернетку огляду можна створити локально, а підтвердження остаточної видачі товару може потребувати актуального серверного залишку. Для кожної операції визначте, які дані доступні на пристрої, наскільки вони можуть застаріти та чи дозволене відкладене виконання. Обмеження варто пояснити до натискання кнопки.
Автоматичне збереження має включати не лише текст, а й посилання на підготовлені вкладення. Визначте місце зберігання файлів і поведінку за нестачі пам’яті. Не показуйте завершення збереження до фактичного результату локального запису. Якщо фотографію не вдалося зберегти, людина повинна побачити конкретну проблему, поки ще може її повторити.
Черга надсилання має бути видимою
Операція в черзі потребує стабільного ідентифікатора, стану, часу останньої спроби та зрозумілого повідомлення. Сервер повинен розпізнавати повтор прийнятої операції, якщо відповідь загубилася. Це дозволяє повторити передачу без другого огляду чи дубльованої позиції. Кнопка повтору не повинна щоразу створювати нову незалежну операцію.
Відділіть помилки зв’язку від відмов через дані або доступ. Відсутність інтернету допускає відкладену спробу; відкликана роль потребує рішення, а не нескінченного повторення. Зберігайте роботу до зрозумілого завершення або погодженого видалення, водночас враховуючи правила захисту локальних даних. Сам факт наявності чернетки не дає права відправити її від іншого облікового запису.
Конфлікт показуйте як вибір, а не втрату
Поки технік працює офлайн, координатор може змінити той самий запис. Перед застосуванням оновлення сервер порівнює очікувану версію з актуальною. Для безпечних незалежних полів можна погодити об’єднання, але для суперечливих значень потрібне явне рішення. Збережіть обидва варіанти й поясніть, яка саме частина роботи потребує перегляду.
Не використовуйте час на телефоні як єдиний доказ того, чия зміна новіша: годинник пристрою може відрізнятися. Історія повинна дозволяти зрозуміти порядок прийнятих сервером версій. Після вирішення конфлікту оновіть індикатор черги, щоб завершена задача не залишалася поруч із повідомленням про помилку та не провокувала зайві повтори.
Випробуйте переривання в різних точках
Для приймання вимкніть мережу до відправлення, під час передачі фото та після прийому сервером, але до отримання відповіді. Закрийте програму й відкрийте знову. Потім змініть запис з іншого пристрою та відкличте роль тестового користувача. Перевірте чернетку, вкладення, кількість серверних записів і можливість завершити конфлікт без втрати тексту.
Brainbaby Labs може допомогти визначити межі офлайн-режиму та реалізувати мобільний або вебзастосунок із відновленням роботи. Для початку потрібні приклад форми, типові вкладення і перелік дій, які вимагають актуального стану сервера. Це дозволить перевірити важливий робочий маршрут замість загальної обіцянки, що весь продукт завжди працюватиме без зв’язку.