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

Ці можливості пов'язані, але не тотожні. Для користувача важливо знати, яку частину роботи він зможе виконати без зв'язку, що потрібно підготувати заздалегідь і які обмеження з'являться. Для розробника — визначити поведінку інструмента в кожній із цих ситуацій.

Я український військовий лікар, працюю з медичним плануванням і навчанням TCCC/CLS та розробляю S-Dose. Це поєднання медицини й розробки визначає мій інтерес до теми. У цій статті S-Dose є контекстом, а не прикладом перевіреної реалізації: конкретні офлайн-функції, механізми оновлення, захист даних і результати тестування тут не оцінюються.

Головне питання ширше за наявність локального довідника: чи може людина завершити потрібну роботу без мережі, розуміючи стан інформації та результат своїх дій?

Офлайн — характеристика конкретної функції

У документації Android Developers підхід offline-first описаний як можливість виконувати всі або критично важливу частину основних функцій без інтернету. Для цього потрібне локальне джерело даних; можливість читання й можливість запису розглядаються окремо [1]. Отже, напис «офлайн» варто розшифровувати через конкретні дії.

Запуск означає, що застосунок відкривається. Доступ до довідника означає, що потрібні матеріали є на пристрої. Пошук потребує можливості знайти інформацію в цих матеріалах. Розрахунок залежить від того, де виконуються обчислення і звідки беруться необхідні правила та значення. Збереження запису потребує надійного місцевого сховища. Синхронізація, якщо вона передбачена, обмінюється змінами з іншою системою після відновлення зв'язку.

Не кожному застосунку потрібні всі ці можливості. Простий довідник може не мати облікового запису, журналу пацієнтів або синхронізації. Калькулятор може виконувати обчислення на пристрої, але завантажувати довідкові дані окремо. Інструмент для спільного ведення записів має інші залежності й складніші вимоги.

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

Інформація, збережена на пристрої, також буває різною. Матеріали можуть входити до встановленого застосунку, завантажуватися як окремий пакет або тимчасово залишатися після перегляду. Така тимчасова копія називається кешем. Android прямо попереджає, що файли кешу можуть видалятися при нестачі місця [2]. Тому перегляд сторінки онлайн ще не доводить, що вона буде надійно доступна пізніше.

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

Підготовка починається до втрати зв'язку

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

Користувачеві потрібне зрозуміле пояснення: що встановлюється одразу, що завантажується окремо, чи треба виконати перший запуск онлайн і як перевірити завершення підготовки. Якщо без авторизації доступний лише довідник, а персональні записи потребують підтвердженого входу, це також має бути видно.

Умовний приклад. Перед роботою людина відкрила потрібний розділ із доступною мережею. Пізніше вона перезапустила телефон, а застосунок запросив повторний вхід. Перша перевірка показала доступність уже відкритого екрана, але не перевірила запуск у новій сесії. Саме тому корисно закрити застосунок і відкрити його без мережі, а потім повторити перевірку після перезапуску пристрою.

Розробник тут має компроміс: обмеження доступу захищають чутливу інформацію, але можуть заважати користуванню без зв'язку. Його слід вирішувати відповідно до призначення функції й характеру даних. Публічний довідник і доступ до записів пацієнтів не обов'язково мають залежати від однакових умов входу.

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

Доступна інформація та актуальна інформація

Локальна копія забезпечує доступність. Її актуальність — інше питання. Якщо пристрій не має зв'язку з джерелом оновлень, він не може підтвердити, що після останньої перевірки не з'явилися зміни.

Для довідника чи протоколу я пропоную розрізняти чотири позначення:

  • Версія застосунку — яке програмне забезпечення встановлено.
  • Версія набору даних або протоколу — яку редакцію матеріалів використовує ця функція.
  • Дата джерела — коли видано або оновлено документ, на якому ґрунтується матеріал.
  • Дата останньої успішної перевірки оновлень — коли застосунок зміг перевірити доступність нової редакції.

Дата встановлення чи завантаження не замінює дату джерела. Невдала спроба з'єднатися не повинна виглядати як успішна перевірка актуальності. Якщо окремі матеріали оновлюються незалежно, одна загальна дата для всього довідника може бути недостатньо інформативною.

Зрозумілий статус міг би звучати так: «Доступна збережена редакція. Зараз перевірити наявність оновлень неможливо: немає зв’язку». Поруч варто показати джерело, версію матеріалів і дату останньої успішної перевірки оновлень. Це авторський приклад повідомлення, а не опис екрана S-Dose.

Актуальність не можна визначати лише віком файла. Рекомендація може залишатися чинною тривалий час, а помилка в новій редакції — вимагати швидкого виправлення. Універсальний строк на кшталт «усе придатне протягом шести місяців» приховує різницю між джерелами, їхніми змінами та призначенням інформації.

Для медичного матеріалу також важливо бачити походження й контекст: для якої аудиторії та умов призначене джерело, які адаптації внесено. Правильна дата сама по собі не встановлює застосовності рекомендації до конкретної ситуації.

Оновлення має залишати зрозумілий робочий стан

Оновлювати застосунок і оновлювати його довідник — різні дії. В одному інструменті матеріали змінюються лише разом із новою версією програми. В іншому завантажуються окремо. Перший підхід спрощує узгодження випуску, але прив'язує зміни контенту до оновлення програми; другий дозволяє змінювати матеріали незалежно, але потребує перевірки їхньої сумісності.

Для окремого пакета варто продумати послідовність: завантажити його до тимчасового місця, перевірити й лише потім зробити активним. Якщо зв'язок зник посередині, частково отриманий пакет не повинен непомітно замінити робочу копію.

Це ідея атомарної зміни: пов'язане оновлення застосовується цілком або не застосовується. SQLite описує механізми такого завершення транзакцій і відновлення після переривання [3]. Транзакція — група змін, яку база даних обробляє як одне ціле. Проте використання бази саме по собі не організовує весь процес оновлення: окремі файли, пошукові дані та логіка розрахунків також мають залишатися узгодженими.

Цілісність, походження й сумісність

Цілісність означає, що файл отримано повністю й він відповідає очікуваному вмісту. Для перевірки можна використовувати криптографічний хеш — обчислений «відбиток» файла. Водночас хеш, отриманий разом із файлом із неперевіреного джерела, не доводить, хто цей файл опублікував.

Походження потребує довіреної основи перевірки. Наприклад, цифровий підпис дозволяє перевірити пакет за ключем, якому застосунок уже довіряє. The Update Framework описує використання підписаних метаданих, хешів і версій для захисту оновлень [4]. Це технічна основа пояснення, а не вимога впровадити саме цей механізм у кожний медичний інструмент.

Сумісність відповідає на третє питання: чи правильно встановлена програма розуміє нові дані? Умовний приклад: пакет використовує нову одиницю вимірювання, яку попередня логіка калькулятора трактує інакше. Файл може бути повним і справжнім, але непридатним для цієї версії розрахунку. Отже, перевірка підпису не замінює перевірку формату, одиниць, залежностей і правил обробки.

Відновлення теж потрібно спланувати: яка копія залишається після невдалого оновлення, чи можна повторити завантаження та як користувач дізнається, що зміни не застосовано. Під час уже розпочатого розрахунку бажано зберігати визначену версію правил або явно запропонувати повторний розрахунок після їх зміни.

Коли стара версія містить відому критичну помилку

Попередня перевірена копія може допомогти при технічному збої нового завантаження. Але якщо для неї вже відома критична помилка, автоматичне повернення до неї потребує іншого рішення.

Я пропоную розглядати це за ураженою функцією. Для помилки, що може змінити результат розрахунку, можуть бути потрібні чітке попередження, обмеження розрахунку або його вимкнення до виправлення. Повідомлення має пояснювати, що саме уражено та які дії потрібні. Оцінка наслідків помилки визначає рішення; загальний банер «версія застаріла» може не передати суті.

Є й принципова межа: відключений пристрій не отримає повідомлення про помилку, виявлену після втрати зв'язку. Тому варто заздалегідь продумати доступні канали інформування користувачів і поведінку інструмента після отримання такого повідомлення. Довільне блокування всіх старих матеріалів за календарем не вирішує цю проблему.

Локальні дані потребують власного плану

Загальнодоступний довідник і персональні записи створюють різні вимоги. Для довідника важливі доступність, походження й узгодженість матеріалів. Для записів додаються питання доступу, конфіденційності, відновлення та видалення.

Офлайн-режим сам по собі не гарантує конфіденційності. OWASP MASVS-STORAGE розглядає захист чутливих даних у сховищах і запобігання витокам, зокрема через журнали та резервні копії [5]. Для конкретного інструмента потрібне розуміння, які дані зберігаються і хто може їх отримати.

Для надійності записів важливо, коли з’являється повідомлення «збережено». Введення тексту на екрані ще не означає його запису до сховища. Якщо збереження не вдалося, наприклад через нестачу місця, користувач має бачити помилку й мати можливість зберегти введене після її усунення. Оновлення структури сховища також потребує перевірки: чи залишаються попередні записи доступними після зміни версії застосунку.

Корисно починати з мінімізації: чи потрібні ім'я, повні ідентифікатори та інші персональні відомості для заявленої функції? Якщо завдання можна виконати без них, їх збирання додає відповідальності без очевидної користі.

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

Резервування зменшує ризик втрати, але створює додаткову копію інформації. Документація Android про резервні копії пояснює залежність їхнього захисту від версії платформи й налаштувань та ризики експорту до доступних іншим програмам каталогів [6]. Для користувача важливо знати, що копіюється, куди, хто має доступ і чи перевірено відновлення.

Збереження лише на телефоні залишає ризик його втрати або пошкодження. Якщо дистанційне блокування чи видалення потребує зв'язку, воно може не відбутися негайно. Видалення запису на пристрої також не означає автоматичного видалення його копій із резервів або сервера. Такі правила варто пояснити відповідно до реальних функцій інструмента.

Повернення мережі — окремий етап роботи

Для простого локального довідника повернення зв'язку може означати лише перевірку оновлень. Синхронізація персональних записів йому не потрібна, якщо таких записів немає.

Для інструмента, що обмінюється записами, потрібно розрізняти «збережено на пристрої» та «передано й підтверджено іншою системою». Це допомагає користувачеві зрозуміти, чи робота залишилася лише локально.

Умовний приклад. Двоє користувачів змінили один запис без мережі. Після з'єднання автоматичне прийняття останньої зміни може приховати виправлення другого користувача. Інша ситуація: сервер прийняв запис, але підтвердження не дійшло до телефона. Повторне надсилання може створити дублікат, якщо система не розпізнає ту саму дію.

Я пропоную передбачати розпізнавання повторних надсилань, збереження історії важливих змін і явне опрацювання конфліктів там, де вони можливі. Правило об'єднання залежить від типу запису: додавання окремої події та редагування вже наявного значення не обов'язково мають оброблятися однаково. Автоматичне рішення доречне лише тоді, коли зрозумілі його наслідки для даних.

Перевіряти завершену дію, а не лише відкритий екран

Практична перевірка починається з потрібної функції: знайти матеріал, виконати розрахунок або зберегти запис. Умови й очікуваний результат варто визначити до тесту. Потім перевірити, чи доступний результат після закриття та повторного відкриття застосунку.

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

Такі випробування слід проводити на тестових даних. Втрату мережі чи переривання оновлення не потрібно навмисно створювати під час надання допомоги або на єдиній копії важливих записів.

Успішний технічний тест підтверджує лише поведінку в перевірених умовах. Клінічна правильність довідника й розрахунків потребує окремої перевірки: відповідності джерелу, одиниць, вхідних припущень, меж і очікуваних результатів. Калькулятор може бездоганно працювати без мережі й водночас застосовувати помилкове правило.

Що запитати про заяву «працює офлайн»?

Оберіть запитання, що стосуються вашого інструмента, і перевірте потрібні функції або уточніть їхню роботу в розробника.

  1. Які саме дії доступні без мережі: читання, пошук, розрахунки, збереження?
  2. Що потрібно встановити, відкрити, завантажити або авторизувати заздалегідь?
  3. Чи працюють потрібні функції після перезапуску застосунку й пристрою? Що відбувається після завершення сесії?
  4. Як видно, які матеріали вже збережено локально й яких бракує?
  5. Де зазначені версія програми, редакція даних, дата джерела й остання успішна перевірка оновлень?
  6. Що залишиться доступним після перерваного або невдалого оновлення? Як дізнатися, чи його завершено?
  7. Як повідомляють про відому критичну помилку і що після цього відбувається з відповідною функцією?
  8. Якщо є персональні записи: що зберігається, як захищене, резервується, відновлюється й видаляється?
  9. Якщо є синхронізація: як видно завершення передачі, як обробляються дублікати та конфлікти?
  10. Які офлайн-сценарії перевірено, на яких версіях і пристроях, та як окремо перевіряли медичний зміст?

Продумана офлайн-робота робить залежності інструмента зрозумілими. Користувач знає, що доступно, що підготувати, яку редакцію він використовує і чи збережено результат. Розробник має визначену поведінку для збоїв та відновлення.

Корисна офлайн-функція дозволяє завершити потрібну дію й зрозуміти її результат, навіть коли перевірити оновлення або передати дані зараз неможливо.

Саме така конкретність допомагає обирати медичні інструменти для нестабільного зв'язку та обговорювати їхні можливості без зайвих обіцянок.

Джерела

  1. Google, Android Developers. Build an offline-first app. Оновлення сторінки: 13 травня 2026 року. Перевірено опис локальних і мережевих джерел та окремих стратегій читання й запису. Сфера: архітектура Android-застосунків.
  2. Google, Android Developers. Access app-specific files. Оновлення сторінки: 1 жовтня 2026 року. Перевірено розділи про файлове сховище й кеш, зокрема можливість очищення кешу при нестачі місця. Сфера: Android; поведінку інших платформ перевіряють за їхньою документацією.
  3. SQLite. Atomic Commit In SQLite. Поточна онлайн-документація, розділи про атомарне завершення, відновлення й обмеження. Використано для пояснення технічного принципу, а не як доказ надійності певного застосунку.
  4. The Update Framework. The Update Framework Specification. Поточна онлайн-специфікація, розділи про підписані метадані, хеші та процес перевірки оновлень. Сфера: технічний захист доставки оновлень, не перевірка медичного змісту.
  5. OWASP Mobile Application Security. MASVS-STORAGE: Storage. Поточна онлайн-редакція; перевірено положення MASVS-STORAGE-1 і MASVS-STORAGE-2 та опис ризиків локального зберігання. Сфера: безпека мобільних застосунків.
  6. Google, Android Developers. Security recommendations for backups. Оновлення сторінки: 25 жовтня 2024 року. Перевірено опис резервування, налаштувань захисту й ризиків експорту. Сфера: Android.

Посилання та наведені розділи перевірено 3 жовтня 2026 року. Текст розглядає технічні й організаційні рішення; він не встановлює регуляторного статусу або відповідності S-Dose будь-яким стандартам.

Дата редакції: