はじめに
これのAndroid版(Kotlin)です。
Kotlinさわったことないですが、Swift感覚で作ってみました。
おそらくこうだろうという感じで作っているので間違っていたらご指摘いただけたら幸いです。
以前作ったやつ
環境
macOS High Sierra バージョン10.13.2
Android Studio 3.2.1
kotlin 1.2.71
つくるもの
あまりに機能がなさすぎると色々な設計でつくっても違いがわかりにくいと思うので今回は下記のようなアプリを作ります。
アプリ要件
livedoor天気のWeb API(商用利用不可)を利用した各都道府県の天気を表示するアプリ。
対象はAndroid 5.0以降。
機能
４７都道府県を一覧表示し、選択した都道府県の今日、明日、明後日の３日間の天気を表示する
- 都道府県一覧の表示は各地方で絞り込みができる
- 都道府県のお気に入り登録ができる（端末で記憶する）
- 都道府県一覧の表示はお気に入りで絞り込みができる
画面構成
都道府県一覧画面と詳細画面の２画面。（スプラッシュ含め３画面）
スプラッシュ画面は無視します。（MVCとかで分離しないので）
都道府県一覧画面
- ４７都道府県を一覧表示
- 都道府県選択で通信で天気情報を取得し詳細画面に遷移する（エラー時は遷移しない）
- 星マークタップでお気に入り登録削除を行う
- お気に入りのみ表示チェックボックスのチェックでお気に入りのみ表示する
- 地方で絞り込みボタンで下の画像のようなポップを表示する
- チェックの切り替えで一覧表示を絞り込んで表示する
詳細画面
- 選択した都道府県名を表示する
- 選択した都道府県の今日、明日、明後日の３日間の天気を表示する
- 表示内容は日付、アイコン、天気、最高気温、最低気温の５項目を表示する
- 右上の再読み込みボタンで天気情報を通信で再取得する
用語解説
MVCとかで個人で認識の違いが出るのはカタカナ語の意味があいまいなのも１つの原因かと思います。
MVCとか調べていてビジネスロジックって結局なんやねんとよくわからなくなるのでこの記事でいうカタカナ語の意味について書いておきます。（実際の意味とは違うかもしれませんが...）
ビジネスロジックとは？
ここの説明では「そのシステムにおける、システム固有の処理を行う部分」とある。
このアプリでいうと下記が該当
- 各地方での絞り込み
- お気に入りの登録
- お気に入りの絞り込み
- 天気情報の取得
レイアウトとは？
このアプリでいうと下記が該当
- Viewなどの部品の配置
- 都道府県一覧の表示
- 天気情報の表示
ユーザアクションとは？
このアプリでいうと下記が該当
- ボタンのタップ
- セルのタップ
それぞれの設計
つくったものはここにあげました。
今回つくったものは通信にOkhttp3、JSONデータを扱うクラスの作成にJsonToKotlinClassを利用しました。
それぞれの設計の私の認識、ファイル数、Activityの行数、つくった感想を書いていきます。
ほぼActivity
とりあえず何も考えずにほぼActivityでつくったのがこれ
ファイル数
- kotlinファイル: 9
- xmlファイル: 21
Activityの行数(コメント含む)
- 都道府県一覧画面: 289行
- 詳細画面: 241行
つくった感想
ファイル数は少なく開発スピードは早い。（ファイル数が少ないのはデータクラスを1つにまとめたため）どのクラスも300行でおさまっているのでこのくらいの規模ならこれもありかなと思います。Adapterに処理を書くのでわりとActivityの行数は少なくなった感じがします。
MVC
プロジェクトはこれ
認識
Model(該当するもの：Object)
- データの保持
- ビジネスロジック
- データ変更をControllerへ通知
View(該当するもの：Fragment, View, xml)
- 画面のレイアウト
- ユーザアクションをControllerへ通知
Controller(該当するもの：Activity)
- ModelとViewの仲介
- Viewからユーザアクションの通知を受けModelのデータを更新
- Modelからデータの更新通知を受けViewの表示を更新
ファイル数
- kotlinファイル: 14
- xmlファイル: 25
Activityの行数(コメント含む)
- 都道府県一覧画面: 155行
- 詳細画面: 135行
つくった感想
とりあえずFragmentをViewとして作りました。ボタンのイベントの取得やら、AdapterにListを渡すのが多少面倒ですがまあスリムになりました。Modelを作るとonSaveInstanceStateで保存するのが楽になる気がします。PopupWindowの表示処理がActivityの行数を結構増やしているのでここをもう少し分割できれば、もう少しスリムにできるかも。部品が多い画面とかはfindViewByIdをFragmentにまとめれるのでかなりActivityはスッキリするので結構みやすいんじゃないかと思います。
その他
その他主旨とずれますがKotlinで気になった点
- findViewByIdじゃなくてIDで直接アクセスすべき？
- !!は禁止すべきか？
- Javaとの互換性を意識するべきか？
iOSとの比較
色々作ったんでせっかくなんでMVCのやつの比較載せておきます。
| 言語 | クラスファイル数 | xml（xib）のファイル数 | 一覧画面行数 | 詳細画面行数 |
|---|---|---|---|---|
| Objective-C | 31 | 8 | 287 | 118 |
| Swift | 26 | 7 | 159 | 67 |
| Java | 23 | 25 | 175 | 144 |
| Kotlin | 14 | 25 | 155 | 135 |
Swiftと比較するとimport文が多いのでその分行数増えたのかなという気がします。
思ったよりもあんま差はないみたいです。
さいごに
割とSwiftに近い感覚で作れたので、iOSやってる人はKotlinの方が書きやすい感じがしました。
この記事はだれかに意見して欲しいと思って書いたので何かちょっとしたことでも意見をくださるとありがたいです。
俺が思う「最強の設計はこれだ！」というのがあれば、是非上記の仕様でアプリつくってみて下さい。
そもそもiOSもAndroidもMVCで作ってる現場ってあんのかな...