Отмена редактирования: NSUndoManager или отдельный NSManagedObjectContext для редактирования?

Question

У меня есть View Controller, который управляет видом, который всегда отображается в режиме редактирования. По сути, это представление в виде таблицы, аналогичное представлению контактов в приложении «Контакты» Apple. Модель под моим представлением представлена ​​двухуровневым графом объектов, состоящим из корневого объекта - назовите его R - с отношением ко-многим к дочернему объекту C. Теперь R - это большой объект (он имеет более 20 атрибутов, все редактируемые, но не обязательные). По умолчанию R имеет n дочерних элементов (n является настраиваемым значением), но дочерние объекты можно добавлять и удалять в коллекцию R из моего представления редактирования, а атрибуты C могут быть отредактированным также. Обратите внимание, что C объекты включают атрибуты для метаданных изображения, поэтому могут быть изображения, выбранные и связанные с моделью при редактировании.

Редактирование R и его дочерних элементов выполняется через основную форму представления таблицы, а также из «вторичных» представлений, к которым я перемещаюсь (назад и вперед) для сбора необходимой информации, в зависимости от случая.

Мой вопрос: как бы вы реализовали «Отменить все правки» в этой ситуации, то есть, как я должен изолировать все свои правки, чтобы легко вернуться к состоянию до редактирования? Используя NSUndoManager с моим основным NSManagedObjectContext? Имеете отдельный NSManagedObjectContext для редактирования? Каковы будут компромиссы для каждого?

Мне плевать на redo. Я ищу идею / решение, которое позволило бы найти баланс между объемом памяти, используемой при редактировании, и возможностью сохранять данные пользователя, если приложение было прервано во время редактирования.

Спасибо за все ваши идеи.

Answer 1

Я бы посоветовал против дизайна, который имеет одинаковую функцию редактирования в двух разных видах.Каждое представление должно представлять объекты другого объекта / класса модели данных и поэтому должно иметь разные редакторы и отменять управление.

Приложение показывает, как это делается.Вы можете удалить весь контакт в главном табличном представлении и отдельные атрибуты контакта в подробном представлении.Изменения в каждом представлении фиксируются, когда представление исчезает.Такая настройка не только значительно упрощает управление, но и позволяет пользователю лучше понять, какие именно изменения они вносят.

Если вы хотите придерживаться своего первоначального дизайна, я бы предложил сохранить стек отмены основного вида таблицы до тех пор, пока мастер не будет полностью выгружен, т.е. не при загрузке подробного вида.

Answer 2

Я пришел к выводу здесь , что для NSUndoManager для правильной работы с базовыми данными это должно быть сделано в дочернем контексте.Поскольку дочерний контекст дает вам возможность «Отменить все изменения», вам также не нужно NSUndoManager.Следовательно, каждый отменяемый контроллер представления должен выполнять свою работу в дочернем контексте. Это означает, например, что контроллер A будет использовать дочерний элемент контекста документа, а если он перейдет к контроллеру B, то будет использоваться дочерний элемент контекста A (дочерний элемент дочернего контекста документа).Если пользователи нажимают Сохранить, контекст сохраняется, который автоматически передает изменения до родителя.Если пользователи нажимают Отмена, контекст отбрасывается, игнорируя изменения.Единственное осложнение связано с приложением для iPad, где A и B могут быть видны и пользователь нажимает кнопку Сохранить на A (но это, вероятно, просто плохой дизайн).