web-dev-qa-db-ja.com

iOS開発用のどのパターンブックにこの特定の情報が含まれていますか？

IOS開発とObjective-Cに関する本を何冊か読んだことがありますが、それらの多くが教えているのは、インターフェイスの操作方法であり、すべてビューコントローラー内にモデルが含まれています。つまり、UITableViewControllerベースのビューにはモデルとしてのNSArray。アプリケーションの構造を設計するためのベストプラクティスが何であるかに興味があります。

特に、以下のベストプラクティスに興味があります。

  • モデルをView Controllerから分離する方法。 NSArrayスタイルの例を特定のモデルオブジェクトに置き換えるだけでこれを行う方法を知っていると思いますが、モデルが変更されたときにビューに警告する方法がわかりません。たとえば.NETでは、INotifyPropertyChangedとデータバインディングに準拠することでこれを解決し、同様にJavaを使用するとPropertyChangeListenerを使用します。
  • ドメインオブジェクトのサービスモデルを作成する方法。たとえば、架空のWidgetオブジェクトのサービスを作成して内部DBを管理し、リモートエンドポイントと通信するためのサービスを作成するための最良の方法を学びたいと思います。インターフェイスコンポーネントがwidgetUpdatedなどのイベントをサブスクライブできるように、これを行うための最良の方法を学ぶ必要があります。これらのサービスはシングルトンクラスであり、モデル/コントローラーオブジェクトに依存性が注入されている必要があります。

私がこれまで読んだ本は次のとおりです。

次の更新された本も購入しましたが、まだ読んでいません。

私はJavaおよび15年の経験を持つC＃のバックグラウンドを持っています。これらの言語で物事を行う方法の多くは、アプリケーションを開発するObjCの方法に適合しない場合があることを理解しています。

誰かが私にこの特定の主題を含むこのトピックに関するtheの本を提供できるでしょうか？

learningdesign-patternsiosobjective-c
3
Brett Ryan

Cocoa Design Patterns by ErikBuckとDonaldYacktmanは、Cocoaでさまざまなデザインパターンがどのように使用されているかを理解するための優れたリソースです。この本は数年前のもので、Cocoa TouchではなくCocoa向けに書かれていますが、2つのフレームワークは概念的に非常に似ており、iOS 5と6に追加しても、基本的なアイデア、特にあなたが求めているアイデアはほとんど変わりません。

モデルをView Controllerから分離する方法。 NSArrayスタイルの例を特定のモデルオブジェクトに置き換えるだけでこれを行う方法はわかっていると思いますが、方法がわからないのは、モデルが変更されたときにビューに警告することです。

モデルは通常、ビューと直接通信しません。コントローラーを経由する必要があります。この点については、次のようないくつかのオプションがあります。

  • Key Value Observing を使用して、ViewControllerにモデルの関連部分を監視させます。

  • notifications を使用します。

  • ユーザー入力のためにモデルが変化している場合、ビューコントローラーは、モデルの一部の側面が変化することを期待することを知っている場合があります。

  • 委任を使用します。モデルのデリゲートプロトコルを定義し、ビューコントローラーで採用します。ビューコントローラをモデルのデリゲートとして設定します。

ドメインオブジェクトのサービスモデルを作成する方法...

あなたのコメントから、モデルオブジェクトのグラフを管理する方法を探していることがわかります。 Core Data フレームワークは、オブジェクトグラフの管理と永続性を提供します。データベーステーブルにすべてを格納する方法を気にすることなく、データをオブジェクトとして簡単に操作できます。高速であり、比較的大量のデータがあっても十分に機能します。

4
Caleb

すばらしい質問です。 MVCに準拠したObjective-cアプリを構築するための最良の方法を見つけるのに苦労しましたが、ビューをモデルと同期するには、デリゲートを使用するのが最もクリーンなアプローチであることがよくあります。

したがって、モデルがネットワーク経由で何かをロードしている場合、デリゲートは次のようになります。

@protocol XXItemLoadDelegate <NSObject>
- (void) willLoadItemWithIdentifier:(NSString*)identifier;
- (void) didLoadItem:(XXItem*)item;
- (void) didFailToLoadWithError:(NSError*)error;
@end

また、ビューがビジーインジケーターを表示/非表示にし、アイテムが読み込まれたら更新する方法は明らかだと思います。

デリゲートパターンの主な欠点は次のとおりです。

  • デリゲートを設定するのを忘れている
  • モデルでデリゲートイベントを呼び出すのを忘れている
  • デリゲートを上書きする（複数のビューに通知する場合）
  • デリゲートをリセットする（たとえば、ビューが再利用される場合、デリゲートは最初にnilにする必要があります）
  • 複数のオブザーバーが必要だと判断した場合にリファクタリングするのは面倒
  • プロトコルとデリゲートメソッドに一貫した名前を付ける

これらすべての欠点にもかかわらず、私は他のアプローチよりもデリゲートの明示性を好みます。

NSNotificationsは、完全に無関係なコードの同期を維持するのに最適です。ただし、コードのトレースとデバッグが非常に困難になるため、慎重に使用する必要があることがわかりました。

KVOは、ビューをモデルに同期するためのオプションでもありますが、大規模なプロジェクトでKVOを使用した経験はあまりありません。

Cocoa Design Patternsの本はあまり気にしませんでした。それは時代遅れのようで、私が望んでいたほど実際的な情報を持っていませんでした。

本の代わりに、githubでより大きなiOSプロジェクトを読むこともお勧めします。いくつかの設計パターンが実際に動作しているのをいつでも見ることができ、いくつかの優れたトリックを学ぶことができます。例えば：

アプリセールスモバイル

3
xinsight