はじめに
対象者
- 改定されたものの、忙しくてアーキテクチャガイドを熟読している暇などない人
- 読んでみたけども、何を言っているのか全く分からなかった人
- アーキテクチャがなぜ必要なのか分からない人
- 設計の原理原則を知りたい人
目次
内容は、主に3つです。
1. 設計の必要性
2. Googleが推奨している設計パターン
3. ベストプラクティス集
1.設計の必要性
UXの注意点
Androidアプリケーションは、ユーザーとAndroidOSの事を考えて開発する必要があります。
ユーザーは、デバイス上のアプリを短時間の中で多くの操作を行うことがある。
モバイルのリソースは限られているため、AndriodOSの最適化処理によっていつでも強制終了する可能性がある。
これを想定した時に回避すべきなのは
- コンポーネントがデータを持っていること
- コンポーネント同士が依存関係にあること
原理原則について
そのために、大事なことは「責務の分離」
関心の分離
例えば、Activity/FragmentはUIの描画または、エントリポイントだけを担当します。
これにより、コンポーネントが独立して機能することに繋がり、さらに、テストのしやすさにも繋がる。
データモデルからUIを駆動する
AndroidOSによるプロセスの最適化によって解放されたり、ユーザーによっては通信環境が悪かったりと状況は様々。
そこで、データは確実に保存/保持して、そこからUIを設計していきましょうということを言っています。
2. Googleが推奨している設計パターン
さて、どのように責務の分離をしていくのが良いのかGoogleの見解を見てみましょう。
UI Layer
データの表示を担当
UI elements
「整形」
データをレンダリングをして、表示させます。
例）ViewやJetpackCompose
State holders
「保持」
UIに関するデータやロジックを保持します。
例）ViewModel
Data Layer
「公開」
データを不変な値で持ち、アプリに一貫したデータを他のレイヤーに公開する役割。
Repository
「一元化」
データソースへのアクセスを一元化します。
（UI LayerからData Layerへのエントリポイント）
UI Layerは、データがどこからきているかを知りません。
Data Sources
「操作」
データソースへの読み書きを行います。
つまり、アプリとデータソースとの仲介役ともいえます。
一つの情報源につき、一つのデータクラスを定義するのが良いです。
Domain Layer
「集約」
いわゆる、ユースケース。
ViewModelの大量発生によるビジネスロジックの重複の回避などを担当。
ここは、optionとあるので必要に応じて責務を分けるのが良い。
3. ベストプラクティス集
飛ばしましたが、依存関係を提供してくれるクラスを定義することでスケーリングに繋がります。
Androidでは、Hiltを用いることが推奨されます。
コンポーネントは破棄されやすいので、そこでデータを保持しないこと
Androidクラスへの依存を減らす（？：良く分からなかった・・）
モジュールは、明確に分けて、なるべく独立させる
車輪の再発明で労力を無駄にしない（Jetpack使ってね！むふふ・・）
単体テスト可能にする
通信状況が悪い時でもUXを維持するために、ローカルDBを出来る限り最新に保つ
おわりに
いかがだったでしょうか。
次回は、UIレイヤーについて要約したいと思います。