Часть табличного представления

В части табличного представления все просто; проблемы могут возникнуть в части источника данных. Чтобы поддержать перемещение строк, реализуйте метод (прежде чем разрешать пользователю переставлять ячейки, представление проверяет, реализован ли этот метод). В режиме редактирования сбоку от ячеек отображается маркер перемещения. При перемещении строки вызывается ваш метод, который предоставляет объекты IndexPath для начальной и новой позиции строки. Чтобы новый порядок строк сохранился, необходимо обновить источник данных. Вы можете реализовать метод tableview:canMoveRowAtlndexPath, чтобы разрешить перемещение только для отдельных строк. В делегате можно реализовать более точный контроль за перемещением строк, например запретить пользователям перемещать ячейки в определенную секцию.

А если я не хочу, чтобы пользователи могли удалять строки? Можно ли при этом разрешить редактирование для некоторых строк?

Безусловно. Реализуйте tableview:can tRowAtIndexPath: и верните NO для тех строк, редактирование которых должно быть запрещено.

При редактировании рецепта мы заменяем объект в массиве. А если в приложении имеется другое представление, в котором хранится ссылка на оригинал?

Хороший вопрос. В двух словах, у вас возникнут проблемы, как бы вы ни старались их избежать. Если другое представление хранит ссылку на удаленный объект, ничего страшного, ведь счетчик ссылок не превышает 1 и объект не будет уничтожен при удалении из массива. Однако другое представление не «увидит» изменений, внесенных пользователем, так как они хранятся в новой версии словаря. Даже при наличии доступа к старому словарю оно не узнает об изменении данных. У проблемы существует несколько решений. Первый вариант — изменение кода, при котором исходный объект остается в массиве и изменяется «на месте». Далее вы следите за тем, чтобы другие представления обновлялись в viewWillAppear. Другое решение — отправка нестандартного оповещения об изменении массива или конкретного элемента. Заинтересованные представления регистрируются для получения этих оповещений.

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

Это не самое эффективное решение, поскольку оно требует поиска объекта в массиве и его удаления перед повторной вставкой, однако мы выбрали его именно ради ясности кода. Впрочем, массив придется сортировать заново, так как название рецепта (и его место в алфавитном порядке) могло измениться при реагировании.

Мы разместили кнопку редактирования в левой части навигационной панели. А как же кнопка «назад»? Ведь она обычно располагается именно здесь?