Приложение без интернета: как согласовать объединение изменений карточки

Менеджер изменил заметку в приложении без интернета. В офисе другой сотрудник исправил телефон того же клиента. Когда связь появилась, программа отправила всю старую карточку и затёрла новый телефон. Требование «приложение должно работать офлайн» не отвечает на вопрос, какие изменения сохранять при таком столкновении. Эти правила нужно согласовать до разработки.

Почему двух последних карточек недостаточно

Если локальная и серверная карточки отличаются, из самих различий не видно, кто что поменял. Нужна базовая версия: состояние, которое устройство знало перед своими изменениями. С ней можно сравнить каждую сторону. База должна относиться к тому же объекту и действительно быть общей точкой; учебная форма её происхождение не проверяет.

Идея сравнения с общим предком используется и в системах контроля версий. Документация Git описывает объединение разошедшихся изменений и остановку на неразрешённых конфликтах. Ниже не реализация Git, а собственная упрощённая модель для отдельных полей карточки. Apache CouchDB также различает обнаружение конфликта и его разрешение приложением: автоматически выбранная версия не обязательно является правильной для бизнеса.

Значения вымышлены. По phone и note можно построить бесконфликтный черновик. По address и tag форма не выбирает победителя, поэтому полная объединённая карточка не выдаётся. Это помогает увидеть, какие решения надо вынести в интерфейс, вместо скрытого правила «последний запрос перезаписывает всё».

Три сравнения для каждого поля

1. Если локальное и серверное состояния совпадают, сохранить это состояние. Оно может означать и одинаковое удаление ключа.
2. Если устройство сохранило базовое состояние, принять серверное изменение.
3. Если сервер сохранил базовое состояние, принять локальное изменение. Когда обе стороны ушли от базы по-разному, зафиксировать конфликт.

Для заметки здесь сравнивается целое значение строки. Форма не объединяет разные абзацы текста, не суммирует счётчики и не соединяет списки товаров. У таких данных другие правила. Поэтому в заказе приложения полезно разделить типы полей, а не обещать универсальное «умное объединение» всего документа.

Удаление — тоже изменение

Ключ, которого нет в JSON, отличается от ключа со значением null. Пустая строка — третье состояние, а число 0 не равно строке «0». Если локально удалить поле, пока сервер оставил его как в базе, модель принимает удаление. Если сервер одновременно заменил значение, получится конфликт удаления и изменения.

Автоматически объединённые поля ещё не гарантируют правильную карточку

Допустим, на устройстве увеличили количество товара, а на сервере уменьшили доступный остаток. Это разные поля, поэтому простой алгоритм может не увидеть полевого конфликта. Однако итоговая заявка способна нарушить бизнес-ограничение. После объединения нужны проверки всей карточки: связи полей, обязательные значения, допустимые переходы и доступные ресурсы.

Результат также нельзя записывать поверх очередного изменения сервера без проверки версии. Пока человек смотрел конфликт, данные могли снова измениться. Реальная синхронизация должна повторно проверить актуальность, обработать отказ записи и сохранить историю решения. Учебный инструмент не подключён к серверу и не выполняет эту часть процесса.

Если общей базы уже нет

Не следует объявлять одну из двух текущих карточек базовой для удобства расчёта. Это изменит смысл сравнения и может скрыть конфликт. Нужно восстановить подтверждённую общую версию из истории либо выбрать другой согласованный процесс сверки с человеком. Форма требует три состояния, но не доказывает их родство.

Что принести на обсуждение разработки

• Несколько реальных типов карточек и перечень разрешённых офлайн-действий.
• Примеры независимых правок, одновременного редактирования одного поля и удаления.
• Правила, которые должны проверяться для документа целиком после объединения.
• Ответственного за конфликт и требования к истории его решения.

Проверочная форма принимает плоские объекты: до сорока полей в каждой версии, латинские имена полей, строки, булевы значения, null и целые числа в указанном диапазоне. Вложенные документы, массивы, дробные числа и повторные ключи отклоняются. Отдельно выводятся бесконфликтная часть и все спорные поля с тремя исходными состояниями.

При заказе мобильного, настольного или внутреннего приложения в Левицкий Концепт такие примеры помогут определить границы автоматизации. Простые независимые правки можно согласовать как отдельный сценарий, а денежные операции, движение склада и смену статусов проектировать по своим правилам. Офлайн-режим станет описанным рабочим процессом, а не одной галочкой в списке возможностей.