Upgrade to Pro — share decks privately, control downloads, hide ads and more …

cookpad.apk#5

Kyohei Kato
June 24, 2020
480

 cookpad.apk#5

Kyohei Kato

June 24, 2020
Tweet

Transcript

  1. DI フレームワークの変遷 RoboGuice (? ~ 2018) Toothpick (2018 ~ 2019)

    KOIN (2019 ~ 2020) Dagger (2020 ~) 移行を担当 見直し 見直し
  2. RoboGuice • https://github.com/roboguice/roboguice ◦ Google Guice をAndroid に転用したもの • リフレクションベースの

    DI フレームワーク • 恐らくクックパッドアプリに入った最初の DI フレームワーク
  3. 利用方針 • 主にインスタンス生成を省略するために利用 • Activity や Fragment から値を注入 • DI

    フレームワークの利用ルールはなく、開発者の裁量にあわせて利用 ◦ 複雑に絡み合うオブジェクトの依存関係
  4. Toothpick の選定理由 • 移行にあたって利用方針の見直しは行われないことに • 乗り換え先として Dagger, Toothpick が上がる ◦

    元々 RoboGuice を上手く活用できておらず、 Dagger の複雑さと学習コストに対して得られるも のが少ない ◦ 縦横無尽な利用方法を整備する上では Dagger の方が強制力がある ◦ Toothpick の方が移行が容易 • 構造がシンプルで移行が比較的容易な Toothpick を選定
  5. KOIN • https://github.com/InsertKoinIO/koin • Kotlin ベースのジェネリクスと Delegated Properties を利用した DI

    フレームワーク • 依存グラフは実行時に Map 上で構築される ◦ Lazy Properties として Map に対してオブジェクトをリクエストする
  6. KOIN の選定理由 • アノテーションプロセッサを利用しない DI フレームワークを探し始める ◦ 移行の容易さ、DI フレームワークの利用の見直しも同時に行う •

    KOIN, Kodein, Dagger が候補に上がる • 導入のしやすさが決め手に ◦ 巨大な Map 構造を築くだけで、初学者にも理解しやすい ◦ パフォーマンス面も申し分なし ◦ アノテーションプロセッサによるコンパイル時間の増加を回避できる ◦ Kotlin コードが拡充しつつあった
  7. VIPER + レイヤードアーキテクチャにおける利用 • VIPER + レイヤードアーキテクチャの上で扱うオブジェクトの生成を DI フレームワークを介して行うよ うに

    • オブジェクト間はすべてインタフェースを介して会話 ◦ オブジェクト生成をすべて任せることで、実体を知らずに済むように ◦ テスト実行時にオブジェクトのすり替えが可能に
  8. Dagger Hilt • 実は移行を進めているタイミングで知らなかった … • 更にアノテーションプロセッサによるコードジェネレーションが強まる ◦ アノテーションだけつければ良くなる時代へ ◦

    初学者の学習コスト軽減 • クックパッドアプリを題材に移行を試みたブログを書いたのでよければ ◦ https://ksfee.hatenablog.jp/entry/2020/06/17/033304