DroidKaigi2024で見たセッションのメモ(当日編)+所感

今年も[DroidKaigi](https://2024.droidkaigi.jp/)に参加してきました。スピード重視で記憶があるうちにセッションを聞いた感想や学びを書いていきたいと思います。

なお、以下は私の所感でありAsk the speakerしたものも自分の受け止め方であるため、参考程度にしていただけると幸いです。正確には実際のセッションを聞いていただけると幸いです。

## [Contextを理解する](https://2024.droidkaigi.jp/timetable/694464/)
Contextの意味づけから入り、なんとなくで使っていたContextを上手に言語化されており、Contextに対するもやもやを解消できたと思います。

activityContextとapplicationContextはライフサイクルを意識する必要があるという話も出てきます。
またライブラリによってはactivityContextを渡しても内部ではapplicationContextになっており、直感に反して動くようです(->workManager)。このあたり注意しておかないと勘違いしそうだと思いました。

## [たすけて！ViewModel](https://2024.droidkaigi.jp/timetable/694231/)
hidaka氏のセッションで、ViewModelについて包括的に話されています。
私も購入した同氏の[技術書](https://booth.pm/ja/items/5748877)もわかりやすいです。

初期化処理をinitでやるか、外から手動でやるか、reactive streamにするかの話はよく目にします。
以下のような記事を最近見ました。
- [Mastering Android ViewModels: Essential Dos and Don’ts Part 1 🛠️ \| by Reza \| ProAndroidDev](https://proandroiddev.com/mastering-android-viewmodels-essential-dos-and-donts-part-1-%EF%B8%8F-bdf05287bca9)
- [Loading Initial Data in LaunchedEffect vs\. ViewModel \| by Jaewoong Eum \(skydoves\) \| ProAndroidDev](https://proandroiddev.com/loading-initial-data-in-launchedeffect-vs-viewmodel-f1747c20ce62)

基本reactive streamが筋が良いようですが、セッションであったとおりプロジェクトの状況に応じて何がよいか、チームで判断しないといけない、というのはそうだと思いました。

またViewModelは今後どうなっていくかというのは開発者にとって重要なテーマだと思います。

DrodikaigiのリポジトリもViewModelがなくなっています。[Circuit](https://slackhq.github.io/circuit/)というライブラリも出てきてたり、ViewModelがなくなっていく動きがあります。登壇者もViewModelは必須でないとしています。ViewModelを使わないやり方だとシンプルにでき、複雑なアプリだと効力を発揮します。

しかし反面ViewModelのメリットはやはりGoogle公式サポートということでドキュメントや関連記事、サンプルも充実しているということです。

このあたり私もViewModelをどうするかは悩みどころで、こっちにすべきだという答えを言ってもらえればどれだけ楽かと思います。しかし現実はそうではなくチーム状況やプロジェクトによっても最適解が変わります。そのあたりは悩んで自分なりに回答を見つけるしかありません。難しいところではありますが、反面楽しいところでもあります。

## [海外就職というキャリアの選択肢](https://2024.droidkaigi.jp/timetable/691330/)
自分がやるかは別にして、海外キャリアには前々から興味があったので拝見しました。

実際の経験を踏まえており、かなり具体性のある内容でした。なかなか聞ける話ではないので、面白く、興味のあるエンジニアなら最初に見てほしいくらいの内容だと思います。

面白かったこととして海外と日本のモバイルエンジニアの違いです。海外ではiOSのシェアが日本よりも低かったり、多言語対応が前提となるところなど、開発の進め方も違ってくるようです。

いきなり転職はハードルが高いですが、少しずつやる方法もありました。ワーホリとアウトソーシングプラットフォームで仕事を取る方法です。前者は自分は資格がないので後者ですが、Ask the speakerにて具体的なおすすめのサイトを教えていただきました。すぐに取り掛かることはないですが、手持ちの選択肢を多く持っておくのは良いと思います。

## DroidKaigi App developer's Fireside chat
DroidKaigiのアプリについてiOS担当のitoさんとtakahiromさんが公式アプリについて話されています。オフレコということなのでこちらを聞きに行きました。アーキテキチャの話は面白い話ばかりで充実した時間になりました。

Repositoryでcomposable関数を使っている話とか、Circuitから着想を得たRin(輪)ライブラリの話、BDDでwhatとhowの部分を分ける話だとか、非常に面白い内容でした。

Q&Aで上がっていた質問で、repositoryのインスタンスを最初に作ってしまっているのがパフォーマンスの観点から課題だということです。使うときにインスタンスを作るのが望ましいですが、リポジトリではわかりやすさのために許容しているとのことです。

## [アプリをリリースできる状態に保ったまま段階的にリファクタリングするための戦略と戦術](https://2024.droidkaigi.jp/timetable/690441/)
こちらはレガシープロジェクトをどうやってリファクタリングするかという内容で、ノウハウが詰まっています。

最初から気になるところをリファクタリングしはじめようとするのを一旦控えて、手順を取ることが大切です。まず環境構築し、依存の少ないデータ層->UIの向きでリファクタリングしていくとよいとのことです。

なかでもフォーマットチェックを最初に入れるというのは重要ではないかと思います。やらなくても動くので後回しになりがちですが、最初にやるべきだと思いました。CIも同じですね。

またモジュール分割をやりすぎないとか、data層のテストとかの話も聞けて良かったです。

[追記]Kotlin Festでできなかった発表の内容が

## [Jetpack ComposeにおけるShared Element Transitionsの実例と導入方法 またその仕組み](https://2024.droidkaigi.jp/timetable/693259/)
単純な使い方は調べれば出てくると思いますが、実務で詰まりそうな課題に対してのアプローチもあり、使うときには役立ちそうです。

Ask the speakerで聞いたのですが、iOSはすでにこういったトランジションは用意されていて、Androidも同じようにできないか、という要望があるようですね。DroidKaigiのアプリにはSharedElementTransitionが使われていて、いい感じになっていました。開発者からも提案していってもよいと思うので、やっていきたいところです。

## [データに基づく意思決定を支える、Google Analytics for Firebase のイベント送信](https://2024.droidkaigi.jp/timetable/678050/)


(追記：セッションタイトル間違えてたので修正しました)

分析の話とその実装方法の話があり、実践的な内容でした。

Analyticsをラップしたヘルパー関数の実装方法の話とか、Android開発においてどう実装していくかという話があります。

また自動コード生成や画面遷移イベントの実装漏れを防ぐ内容もありすぐにでも使いたくなりました。DetektやKonsistを使って実装漏れを検出するようです。

最近[modifierを指定するだけでログイベントを送信する方法](https://proandroiddev.com/add-powerful-analytics-modifiers-in-jetpack-compose-with-modifierlocal-399e3f8b7914)を見たのですが、こちらの方法を使っても実装漏れの検出はできる気がします(まだ試していない)。

## [Androidアプリのスクリーンショットテストをマスターする](https://2024.droidkaigi.jp/timetable/693281/)
roborazziと公式のスクリーンショットテストをわかりやすく比較しています。

こちらShowCaseを使ってすべての@Previewアノテーションがついた画面をスクショする方法が紹介されています。

全部撮る必要あるのか？と思って質問したところ撮っているようですね。画面単位でなく小さいコンポーネントのPreviewも撮っているとのこと。@Previewを付けるようなコンポーネントのテストはいろいろなところで使われることが多いと思います。そういうコンポーネントは影響範囲も大きいので見ておいたほうがいいとのことでした。

## [Debugging: All You Need to Know](https://2024.droidkaigi.jp/timetable/694440/)
かなり得るものが多かったセッション。

print debugでなく、Debuggerの機能を使おうという内容。自分がDebuggerのほんの一部しか使っていないとわかりました。

print debugはよくよく考えると試行回数が多く時間がかかってしまいます。デバッグは開発で占める時間が多いので、効率よくデバッグするのは重要です。

これを機にDebbugerをいろいろ試してみて、print debugを卒業していきたいです。

## [Android開発以外のAndroid開発経験の活かしどころ](https://2024.droidkaigi.jp/timetable/693873/)
登壇者の自己紹介から入っていきますが、そのなかでDroidKaigiやOSSのリポジトリの歴史に触れられていました。自分はそのあたり知らなかったので面白かったです。

セッションを聞いて、ちょっと主題とは違うかもしれないんですが、自分はもうちょっと他の技術に触れていきたいなと思いました。最近はAndroidしかほとんど触っていないので、他の技術もまた触れてみたいなと。

非常にエモい内容で、モチベーションを掻き立てられる内容でした。


## 所感
### Droidkaigiリポジトリへのcontribute
去年はすごく細かい一つのプルリクを出していただけですが、今回はちゃんとしたものも含めて合計6つほど出しました。Issueも出していました。

takahiromさんにレビューいただいてアドバイスも頂き大変勉強になりました。また他の方が書いたコードを見るだけで勉強になります。

実はDroidKaigiのリポジトリが出る少し前からOSSへのcontributeを少しずつやっていました。習慣になってきているのでこの流れは続けていきたいです。

### Droidkaigiへの望み方
セッションに出てる人は発表に向けて綿密に調査し、その分野を第一人者と見て良いと思います。
無料でコンサルしてもらえるようなもので、Ask the speakerはぜひとも活用したいところです。自分のプロジェクトで困っているところを聞きましょう。

セッションは興味あるものを見る、というのももちろんアリですが、一つの方法として、当日のセッションはAsk the speakerで聞きたいことがあるものを見に行く、というのがおすすめです。

興味あるセッションは事前に予習して質問を考えておくとなお良いです。（自分は今回そこまで考えられていませんでした）

### カンファレンスを通じて感じたこと
Droidkaigiは本当に良い雰囲気ですね。
発表する人に向けて、本番の前に、主催者さんがねぎらいの言葉を掛けていらっしゃったのが印象的でした。

今回私はプロポーザルを出していたものの残念ながら採用されませんでした。ハードルは高いですが来年も出せたらなと思います。