UIApplicationシングルトンが定義済みの時間にデリゲート メソッドを呼び出せるように、アプリケーション デリゲートを使用する代わりに、単にサブクラス化することの利点と欠点は何UIApplicationですか? (更新:なぜ iOS アーキテクチャは、UIApplicationさまざまなメソッドをサブクラス化してオーバーライドすることでアプリケーションを作成できるようにするのではなく、アプリケーション デリゲートを使用するのですか?)
これは、新しいUIViewコントロールを作成するときに、サブクラス化するUIView( update:またはサブクラス化するUIViewController) ためです。では、なぜアプリケーションの場合、サブクラス化せずUIApplicationに委譲を使用するのでしょうか?
繰り返しますが、ドキュメントから：
サブクラス化の注意事項
UIApplication をサブクラス化して sendEvent: または sendAction:to:from:forEvent: をオーバーライドし、カスタム イベントとアクションのディスパッチを実装することを決定する場合があります。ただし、このクラスを拡張する有効な必要性はほとんどありません。アプリケーション デリゲート (ほとんどの場合、UIApplicationDelegate で十分です。UIApplication をサブクラス化する場合は、サブクラスで何を達成しようとしているのかを十分に確認してください。
開発者が通常そうしない理由は、その必要がないからです。UIApplication は、ほとんどの場合、必要に応じて機能します。特定の事前定義されたケースで何をすべきかについてのヒントが必要なだけです (デリゲートがあるのはそのためです)。一方、UIView は非常に汎用的であり、そのまま使用されることはないと思います。これはおそらく、iOS の世界で最もカスタマイズされたクラスです。
UIApplication クラスは、iOS で実行されているアプリケーションの制御と調整の一元化されたポイントを提供します。
すべてのアプリケーションは、UIApplication (または UIApplication のサブクラス) のインスタンスを 1 つだけ持つ必要があります。アプリケーションが起動されると、UIApplicationMain 関数が呼び出されます。他のタスクの中で、この関数はシングルトン UIApplication オブジェクトを作成します。その後、sharedApplication クラス メソッドを呼び出して、このオブジェクトにアクセスできます。
では、「なぜ UIApplication をサブクラス化しないのですか?」とはどういう意味ですか? Apple は、サブクラスで何を実装するかについてのメモも提供しています。
標準クラスだけでの委任とシングルトンの使用に関する質問については、答えは簡単です。アプリケーションは、イベントを受信してディスパッチし (外部およびシステム関連の両方)、マルチタスクを処理し、システムと緩やかにやり取りするための共通の方法を提供する必要があります (つまり、 main.m にアプリ デリゲートへの参照が含まれている理由)。
委任はコア デザイン パターンです。これにより、プログラムの部分間で責任を分離できます。たとえば、画面に描画するプログラムの部分は、おそらくデータベースと通信してはならないという考えです。これにはいくつかの理由があります。
パフォーマンス: 画面に描画する同じオブジェクトがデータ ストアにアクセスすると、パフォーマンスの問題が発生します。限目。完全停止。
コードのメンテナンス: 適切にモジュール化されたコードを概念化するのは簡単です。(私の場合はともかく)
柔軟性: コード内でサブクラス化するのは素晴らしいことですが、あらゆる種類の望ましくない動作をするモノリシックなクラスに出くわすまでは。動作をオーバーロードして無効にする必要があり、プロパティの名前空間が汚染される可能性があります。代替案として、カテゴリ、委任、およびブロックを試してください。
そうは言っても、サブクラス化が適切な状況に実際に遭遇しました。一定期間操作されなかった場合に特定の設定メニューを自動的に閉じたいキオスク アプリがあります。そのためには、アプリ全体でタッチ イベントにアクセスできる必要がありました。をサブクラス化UIApplicationし、オーバーライドしsendEvent:ました。エッジケースですが、それは適切でした。ソロモン王が伝道者の書で言い換えたように、「太陽の下では、すべてのものには時間と場所があります。
プログラムの作成、読み取り、反復、保守を容易にするために、特定のプラクティスに従うことを強くお勧めします。多くのクラスをサブクラス化することは大歓迎です。宣伝どおりに実行される限り、Apple はコードが貧弱であることを理由にアプリを拒否することはありません。とはいえ、特定の実証済みの実践に従わない場合は、自分の墓を掘っていることになります。サブクラス化は本質的に悪いことではありませんが、カテゴリ、プロトコル、およびブロックは非常に魅力的であるため、いずれにしてもそれらを優先します。
UIView サブクラスが行う必要があるかもしれない多くの特殊なことがあります。UIScrollView、UIImageView、UIWebView などについて考えてみてください。それらの内部動作がどれほど劇的に異なる必要があるかを考えてみてください。それでも、それらはビュー階層に参加する必要があるため、サブクラス化は理にかなっています。
一方、UIApplication は、アプリケーション全体のイベント、通知、URL を開く、ウィンドウへのアクセス、およびその他の一般的なもののための中心的なハブです。通常の状況では、アプリはUIApplicationDelegate プロトコルが提供するものを知る必要があるだけです。
UIApplication の概要からのメモでは、 UIApplicationをサブクラス化する理由の 1 つについて説明しています。
UIApplication をサブクラス化して sendEvent: または sendAction:to:from:forEvent: をオーバーライドし、カスタム イベントとアクションのディスパッチを実装することを決定する場合があります。ただし、このクラスを拡張する有効な必要性はほとんどありません。アプリケーション デリゲート (ほとんどの場合、UIApplicationDelegate で十分です。UIApplication をサブクラス化する場合は、サブクラスで何を達成しようとしているのかを十分に確認してください。
ただし、これは非常に特殊な場合にのみ必要です。