【Kotlin】coroutine 複数の非同期処理をまとめてキャンセルする

非同期処理には必ず絡んでくるのがライフサイクル。

RxJava のようにまとめたいですよね。


private CompositeDisposable compositeDisposable =
    new CompositeDisposable();

@Override public void onCreate() {
  compositeDisposable.add(backendApi.loadUser()
      .subscribe(this::displayUser, this::handleError));
}

@Override public void onDestroy() {
  compositeDisposable.clear();
}

SendChannel を使って同様にこのような。


interface JobHolder {
  val job: Job
}


class MainActivity : AppCompatActivity(), JobHolder {

  override val job: Job = Job()

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    addJob {
      while (true) {
        delay(500)
        println("A")
      }
    }

    addJob {
      while (true) {
        delay(1000)
        println("B")
      }
    }

  }

  // Job の actor として action を登録する
  private fun addJob(action: suspend () -> Unit) {

    val actor = actor<Unit>(job + UI, capacity = Channel.CONFLATED) {
      for (event in channel) action()
    }
    actor.offer(Unit)
  }


  override fun onDestroy() {
    super.onDestroy()
    job.cancel()
  }

}

まとめてキャンセルできましたね!

どうせなら作って置いたらどうだろう。


class JobHolder {

  private val job = Job()

  fun add(action: suspend () -> Unit) {
    val actor = actor<Unit>(job + UI, capacity = Channel.CONFLATED) {
      for (event in channel) action()
    }
    actor.offer(Unit)
  }

  fun cancel() {
    job.cancel()
  }
}

Lifecycle and coroutine parent-child hierarchy
Children of a coroutine

 

こうでもいけるってよ: 2018-04-27追記


val rootParent = Job()

fun foo() {
  launch(UI, parent = rootParent) {
    // ...
  }
}

fun bar() {
  launch(CommonPool, parent = rootParent) {
    // ...
  }
}

fun destroy() { rootParent.cancel() }

Kotlin Coroutines on Android: Things I Wish I Knew at the Beginning


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