全体の概要からの続きみたいなもの。 前回がアプリ開発を始める時にざーっと考える（ベースであればとりあえず開発が開始できる）話だとすると、今回はアプリを作る時に何を組み合わせるかと言う話にしたいなと思っています。
去年のエントリがこちら。
雑感
「今から新規でアプリを作ります」という時に選択するライブラリについて、技術として2019年から2020年にかけて大きく変わったと言う印象はありません。 このため、ライブラリの選定が変わったもの以上にライブラリの枠組みが変わった点を2点あげ、ライブラリの読み方を書いておきたいと思います。
ktx
ktx は様々なライブラリのKotlin用拡張関数ライブラリです。
リリース時の資料なんかはこちら。
All of the Android KTX libraries are now available for contribution in AOSP: https://t.co/uIGPuQLSzg. Look for 'ktx' folders nested inside of the artifact to which they apply. For example, `collection/ktx/`. If you can think of new ones, those are also welcome.
— Jake Wharton (@JakeWharton) 2018年7月24日
Android Jetpackでも提供されている core-ktx や、fragment-ktx などは知らない間に使っているかもしれません。
一応コードを引用して紹介しておくと、ktxを使わないケースと使うケースが次のようになります。
// 使わない sharedPreferences .edit() // create an Editor .putBoolean("key", value) .apply() // 使う sharedPreferences.edit { putBoolean("key", value) } // 使わない sharedPreferences .edit() // create an Editor .putBoolean("key", value) .commit() // 使う sharedPreferences.edit(commit = true) { putBoolean("key", value) }
この時、ktxで提供されているのは次のような拡張関数です。
inline fun SharedPreferences.edit(
commit: Boolean = false,
action: SharedPreferences.Editor.() -> Unit)
ktxは「Kotlinでライブラリを利用する時に、利用を簡単に/便利にする」ような位置付けであって、Kotlinのプロジェクトでも別に必須のものではありません。 2020年に大きく変わったのは、様々なライブラリがktxの提供を始めたことです。
例えば、Firebaseにktxが追加されるようになりました。 個人の経験になりますが、下記のktxは実際に利用して（それなりに）メリットを感じています。
また、3rd partyのライブラリでもktxが提供される流れもあります。 ライブラリの選定時にktxが提供されているかを調べてみるのも良さそうです。 （後述のCoilのように、そもそもKotlinで作りJavaでも利用できるようにしているライブラリもあるので、数年後にはktxは消えているかもしれませんが）
For those who are using PermissionsDispatcher but not a huge fun of kapt, we just started providing permissionsdispatcher-ktx which does't depend on annotation processing😉
— hotchemi (@hotchemi) 2020年3月25日
Since it's still in alpha stage we're looking forward to your feedback!🙏https://t.co/i7PagPnRpf pic.twitter.com/knhGlK1QQ3
※注意、PermissionsDispatcherのktxは2020年4月5日時点でalphaリリースです
BOM
Android向けのライブラリがBOM(bill of materials)に対応するようになりました。 利用シーンが多いのはFirebaseやOkHttpではないかと思います。
- Firebase
- OkHttp
BOMGradle 5.0より導入された機能になります。 この機能を用いると、BOMで管理されるライブラリのバージョンをそれぞれ指定する必要がなくなります。
SpringのBOMなどは割と利用されている印象があるので、サーバーサイドの方からすると「ようやくか」というところかもしれません。
https://mvnrepository.com/artifact/org.springframework/spring-framework-bommvnrepository.com
FirebaseやOkHttpのような一つのライブラリの中でも複数のモジュールが存在するもの、またライブラリの中でも依存してる可能性が高いものについて。 BOMの活用によりより快適なビルド環境が構築されそうな予感がしています。
ライブラリ
Android Jetpack
TargetSDKの関係でAndroid Jetpackの利用をする年となりました。
旧来のsupport libは28の時期までしか更新されていないため、29以降が必須となる今年はAndroid Jetpackに移行する(AndroidXライブラリに移行する)必要があります。 とはいえ少し古い資料を参考にしつつAndroidXへのマイグレーション処理を行えば、旧来のバージョンからの変更を行うのは難しくありません。
大変なのは、AndroidXになり新たに提案されつつあるAPI更新に対応することです。 特に変更が大きいクラスはFragmentでしょう。
Fragmentを利用してアプリを作成する場合には、1.0.0から最新までの変更点を全て確認することを強くお勧めします。
Network
REST APIであればOkHttp + Retrofit2 + Moshi-Codegen、GraphQLであればOkHttp + Apollo-Androidになるかと思います。 gRPCの場合は……リファレンスを参考に実装することになるかと。
OkHttpとRetrofit、MoshiがKotlinでリライトされました。 一時期移行に伴う不具合が散見されましたが、2020年4月5日時点では収束したと言えます。
昨年からの大きな変更としては、Gsonが下火になったことではないでしょうか。 下記の問題はGsonの利用を続けることを非常に難しくしました。
確認したところ開発が続いているようですが、KotlinとGsonの仕組みの相性がよくない（ハズ）のため、新規に開発を行うのであればMoshi-Codegenをお勧めします。
DI
Android Developerにページができました。
Daggerの使い方も記載されるようになり、今後より書きやすくする対応を始めているところのようなので、Daggerを選んでおけば良いと思います。
Image
現時点では下記4つの選択肢があります。
このうち、Picassoは（開発が動いている様子はあるのですが）リリースが止まっているためお勧めできません。
Frescoは ImageView の代わりに com.facebook.drawee.view.SimpleDraweeView を利用する点などがあるため、ライブラリへの依存が（他のライブラリに比べると）強くなってしまう印象があります。このため、自分はあまり選択しようと言う気持ちになりません。
GlideとCoilを比べると、Glideの方が（歴史が長いため）APIの変更などの開発が少なく、使用例も豊富な印象です。 一方でCoilは0.9.5になりstableリリース間近であることや、Glideに比べてメソッド数が少ないことなどから、利用しても良いかなと感じるようになっています。
ゼロからKotlinでアプリを作るのであれば、Coilで開発を始めてみても良いのではないでしょうか。
Other
ViewBinding
ライブラリに含めるか迷ったのですが、一旦ここで。
リンクの内容そのままなのですが findViewById を使わなくてよくなるライブラリです。
DataBindingじゃないかと言う気もすると思うのですが、データのバインドをしないケースならViewBindingを利用できるようになりました。
これにより、ButterKnifeがDeprecatedになりました。 古いプロジェクトであれば、これの影響が一番大きいのではないかと思います。
PermissionsDispatcher
RxJavaではなくKotlin Coroutinesを使うのであればRxPermissionsを使う必要性も低いと思うので、Androidのパーミッション周りで困ったら使いましょう。 先述の通りktxによる利用も、kaptを利用する場合もincremental buildへの対応もされているので、それなりのPCを利用していればビルドで気になることはないと思います。
ThreeTenABP
LocalDate や OffsetDateTime などのJava8で提供されるTime & Date APIをAndroidで利用するためのライブラリです。
新規アプリであればAndroid O以降を対象にして開発が開始されるであろうことや（しますよね？）、Android Gradle Pluging 4系で入るJava8 APIのR8によるDesugarにより、来年には不要になっていそうです。
一部のライブラリが依存していることもあるので、ゆっくりとライブラリ側の対応を待ちつつ（もしくはPRを作りつつ）、移行していく1年になりそうです。 本当にお世話になりました。
終わりに
ざっくり書くつもりが去年よりも長いエントリになってしまいました。 若干誰得な話になっている気がするのですが、本エントリが開発の助けになれば幸いです。
