あなたの build.gradle バージョン記述、きもいです。

きもいですよ。

こう書いていたり、


minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion

こう書いてたり、


dependencies {
  implementation "com.android.support:appcompat-v7:$rootProject.supportLibraryVersion"
  implementation "com.android.support:support-v4:$rootProject.supportLibraryVersion"
  implementation "com.android.support:design:$rootProject.supportLibraryVersion"

「変数を使ってまとめました!」とか言ってるけど。

きもいですよ。

そもそも、定義の位置がヘボいのですよ。

 

書いてたのは私です。

以下のように書いてました。

root/build.gradle


ext {

  minSdkVersion = 24
  targetSdkVersion = 27
  compileSdkVersion = 27
  buildToolsVersion = '27.0.2'

  supportLibraryVersion = '27.1.0'
  firebaseVersion = '11.8.0'

}

これのせいで、「${rootProject.firebaseVersion」とか「rootProject.ext.***」とかダラダラ書く羽目になるようです。

stackoverflow も今やゴミのだらけでどれが正しいのか分かりづらいです。

 

神はこのように書いていた。

root/build.gradle


buildscript {

  ext.buildConfig = [
      'compileSdk': 27,
      'minSdk': 24,
      'targetSdk': 27
  ]

  ext.versions = [
      'supportLibrary': '27.1.0',
      'kotlin': '1.2.30',
      'okhttp': '3.10.0',
      'retrofit': '2.3.0',
      'kotshi': '1.0.1',
      'dagger': '2.15',
  ]

ブロック buildscript {} 内に map ですっきり記述しています。

module/build.gradle


android {

  compileSdkVersion buildConfig.compileSdk

  defaultConfig {

    minSdkVersion buildConfig.minSdk
    targetSdkVersion buildConfig.targetSdk

    versionCode buildConfig.versionCode
    versionName buildConfig.versionName

  }
}

// ....

dependencies {

  implementation "org.jetbrains.kotlin:kotlin-stdlib:${versions.kotlin}"
  implementation "com.android.support:appcompat-v7:${versions.supportLibrary}"
  implementation "com.android.support:support-v4:${versions.supportLibrary}"
  implementation "com.android.support:design:${versions.supportLibrary}"

  implementation "com.google.firebase:firebase-core:${versions.firebase}"
  implementation "com.google.firebase:firebase-auth:${versions.firebase}"

定形なテンプレートとして使えます。

参照する際は、「rootProject」とか「ext」の単語は不要です。

 

関連の以下も必須だろうと思います。

サポートライブラリのバージョンを揃える

👉 【Gradle Version Catalog】libs.versions.toml キー名の形式 camelCase vs kebab-case hatena-bookmark

Flip Tables で List を見やすくログに表示する

安定のJake産です。

JakeWharton/flip-tables: Because pretty-printing text tables in Java should be easy.

例えば、ログに、List<Item> を


println(list)

このように表示されているのが、


I/System.out: [Item(exchange=quoine, pair=bchjpy, price=127989.3), Item(exchange=bitflyer, pair=btcfxjpy, price=1073351.0), Item(exchange=kraken, pair=btcjpy, price=1046576.0), Item(exchange=bitflyer, pair=btcjpy, price=1038000.0), Item(exchange=quoine, pair=btcjpy, price=1035870.94), Item(exchange=kraken, pair=ethjpy, price=91402.0), Item(exchange=quoine, pair=ethjpy, price=90595.82), Item(exchange=kraken, pair=xrpjpy, price=109.815), Item(exchange=kraken, pair=zecjpy, price=41855.0)]

こう書くだけで、


println(FlipTableConverters.fromIterable(list, Item::class.java))

こんなテキストで表で整形されて表示されます。


I/System.out: ╔══════════╤══════════╤════════════╗
I/System.out: ║ Exchange │ Pair     │ Price      ║
I/System.out: ╠══════════╪══════════╪════════════╣
I/System.out: ║ quoine   │ bchjpy   │ 127989.3   ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ bitflyer │ btcfxjpy │ 1073351.0  ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ kraken   │ btcjpy   │ 1046576.0  ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ bitflyer │ btcjpy   │ 1038000.0  ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ quoine   │ btcjpy   │ 1035870.94 ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ kraken   │ ethjpy   │ 91402.0    ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ quoine   │ ethjpy   │ 90595.82   ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ kraken   │ xrpjpy   │ 109.815    ║
I/System.out: ╟──────────┼──────────┼────────────╢
I/System.out: ║ kraken   │ zecjpy   │ 41855.0    ║
I/System.out: ╚══════════╧══════════╧════════════╝

数秒で使えます。

 

なんだかスッキリな気分となったりで気分転換にもよいですよー。

今後は「イベントリスナー」は書かずに「イベントハンドラー」を書け!?

「イベントリスナー」と「イベントハンドラー」て分かってるようで分かってないような。

特に, Kotlin では混乱します。

一般的に「リスナー」と「ハンドラー」は定義として

「リスナーは起動するイベントを監視するもの」

「ハンドラーはイベントの処理を担当するもの」

混乱の原因として、同じオブジェクトをイベントのために監視(Listen)して処理(Handle)することがよくあります。

無名クラスをリスナーとしてセットして、それのメソッドがハンドラーのパターン。


cancelImage.setOnClickListener(object : View.OnClickListener { // 1
    override fun onClick(v: View?) { // 2
        dismiss()
    }
})

// 1 -> リスナー
// 2 -> ハンドラー

また、以下のようにリスナーと名前をつけてクラスを作ることができます。


class OnCancelSnackListener(
    val snackbar: Snackbar
): View.OnClickListener {
    override fun onClick(v: View?) {
        snackbar.dismiss()
    }
}

使い方:


cancelImage.setOnClickListener(OnCancelSnackListener(this))

一般的に、リスナーは「***Listener」、ハンドラーは「On***」と命名されます。

問題なのはラムダ記述の場合です。


cancelImage.setOnClickListener { dismiss() }

どれが「リスナー」なのか「ハンドラー」なのか。

リスナーオブジェクトは、Kotlinでは隠れてしまいます。

これは、setOnClickHandler と書くべきではないのかと思えたります。

ExJSなどjavascriptライブラリでは以下のような記述があります。


handler: function() {
}

listeners: {
   'click': function() {
   }
}

これらのJavaや他の言語の接尾語「***Listener」を使う慣習は歴史的な理由なだけです。

Kotlin stdlib や JetBrains のコードからそのことを確認できます。

自信をもって以下のように書きましょう。


fun setOnLoadedListener(handler: () -> Unit) {
   // Code
}
fun addOnFlingListener(handler: () -> Unit) {
   // Code
}

これまでどおり以下のようにも書くことができます。


fun setOnLoadedListener(listener: () -> Unit) {
   // Code
}
fun addOnFlingListener(listener: () -> Unit) {
   // Code
}

プロジェクトごとにどちらかに統一するのが良いでしょう。とな。

イベントハンドラとラムダ

Programmer dictionary: Event listener vs event handler