#はじめに
###対象者
- 改定されたものの、忙しくてアーキテクチャガイドを熟読している暇などない人
- 読んでみたけども、何を言っているのか全く分からなかった人
- アーキテクチャがなぜ必要なのか分からない人
- 設計の原理原則を知りたい人
#目次
内容は、主に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レイヤーについて要約したいと思います。
##参考
https://developer.android.com/jetpack/guide?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-architecture%23article-https%3A%2F%2Fdeveloper.android.com%2Fjetpack%2Fguide