С какими проблемами синхронизации вы сталкивались
Что проверяют
Был ли у вас офлайн по-настоящему или приложение всегда жило при хорошей сети. Вопрос про опыт, поэтому ждут историю: что именно разъехалось, как вы это заметили и какую стратегию выбрали, а не перечисление технологий.
Как отвечать
Возьмите один случай и разберите его по узлам, которые встречаются в любой синхронизации:
- конфликт правок. Один объект изменён на двух устройствах. Варианты: побеждает последняя запись, побеждает версия с большим номером ревизии, или поля сливаются по отдельности. Выбор объясняется ценой ошибки: заметку слить можно, остаток по счёту нельзя;
- время. Часы на устройстве переводятся пользователем, поэтому сравнивать нужно серверную отметку или счётчик ревизии, а не локальное время;
- очередь операций. Изменения без сети копятся журналом и повторяются при её появлении, каждая операция с ключом идемпотентности, иначе повтор после таймаута создаёт второй объект;
- идентификаторы. Созданная офлайн запись живёт с временным идентификатором, после отправки приходит серверный, и все ссылки на неё надо переклеить;
- удаление против правки. Мягкое удаление с отметкой решает спор, жёсткое оставляет клиент с записью, которой уже нет.
Отдельно скажите про фоновое слияние: в Core Data изменения приезжают из фонового контекста, и интерфейс обязан быть готов обновиться в любой момент.
Где спотыкаются
Отвечают, что взяли готовую синхронизацию платформы и проблем не было. Вопрос как раз про грабли, и такой ответ читается как отсутствие опыта.
Второе: доверяют времени устройства. Достаточно одного пользователя с часами, убежавшими вперёд, чтобы его правка побеждала всегда, а чужие изменения молча пропадали.
Третье: тянут всё при каждом запуске. Полная выгрузка отлично работает на тестовом аккаунте с десятком записей и превращается в минуту ожидания у того, кто пользуется приложением год.