• Android - впровадження офлайн-режиму з дифф-синхронізацією та шифруванням для польового застосування інвентаризації

    10 годин тому
    • Бажаний бюджет до 650.75 USD
    • Очікує виконавця...
  • Є внутрішнє Android-додаток для польової інвентаризації обладнання на складах та будмайданчиках. Зараз воно працює лише онлайн: сканування QR/штрих-кодів, перегляд карток, створення актів та фотофіксація. На об'єктах часто немає мережі, через що співробітники ведуть записи в сторонніх нотатках і потім переносять дані вручну. Потрібно додати повноцінний офлайн-режим із надійною синхронізацією з появою інтернету.

    Технічне середовище: Kotlin, Android 10+, MVVM, Retrofit, Room вже використовується частково, серверне API міняти не можна. Авторизація по OAuth2, access token живе 30 хвилин, refresh token доступний. Бекенд надає REST endpoints: GET /items?updatedSince=timestamp, POST /acts, PATCH /items/{id}, завантаження фото окремим endpoint. На сервері є поле version (int) і updatedAt (ISO) для сутностей Item і Act, але конфлікт-резолв на сервері відсутня.

    Що потрібно реалізувати:
    - Локальне сховище: розширити схему Room для Item, Act, Attachment, а також таблиць черги операцій (pending ops) та метаданих синхронізації. Дані (включаючи чутливі поля та шляхи до вкладень) повинні зберігатися із шифруванням на пристрої. Допустимо використовувати Jetpack Security (EncryptedFile/EncryptedSharedPreferences) та/або SQLCipher for Android, вибір обґрунтувати в коментарі до PR.
    - Черга змін: всі дії користувача в офлайні повинні записуватися як ідемпотентні операції (створення актів, зміна статусів, прив'язка фото, редагування полів), з можливістю повторного відправлення без дублів. Для кожної операції потрібен clientOperationId (UUID) та детерміновані правила повторного відправлення.
    - Синхронізація у фоні: через WorkManager (constraints: network connected, battery not low). Реалізувати двонаправлену синхронізацію: pull оновлень із сервера через updatedSince, потім push локальних операцій. Підтримати backoff, часткові помилки, мережеві таймаути та оновлення токена.
    - Вирішення конфліктів на клієнті: якщо локально змінювали Item і на сервері він теж змінився (version/updatedAt), потрібно застосувати стратегію: пріоритет у локальної зміни для конкретного набору полів (зафіксувати список), але якщо конфлікт за статусом/відповідальним - показати користувачеві екран порівняння з вибором варіанта та логуванням рішення. Екран повинен з'являтися лише для реально конфліктуючих сутностей.
    - Вкладення (фото): зберігати фото локально з чергою завантаження, переживати перезапуск програми. Обмеження: не більше 50 МБ сумарно в черзі, при перевищенні показувати зрозуміле повідомлення та блокувати додавання нових вкладень до синхронізації/видалення.
    - Телеметрія: додати локальний лог синхронізації (до файлу) з рівнями, без надсилання назовні. Лог повинен містити кількість операцій, час синка, кількість конфліктів, помилки API.

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

    Обмеження: серверне API не змінювати, нові бібліотеки додавати тільки при необхідності та з мінімальним footprint, підтримка Android 10-14, додаток має коректно працювати без Google Play Services.

    Критерії приймання (вимірні):
    1) У режимі airplane mode можна: відсканувати 30 позицій, змінити мінімум 20 полів у різних Item, створити 5 Act і прикріпити 10 фото - всі дані зберігаються локально і відображаються після перезапуску програми.
    2) Після включення інтернету синхронізація завершується без дублів: на сервері з'являється рівно 5 нових Act, у Item немає змін, всі 10 фото прив'язані.
    3) При штучно створеному конфлікті (Item змінено на сервері після останнього pull, і той самий Item змінено локально) програма виявляє конфлікт і показує екран порівняння; після вибору користувача результат збігається з обраною версією, конфлікт зникає за наступного синку.
    4) Фоновий sync через WorkManager виконується не частіше ніж раз на 15 хвилин, але ручний запуск з екрана налаштувань ініціює sync відразу.
    5) Локальні дані дійсно зашифровані: не можна прочитати вміст БД/файлів вкладень у відкритому вигляді при копіюванні з пристрою (достатньо вказати спосіб перевірки).

    Очікувані етапи: аудит поточної архітектури та схеми даних, проектування моделі синка та конфліктів, реалізація storage/queue, реалізація sync engine, UI конфліктів, тестування та стабілізація.

    Доступ надам: вихідні коди Android, Swagger/колекція запитів, тестовий стенд API, кілька тестових акаунтів і сценарії польових користувачів.
Ваша пропозиція

Ви ще не залишили пропозицію до цього замовлення.
Натисніть «Запропонувати послугу», щоб надіслати свою пропозицію.

Потрібне схоже завдання?

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

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