Android開発にはHiltとかDaoとかRoomとか新しい物出過ぎてて、本職じゃないとついていけねーー
Roomはいいとして、HiltってAndroid限定で依存関係まとめられる方法だし、転用考えるとほんとに便利なのか？？ #fedibird
@kyuphd
DIはAndroid以外でもとても有用ですよ～
Android含むKotlin全般用のライブラリだったらkoinとかも有名ですし、Webサーバーを作るためのSpringBootとかもDIの機能を含んでますね！
@mirror_kt
ご意見ありがとうございます、とっても助かります！
久々にまともなアプリを作ろうとして苦戦しまくっているので、ご教示いただいた単語周りを調べて理解を深めてみます。
@kyuphd ライブラリの使い方はドキュメントを読めばいいですが、それ以前の話として例えば今回の場合DIという概念への理解が必要そうです
概念がわかってないのにライブラリについて学んでも挫折するだけな気がしています
(私が前述したライブラリたちも、「hiltと同じDIという概念はAndroidの外でも有用だよ」の例示であって例示以上の意味(これらを学んでみろなど)は全くありません)
@kyuphd そもそもDIする上でライブラリは必須ではない(あると便利、というだけ)なのでまずは使わずにどういうものでどう便利なのかを知ってみるのも手です
@mirror_kt
DI自体は理解していて、公式documentの手動のもの(constructor内で依存性もたせるとか。個人的にはそれようのClass立てるのが好きですが)は別アプリでは使っているんですよ。
ただ、それをわざわざ外部ライブラリに依存させたほうがテストしやすいってところがいまいちという感じです。
コード生成で容量増えるのもガラケーアプリの100 kb制限とかで組んでた身からすると気持ち悪くて...
そのため、自分の中で手動DI納得のいくライブラリがあるか知りたい感じです。
もしくは、テストのしやすさがどこまで変わるかとか。
@kyuphd あぁなるほど…
(それ用のクラスを立てるのはDIではなくServiceLocatorパターンになってしまいそう、場合によってはアンチパターンですね)
hiltが生成するコードはボイラープレートを減らすものなので、コード生成をやめても結局人間が書くべきコードではあります
(コード生成したから容量が増えた、なんてことはないはず)
Androidの場合はライフサイクルが絡むので
「アプリの起動時にすべての依存関係を解決してインスタンスを作り、アプリの終了時に全部のインスタンスを破棄する」なんてことをやってしまうと、「今開いている画面では必要のないインスタンスがメモリを圧迫して、めちゃめちゃ重たいアプリの出来上がり」になってしまいます
かといって人力で「画面が変わったからこのインスタンスを作って～、これいらなくなったから破棄して～」も大変ですしここを失敗するとバグらせるので、ライブラリ任せにしたほうがテスタビリティは上がったりします
@mirror_kt
ありがとうございます！
一番理解できていないところがそのあたりみたいです。
ServiceLocaterはアンチパターンなんですね。
> 今開いてる画面では...
完全にこれでした。
一気に理解の解像度が上がって本当に助かりました。
@mirror_kt
元々が古のAction Scriptあたりからブログラミングを触り始めたので、独学すぎて基礎がボロボロなんですよね...
jsなどではちゃんとMVCとかのアーキテクチャで組むのは試してみたので、ライブラリ周りのお勉強をしているところです。