Androidアプリケーションアーキテクチャ。 パートIV-統合レベル

この記事では、Androidアプリケーションの一部が相互作用するさまざまなメカニズムについて説明します。 これらすべてのメカニズムを「相互作用のレベル」と呼ぶことに同意しましょう（私の知る限り、Androidのドキュメントにはこれに関する特別な用語はありません）。



前に示したように、Androidフレームワークはいくつかの相互作用パターンを実装しています。

• Intentクラスを使用したメッセージング
• IntentクラスとBroadcastReceiverクラスを使用するオブザーバー
• メソッドコールが後続する遅延バインディングは、コンテンツプロバイダー（ ContentProviders ）およびローカル（インプロセス）サービス（ サービス ）にアクセスするために使用されます
• サービスコール（AIDL）のレイトバインディングとプロセス間手続き通信 （IPC）

メッセージング

明らかに、これは開発者がAndroid向けのプログラミングを開始するときに遭遇する最初の対話メカニズムです。 アクティビティまたはサービスを起動するために使用されます 。 このメカニズムは、 Contextクラスの3つのメソッド（以前の記事の 1つで言及されていた）とActivityクラスの1つのメソッドを使用して実装されます。

• ContextクラスのstartActivity（）はアクティビティを開始します
• ActivityクラスのstartActivityForResult（）はアクティビティを開始します
• ContextクラスのstartService（）またはbindService（）は、必要に応じてサービスを開始し、それと通信します（2つのメソッドにはいくつかの違いがあります）

どちらの場合も、Intentクラスは送信されたメッセージとして機能します。



Androidは、メッセージの宛先となるアクティビティまたはサービスをどのように知るのですか？ これを行うには2つの方法があります。

• インテントは、コンポーネントの名前を明示的に示す場合があります。 このようなインテントは、明示的（ "explicitIntents"）と呼ばれます。 ターゲットコンポーネントは、setComponent（）およびsetClass（）メソッドによって決定されます。 このタイプの意図指向の相互作用メカニズムは、他のすべてとは異なり、遅延バインディングパターンを実装しません。
• ターゲットコンポーネントは、 インテントフィルターに基づく非常に珍しい意思決定メカニズムによって決定されます。

メッセージ（Intentクラスのインスタンス）を送信する場合、対話メカニズムは1つのコンポーネントのみにメッセージを配信するか、まったく配信しないことに注意してください。

パブリッシャー/サブスクライバー

パブリッシャー/サブスクライバーインタラクションメカニズムは、メッセージと同じIntentクラスを使用し、ターゲットコンポーネント定義メカニズムと同じフィルターを使用しますが、動作が少し異なります。 この場合に使用されるインテントは「ブロードキャスト」と呼ばれます。 これらの意図はBroadcastReceiverにのみ配信できます。



メッセージの送信に使用されるインテントとは異なり、単一のブロードキャストインテントを複数のコンポーネントに配信できます。



実際、Androidは2つの異なるパブリッシャー/サブスクライバーメカニズムを実装しており、それぞれに2つのバージョン（通常および「スティッキー」、「スティッキー」）があります。

• 通常のブロードキャストは、ContextクラスのsendBroadcast（）およびsendStickyBroadcast（）メソッドによって実装されます。
• 順序付きブロードキャストは、sendOrderedBroadcast（）およびsendStickyOrderedBroadcast（）メソッドによって実装されます。

まだ混乱していませんよね？



通常のブロードキャストメカニズムは、すべての適切なブロードキャストレシーバーに意図を非同期的に配信し、それらに個別に応答します。 つまり、あるブロードキャストレシーバは、別のブロードキャストレシーバがインテントに応答する方法、またはインテントが別のブロードキャストレシーバに配信される方法に影響を与えることはできません。 これは、通常のパブリッシャー/サブスクライバーテンプレートです。



順序付けられたブロードキャストメカニズムは、インテントをすべての適切なブロードキャスト受信者に順番に、つまり一度に1つだけ配信します。 したがって、各放送受信機は潜在的に次のことができます。

• 同じ意図で機能した以前の放送受信機の結果を使用する
• 必要に応じて、インテントのさらなる処理を中断します

順序付けられたブロードキャストを初期化するコンポーネントは、ブロードキャスト受信機のチェーン全体からインテントを処理した結果を受け取ることができます。



合理化されたブロードキャストは、 一連の責任テンプレートの実装です 。



スティッキー放送は、従来の放送の一種です。 違いは、コンテキストクラスのremoveStickyBroadcast（）メソッドを使用して明示的に削除するまで、インテントを使用できることです。 削除されない「スティッキー」インテントはメモリリークを引き起こすため、このタイプのブロードキャストは注意して使用する必要があることに注意してください。

意図指向の相互作用メカニズムに関する結論

説明されているすべての相互作用メカニズムは、メッセージとしてIntentクラスを使用します。 提示されているメソッドのほとんどはContextクラスによって実装されていることに注意してください。つまり、理論的にはすべてのサブクラスで使用できます。



これから、すべてのAndroidインタラクションメカニズムがIntentクラスを使用していると結論付けることができます。 しかし、これは完全に真実ではありません。

ContentProvidersの遅延バインディング

ほとんどの場合、 ContentProviderクラスは SQLiteデータベースのラッパーとして使用されます。 理論的には、データを保存/受信する他のメカニズムに使用できます。 このクラスの使用方法については、 こちらをご覧ください 。



コンテンツディストリビュータを使用する方法は多数あります。 コンテンツパーサー（通常、プロキシパターンを実装する ContentProviderClientのインスタンスまたはサブクラス）でプロキシとして機能するオブジェクトの取得が含まれます。 その他は、 Cursorクラスのインスタンスを返します。これにより、プロバイダーから返された多くのデータを反復処理できます。 いずれの場合でも、特定のContentProviderはURIで識別される必要があります（詳細については、 こちらをご覧ください）。



いずれにせよ、これは典型的な遅延バインディングパターンです。

遅延バインディングとプロセス間通信（IPC）

相互作用のメカニズムがこれで終わったと思うなら、あなたは間違っています。



ContentProviderクラスとは別に、MVVMアーキテクチャのモデルとして機能するServiceクラスがあります。 前の記事で 、同じ役割を実行する2つの異なるクラスがAndroidにあるという仮説的な理由について説明しました。

• ローカルサービスは、呼び出された同じプロセスで開始されます。 アーキテクチャ的には、コンテンツプロバイダーに似ていますが、前者には独自のライフサイクルがあり、データベースに義務的な目がないという点が異なります。 ローカルサービスにアクセスするには、遅延バインディングのバリアントが使用されます。
• リモートサービスは、呼び出されたプロセスではなく、別のプロセスで実行されます。 このようなサービスとの通信は、 AIDL （Android Interface Definition Language）と呼ばれるIPCの形式を介して行われます。

同じサービスをローカルとリモートの両方で使用できることは少しわかりにくいです。 違いは、サービスを呼び出すコンポーネントが（同じプロセス内または別のプロセス内）にある場所です。



こことここでは、サービスの使用に関する詳細を読むことができます。



前の記事：

• Androidアプリケーションアーキテクチャ。 パートI-起源
• Androidアプリケーションアーキテクチャ。 パートII-建築スタイルとパターン
• Androidアプリケーションアーキテクチャ。 パートIII-アプリケーションの主要部分

翻訳者から。 これは、Androidアプリケーションのアーキテクチャに関するVlad Nevzorovの 4つの記事の最後です。 私の助けと数晩コンピューターから気を散らさないようにしてくれた愛する妻ガリアに感謝し 、有益なコメントと発言のためにハビライザーのMonnoroch 、 Semp 、 PomanoB 、 ssidelnikov 、 So1 、 Manul 、 pravic 、およびszKarlenに感謝します。