Continuity is The Father of Success

Androidアプリとかゲームとか。毎日続けてるものについて。

Androidアプリ開発を始める 2020年春版 ライブラリ編

全体の概要からの続きみたいなもの。 前回がアプリ開発を始める時にざーっと考える(ベースであればとりあえず開発が開始できる)話だとすると、今回はアプリを作る時に何を組み合わせるかと言う話にしたいなと思っています。

blog.dr1009.com

去年のエントリがこちら。

blog.dr1009.com

雑感

「今から新規でアプリを作ります」という時に選択するライブラリについて、技術として2019年から2020年にかけて大きく変わったと言う印象はありません。 このため、ライブラリの選定が変わったもの以上にライブラリの枠組みが変わった点を2点あげ、ライブラリの読み方を書いておきたいと思います。

ktx

ktx は様々なライブラリのKotlin用拡張関数ライブラリです。 リリース時の資料なんかはこちら。

jakewharton.com

Android Jetpackでも提供されている core-ktx や、fragment-ktx などは知らない間に使っているかもしれません。

developer.android.com

一応コードを引用して紹介しておくと、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は消えているかもしれませんが)

github.com

※注意、PermissionsDispatcherのktxは2020年4月5日時点でalphaリリースです

BOM

docs.gradle.org

Android向けのライブラリがBOM(bill of materials)に対応するようになりました。 利用シーンが多いのはFirebaseやOkHttpではないかと思います。

BOMGradle 5.0より導入された機能になります。 この機能を用いると、BOMで管理されるライブラリのバージョンをそれぞれ指定する必要がなくなります。

firebase.google.com

SpringのBOMなどは割と利用されている印象があるので、サーバーサイドの方からすると「ようやくか」というところかもしれません。

mvnrepository.com

FirebaseやOkHttpのような一つのライブラリの中でも複数のモジュールが存在するもの、またライブラリの中でも依存してる可能性が高いものについて。 BOMの活用によりより快適なビルド環境が構築されそうな予感がしています。

ライブラリ

Android Jetpack

developer.android.com

TargetSDKの関係でAndroid Jetpackの利用をする年となりました。

developer.android.com

旧来のsupport libは28の時期までしか更新されていないため、29以降が必須となる今年はAndroid Jetpackに移行する(AndroidXライブラリに移行する)必要があります。 とはいえ少し古い資料を参考にしつつAndroidXへのマイグレーション処理を行えば、旧来のバージョンからの変更を行うのは難しくありません。

大変なのは、AndroidXになり新たに提案されつつあるAPI更新に対応することです。 特に変更が大きいクラスはFragmentでしょう。

developer.android.com

Fragmentを利用してアプリを作成する場合には、1.0.0から最新までの変更点を全て確認することを強くお勧めします。

Network

square.github.io

square.github.io

github.com

github.com

REST APIであればOkHttp + Retrofit2 + Moshi-Codegen、GraphQLであればOkHttp + Apollo-Androidになるかと思います。 gRPCの場合は……リファレンスを参考に実装することになるかと。

OkHttpとRetrofit、MoshiがKotlinでリライトされました。 一時期移行に伴う不具合が散見されましたが、2020年4月5日時点では収束したと言えます。

昨年からの大きな変更としては、Gsonが下火になったことではないでしょうか。 下記の問題はGsonの利用を続けることを非常に難しくしました。

r8.googlesource.com

確認したところ開発が続いているようですが、KotlinとGsonの仕組みの相性がよくない(ハズ)のため、新規に開発を行うのであればMoshi-Codegenをお勧めします。

github.com

DI

Android Developerにページができました。

developer.android.com

Daggerの使い方も記載されるようになり、今後より書きやすくする対応を始めているところのようなので、Daggerを選んでおけば良いと思います。

developer.android.com

dagger.dev

medium.com

Image

developer.android.com

現時点では下記4つの選択肢があります。 このうち、Picassoは(開発が動いている様子はあるのですが)リリースが止まっているためお勧めできません。 Frescoは ImageView の代わりに com.facebook.drawee.view.SimpleDraweeView を利用する点などがあるため、ライブラリへの依存が(他のライブラリに比べると)強くなってしまう印象があります。このため、自分はあまり選択しようと言う気持ちになりません。

GlideとCoilを比べると、Glideの方が(歴史が長いため)APIの変更などの開発が少なく、使用例も豊富な印象です。 一方でCoilは0.9.5になりstableリリース間近であることや、Glideに比べてメソッド数が少ないことなどから、利用しても良いかなと感じるようになっています。

ゼロからKotlinでアプリを作るのであれば、Coilで開発を始めてみても良いのではないでしょうか。

Other

ViewBinding

ライブラリに含めるか迷ったのですが、一旦ここで。

developer.android.com

medium.com

リンクの内容そのままなのですが findViewById を使わなくてよくなるライブラリです。 DataBindingじゃないかと言う気もすると思うのですが、データのバインドをしないケースならViewBindingを利用できるようになりました。

これにより、ButterKnifeがDeprecatedになりました。 古いプロジェクトであれば、これの影響が一番大きいのではないかと思います。

github.com

PermissionsDispatcher

github.com

RxJavaではなくKotlin Coroutinesを使うのであればRxPermissionsを使う必要性も低いと思うので、Androidパーミッション周りで困ったら使いましょう。 先述の通りktxによる利用も、kaptを利用する場合もincremental buildへの対応もされているので、それなりのPCを利用していればビルドで気になることはないと思います。

ThreeTenABP

github.com

LocalDateOffsetDateTime などのJava8で提供されるTime & Date APIAndroidで利用するためのライブラリです。 新規アプリであればAndroid O以降を対象にして開発が開始されるであろうことや(しますよね?)、Android Gradle Pluging 4系で入るJava8 APIのR8によるDesugarにより、来年には不要になっていそうです。

jakewharton.com

一部のライブラリが依存していることもあるので、ゆっくりとライブラリ側の対応を待ちつつ(もしくはPRを作りつつ)、移行していく1年になりそうです。 本当にお世話になりました。

終わりに

ざっくり書くつもりが去年よりも長いエントリになってしまいました。 若干誰得な話になっている気がするのですが、本エントリが開発の助けになれば幸いです。