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

    9 часов назад
    • Желаемый бюджет до 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 - внедрение офлайн-режима с дифф-синхронизацией и шифрованием для полевого приложения инвентаризации» можно использовать как ориентир для своего брифа: что нужно сделать, какой результат нужен и какой бюджет указать.