2019-12-07

フラーで SingleActivity + MVVM + DI + Repository 構成で1年間Androidアプリを作って感じたメリットと課題

この記事はフラー Advent Calendar 2019 の7日目の記事です。

個人的なことですが、今年初めてお仕事として新規Android アプリ開発に携わり、今年の5月にリリースしました。そして現在も、来年にリリース予定の別のプロダクトを開発しています。

新規でアプリを作るときにまず間違いなく通る道は「どのような設計パターンにするか」だと思いますが、現在、フラーで新規に開発しているAndroidアプリは 「SingleActivity + MVVM + DI(Dagger) + Repository」 という構成を取ることが多いです。

そもそもなぜ設計パターンを導入したのか

これは16日目に登場予定の "Daiki Okumura" が2018年の夏頃に導入したことが発端ですが、それまでのプロダクトにはこれといった設計パターンがありませんでした。

ここからは内情的な話になりますが、2017年から発足した弊共創事業部の創成期は「来年にはもしかしたらプロダクト毎死んでいるかも分からない」「一人が短期間で作り上げる」「そもそもAndroidエンジニア足りなすぎた、時間が足りなかった」と聞いています。

そもそもアプリ自体もミニマムなものが多く、導入に至らなかったことは容易に想像できます。その状況から一気に割とモダンな構成になった訳ですが、結論から言うと、非常に開発がやり易くなっていると感じます。

それぞれのメリットと課題感

昔話はこの辺にして、現在弊チームが採用している「SingleActivity + MVVM + DI(Dagger2) + Repository」について1年間使ってみて感じた良い点と現在抱えている課題感を共有したいと思います。

また、構成についての説明はほぼしないのですが、同じ構成のサンプルアプリが、 Googleが紹介しているarchitecture-components-samples`のGithubBrowserSampleとしてGitHubにあがっているのでそちらをご覧ください。色々なMVVMのサンプルを読みましたが、このサンプルが簡素すぎても複雑すぎてもなく丁度良いサイズ感で、参考にしています。

横道に逸れますが「GitHubのリポジトリ一覧を表示する」アプリって何万回作られているんでしょうね。もしかしたら一番多いアプリかもしれません。

「SingleActivity + MVVM + DI(Dagger) + Repository」の良かった点と現状の課題

Single Activityについて

「Android Single Activity」でGoogle検索してもなぜかあまり日本語の記事が出てきませんが、SingleActivityとはその名の通り、アプリケーションにActivityを一つしか持たないようにするものです。Fragment間の画面遷移は Android Architecture Component(以下、AAC)のNavigationに頼っています。

良かった点

Activityのライフサイクル管理を考えず、Fragmentのみに集中できること
AAC Navigationをフル活用できること
- SafeArgsを使うことで型安全に画面間の値渡しが可能になる今まで値を渡されるActivityに createIntent()のようなメソッドを書いていたのが不要になった

fun createIntent(
  context: Context,
  param1: Int,
  ...

画面遷移のアニメーション定義もxml管理できるようになる

課題

単一のActivityが唯一全てのFragmentの状態を知り得るため、処理が多くなりがちになる
処理が多くなるなら、Singleであることにこだわる理由はなさそうなので、分割もあり?
Fragmentのバックスタックの理解など、Fragmentへの理解がだいぶ必要になる。というか一度はハマる　
みんな本当にGUIのNavigationEditorで管理してるのだろうか、、、ぐちゃぐちゃになっているので見れたものじゃないが

MVVMについて

MVVMパターンはGoogleも推奨しているパターンの一つですね。もちろん以下のような注釈付きですが。

1 つの方法であらゆるシナリオにそれぞれ応じるアプリを作成することは不可能です。しかし、ここで紹介する推奨アーキテクチャは、多くの状況やワークフローで利用できる優れた出発点になります。

https://developer.android.com/jetpack/docs/guide?hl=ja

良かった点

それなりに古くからある考えなので、情報量が多いことがありがたい。参考になるコードの実例も、解説記事も
Jetpack(AAC ViewModel、LifeCycle、LiveData)をフル活用できる
適切な分離が出来れば、Viewをスリムに保つ事が出来て、かつViewModelのUnitTestを書くことができる

課題

例えば自分は、MVPパターンの開発経験しかなかったのでMVVM自体の習得と共に、DataBindingやJetpackも同時に把握しなければならず、慣れるまで時間がかかった。 Android設計パターン入門でもMVVMは習得にコストがかかる、と書かれているが、本当にそうだと感じる
- 特に初学者などには間違いなくハードルが高いので、「それぞれのコンポーネントが出来ること」と、「MVVMでやりたいこと」とを丁寧にフォローしないとパンクする。
- 「最近のAndroid開発、初学者に厳しすぎないか問題」は正にこれのことだと思っている。

DI(Dagger2)について

DIパターンはUnitTestを書く時に便利なので、採用しています。Dagger2を使用しています。

良かった点

複雑そうだし、実際最初に書く時は辛いが一度書いてしまえば、後は便利
UnitTestが容易に書けるようになる。寧ろ無いと本当に辛い

課題

やはり一番の課題はここも学習コストだと感じる
- MVVMとDaggerのダブルパンチだと相当辛い。(正直、納期のために雰囲気コピペで乗り切ることもあった。今は無い。)
Daggerを捨てて、Koinに移行?という手もあるが、以下のようなデータを見るとまだまだDaggerで良いのかなという感じ https://github.com/Sloy/android-dependency-injection-performance

Repositoryパターンについて

MVVMパターンでは特に Model をどのように組むかについて指示は無いので、サンプルや記事を眺めてみてもプロダクトによってUseCaseを挟んでいたりInterfaceを挟んでいたりいなかったりとバラバラですが、弊チームでは、APIやローカルDBまでの仲介役としてRepositoryを利用していて、UseCaseは使っていません。

良かった点

具体的なデータ取得の方法に依存しないように出来るため、APIが直前まで出来ない問題に対応出来ること
- モックデータを用意しておいて、直前に差し替える、ということを行える
DIパターンの恩恵に預かって、だがビジネスロジックのUnitTestを書く事ができる

課題

Repositoryに処理が寄りがちになる
- まだそこまで大きくなっていないが、もっと大きくなったらUseCaseを導入した方が良いなと感じている

全体:今後やりたいこと

Multi Moduleの導入
- やっと最近上記の構成に慣れ始め、また人も増え始めたところなので、また新しいことを導入するには早い、と思い導入に至っていないが、次に新規で作る際は入れない理由が無さそう。

後半駆け足になりましたが、今日はこの辺で。

明日はまた私で、「エンジニアリング全般で何か」書きます。

2019-08-27

インターンシップをやっつけてきた話

南魚沼でインターンシップをやっつけてきた。

(勢いで書きなぐっているので良く分からん感じになってるかも)

note.mu

インターンシップの詳細は、スーパー高専3年生の成田さんが書いた上記の記事たちにお任せるとして、個人的なふりかえりを書いていこうと思う。

個人的に、どうでした?

一言でいうと、得られるものが多かった。

フラーに入って新規で1から色々ものづくりしてきたけど、その経験を活かし、今回、学生からあがってきた詰まりポイント、ハマりポイントに対してほぼ全て即時に対応出来た。それは今後の自信になった。

また、学生からの相談にも、「現場ではこうするね」と全てキッチリと回答出来たと思う。そういったことも含め、今までしっかりと腹落ちするまで意思決定を繰り返してきたのだな、間違っていなかったな、とふりかえることが出来た。

学生達は、どうでした?

素直過ぎるくらい、みんな素直だった。

こっちの言った事に対してめちゃくちゃ真に受けて吸収する、という印象。良くも悪くも、そういう感じだった。むしろそういう意味では、「もう少し自分で考えてやってみてもええんやで」というオーラを出したら何人かそういう方向に行動していた人も見えて、いやだから素直だなぁ!!となった。

その素直さを活かしてもっともっと行動して、いろんな大人と話してって欲しいなと思った。色んなことを吸収して大きくなれそう。

一番印象に残った事

エンジニアの子は二人いて、基本的に自分と常にペアプログラミングで行なっていた。基本的に「あ、これ分からないでしょ。調べてみて。やってみて」ってやって、それでも迷宮入り(といっても時間が無いので3分とか詰まってそうならすぐタオルを投げていた)しそうな時に助け舟を出す、というのを繰り返していたんだけど最終日あたりに多分段々と学生も勘所が分かってきて、メンターよりも早く解決策を出しちゃうっていうのが見られた事。

つまりは、ペアプログラミングは最強。特にAndroid アプリ開発はAndroid Studioを如何に上手く使うかみたいなところの勝負でもあるので、そういう意味でもこの形式は間違いないな、と思った。

特徴は「田舎の古民家で、学生と6日間寝食を共にするということ」

やってみて個人的に、このインターンシップの特異性は、その一言に尽きると思った。寝食を共に隔離された環境下で行うことで学生同士や学生とメンターとの距離が急速に近づくこと。だからこそテーマに沿った誰でも考えそうな上辺だけの議論ではなく、「本当にこの企画で良いのか?面白いか?向こうのチームに負けてないか?(もちろん全然勝ち負けではないけど、多分意識してたと思う)」といったことを真剣に本音でぶつけあうことが出来ている、と感じた。

で、またやりたい?

もちろん。今回参加してくれた学生達にもどっかで会いたいし、その時までにもっと僕も成長しないとなと思ったし、そう心から思える仕事は中々無いので、こういう機会を大事にしていきたいです。

おつかれさまでございました。おそらくこれを読んでいるであろう参加してくれた学生達へ。また会いましょう。

2019-08-26

「田舎の未来」を読んだ。

僕は、まぁ車で20分くらいの距離にイオンがあればどこでも良いっすね、と思うくらいには地方創生とかそういうものに興味が無い。無かった。

「田舎の未来」という本を読んだ。これは、衰退していく筆者の北海道の地元の現状と、それでも諦めずに何か出来ないかとしぶとく可能性を探り続けて戦っている事や調査の7年間をまとめた本だ。

元々、筆者と仕事で少し関わりがあるので知っていて、あと僕の出身地の滝上町と遠軽は距離にして62kmくらいと近いのでいつか読もうとは思っていた。また、会社のインターンシップのテーマと被ることも多そうだし、お盆休みだったしで良い機会だなと思って、読んだという感じ。

結論を言うと、とても面白かった。同じような地元の僕から見て、共感出来ることだらけだった。

例えば、「地方と都市」という対立構造(地方での丁寧な暮らしvs都市での刺激的な暮らし)をやめませんかという話。

丁寧な暮らし。ハッキリ言うと僕の大嫌いなキーワードだ。僕の地元は冬になると、年によっては一晩でドアを開けることが出来なくなるまで雪が積もったり、-40℃まで気温が下がったりする。正直、丁寧な暮らしどころではない。一晩うっかりしていると死ぬんだから。だからどうしても違和感を感じてしまう。

地方と都市という対立構造に持ち込むこと自体がナンセンスで、益々溝が生まれていくからやめろ、という筆者の意見に賛成だ。

そんな感じで、自分の中のモヤっとしていたことや、それへの回答を述べていて非常にスッキリとした。

今、僕は妻の実家が近いから新潟にいる。良い意味で特に場所に対してのこだわりがないので、別に自分の地元に戻りたいとも思っていない。その土地に対しての面白さって特に無いものだと思っているからだ。

しかし、今所属しているフラーが長岡花火アプリ、佐渡汽船公式ページといった地元に密着した仕事をしていることや、この周辺の土地で本気でやっている人に会ったりして見て、ちょっと気持ちが変わってきている。

どういう風に変わったかというと、「地方に面白い人なんていないんだろうな」とどこか偏見を持っていたのが、「自分が面白い人を探していないだけ。面白い人はちらほらいる」という気持ちに変わった。

例えば、この前南魚沼市で6日間インターンシップをやったのだけど、そのインターンシップの協力をしてくれた市役所の人がバリクソ面白い人だった。僕の中の公務員のイメージが変わった。

そして、この筆者のように。地方にも面白いことをやっている人は、多分他にもいる。インターネットによってその熱量が伝わりやすくなってきている。

何が言いたいかというと、僕は「地方創生」という難しい言葉はちょっと意味が分からないけど、「地方でやってる地方にしか出来ない面白いことや、そこにいる面白い人」に対しては単純にワクワクするし、人々も結局そこに惹かれるのでは無いか。ということだ。

まとめると、地方創生って、その土地にどれだけ熱量が高く面白い人がいるかで決まると思っている。僕はそれになろうとは思わないけど、そういう人の熱量を伝えられるように、ふわっと他の人に波及させることが出来たら面白いなぁと思ったりしている。

今日はそんなとこで。

(参考)

http://sanokazuya0306.hatenablog.com/entry/20120922/1348323875

田舎の未来手探りの7年間とその先について (SERIES3/4 4)

作者: さのかずや
出版社/メーカー: タバブックス
発売日: 2019/04/25
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

2019-04-06

地方のITベンチャーに入社して5ヶ月が経った

感想

中旬くらいに区切りが付いて、一息ついた頃に体調を崩してしまった。この仕事終わったら、あれしようこれしようと約束していたことがそれで出来なくなって嫁がブチギレて実家に帰る。今は大丈夫です。

やっぱり全然詳しく言えないけど、こんな感じです。新規案件をやることで決断力や判断力もついて成長したけど、前よりもインプットが減ってしまって、技術を荒く使っている感が否めないので、このリリース終わったら丁寧に復習しておきたい。まぁその前に妻に色々あれするのが先だけども。ありがとういつも。調理師免許持ってるだけあって、いつもご飯が美味しいです。

まぁ、そんな感じです。楽しくやってます。

2018-12-17

AdventCalender2018 にEpoxyの記事を書いた

Epoxyの導入記事を書いた。

qiita.com

社内向け導入として書いたものに追記した感じ。

Epoxy、すごく便利だなと感じてるけど、イマイチググってもあまり日本語の情報が出てこなかったりしててもしかしたら導入しているとこは少ないのか、、、?とモヤっとしてたので、少しでもEpoxy使う人増えるといいなというお気持ちで書いた。ほぼほぼ公式ドキュメントに書いてあることで、新規性も深掘りもあったもんじゃないけど。

こういう記事を書くにあたっての「気持ち」だったり「課題と目的」は大事だなと感じている。この前、長岡の勉強会に行ってきた時にふと@Nkznさんが「技術記事の面白いとこは筆者がどんな動機で書いたのか、だよね。」みたいなことを雑談で話してたのを聞いて、それを意識してるのかもしれない。

ちょっと関係ないけど、「勉強会に行って懇親会で会話するのは刺激を受けるよね」の"刺激"って凄く具体的でない言葉で嫌いなのだけど、上記みたいなことが正に刺激を受けるってことなんだろうなと思った。大事だなと日々感じていたけど、言語化されてなかったことが言語化されて整理がつく感じ、というか。その感覚は好きだ。

めっちゃ話が逸れてしまった。けど、こういう書き方も面白いかもな。ラジオみたいで。

2018-11-07

ペパボをやめて、フラーに入る。

頑張って退職エントリでも書くか
— うじ川@新潟 2018/11/10〜 (@ujikawa1026) November 6, 2018

退職エントリ、流行ってませんか?

多分、退職エントリには人生色々が詰まっていて、それが面白いからだと思います。ただ、僕は天邪鬼なので流行ってるとそれにノリたくないな、と思ってしまって退職しても、なんとなく書かずにいました。あと、前職のこと悪く言う記事とか散見されるようになりましたが、あれ僕個人的には凄く嫌な感じがして、それもあると思います。

あと、ブログ、と言うか僕が書くこと全般って自分の思考を整理し、整理した状態のものを後から見返すと自分が面白いから書くことがほとんどなのですが、こと今回の退職についてはこれでもかってくらい考えて、整理なんて不要なものでした。あと、そういった感情と共に刻み込まれたものって絶対に忘れないし、そういう意味でもあまり退職エントリを書く気持ちになりませんでした。

あと僕は正直だからもっと本当の理由を言うと、前職のペパボって僕から見て本当すごい人とか面白い人いっぱいいて、その中にいるとどうしても僕は比較してしまうんですが「これは俺やったったな。うん、やったったぞ」と胸張って思えることがあまりなくて、そんな人間が偉そうに何を語るんだ?と思っていたのもあります。「僕がすげぇ」じゃなくて、「あいつがすげぇ」、「この人も超面白いよ」って紹介したい感じ。

「なんで転職したんですか?」

でも、やっぱりというか、あまりに色んな人に同じ質問をされるので(仕方ないというか当たり前だけど)、雑になってきて、なんか言ってることブレそうなのと、大事なことはブログに書いておきたい。長くなりそうだけど。今回の目的はそんなところです。

「なぜやめたの?」
「なぜフラーに行くの?」
「なぜ新潟に行くの?」
「なんか意気込みをお願いします」

「なぜやめたの?」

転職しようかなぁと思った一番最初のきっかけは、はっきり言うとお金の問題かなと思います。

僕は子供がいるのですが、待機児童の問題で保育園に入ることが出来ず、それが理由で妻も働くことが出来てませんでした。お互い実家が遠方なので、子供を預けて働く実績を作ることも出来ません。

お互いどんな病気になっても良いように保険にもしっかりと入って、子供のための学資貯蓄も少しは出来ているのですが、子供がやりたいことを自由に出来るような将来に備えた貯蓄が出来ているかというと出来ていないという状況でした。

なので、最初は節約という節約を全て行いました。携帯代、ネット代、自分のお小遣い、、、みたいに基本ですが、大きな支出から見直しを行い、全て削りました。その結果、妻の知り合いに家計を診断してもらったら「これ以上削れるところがない」と言われるくらいに支出を絞れて、少しは貯金出来るようになりました。

しかし、一番高くどうにもならないのが家賃です。東京ってやばいです。毎月2桁万円で圧迫してきます。では、家賃安いとこ行く?といっても引越しするのもお金がかかるし、これから子供が大きくなっていくのに狭い部屋には住めないなぁというスパイラルに陥ってました。この頃から地方での転職を考え始めていました。

もちろん、支出を減らすだけでなく、収入を増やすという面でペパボで年収を上げるぞ、というのも出来る限りちゃんと頑張っていたし、上司にも相談していたのですが、「可処分所得を増やし、貯蓄に回す」という目的で考えると、現職に居続けることが手段ではない、と思って少しだけ転職活動というか、他の会社はどうだろうなぁとか自分は外に出たらどれくらいの価値なんだろうなぁとか、いや、やっぱり家賃高くね？ということを考え始めました。

元々、ペパボには「技術力つけるぞ」って思って入ったのですが、本当勝手なのですが、家族が出来てから自分の価値観がどんどん変わっていってしまって。自分が技術力付けるの待ってもらってるみたいな状態ってなんだ、とか、いや、そもそも技術力付けるってどこまでいけば終わりなんだふわふわしてんな自分とか、色々葛藤する中で、そんな自己の葛藤すらいらんから家族にとって大事なのはお金だな、というのを強く思うようになりました。もちろん技術力をつけたいという気持ちは今もありますが、自分がやりたいことが、家族を幸せにすることの方が上位にきてしまった、という感じです。そういう自分に起きる変化をちゃんと考えてなかった、というのは本当に本当に反省です。

転職活動はだいたい2軸で細々と行なっていました。

1つは都内で年収をドカンと上げるっていうのと、もう1つは地方でちょっとだけ上げるっていうのです。ご存知かもしれませんがモバイルの仕事って今ちょっとしたバブル状態でして、知り合い経由や転職ドラフトなどで、どちらもそれなりに良いお話は貰えて、結局フラー株式会社に行くことにしました。

新潟でアプリやりたい方はフラーさんへ。Webやりたい方はクーネルワークさんへ。そして農業であらゆるITをやりたい方はウォーターセルへお越しください。https://t.co/XKSkLcdaVq
— なかざん@Android入門本書きました (@Nkzn) March 13, 2018

(フラーを知るきっかけとなったNkznさんのツイート)

「なぜフラーに行くの?」

最初は年収とかそういうのきっかけの転職活動だったし、その目的はブレてなかったんですが、社長や立ち上げメンバーが高専生で、自身も高専生というのがあり、話してて「なんか昔から知り合いだった気がする」みたいな感覚があったのが実は結局は大きいかもしれないです。

後、フラーは本社が千葉県にあって、新潟にも拠点があります。新潟オフィスでは、長岡高専生に向けて講義も行なっていたり、フラーがインターンシップを積極的に開催したりなどと、教育とか後輩育成にも積極的です。僕は実は、人に何かを教えることが好きなのですがそういった文化とかが気に入ったのもあったり。( そして既にそういった活動にアサインされている)

自分は割と300~400人くらいの大きめの会社しか経験してこなかったのでここらでもう少し小さめの会社で「大きくしていくぞ」というフェーズを経験したいなというのもあったり。

多分、理由はもっとあるのですが、少しずつ「フラーの良いとこ」みたいな括りで後日紹介していけたらなぁと思います。

「なぜ新潟に行くの?」

元々は妻の実家が近いからです。あと単純に家賃が安いから(地方、本当家賃安い!!)です。一瞬、郊外にマンション買って〜というのも考えたのですが、通勤時間は割と無駄だと考えてるマンなので、それもないなという感じでした。

ただ、フラーの話を聞いているうちにふつふつと「地方でモバイルアプリだったり、東京でやってるようなWebの仕事が出来たら面白くない?というかそういう土壌を作れば良くない?出来ないわけなくない?面白そう!!」みたいな気持ちが出てきたというのも事実です。

僕はエンジニアの「技術をオープンにして共有しよう」という文化とか考え方が大好きです。でも、それをちゃんとやってる人はまだまだ東京に固まってるなと思ってるので、フラーという会社を利用して(良い意味で)、そういった志向の新潟で働くWeb系のエンジニアを増やしていきたいなと思っています。というか、フラーに入ってくれれば良いやという気持ちです。

「なんか意気込みをお願いします」

僕、たぶんめちゃめちゃ技術力が高い訳ではないかもです(もちろん、研鑽していくけど)。でもせこせこ動き回ったり、きっちりコミュニケーションとったり、気が利くやつみたいな、潤滑油みたいな、総合力みたいなとこで細かいポイント稼ぐやつみたいになれたらなと思っています。なので、新潟のエンジニアの方、雑に呼んでいただければ良い感じにあれこれしますので、そこんとこよろしくお願いします。

2018-10-25

Androidのfirebaseのコアライブラリを15.0.0以上にアップデートすると勝手に付与される「com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE」というパーミッション

雑に書く。

Androidアプリのfirebase周りのライブラリのバージョンを12.0.1から最新(16とか17あたり)にアップデートしようとしたら、アプリに表題の謎のパーミッションが付与されていた。

原因としては"com.google.firebase:firebase-core"というライブラリで、このライブラリの15.0.0以上を使おうとすると自動で

「com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE」

というパーミッションが付いてきていた。

ググると分かるけど、このパーミッションについての公式の情報が何も出てこなくてただただ、「これ、何なの?消して良いの?」みたいなstackoverflowしか出てこない。パッケージ名とパーミッション名からPlayStoreからのリファラを受け取るための何かなのだろうという予想はつくのだけど、それ以外のことが分からない。

設定で見ると、他のパーミッションは何かしら説明があるのだけど、これは無い。NORMALのパーミッションレベルだからそこまでセンシティブな情報を扱うものでは無いのだろうと予想はつくけど、何するのか分からなくてちょっと怖い。

困ったので、他の有名どころのアプリをいくつかダウンロードしてみると、このパーミッションがついていた。おそらく該当のライブラリを使っているのだろう。

このパーミッション自体を削除することは可能であるけど、消してどこかで動かなくなる方が怖いし、他のアプリでも使われてるなら大丈夫だろうという感じでFirebaseを信じることにしたけど、やっぱりもやっとする。

これの詳細が分かる強いエンジニアの方、何か分かることを教えてはくれませぬか。よろしくお願いいたします。