hunachi’s diary

Android studio でお勉強してます。

「大きめのAndroidアプリでの設計について考えてみる ~pocket~」を読んだ.

はじめに 

こんにちは,ふなちです!

 

1週間以上前になるんですが,技術書店で入手した

「大きめのAndroidアプリでの設計について考えてみる ~pocket~」

を完走させていただきました.

 

booth.pm

 

頭が悪いのにも関わらず,設計のお話は好きなので,楽しかったですし,とても勉強になりました.

ありがとうございます!

あと,この本の土台となっているリポジトリのコード

github.com

も何度も読ませて頂き,参考にさせて頂きました.(実はDroidKaigiの釘宮さんのセッションの影響もあって,本を買わせていただく前からこのリポジトリは何度か拝見させて頂いてました)

 

これ以降技術的に間違えた内容があるかもしれないです.

間違えの指摘,アドバイス等はhttps://twitter.com/_hunachiにお願いします:bow:

 

※ これ以降は,「大きめのAndroidアプリでの設計について考えてみる ~pocket~」の事を「本」と表現しています.かなり大雑把で失礼になっている気がしますが語彙力不足です.すいません.

 

感想

表紙

女の子とピンクドロイド君が可愛い,可愛すぎてやばたにえん.彼女にしたい.

視点が白板側っていうのも好きです.

 

技術的な感想

 先週,個人的な事情で小さいアプリを作っていたんですが,それはこの本で学ばせて頂いた事を取り入れながら書いたので,基本的には実際に取り入れてみた感想を書いていきたいと思います.

 ※ 本の感想と,取り入れてみた感想を分けて両方書こうとするとやばい量になる気がしたので,取り入れてみた感想をメインで書く事にしましたご了承下さい:bow:.

 

ちなみに今回作成したアプリはこちらです.

github.com

(色々あってミラー版です)

 

また,小さなアプリには不向きですって書いてあるのにごめんなさい,小さなアプリなのにも関わらず参考にさせて頂きました.module分けに関しては,規模の関係もあり好き勝手にしてしまっていて,なにを勉強したんだって感じかもしれないコードになってしまったのですが,ドメイン部分の書き方などを参考にさせていただいたりして,コードの品質が以前より改善したと思います.

 

マルチモジュールについて

DroidKaigi 2018 - マルチモジュールのすヽめ / kgmyshin [JA] - YouTubeで以前学ばせて頂いていたのと,インターン先でもmodule分けを体験していたので多少なりともmodule分けの知識あ持っていたのですが,module分けのメリットなどをより詳しく知ることができました.

コンテキスト毎で分けるのは分かるのですがレイヤー毎にmodule分けするというのは驚きました.確かに,強力なレイヤー化アーキテクチャに!(。 ・ω・))フムフム.

 

実際に大きなアプリでなくてもmodule分けを取り入れる事で,infraの部分は他のモジュール(View)からでは基本repository以外見えない状態にでき,コードの品質がよくなりました.

 

先日のGoogle I/Oで「Dynamic feature modules」の発表があった事もありmodule化の流れが (((o(*゚▽゚*)o))).

 

ちなみに,個人的に以下の記事が分かりやすかったです.

tomoima525.hatenablog.com

 

レイヤー化アーキテクチャについて

今までレイヤー化アーキテクチャを実践しようと思ったことはありましたが,綺麗な分け方がいまいち理解できておらず,迷走し中途半端なレイヤー化アーキテクチャをしたことしかありませんでした.

 

しかし,本で詳しく説明していただいていたので,今までのモヤモヤがほぼなくなり,以前よりもだいぶ綺麗なレイヤー化アーキテクチャを実現する事ができました.

 

そのおかげで,レイヤー化アーキテクチャの恩恵をたくさん受けられました.

特に,domainレイヤーの大切さは実際に実装する中でも実感できました.

コードがぐちゃぐちゃにならずに済みますし,自分がどういうコードを書きたいのかというのをきちんと決めておかないと手が進まないというのも大切だと思いました.(とりあえずコードを書くという悪い癖が治りました.)

またコードがより整理され可読性もかなり上がりましたし,後々のコードの管理がとても楽になりそうです!

 

去年の秋に,知識が乏しい中かなり大きなアプリを作った際の苦しみを思い出しつつ,大きなアプリでレイヤー化アーキテクチャ使わない手はないのでは?と思えました.もっと早く知っときたかった(> <。)

 

レイヤー化アーキテクチャを適用した際の実装順について

また,実装順に関しても参考にさせて頂きました.

本によると,

 

              > ui -> usecase 

domain

             ┗ > infra

 

でした.私は今回

 

domain  ->  ui  ->  infra

 

という順で書いていきました.(小さなアプリだったのでusecaseは使わなかった.)

 

またここに詳しいことは書かないのですが,本にはこれらのレイヤー中での実装順も丁寧に説明されており分かりやすく,凄く参考になりました.

実装例が充実していたのには感謝しかないです:pray:

 

余談なのですが,以前は,部内の開発スピードが早い人に普段,どの順番で書いてるか聞いたりしてどうにか効率の良い開発順を知りたかったのですが,同じ分野をしている人がいないというのもあり,迷走して逆に開発スピードがダウンするという事をしていました.

その結果最近は,一人で開発してるんだし書きたいところから〜とか適当に書いていき後に混乱を招くというバカな事をしていました.

しかし,この本のおかげもあり,今回はスピーディーにモヤモヤもなく開発をすることができました.ありがとうございます!

 

その他で学んだ事
  • MVPについて.

今までほとんどMVVMでの実装をしかしたことがないのですが,この本を通じて,MVPの良さも知ることができました.

PresenterとViewとがContract(intarface)で繋がっている?ため役割を明確にContract定義でき可読性がかなり上がるという点と,機能が多いアプリでMVVMを使うとViewModelが肥大化してしまう問題に直面しかねないが,MVPだとBindingModelを別に作れるので,肥大化が起こりずらいという点でメリットを感じました(。 ・ω・))フムフム

 

今回作ったアプリでは色々考えた結果,DataBindingのBindingAdapterを乱用できたのでそこまでViewModelが肥大化しなかった&Viewへの依存関係は完全に断ち切りたかったのもあり,MVVMを採用しました.

 ※ Contractを使ってViewとViewModelを繋いで可読性をあげてもよかったのかなぁって思いもしました.(迷走タイム)

 

  • ScreenTransitionについて.

先日のGoogle I/OJetPackのNavigationの発表があったので今更この話をって感じかもしれないですが,印象に残ったので書かせて下さい.

これは実質,Navigatorクラスが必要かどうか問題についてなのですが,Navigatorクラス(全ての画面遷移を管理するクラス)は採用せずに,ScreenTransition(interface)を作り,画面遷移の実装はActivityにするという方法について知ることができました.

 

今回作ったアプリではFragmentが存在しなかったので,以前インターンで出会って感動したActivityにもFragmentのnewInstanceを作るという形をとりましたが,Fragmentが存在して,Fragmentの切り替えも一緒に実装するとなると,ScreenTransitionを作る方法が個人的に最適だと思いました!

 

また,Navigationクラスを使うデメリットについてのコラムはとても共感できる内容でした.DroidKaigiアプリでもNavigatorクラスは存在してましたし,他の方のコードにもNavigatorクラスが存在することが多かったので,Navigatorクラスって便利なのかぁって思い試した事があったものの,ごちゃっとなってしまったりして何かモヤモヤしてたのですが,そのモヤモヤを全て言語化してくれてる感じで,スッキリしました୧(๑•̀ㅁ•́๑)૭

 

アプリを作ってみたけど,まだ修正が必要かもと思う部分について

注:この章は,ほぼ本の感想じゃないです!

アプリを作ってみたけど,私の頭が足りておらず,まだ修正が必要かもと思う部分が2つあります.

 

1つ目は,ドメインとインフラは他のコンテキスト(モジュール)から見えないようにすべきという事をしないといけないのにも関わらず,モデル(データクラス)をドメインに書いてしまい,しかもそれを他のモジュールから使えるような形(not internal)にせざるおえない事になってしまった事です.小さなアプリだったので,色々な部分で使うためのデータクラスだけをもつモジュールを作るべきだったのかな?と思いました.

 

2つ目は,infraがデータを提供してくれるRepositoryも,インターフェースだけをpublicにして,それを実装したクラスはintarnalにすべきだったと思うんですが,DIを下手に使った関係でその実装したクラスまでもpublicにせざるおえなくなってしまいました.もうちょっとmodule間で上手にDIを使う方法を考えていきたいです.また釘宮さんのコードも参考にしてもうちょっと勉強していきたいです.

 

 最後に

これを機にアプリの設計についてもっと考えていって,いつか社会に出たりして大きなプロジェクトの設計を考えるとなる機会が訪れるなんてことがあった場合に最適解により近い設計ができるといいです.

 

釘宮さんありがとうございました.

社会人になって自分でお金を稼ぐことができるようになったら恩返しできたらいいです.あわよくば,自分も本を出したりして社会に貢献できるようになりたいです.(厳しい道!)

 

P.S.

技術書店でGETした他の本の感想等に関しても

技術書店4に行った. - hanahanahunachi’s diary

にList化していくつもりなのでよろしくお願いします(> <。).