Androidアプリケーションアーキテクチャ。 パートIII-アプリケーションの主要部分

そのため、Android OSのアーキテクチャの起源と、 このアーキテクチャに実装されているテンプレート については既に説明しました。 次に、Androidアプリの構成要素について説明します。

この記事では、Androidアプリケーションのアーキテクチャーの主要な「キャラクター」を紹介します。

一般に、Androidアプリケーションは次のもので構成されます。

• Android SDKのメインクラス（ View 、 Activity 、 ContentProvider 、 Service 、 BroadcastReciever 、 Intent ）のサブクラスであるJavaクラスと、Android SDKに親を持たないJavaクラス。
• アプリケーションマニフェスト
• 文字列、画像などのリソース
• ファイル

Javaクラス

次の図は、開発者が対処しなければならないAndroid SDKのメインクラスの階層を示しています。



実際、さらに多くのクラスがありますが、これらは主なクラスです。 黄色で強調表示-開発者が直接作業しているもの（特に、それらから継承されたもの）。 残りも同様に重要ですが、直接使用されることはあまりありません。

ビューは、すべてのユーザーインターフェイスウィジェット（GUIウィジェット）の基本クラスです。 Androidアプリケーションインターフェイスは、このクラスの子孫のインスタンスのツリーです。 このツリーはプログラムで作成できますが、間違っています。 ユーザーインターフェイスはXML（レイヤーファイル、レイアウトファイル）を使用して定義され、実行時に自動的に（inflate、Android用語）対応するオブジェクトのツリーに変わります。

Activityクラスとそのサブクラスには、ユーザーインターフェイスの背後にあるロジックが含まれています。 詳細に調べると、このクラスはModel-View-ViewModel （MVVM）アーキテクチャテンプレートのViewModelに対応しています。 Activityサブクラスとユーザーインターフェイスの関係は、1対1の関係です。 通常、各Activityサブクラスには1つのユーザーインターフェイスレイヤーのみが関連付けられ、その逆も同様です。 アクティビティにはライフサイクルがあります。

ライフサイクル中、アクティビティは次の3つの状態のいずれかになります。

• アクティブで実行中-このユーザーインターフェイスはフォアグラウンド（技術的に言えば、アクティビティスタックの最上部）にあります
• 一時停止-このユーザーインターフェイスがフォーカスを失ったが、まだ表示されている場合。 この状態では、コードは実行されません。
• 終了-ユーザーインターフェイスが表示されていない場合。 この状態では、コードは実行されません。

アクティベーションコードは、対応するユーザーインターフェイスが表示され、フォーカスがある場合にのみ実行されます。 アクティビティが一時停止または完了したときにアクティビティオブジェクトとその関連オブジェクトがメモリ内にあるという保証はありません（これを覚えておくことは非常に重要です。 先ほど Androidのメモリ管理のこの点について説明しました）。

ContentProviderクラスとそのサブクラスは、MVVMアーキテクチャのモデルを表します。 ほとんどの実用的なケースでは、これは少し派手なURIベースのアクセス方法を備えたSQLiteデータベースのラッパーです。 理論的には、データベース以外に基づいてContentProviderを作成することを開発者に迷惑させることはありません。 ただし、既存のコンテンツプロバイダーのquery（）メソッドはCursorオブジェクトを返します。これは、JDBC ResultSetインターフェイスとその動作に非常に似ています。 したがって、コンテンツプロバイダーの真の目的がデータベースのカプセル化であることを誰もが疑うことはないでしょう。

Androidチームがこの設計にどのようになったのかはわかりませんが、私の意見では、2つの良い、しかし互換性のないアイデアがここにつながっています。

それが私がそう思う理由です。 コンテンツプロバイダーの基本的な考え方は、AJAXアプリケーションのアーキテクチャに基づいているようです。 AJAXアプリケーションは通常、モデルがサーバー側URIとして表されるMVVMアーキテクチャを使用します（ただし、これはデータをローカルに保存できるHTML5で変更されました）。 実際、コンテンツプロバイダーがURIを使用して要求され、MIMEタイプを使用して拡張機能を作成するという事実は、AJAXがコアであることを示しています。 GoogleのスタッフがGmail、Google Docsなどの多数のAJAXアプリケーションを作成したことを思い出してください。アイデアがAJAXアーキテクチャから借用されたことはごく自然なことです。

他の誰かが別の素晴らしいアイデアを思いついたのかもしれません。モバイルデバイス上に完全なリレーショナルデータベースを保持することは素晴らしいことです。 （これは、携帯電話が現在よりもずっと弱かった2005年頃でした）。 そして、その結果、彼らは2つの優れたアイデアを1つのContentProviderクラスに結合しました。 通常のソフトウェア開発の場合と同様に、2つの優れたアイデアを組み合わせても、必ずしも優れたアイデアが得られるとは限りません。 Androidの場合、コンテンツプロバイダーにはやや意地悪なデザインがあります。

Serviceクラスとそのサブクラスは、どういうわけか分類するのが難しいと思います。 Googleの人たちも同じ問題に直面していると思います（ドキュメントを読んでください）。 彼らの分類は基本的にこのクラスが何でないかを示しています。 個人的には、サービスはモデルのバリエーションであり、ContentProviderとはわずかに異なるユースケースを提供すると考えています。

私の意見では、Androidサービスのアーキテクチャ設計はOSGIサービスに触発されています 。

このサービスは、Androidスレッドモデルによって生じた論理的な問題の解決策として、Googleのスタッフによって作成されたと思います。

考えてみてください：アクティビティはアクティブで、ユーザーインターフェイスがフォアグラウンドにある場合にのみ実行されます。 別のアクティビティのインターフェイスが現在のアクティビティを閉じるとすぐに、現在のアクティビティが何かを実行していても、後者は停止します。 しかし、それを実行するプロセスがフォアグラウンドにない場合でも、何らかの操作を実行する必要がある場合はどうでしょうか？ アクティビティでは、これを行うことはできません。 ContentProviderには独自のライフサイクルがないため、ContentProviderを使用してこれを行うことはできません。ContentProviderを使用するアクティビティがアクティブな間のみ実行できます。

そして、ここでサービスが助けになります。 それらは、作業を行うプロセスがフォアグラウンドにない場合でも実行できます。 したがって、バックグラウンドで作業している場合でも終了する必要があるタイムストレッチ操作を実行するアクティビティを開発している場合、この操作を実装するサービスを作成し、アクティビティから開始する必要があります。

サービスにはライフサイクルもあります。 これは、一定の条件下でAndroidアプリケーションによってインスタンス化および起動できることを意味します（これについては後で説明します）。

前述したように、モデルのようなサービスには、ContentProvierよりも一般的な目標があります。 データベースを使用できますが、ContentProviderの場合のように、そのAPIはデータベースに関連していません。 ほとんどの場合、サービスは外部サーバーとの通信に使用されます。

BroadcastReceiverクラスとそのサブクラスは、Androidアーキテクチャに実装されたパブリッシャー/サブスクライバーインタラクションメカニズムの「サブスクライバー」を表します。

前の記事で相互作用のメカニズムについてはすでに説明しました。

もちろん、Android開発者は、Android SDKからクラスを拡張するだけではありません。 彼は自分のクラスを好きなように書くことができます。 ただし、これらはすべてAndoird SDKのクラスの「ヘルパークラス」にすぎません。

Androidマニフェスト

Androidマニフェストは、Androidアプリのもう1つの重要な部分です。 このアイデアは、Eclipseのプラグインマニフェストに触発されました。

AndroidマニフェストはXMLファイルであり、いくつかの機能を実行します。 Googleがそれらを説明する方法は次のとおりです。

• Javaアプリケーションパッケージの名前を定義します。 パッケージ名は、アプリケーションの一意の識別子です。
• アプリケーションのコンポーネント（アクティビティ、サービス、放送受信機、コンテンツプロバイダー）について説明します。 各コンポーネントを実装するクラス名を決定し、その機能（たとえば、処理できるIntentメッセージなど）を通知します。 これらの発表により、Androidシステムはどのコンポーネントおよびどの条件で起動できるかを知ることができます。
• アプリケーションコンポーネントを含むプロセスを定義します。
• APIの保護された部分にアクセスし、他のアプリケーションと対話するために、アプリケーションに必要なアクセス許可を宣言します。
• また、アプリケーションコンポーネントにアクセスするために必要な権限を宣言します。
• アプリケーションの実行中にプロファイリングやその他の情報を提供するインストルメンテーションクラスを列挙します。 これらの宣言は、アプリケーションの開発およびテスト中にのみマニフェストに存在します。 アプリケーションが公開される前に削除されます。
• アプリケーションが必要とするAndroid APIの最小レベルを発表します。
• アプリケーションを関連付けるライブラリーをリストします。

2番目の点に注意してください。 特定のクラスがアプリケーションのActivity、ContentProvider、BroadcastReceiver、またはServiceを拡張する場合、マニフェストに記述されるまでこのクラスは使用できません。

資源

何らかの形式の最新のGUIアプリケーションはすべて、リソースを使用します。 Androidアプリも例外ではありません。 次のタイプのリソースを使用します。

• 画像
• GUIレイヤー（XMLファイル）
• メニュー宣言（XMLファイル）
• テキスト文字列

リソースがAndroidアプリに関連付けられる方法は珍しいことです。 通常、Javaでは、リソースは文字列によって識別されます。 このような行には、たとえば、画像を含むファイルのパスと名前、またはこの行のIDなどが含まれます。 問題は、コード変換中にそのようなリンクのエラーを検出できないことです。

次の例を見てみましょう。 mybutton.pngという名前のファイルには、ボタンの画像が含まれています。 開発者はミスを犯し、コードからリソースを参照してmybuton.pngをダイヤルします。 その結果、コードは存在しないリソースを使用しようとしますが、コンパイルは成功します。 エラーはテスト中にのみ検出できます（またはまったく検出されない場合があります）。

Googleのスタッフは、この問題のエレガントな解決策を見つけました。 Androidアプリケーションをビルドすると、 R （1文字のみ）という名前の特別なJavaクラスが生成されます。 このクラスには、いくつかの静的な最終データセットが含まれます。 そのような各データセットは、個別のリソースへのリンクです。 これらのリンクは、リソースと通信するためにアプリケーションコードで使用されます。 これで、リソースへのリンク内のエラーはすべて、コンパイルプロセスで明らかになります。

ファイル

Androidアプリケーションは、いくつかの異なるファイルタイプを使用します。

• 汎用ファイル
• Dbファイル
• Opaque Binary Blob（ OBB ） ファイル （アプリケーション用にマウントできる暗号化されたファイルシステムです）
• キャッシュされたファイル

もちろん、これらはすべてLinuxファイルにすぎませんが、さまざまなAPIと個別のストレージで処理する場合にのみ、それらを個別のファイルタイプと見なすことは理にかなっています。 また、内部ストレージまたは外部ストレージに格納されているファイルからも分離されています（後者は存在しないか、いつでも消える/表示される場合があります）。

ファイルを操作するためのAPIは、アクティビティクラスとサービスクラスの派生元であるContextクラスによって実装されます。 このクラスについては、すでにここで説明しています 。

今日は以上です。 次の記事では、Androidアプリケーションのさまざまな部分がどのように相互作用するかについて説明します。

前の記事：

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

次の記事： Android Application Architecture。 パートIV-統合レベル