[Android]ライブラリーとGradleのバージョンを指定する技術
はじめに
このシリーズを初めての方はこちらです。
「最近Androidを始めた同僚のソースをモダン化計画 」シリーズ開始 ｜ Developers.IO
リリースを目指して作っているので、公開してまずいところは、一部改変しています。
前回復習
[Android]ライブラリーとGradleが古いバージョンを使っていると気づく技術 ｜ Developers.IO
古いバージョンを使っていると気づいたら、次は新しいバージョンに設定します。設定するだけと思いがちなんですが、ここよく考えたほうが良いです。長いプロジェクトや個人や趣味で放置しがちのプロジェクトほど、1周回って悩みどころなんです！
バージョン指定の方法
まずはどんな指定の仕方があるか洗い出します。無駄に選択肢がたくさんあります。皆さんはどれを使っていますか？
直接バージョンを指定する
愚直にバージョンを直接書きます。
1 | implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:0.22.5" |
+ で指定する
マイナーバージョンをいちいちアップデートしたりめんどいので+を使うと楽ですね。+ですると、その中でも一番新しいバージョンという指定ができます。
1 2 3 | implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:0.22.+"implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:0.+"implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:+" |
build.gradleで変数を使って指定する
メリットとしては、Android Supportライブラリーなどは全部同じバージョンを指定しないといけないですが、変数をつかってるので統一しやすいです。
設定例:
1 2 3 4 | ext.firebase_version = '16.0.1'implementation "com.google.firebase:firebase-core:$firebase_version"implementation "com.google.firebase:firebase-invites:$firebase_version" |
1 2 3 4 | def firebase_version = '16.0.1'implementation "com.google.firebase:firebase-core:$firebase_version"implementation "com.google.firebase:firebase-invites:$firebase_version" |
使用例
timber/build.gradle at master · JakeWharton/timber
gradle.propertiesを使って指定する
個人の感想ですが、メリットとしては、「build.gradleで変数を使って指定する」と同じですが、app/build.gradleは長くなりがちで、ファイルの途中にバージョン定義があったり探しにくいです gradle.propertiesに書くことで、指定箇所がわかりやすくなります。
設定例:
/gradle.properties
1 | support_lib_version=25.1.1 |
/app/build.gradle
1 | implementation "com.android.support:support-v4:${support_lib_version}" |
例：Droid Kaigi 2017
conference-app-2017/gradle.properties at master · DroidKaigi/conference-app-2017
conference-app-2017/build.gradle at master · DroidKaigi/conference-app-2017
1周回っての結論: 何も工夫せず直接バージョンを指定する
ええーっという方が多いと思うんですが、昔は僕も「+で指定するのめっちゃ楽ー。サポートライブラリーのバージョンを揃えるために変数つかって一気に指定するとか便利ー」とか思っていた時期がありました。直接バージョン指定するなど情弱っと。
今は、逆で1周回って「直接書いたほうが変な罠踏まないしメンテが楽で、変更も楽だな」と思うようになりました。
とはいえ、こればっかりは趣味の世界だと思います。チーム内でよく話し合って決めていただけばと思います。僕なりの結論を書きます。
古いバージョンに気づける
前回で説明した通り、古いバージョンのときは背景の色がつくので気づけます。
+ で指定した場合は、ずっとあの色の背景なので、気づけないんですよね。
ビルドがはやくなる
+ で指定している場合は、Android Studioでビルドや起動するたび最新版のチェックしてDLが走るので少し遅いです。バージョンが指定ある場合すでにDLしてたらチェックが走らないので早い。
オフラインモードでビルドできる
「ビルドがはやくなる」でチェックがはしるということはオンラインじゃないとビルドができないです。一度DLし終わった状態だとオフラインモードでのビルドは、めちゃめちゃ早いのでオススメです。
突然動かなくなったときの無駄な調査が発生しない
+ 指定の場合は、突然ビルドができなくなるっということが半年に一回ぐらい起きます。「そのときなんで？昨日までできたじゃん。。」パニック状態。+だとライブラリーのバージョンを気にしないで運用/開発してると思います。なので疑うのが一番最後なんですよね。ソースコードをもうめちゃめちゃ疑った後に途方にくれてbuild.gradleみて、「あっ」てなるやつです。
だめだったときに、もとに戻しやすい
これまた + のときです。 「突然動かなくなったときの無駄な調査が発生しない」で話した、突然動くなったときの対処が難しい。どのバージョンで動いてたっけ？っという不毛な調査することになります。だって一度もバージョンを確認していないのだから、コミット履歴みても成功していたバージョンがわからない。一つずつバージョンあげてみてテストしたりなどをします。つらい。
意外と変更が簡単
変数だとあまりに触らないから、影響範囲が忘れがち 変数系にいえることなんですが、バージョン変更が意外と面倒で、ここ書き換えるとどこ変わるんだっけ？結局最新バージョンいくつに変更するんだっけ？って何往復かしてしまいます。月に1回、3ヶ月1回しか触らないので、影響範囲を忘れています。
100歩譲って、そこはまぁ我慢しよう。バージョンの更新ちょっとストレスがあるんです。
変数だとAndroid Studioがいい感じに変えてくれない
変数系でもAndroid Studioで気づくことはできるんですが、Android Studioが変えてくれないんです。
前回Android Stuidioがいい感じにバージョンを編集してくれるので、メッセージ読んで「Alt Enter or Option Enter」 して、動作確認してだめだったら前に戻すっていうことも簡単にできます。Support Libraryとかの揃えるのめんどくさい？っと思うと思うのですが、更新のタイミングをそろえるとAlt Enter or Option Enterで最新に変えていくと全部バージョンが揃うのであんまり困っていません。
以上の点で趣味でもプロダクトでも、僕は1周回って直接バージョンを指定しています。
これはすべてAndroid Studioさんが優秀すぎるからです。
まとめ
「Droid Kaigiとかイケイケのプロジェクトは変数とか使って指定してるよ！今どき直接バージョンしてるとか、ふっるい〜。この情弱めが！」っと言われても、僕は理由を説明します。
好みの問題もあるので、チームでメリット・デメリットをよく話し合い決めていただければ思います。
