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

Kotlin で 非同期処理 Coroutine #1 ~ launch(), async()

ネット上を調べてみてもよくわかりません。

難しい言葉や experimental な仕様の変更などあったりして。

少しづつ試してみながらマスターしていきましょう。

// build.gradle

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:0.22.2"



//gradle.properties

kotlin.coroutines=enable

kotlinx.coroutines/coroutines-guide-ui.md at master · Kotlin/kotlinx.coroutines

まず、これ。


for (i in 1..10) {
  Timber.d("$i")
  Thread.sleep(1000)
}

非同期にしたいですよね。
launch から始めます。


launch { // @
  for (i in 1..10) {
    Timber.d("$i")
    Thread.sleep(1000)
  }
}




launch {
  for (i in 1..10) {
    Timber.d("$i")
    delay(1000)  // @
  }
}

引数をつけて渡す。

UI :
UIスレッドで実行。

CommonPool :
バックグランドスレッドで実行。


launch(UI) {  // @
  for (i in 1..10) {
    Timber.d("$i")
    delay(1000)
  }
}




launch(CommonPool) {  // @
  for (i in 1..10) {
    Timber.d("$i")
    delay(1000)
  }
}




launch(UI + CommonPool) {  // @
  for (i in 1..10) {
    Timber.d("$i")
    delay(1000)
  }
}

launch() の戻りからキャンセルできます。


val job = launch(UI) {  // @
  for (i in 1..10) {
    Timber.d("$i")
    delay(1000)
  }
}

fab.setOnClickListener {
  job.cancel() // @
}

 

まとめ

UIスレッドに限定されたコルーチンは、UIスレッドをブロックすることなく、UI内の何かを自由に更新して中断することができます。

delay が待っている間UIスレッドはブロックされないのでUIはフリーズしません。ただ単にコルーチンを中断します。

Job.cancelは完全にスレッドセーフでノンブロッキングです。
実際に終了するのを待つことなく、コルーチンがそのジョブをキャンセルするように通知するだけです。 どこからでも呼び出すことができます。

基本的な非同期呼び出しは、launch() と async() の2つ。似ているが戻りが異なる。