はじめに
Jetpack Composeについて学びたいと思ったので、勉強がてら名刺アプリを個人開発してみました。その時に検討した内容を備忘録的に書いていきます。
この記事では、フォルダ構成検討時に学んだこととを書いてます。（時間があれば他のことも書いてみる予定）
アーキテクチャーとフォルダ構成
Kotlinは、MVVM（Model/View/ViewModel）が主流のようなのでそのまま採用します。
ただ、UIロジックを分離させないとViewModel層がかなり肥大化するので、そこを考慮した上でフォルダ構成を考えてみました。
フォルダ構成
/app
├── /src
│ ├── /main
│ │ ├── /java/com/example/app
│ │ │ ├── /data
│ │ │ │ ├── /model
│ │ │ │ │ └── BusinessCard.kt
│ │ │ │ ├── /repository
│ │ │ │ │ └── BusinessCardRepository.kt
│ │ │ │ └── /network
│ │ │ │ └── BusinessCardNetwork.kt
│ │ │ ├── /domain
│ │ │ │ └── /usecase
│ │ │ │ └── RegisterBusinessCardUseCase.kt
│ │ │ ├── /ui
│ │ │ │ ├── /screen
│ │ │ │ │ ├── /home
│ │ │ │ │ │ ├── HomeScreen.kt
│ │ │ │ │ │ └── HomeViewModel.kt
│ │ │ │ │ ├── /detail
│ │ │ │ │ │ ├── DetailScreen.kt
│ │ │ │ │ │ └── DetailViewModel.kt
│ │ │ │ │ └── /profile
│ │ │ │ │ │ ├── ProfileScreen.kt
│ │ │ │ │ │ └── ProfileViewModel.kt
│ │ │ │ └── /component
│ │ │ │ ├── CustomButton.kt
│ │ │ │ └── CustomCard.kt
│ │ │ ├── /di
│ │ │ │ └── AppModule.kt
│ │ │ ├── /navigation
│ │ │ │ └── AppNavigation.kt
│ │ │ ├── /util
│ │ │ │ └── Constants.kt
│ │ │ └── MainActivity.kt
│ │ └── /res
│ │ └── /image
│ │ └── /icon
│ │ └── /values
フォルダごとの役割
ここではそれぞれの役割について簡単に説明します。
Data層
| フォルダ名 | 説明 |
|---|---|
| model | データ型を管理する |
| repository | データの取得先・取得方法を管理する |
| network | API通信などを管理する |
Domain層
| フォルダ名 | 説明 |
|---|---|
| usecase | ビジネスロジックを管理する |
UI層
| フォルダ名 | 説明 |
|---|---|
| screen | 画面を管理する同じ階層にViewModelファイルも配置する |
| component | ボタンやダイアログなどのパーツを管理する |
DI層 (Dependency Injection)
| フォルダ名 | 説明 |
|---|---|
| di | 依存性の注入（Repository、ViewModelなどをまとめて組み立てる） |
Navigation層
| フォルダ名 | 説明 |
|---|---|
| navigation | 画面遷移を管理する |
Util層
| フォルダ名 | 説明 |
|---|---|
| util | よく使う定数や関数を管理 |
Res層
| フォルダ名 | 説明 |
|---|---|
| image | 画像を管理する |
| icon | アイコンを管理する |
| values | 色や文字サイズを管理する |
フォルダ構成検討時に学んだこと
１、UI 層は「画面」と「コンポーネント」を分離する
UI のロジックは Composableアノテーションを使って呼び出すらしいので、再利用できるパーツは componentフォルダに分離しておくことで「画面」と「ロジック」をスッキリさせました。
例：Composeアノテーションの使い方
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
MyApplicationTheme {
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
HomeScreen(Home().text())
}
}
}
}
}
@Composable
fun HomeScreen(text: String) {
Text(text = text)
}
２、ViewModelの状態管理にStateとFlowを使う
Stateは聴き馴染みがありましたが、Flowは初めて知りました。
State: 現在の状態を表すオブジェクト。UIがどのようなデータを表示するか、またはどのような状態（読み込み中、エラー中、成功した状態など）であるかを管理してる
Flow: データのストリームを提供するKotlinの機能らしい。非同期でデータを受け取り続けることができるのでデータの変化を監視できる。
３、sealed classでUIの状態 (Loading, Success, Error) を管理する
sealed class（シールドクラス）は、例えば、以下のようなUIの状態を管理できるらしい。
Loading: データを読み込んでいる最中
Success: データの取得が成功した状態
Error: データの取得に失敗した状態
４、ビジネスロジックの考え方
ビジネスロジックは、pureなJava(Kotlin)で実装してフレームワークなどに依存しない作りにした方がよい。
将来的にフレームワークを変更する必要が出てきた時に移行することが容易になり、ビジネスロジックをそのまま使える。
まとめ
小規模〜中規模：ちょっと工夫は必要だけど、基本的にはMVVM構成でよさそう
大規模：クリーンアーキテクチャーを採用したい
マルチプラットフォーム：Modelにビジネスロジックを集約し、異なるプラットフォームでも再利用しやすい構成になっているMVI（Model-View-Intent）がいいのかも？
という感じで、フォルダ構成を検討するだけでも、いろんな考え方、やり方があるんだなと大変勉強になりました。