はじめに
アプリのアーキテクチャというと、僕が一番はじめに思い浮かぶのはMVCとかMVP、Fluxみたいな
今回のアプリでどのパターンを採用するかという点です。
ただ、現場でそのパターンだけ考えれば良いかというとそれ以外の部分に対しても
もっと検討することが多くて、何を検討するかがまとまっていないことが多いので、
自分の備忘録としてまとめてみることにしました。
お題
・アプリが起動したらQiitaの記事の一覧を表示できる
・記事をタップしたら、Webのページで記事の内容を閲覧できる
・どの記事を見たのか、履歴を確認できる
・どんな記事を見たのか集計して、アプリの改善に使いたい
・（簡単にするため、認証はなし）
というQiita閲覧アプリで考えてみます
要素を分解してみる
アプリが起動したらQiitaの記事の一覧を表示できるアプリ
QiitaのAPIを使った通信が必要。
https://qiita.com/api/v2/docs#投稿
APIはJSONなので、JSONを解析できるライブラリがあると楽そう。
リスト表示であれば、標準コンポーネントで十分。
・記事をタップしたら、Webのページで記事の内容を閲覧できる
Webのページを簡単に閲覧できるコンポーネントを使いたい。
ページそのままの表示で良いので、ChromeCustomTabsやSFSafariViewControllerでも良さそう。
他のページに飛ぶ場合の制御が必要な場合は何か制御が必要かもしれない。
その場合、WebViewやUKWebViewを採用する必要がありそう。
・どの記事を見たのか、履歴を確認できる
記事をタップしたタイミングで記事のidを保存する必要がある。
履歴もリスト表示なので、複数の行を保存できる方が良い。
履歴の最大保存件数は顧客やPOに確認する。
複数の行保存の場合、UserDefaultやSharedPreferenceよりも
RoomやRealmの方が良いかな。Realmにするなら、Androidも合わせた方がいいかも。
・どんな記事を見たのか集計して、アプリの改善に使いたい
Analytics系のサービスを使う必要がある。
定番はFirebaseだが、それ以外に使いやすいサービスはあるか？
上記以外だと、どこまでテスタブルか、テストが標準でサンプルがあるか、
アプリ配信は何を使うか？などがありそうです。
検討できる項目にしてみる
| 検討項目 | 検討点 |
|---|---|
| 通信ライブラリ | 一般的か、簡単に使えるか、テストを分離できるか、細かいカスタマイズが可能か |
| WebView | 簡単に使えるか、テストを分離できるか、自分でページ表示の制御が可能か |
| データ保存 | 一般的か、簡単に使えるか、テストを分離できるか、保存が高速か、コードは短くなるか |
| Analytics | 一般的か、簡単に使えるか、テストを分離できるか、細かいカスタマイズが可能か |
- Androidの通信ライブラリの場合
調査して、候補を並べ、各項目の採点のウェイトを設定する。
（今回のアプリの要件を満たすために重要なものは高い点数をつける）
各項目の点数を設定して、合計を算出する。
| 候補 | 公式ページ | 一般的 3 | 簡単さ(学習コスト) 3 | テスト 2 | 細かいカスタマイズ 1 | 合計 |
|---|---|---|---|---|---|---|
| Retrofit2 | https://square.github.io/retrofit/ | 3 | 3 | 2 | 1 | 23 |
| OkHttp3 | https://square.github.io/okhttp/ | 3 | 2 | 2 | 1 | 20 |
| HttpURLConnection | https://developer.android.com/reference/java/net/HttpURLConnection | 3 | 1 | 1 | 3 | 17 |
※情報収集の元の記事があるとなおわかりやすい
※通信プロトコルがJSONを使ったREST以外にGraphQLやgRPCもあると、そこへの対応有無も検討対象になる
そして決める
各項目の情報がまとまれば、あとは以下のように整理するとわかりやすくなると思います。
- Android
| 検討項目 | 採用技術 | 採用理由 |
|---|---|---|
| 通信ライブラリ | Retrofit | 一般的なライブラリで学習コストが小さい |
| WebView | ChromeCustomTabs | 表示を全てChromeに任せられる、アプリでの表示制御も不要である |
| データ保存 | Room | Androidの標準ライブラリ、今後の変化にもっとも強いと思われるため |
| Analytics | Firebase | 一番の定番で情報が多くあるため |
- iOS
| 検討項目 | 採用技術 | 採用理由 |
|---|---|---|
| 通信ライブラリ | Moya | 一般的なライブラリで学習コストが小さい |
| WebView | SFSafariViewController | 表示を全てSafariに任せられる、アプリでの表示制御も不要である |
| データ保存 | Realm | iOSのDBではスタンダードなライブラリのため |
| Analytics | Firebase | Androidに同じ |
まとめ
SIer系の仕事が多かったので、まとめ方としては固い進め方かなと思います。
また、これがベストの進め方ではなく、もっと良い進め方があればコメントをもらえると嬉しいです。
その他
冒頭でMVCやMVPのことを書いて、それが抜けてしまいましたが、
各機能を満たす為の技術やライブラリを検討する前段階でリアクティブプログラミングか
使わなくても良いかの検討も必要そうです。
アーキテクチャ検討というよりもライブラリ検討になってしまったかもしれません。