Определите, что именно считается записью
Для учебного журнала достаточно идентификатора занятия, даты, названия и введённой длительности. Сначала задайте правила полей: обязательность, допустимый формат и единицы. Например, пустую длительность нельзя молча считать нулём, если эти состояния имеют разный смысл. Идентификатор нужен, чтобы отличать изменение существующей записи от создания новой. В базе данных этому соответствует ключ строки; некоторые хранилища также позволяют задавать ограничения уникальности. Но совпадение названия и даты не всегда означает дубликат: человек мог провести два разных занятия. Поэтому правило идентичности должно следовать смыслу события, а не удобству сравнения текста.
Разделите локальное сохранение и передачу на сервер
В приложении, рассчитанном на работу без сети, данные можно сначала сохранить на устройстве, а затем отдельно синхронизировать. Экран должен различать эти результаты. Сообщение о локальном сохранении не подтверждает, что запись уже доступна на другом устройстве. Если передача не удалась, полезно оставить понятное состояние ожидания и возможность повторной попытки согласно выбранной архитектуре. При чтении журналу нужен определённый источник актуальных данных, например локальная база, обновляемая через слой работы с данными. Иначе после возврата на экран разные части приложения могут показывать несовместимые версии одной записи. Возможные конфликты между устройствами требуют отдельного правила разрешения.
Проверяйте переходы, а не только картинки
Представим вымышленную запись о прогулке длительностью двадцать минут. После подтверждённого локального сохранения пользователь закрывает приложение и открывает его снова. Ожидаемый результат: в журнале одна запись с тем же идентификатором. Теперь проверим двойное нажатие. На уровне интерфейса можно временно исключить повторное действие, но этого недостаточно для всех повторов операции. На уровне данных тоже нужна определённая обработка одинакового запроса или повторного сохранения той же записи. Название кнопки не решает эту задачу. Заранее опишите, когда создаётся новое событие, когда обновляется прежнее и какие сведения сохраняются при ошибке.
Попробуйте на практике
Составьте сценарии проверки учебного журнала на бумаге. Используйте только вымышленную запись о прогулке и не вводите личные сведения о здоровье.
- Опишите поля записи и присвойте ей условный идентификатор З17. Укажите, что означает пустая длительность и в каких единицах хранится заполненное значение.
- Запишите последовательность: ввод, нажатие сохранения, подтверждение локальной записи, закрытие и повторное открытие приложения. Для каждого шага укажите видимое состояние и ожидаемые данные.
- Добавьте сценарий отсутствия сети после локального сохранения. Разделите подписи сохранено на устройстве и передано на сервер, обозначив неподтверждённую передачу.
- Проверьте повторное нажатие и повторную попытку передачи. Опишите ожидаемое число записей и правило, которое позволяет распознать повтор той же операции.
Как проверить результат. Во всех сценариях должно быть понятно, где находятся данные, какое подтверждение уже получено и что ещё ожидается. Для одного успешно сохранённого события повтор действия не должен без объяснения создавать второе занятие.
Частые вопросы
Можно ли начать без облачной синхронизации?
Да. Локальный журнал является самостоятельным учебным вариантом. Тогда интерфейс и описание возможностей должны прямо соответствовать хранению на устройстве, без обещания доступности данных на других устройствах.
Нужно ли сразу рассчитывать калории и эффективность тренировок?
Нет. Такие показатели требуют отдельного обоснования и могут создавать ложное впечатление точности. Для первого прототипа полезнее проверить корректность пользовательских записей, их сохранение и восстановление.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.