0

一般的なシナリオは、基になるモデルを追加または編集できるビューを用意することです。 が nilinitWithObject:(MyManagedObject*)objectの場合は、単純に を使用してビューをソースし、新しいビューを作成できます。object

ManagedObjectContextビューを離れるときに、 が汚れているかどうかを尋ねることができますが、objectが変更されたために汚れているのか、それとも他のobjects場所で変更された可能性のある他のものが原因で汚れているのか、どうすればわかりますか?

また、ユーザーにcancelオプションを提供したい場合rollback、現在のビューのみを変更するにはどうすればよいでしょうか (また、このビューで新しく作成されobjectた場合は削除しますか?)object

複数の を使用することをお勧めしますManagedObjectContextか? (ビューごとに 1 つ? -- この場合、同期が問題になる可能性がありますね?) または、UndoManager?を使用する必要があります。これを使用して達成できますundoGroupsか?

4

1 に答える 1

2

私が知っている一般的な方法は3つあります。そして間違いなく、私は他の人々がこれにどのように対処したかを投稿するのを聞きたいです。

グループの元に戻す 詳細ビューコントローラーをモーダルに（保存およびキャンセルオプションを使用して）表示する前に、元に戻るグループを作成してから、管理対象オブジェクトコンテキストで管理対象オブジェクトインスタンスを作成し、予備セットアップを行います。

保存とキャンセルのデリゲートメソッドで、undoグループを終了し、cancelでundoNestedGroupも実行します。

良い例：編集を簡単に元に戻すことができます。悪い例：キャンセルしたくない特定のアクションがある場合、それは非常にトリッキーになります。言い換えれば、それはオールオアナッシングのアプローチをキャンセルします。

手動処理 ​​これは、個々の編集を追跡するのが非常に難しいため、新しいアイテムを追加するときに非常に実行可能です。これは基本的に、キャンセルのデリゲートメソッドで、詳細ビューコントローラを表示する前に追加したことがわかっているオブジェクトを削除することを意味します。

ドラフトコンテキスト これは、メインコンテキストにマージして戻すか、すべての変更を破棄する別の管理対象オブジェクトコンテキストインスタンスを作成することを意味します。あなたが言ったように、マージ部分は多少苦痛かもしれませんが、それは完全に実行可能です。アプローチされた元に戻るグループと比較して、これには、保存した変更のみをマージするという利点があります。したがって、まだ少し注意が必要ですが、どの変更を保持し、どの変更をキャンセルするかをより適切に微調整できます。

iOS5では、Appleはネストされたコンテキストを追加しました。このコンテキストでは、詳細ビューコントローラが使用する子コンテキストを簡単に作成し、保存するか破棄することができます。コンテキストのマージを処理するために追加のコードは必要ありません。

良い例：保存する準備ができるまで、すべての変更からメインコンテキストに影響を与えないようにします。悪い例：iOS5より前に実装するのはより複雑です（これは素晴らしいネストされたコンテキストを導入します）。

よろしくお願いします、

sven。

于 2012-05-27T08:49:03.923 に答える