Androidアプリケーションの構造はおおよそ次の要素から構成します。
役割 | Androidフレームワーク上の要素 |
---|---|
ビュー | レイアウトXML、カスタムビュー、カスタムレイアウト |
コントローラ | Activity |
モデル | コンテンツプロバイダ |
サービス | サービス |
一つのアプリをこれらの要素を適宜組み合わせて実現します。例えば、画面レイアウトをXMLで定義し(ビュー)、画面へのデータ表示や、画面への操作のイベント取得をActivityで定義し(コントローラ)、データをコンテンツプロバイダで管理し(モデル)、コンテンツプロバイダ内でSQLiteデータベースを読み書きするアプリを実現することができます。こうすると、自然とMVC的な構造が出来そうです。
オライリー「プログラミングAndroid」では、Network MVCという設計を紹介しており*1、
Activity -> ContentProvider -> Service
という依存関係で、MVC+ネットワークの構造を作っています。Serviceで通信を非同期に行うほか、通信で取得したデータをキャッシュしておくといった仕組みを設けられます。
一方、レイアウトXMLを使わずActivityでゴリゴリにビューを記述し、コントロールを記述し、はたまたSQLiteへのデータ読み書きをする万能Activity(一つのActivityが全てを統べる、ファットActivityやマッチョなActivityと呼ばれることも)も作れてしまいますが、これはアンチパターンになってしまいます。でも、Android入門的なサンプルの多くが万能Activityで作られていて(特定のトピックを説明するためだけにシンプルに書かれているにせよ)、それを見真似て万能Activityなアプリケーションを書いてしまうことになりかねません。
そこで、なるべくAndroid標準フレームワークに沿って作るのがよいと思います。
ところで、このActivity、コンテンツプロバイダ、サービスはそのアプリケーション(プロセス)内だけでなく、別なアプリケーションから呼び出して利用することができます。例えば、下図のようにすることも可能です。
アプリケーション1 アプリケーション2 +-------------+ +-------------+ |AlfaActivity |----------->|BravoActivity| +---+--------+ +----+--------+ ↓ | +-------------+ | |コンテンツ |<----------------+ |プロバイダ | +-----+------+ ↓ +--------+ | SQLite | +--------+
Androidでは、主なアプリケーション間の連携(通信)手段として次があります。
- 暗黙的なIntent(Activity間、IntentService)
- コンテンツプロバイダーインタフェース(クエリ、ノーティファイ)
- AIDL
- Messenger
これを使ってアプリケーション連携できるMVC的コンポーネントを組み合わせてアプリケーションを作っていくというフレームワークがAndroidなのだなぁとちょっと感心しました。