1

私は.NETWebアプリケーションのバックグラウンドを持っており、iOSの開発を始めたばかりです。私のアプリの初期設計は、NSNotificationCenterを中心にしています。NSNotificationCentreに到達することが初心者の一般的な間違いである方法を説明するさまざまな投稿を見るまで、私はこれにかなり満足していました。

これが私が対処しようとしている問題の単純化されたバージョンです:

私のアプリケーションは、Webサービス呼び出しを使用して入力されたメッセージのリストを表示しようとしています。Facebookメッセージングを考えてみてください。

アプリが最初に読み込まれると、サーバーからメッセージのコレクションがプルされ、ユーザーにテーブルに表示されます。ユーザーは(APIを介して返送される)新しいメッセージを追加でき、アプリはフィードに追加された新しいメッセージに関するプッシュ通知を受信できます。

メッセージがディスクに永続化されることはないので、モデルにPOCOを使用して、物事を単純にします。

メッセージフィードビュー(ストーリーボード内)への入力を担当するMessageFeedControllerがあります。また、現在取得されている値を格納し、さまざまなメソッドを持つメッセージフィードモデルもあります。

  • (void)loadFromServer;
  • (void)createMessage:(DCMMessage *)メッセージ;
  • (void)addMessage:(DCMMessage *)メッセージ;
  • (NSArray *)メッセージ;
  • (int)unreadMessages;

私が持っている現在の実装はこれです:

ユースケース1:初期ロード

  1. ビューが最初に表示されると、「loadFromServer」メソッドが呼び出されます。これにより、メッセージコレクションにデータが入力され、NSNotificationCenterイベントが発生します。
  2. コントローラはこのイベントを監視し、受信するとテーブルビューにデータを入力します

ユースケース2:新しいメッセージ

  1. ユーザーが[追加]ボタンをクリックすると、新しいビューが表示され、メッセージを入力して[送信]をクリックすると、ビューが閉じられます。
  2. これにより、APIを呼び出すモデルのcreateMessageメソッドが呼び出されます
  3. 応答があると、モデルはNSNotificationCenterイベントを発生させます
  4. もう一度、MessageFeedControllerはこのイベントをリッスンし、テーブルに再入力します

ユースケース3:プッシュメッセージ

  1. アプリが開いている間にプッシュ通知が受信され、新しいメッセージの詳細が示されます
  2. AppDelegate(または他のクラス)は、モデルのaddMessageメソッドを呼び出して、モデルをコレクションに追加します
  3. 繰り返しになりますが、MessageFeedビューが開いていると仮定すると、再入力されます

3つのケースすべてで、MessageFeedビューが更新されます。これに加えて、BadgeManagerは、アプリアイコンバッジとタブバーバッジを設定する責任があるこれらのイベントもリッスンします。どちらの場合も、バッジ番号は未読メッセージの数に関連しています。

別のビューが開いていて、これらのイベントをリッスンしている可能性もあります。このビューにはメッセージの要約が保持されているため、コレクションがいつ変更されるかを知る必要があります。

そうです、私に固執してくれてありがとう、私の質問は次のとおりです。これはNSNotificationCentreの有効な使用法のように見えますか、それとも誤用しましたか?

私が懸念していることの1つは、メッセージテーブルの再入力の途中でメッセージコレクションが変更された場合にどうなるかが100%わからないことです。これが発生しているのを確認できるのは、新しいメッセージに関するプッシュ通知を受信した場合のみです。この場合、とにかくNSNotificationに基づいて行動する前に、テーブルの作成を終了する必要がありますか?

ご協力いただきありがとうございます

ダン。

4

3 に答える 3

3

つまり、メッセージ リストが更新されるたびに通知を投稿しています。これは NSNotificationCenter の完全に有効な使い方です。

別のオプションは、Key-Value Observingを使用することです。

コントローラー (および他のユーザー) は、"messages" プロパティにオブザーバーとして登録でき、そのプロパティが変更されるたびに通知されます。モデル側では、KVO を無料で入手できます。という名前のメソッドを呼び出すだけでsetMessages:、KVO 変更通知がトリガーされます。通知を手動でトリガーすることもできます。必要に応じて、追加、削除、または変更されたアレイのインデックスを KVO 通知に含めることができます。

KVO は、この種の変更通知を行うための標準化された方法です。Cocoa Data Bindingを使用して OS X アプリを実装する場合は特に重要です。

NSNotificationCenter は、各通知に追加情報をバンドルできるという点でより柔軟です。

メッセージ リストがメイン スレッドでのみ更新され、対応する変更通知を投稿しない限りメッセージ リストが変更されないようにすることが重要です。コントローラは、最上位のビュー コントローラでない場合や画面上にない場合は常に、これらの通知を無視するように注意する必要があります。viewWillAppear:で変更通知に登録し、 で登録解除することは珍しくありませんviewWillDisappear:

于 2012-11-19T17:04:40.780 に答える
1

NSNotifications受信者コードがポストされるとすぐに同期的に実行されるため、再入力中の新しいメッセージはその実行キューの後ろに追加されます。全体として、私には有効に思えますし、View Controller とモデルの間の適度な分離が保たれています。

同じ情報の到着をリッスンする可能性が高いクラスの数に応じて、デリゲート パターンを使用し、デリゲート オブジェクトのディクショナリを保持することもできますが、個人的には、これがそれほどうまくスケールするようには感じません。また、クラッシュを避けるためにページの割り当てが解除された場合は、デリゲートを nil-out する必要があります。要約すると、あなたのアプローチは私には良いようです。

于 2012-11-20T12:17:32.453 に答える
1

私の意見では、デリゲート プロトコル パターンを使用することは、このシナリオにより適しています。アプリケーション内の多くのビュー コントローラーで「API レイヤー」を使用する必要があるシナリオを考えてみましょう。別の開発者があなたのコードを紹介された場合、彼らはプロトコルのようなクリーンな「インターフェース」に従うだけでなく、notificationcenter のサブスクリプションを探す必要があります。

そうは言っても、コードは問題なく動作し、これは通知センターの有効な使用法です. プロトコルベースのアプローチを使用することは、「よりクリーンな」コードに対する私の個人的な好みです。iOS SDK 自体を見回すと、Apple 自身がプロトコルを使用し、通知を使用するシナリオが表示されます。プロトコルを理解して使用する方が、通知のために何を聞く必要があるかを掘り下げて判断するよりもはるかに簡単だと思います.

于 2012-11-19T17:07:18.357 に答える