今回は業務で Android の設計について調査したので備忘録がてらつらつら書いていこうと思います。参照したドキュメントはこちらです。
モバイルアプリのユーザー体験
Android アプリでは アプリマニフェスト にアプリコンポーネントを宣言しておき、全体的なユーザー体験をどのように組み込むかを決定します。
ちなみにアプリコンポーネントにはこのようなものがあります。
- アクティビティ
- フラグメント
- サービス
- コンテンツプロバイダ
- ブロードキャストレシーバー
...etc
通信の問題だったり、インテントを使った別アプリ起動、メモリ解放のためのアプリコンポーネントの破棄などは任意のタイミング・順番でおこるため、アプリのデータや状態をアプリコンポーネント内に保存してはいけません。
また、アプリコンポーネントは互いに依存せず、独立した状態を保つ必要があります。
アーキテクチャに関する一般的な原則
関心の分離
これが最も重要です！
アクティビティやフラグメントにすべてのコードを書くのは間違い。
そうではなく、UIベースのクラスには UIやOSとのやり取りを処理するロジックのみ含めるなどしてシンプルにしておきます。このようにしておくとライフサイクルに関連する多くの問題を回避することができます。
アクティビティやフラグメントを直接管理しているのは開発者ではなく、OSです。
そのため、これらのクラスへの実装は必要最低限にすべきです。
UIをモデルで操作する
永続モデル がおすすめ。
モデルとは、アプリのデータを処理するコンポーネントです。モデルはアプリコンポーネントから独立しているため、ライフサイクルの影響を受けません。
永続モデル が好ましい理由としては次の2点です。
- OSがアプリを破棄してリソースを開放しても、ユーザーのデータが失われない
- ネットワーク接続が不安定、または利用不可の場合でもアプリが動作し続ける
アプリの推奨アーキテクチャ
ここからはE2Eのユースケースを通じて、アーキテクチャコンポーネントを使用したアプリ構築方法について記述します。
ユーザープロフィールを表示するUIを作成する場合 （データ取得にはバックエンドのREST APIを使用）
ポイント
- 各コンポーネントはその1レベル下のコンポーネントにのみ依存している
- 一貫性のあるユーザー体験が提供できる
この設計ではリポジトリが永続データモデルとリモートのバックエンドデータソースに依存している構造になっています。
この状態だとユーザーが数分後にアプリに戻っても、はたまた数日後に戻っても、アプリがローカルに保存しているユーザー情報を表示できます。また情報が最新でない場合はバックグラウンドでデータの更新を開始できます。