モバイルアプリのユーザー エクスペリエンス
アプリ開発者は端末のオペレーティングシステムやユーザーの操作にはせいぎょうができないのでアプリコンポーネントは体外に依存すんな
アーキテクチャに関する共通の原則
記載通りアプリコンポーネントをデータや状態の保存につかえない
アプリがデカくなったらアプリの拡張や堅牢度を高めてテストしやすくすることが大事
Activity と Fragment の実装はデベロッパーが管理するものではないこれらのクラスは、Android OS とアプリの間のコントラクトを体現する単なる結合クラスでユーザーの操作によって簡単に破棄されるからこれらへの依存を最小限にする。
1 つの重要な原則は、UI をデータモデルで操作することです
アプリ アーキテクチャをデータモデル クラスに基づいて構築すると、アプリのテストのしやすさと堅牢性を高めることができます。
信頼できる唯一の情報源これは一か所で操作ができるとデータの保護やバグが見つけやすくなる
アプリデータの信頼できる情報源は、通常はデータベースです。場合によっては、ViewModel や UI が信頼できる情報源になります
単方向データフローここはviewModelからuiへの渡し方の話
アプリの推奨アーキテクチャ
下の二つが最低限必要
- 画面にアプリデータを表示する UI レイヤ
- アプリのビジネス ロジックを含み、アプリデータを公開するデータレイヤ
https://developer.android.com/topic/architecture/recommendations?hl=ja
これがアーキテクチャの推奨事項のページ
UI レイヤ
composeとviewModel系のこと
データレイヤ
ビジネスロジックでデータの作成、保存、変更 ex) リポジトリ クラス
ドメインレイヤ
UI レイヤとデータレイヤの間に位置するオプションのレイヤです
複雑なビジネス ロジック、または複数の ViewModel で再利用される単純なビジネス ロジックをカプセル化します
このレイヤのクラスを「ユースケース」または「インタラクタ」
特定のクラスの依存関係を収集できます。
依存関係の注入（DI）: 依存関係の注入を利用すると、クラスの依存関係を構築することなく定義できます。ランタイムには、別のクラスがこの依存関係を提供します。
サービス ロケータ: サービス ロケータ パターンでは、クラスが依存関係を作成せずに取得できるレジストリが提供されます。
アーキテクチャのメリット
優れたアーキテクチャをアプリに実装することは、プロジェクト チームとエンジニアリング チームに次のような多くのメリットをもたらします。
アプリ全体の保守性、品質、堅牢性が向上します。
アプリのスケーリングが可能になります。より多くの人々とチームが、コードの競合を最小限に抑えながら、同じコードベースで開発に寄与できます。
オンボーディングに役立ちます。アーキテクチャによってプロジェクトに一貫性がもたらされるため、新しいメンバーが速やかにチームに適応し、短時間でより効率的に作業できるようになります。
テストが簡単になります。優れたアーキテクチャでは、一般的にテストしやすいシンプルな型が推奨されます。
適切に定義されたプロセスを使用して、体系的にバグを調査できます。