Що відбувається, коли ваш застосунок втрачає інтернет (і як продовжувати працювати)

Ваш Wi-Fi відключається. Ви заповнюєте форму в застосунку — половина полів уже готова, ви витратили на це п’ять хвилин. Що станеться далі?

Якщо ваш застосунок працює лише онлайн, історія така: сторінка перезавантажується. Дані зникають. Ви починаєте спочатку. Закриваєте застосунок — і більше не повертаєтесь.

Якщо ваш застосунок побудований за принципом offline-first, історія інша: ви продовжуєте друкувати. Ваші дані в безпеці. Коли Wi-Fi повертається (через три хвилини чи через три дні), усе синхронізується. Ось offline-first дизайн одним реченням: застосунок продовжує працювати без інтернет-з’єднання, зберігає зміни локально й синхронізує їх, щойно ви знову онлайн.

Більшість білдерів застосунків пропускають офлайн-режим, бо так простіше будувати. Але offline-first — це не складно, це усвідомлений вибір. Це різниця між застосунком, до якого людина тягнеться, і застосунком, який видаляє.

Що насправді відбувається, коли ваш застосунок втрачає інтернет?

Коли ваш застосунок втрачає інтернет, він або продовжує працювати, або ні — середини немає. І втрата з’єднання — не рідкість: у пасажира в літаку немає інтернету, у людини в тунелі немає сигналу, у гостя на заміському заході нестабільне покриття, у того, чий домашній роутер перезавантажується о 3-й ночі, — мертвий Wi-Fi, а хтось прив’язаний до телефону вичерпав ліміт хотспоту.

У всіх цих випадках ваш застосунок або працює, або ні.

Ми створили застосунок для обліку часу фрилансерів. Він падав в офлайні. Один фрилансер (який користувався ним на будмайданчиках без сигналу) припинив ним користуватися — перейшов на олівець і папір, бо принаймні олівець працює всюди. Через три місяці, після появи офлайн-режиму, він повернувся й більше не йшов.

Механіка проста: зберігати роботу локально, коли інтернету немає, і синхронізувати її, коли з’єднання повертається. Оце і все.

Які бувають типи офлайну?

Є три типи офлайну, до яких варто готуватися: навмисний, несподіваний і повільний — і кожен потребує свого рішення.

Навмисний офлайн — користувач сам обрав працювати офлайн. Він у літаку або знає, що Wi-Fi поганий. Він очікує синхронізації пізніше. Найпростіше реалізувати: просто зберігайте чернетки локально й надсилайте їх, коли з’єднання повернеться.

Несподіваний офлайн — інтернет пропав раптово. Користувач був посеред роботи. Якщо ви обірвете його на півслові, він розлютиться. Виправлення те саме (зберігати чернетки локально), але UX має бути дбайливішим: покажіть, що застосунок і далі працює, і повідомте, коли з’єднання повернулось.

Повільний офлайн — з’єднання є, але настільки повільне, що його наче й немає. Клієнт заповнює форму, натискає «надіслати» й чекає 20 секунд, доки відправка завершиться. За цей час він думає, що щось зламалось, і тисне «надіслати» ще раз (тепер у вас дубль). Це найскладніше протестувати, але виправлення чесне: покажіть, що робота триває (індикатор завантаження), або дозвольте перейти на іншу сторінку, не втративши чернетку.

Як попросити свій білдер про офлайн-режим?

Просіть про це частинами, а не як одну велику функцію — offline-first це філософія дизайну, а не один пункт у чекбоксі. Ось п’ять конкретних запитів, які можна поставити білдеру:

Зберігати чернетки локально: «Коли хтось заповнює форму чи нотатку, зберігайте це на телефоні/у браузері. Якщо він оновить сторінку, форма має залишитись заповненою». Перевірте так: заповніть щось, закрийте вкладку браузера, відкрийте знову — форма має бути на місці.
Працювати офлайн: «Якщо немає інтернету, застосунок має показувати наявні дані, дозволяти користувачу їх переглядати й вносити зміни, а зміни ставити в чергу на синхронізацію, коли інтернет повернеться». Перевірте так: вимкніть Wi-Fi, спробуйте зробити щось корисне, а потім увімкніть Wi-Fi назад і подивіться, як дані синхронізуються.
Синхронізувати тихо: «Коли ми синхронізуємо зміни, не показуйте велике діалогове вікно. Покажіть невеликий індикатор, наприклад «Зберігаємо…» вгорі, який зникає, коли завершено. Якщо збереження не вдалося, зберігайте зміну локально й повторіть спробу пізніше».
Показувати правду: «Повідомляйте користувачу, які дані свіжі (щойно синхронізовані з сервером), а які — лише локальні (ще не синхронізовані). Використайте невеликий індикатор чи позначку — не робіть це лякаючим, просто чесним».
Один робочий процес, локальний насамперед: «Основна дія, заради якої користувач приходить (перевірити бронювання, написати нотатку, відстежити час), має працювати офлайн. Другорядні речі (пошук по всій історії записів, отримання актуальних цін) можуть вимагати інтернету».

Реальні історії

Організаторка весіль створила застосунок для керування підтвердженнями участі гостей. Вона роздруковувала список, ходила з ним на заходах і відзначала відповіді. Але Wi-Fi на майданчиках жахливий. Вона попросила offline-first: зберігати список локально, синхронізувати вдома. Тепер це її основний інструмент — навіть коли є сигнал телефону, застосунок працює, не чекаючи на дані. Вона в захваті.

Шкільна вчителька використовувала застосунок для відстеження прогресу учнів. Постійно втрачала зміни, переходячи між класами з нестабільним покриттям. Офлайн-режим дозволив їй працювати вільно, синхронізувати пізніше й не обирати між телефоном і роботою. Одна зміна — величезний приріст довіри.

Страховий оцінювач заповнював звіти про пошкодження на місці (у деяких сільських районах немає сигналу). Початковий застосунок вимагав інтернету для надсилання. Ми додали офлайн-чернетки. Тепер він заповнює форму, надсилає офлайн, а синхронізація відбувається, поки він їде назад. Більше жодного «я нічого не можу надіслати, поки не приїду додому».

Усі три випадки можна було б «вирішити» фразою «просто знайдіть кращий Wi-Fi», але реальний світ так не працює. Offline-first став для них більшим зрушенням довіри, ніж будь-яка краща синхронізація.

Чи робить offline-first ваш застосунок швидшим?

Так — offline-first застосунки відчуваються швидшими, бо вам не доводиться чекати на сервер. Ви друкуєте, застосунок зберігає це локально (миттєво) і синхронізує у фоні. Жодного індикатора завантаження, жодного очікування. Навіть за наявності інтернету досвід відчувається чіткішим, бо сервер не стоїть на заваді.

Застосунок, що працює лише онлайн, змушений чекати підтвердження кожної зміни від сервера. Натискання клавіші → мережевий запит → перевірка на сервері → відповідь → показ користувачу. Зазвичай це нормально, але на повільних мережах (або на мобільному з повільним сервером) кожна взаємодія затримується.

Скільки коштує реалізувати offline-first?

Offline-first коштує додаткового часу розробки на початковому етапі. Ваш білдер має продумати:

Локальне сховище: як зберігати дані на телефоні/у браузері, щоб вони не зникли, якщо застосунок аварійно завершить роботу. Не складно, але це має бути свідомим рішенням.
Вирішення конфліктів: якщо користувач змінює поле офлайн, а потім хтось інший (або інший пристрій) змінює те саме поле до синхронізації — чия версія переможе? Зазвичай онлайн-версія (вона свіжіша), але користувача варто попередити, а не здивувати. Реальний приклад: два телефони редагують одну й ту саму нотатку офлайн, обидва виходять онлайн — перемагає той, хто синхронізувався другим, а перший користувач бачить: «Ваша версія була застарілою, ось поточна».
Застарілі дані: якщо користувач був офлайн три дні, чи має застосунок мовчки оновити все, коли він знову підключиться, чи спершу запитати? Запитати безпечніше — до старих даних можуть бути прив’язані незбережені зміни.

Продумати це непросто задарма, але це простіше, ніж здається.

Винагорода: застосунки, яким люди довіряють. Offline-first застосунок не виправдовується («вам потрібен інтернет, щоб цим користуватися») і не втрачає вашу роботу. Це дуже багато значить.

Як перевірити, чи ваш застосунок працює офлайн?

Не потрібно летіти в літаку, щоб це перевірити — режим «в польоті» на вашому телефоні й буде вашим полігоном. Ось як:

Відкрийте та заповніть щось: зробіть щось звичайне (заповніть форму, додайте нотатку).
Перейдіть офлайн: увімкніть режим «в польоті» або вимкніть Wi-Fi.
Продовжуйте працювати: спробуйте зробити те саме ще раз. Якщо застосунок відмовляється — offline-first там ще немає. Якщо працює — добре. Якщо це плутає, попросіть у білдера чіткий індикатор «Ви офлайн».
Поверніться онлайн: вимкніть режим «в польоті».
Перевірте синхронізацію: ваші зміни синхронізувались автоматично? Якщо довелося натискати кнопку «синхронізувати» чи оновлювати сторінку — це ще не зовсім те.

Найкращі офлайн-застосунки відчуваються настільки природно, що ви навіть не помічаєте, що вони офлайн — ви просто помічаєте, що застосунок і далі працює.

Чи справді вашому застосунку потрібно працювати офлайн? Якщо відповідь «у моїх користувачів нестабільний інтернет, або вони працюють у місцях без сигналу» — тоді так. Якщо «вони завжди на стабільному Wi-Fi» — поки що можна це пропустити. Але в той момент, коли хтось скаже «я втратив свою роботу», ви пошкодуєте, що не подумали про це раніше.