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

    1 місяць тому
    • Бажаний бюджет до 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, кілька тестових акаунтів і сценарії польових користувачів.
  • Як ви оцінюєте це завдання?

    Увійдіть в обліковий запис, щоб залишити свою оцінку.

    Усього оцінок: 0

Ваша пропозиція

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

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

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

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