Розробка мобільного застосунку для полювання з офлайн-картами та трекінгом

Розробка мобільного додатка для полювання: що ламається в офлайні

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

Це не «поганий інтернет в угіддях», а наслідок того, як спроєктовано офлайн-режим додатка: він залишається запасним сценарієм, а не основним.

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

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

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

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

Розбираємо, як це закривається в додатку для полювання, і що саме перевіряти в готовому продукті перед виходом у угіддя.

Що дає офлайн-карта й трекінг: вимірюваний ефект

Автономна робота додатка

Зв’язок в угіддях зникає на кілометри, тому автономна робота додатка — не окремий режим, а базовий стан.

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

У полі карта малюється з локального сховища за секунди, і клас відмов «немає даних — немає маршруту» зникає: без мережі доступні побудова, ведення та повернення за власним слідом.

Трекінг маршруту та витрата заряду

Точки пишуться з адаптивним кроком: на рівному переході рідше, на петлях і підході до звіра частіше. На восьмигодинному виході трекінг знімає близько 10–15% заряду проти половини батареї за безперервного запису.

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

Мітки угідь як спільні дані

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

Способи зберігання карт і режими синхронізації даних

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

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

Мітки й треки пишуться в локальну чергу й ідуть на сервер за першої появи зв’язку; конфлікт двох правок розв’язується за часом зміни, тому трек не губиться під час обриву.

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

Етапи роботи: від аудиту карт до передачі збірки

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

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

1. Аудит додатка та джерел карт. Розбираємо поточну збірку з магазину додатків і нашу кодову базу, перевіряємо права на картографію, оцінюємо потрібні області та шари. Підсумок — перелік вузьких місць і рішення: дорощувати наявне чи збирати заново.
2. Схема шарів і кешу. Розкладаємо базову карту, межі господарств, рельєф і користувацькі мітки, задаємо правила завантаження областей, щоб вони відкривалися без мережі.
3. Офлайн-режим. Фіксуємо, що саме працює без зв’язку: карта, мітки, запис треку, журнал. Області вантажаться цілком, без «білих плям» на межі зони.
4. Трекінг і запис маршруту. Пишемо запис треку з фільтрацією тремтіння, прив’язуємо мітки й точки зустрічі, стежимо за витратою заряду на багатогодинному виїзді.
5. Польові випробування. Виїжджаємо з прототипом у ліс і яри, перевіряємо слабкий сигнал, заміряємо відхилення треку й час відгуку після кількох годин роботи.
6. Передача збірки й навчання. Віддаємо підписану збірку, доступи до картографії, документацію за шарами та інструкцію для польових користувачів, навчаємо відповідальних.

Комплект передачі: схеми шарів, політики доступу, регламенти

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

• Схема шарів карти — які шари відображаються, порядок накладання, пріоритети й правила показу на різних масштабах, включно з клубними та закритими ділянками.
• Налаштування офлайн-областей — які регіони попередньо завантажуються, з якою деталізацією за масштабами формуються пакети й як обмежується обсяг, щоб пам’ять пристрою не переповнювалася.
• Регламент оновлення карт — періодичність випуску, версіонування пакетів, довантаження лише змінених фрагментів і відкат до попередньої версії.
• Політики доступу — ролі (мисливець, єгер, адміністратор господарства), права на закриті точки, порядок запрошення учасників і журнал дій.
• Схема трекінгу — інтервал запису треку, буферизація за втрати супутникового сигналу, формат вивантаження й правила зберігання історії.
• Документація додатка — архітектура, середовища збірки, залежності, порядок випуску версій та інструкція для служби підтримки.
• Інструкція для власника — як додати шар, регіон або точку самостійно, без звернення до розробника.

Кожен пункт узгоджуємо з вашою командою й передаємо у вигляді, придатному для передачі іншій команді, а не як листування в месенджері.

Кейс: промисловий маршрут без мережі — метрики до та після

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

Що ламало офлайн-режим у полі

Карта підвантажувалася потоком і відкривалася за 40–60 секунд, а без мережі не відкривалася взагалі. Точки треку накопичувалися в пам’яті пристрою й скидалися за розряджання чи перезапуску: губилося до 12% виїздів, ще 8% маршрутів приходили обрізаними на останній ділянці. Диспетчер розбирав польові записи по півдня за звітний період.

Що змінили

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

Що показали метрики до та після

Частка виїздів із повним треком зросла з 80% до 99,4%, втрачених маршрутів за сезон — нуль. Пробіг і час в угіддях рахуються за фактом, а не зі слів: звіт за обходами збирається з даних за хвилини.

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

Чим офлайн-карти відрізняються від довантаження карт по мережі

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

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

Нижче — режими, між якими реально обирають, коли обговорюють офлайн-карти або довантаження по мережі.

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

Векторні дані з OpenStreetMap укладаються в локальну базу — карта залишається компактною й читабельною на слабкому пристрої.

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

Часті технічні сумніви щодо трекінгу та карт

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

Нижче — відповіді на інженерні сумніви, які зазвичай піднімають на етапі оцінки, і те, як ми їх закриваємо.

Наскільки точний запис треку в лісі та в горах?

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

Як оновлюються офлайн-карти та шари?

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

Що буде з маршрутами за зміни пристрою?

Мітки, треки й точки зустрічей прив’язані до облікового запису й синхронізуються за появи мережі; за конфлікту перемагає пізніша правка. Додатково доступне вивантаження треків у GPX — маршрути не залишаються замкненими в одному телефоні.

Обговоримо задачу й повернемося з оцінкою та планом робіт

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

• Сценарії використання — як проходить вихід, що фіксується по дорозі, де зараз ламається процес і які дії мисливець робить найчастіше.
• Карти й шари — звідки беруться тайли, чи потрібні межі угідь, квартали, лісові дороги, рельєф; хто оновлює карти й як часто.
• Офлайн-режим — що зобов’язане працювати без мережі: навігація за маршрутом, позначки точок, запис треку; як накопичене досилається за появи зв’язку.
• Трекінг — потрібна точність і частота запису, робота у фоні, витрата батареї, поведінка за втрати сигналу й відновлення треку після збою.
• Парк пристроїв — моделі та версії системи на руках, частка старих апаратів, вимоги до автономності в полі.
• Приватність і правила — хто бачить точки й треки, як ділитися маршрутом із групою, чи потрібен експорт і в якому форматі.
• Інтеграції — датчики, нашийники, зовнішні сервіси, облікові записи угідь і обмін із уже використовуваними системами.

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