visible true

技術的なメモを書く

もうAndroidの非同期処理はasync/awaitでいいんじゃないかなぁと思った

Rx Ja Night Vol.2 - connpassで「 Androidの非同期処理をKotlinコルーチンで行う」という話をしてきました。

スライドで使っているコードは次のリポジトリに置いています。

github.com

今回取り扱った非同期処理の範囲

スライドやリポジトリのREADME.mdに大体書いているのですがコチラにも載せときます。 詳細な説明はスライドやリポジトリを参照してください。 次の非同期処理をコルーチンで実現します。

単発の実行
直列の実行
並列の実行
+
エラーハンドリング
キャンセル

環境

すべてKotlinが提供する標準の機能を用います。

implementation "org.jetbrains.kotlin:kotlin-stdlib-jre7:1.1.2-4"
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:0.16"
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:0.16"

単発の実行

コルーチン(async/await)ではこういう風に書けます。

val job = launch(UI) {
    try {
        val shop = async(CommonPool) { shopApi.getShop(10) }.await()
        // success
    } catch (e: Exception) {
        // error
    }
}

launch(UI)async(CommonPool)はコルーチンのビルダー関数と呼び、続いて渡すブロックをコルーチンにしてくれます。 ここではlaunch(UI)はコルーチン内をUIスレッドで実行する、async(CommonPool)はコルーチン内をスレッドプールで実行する、という理解でいいと思います。 毎度書くと冗長なので、次のようなパッケージレベル関数を用意して簡潔に書けるようにしたりできます。

fun <T> async(context: CoroutineContext = CommonPool, start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> T)
        = kotlinx.coroutines.experimental.async(context, start, block)

fun ui(start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> Unit)
        = launch(UI, start, block)

スッキリ

val job = ui {
    try {
        val shop = async { shopApi.getShop(10) }.await()
        // success
    } catch (e: Exception) {
        // error
    }
}

エラーについてもtry-catch式なので、様々な例外をよしなに扱えます。 uiの中でawait()して待ち合わせていて大丈夫かって気になりますが、 Kotlinコンパイラがよしなにコルーチン内のコードを状態毎に分解していて、 await()の呼び出しの所で処理を中断しているので大丈夫です。 await()が完了すると結果がdispatchされ、Handler.post()で続きを実行するといった具合です。

直列の実行

await()を後続のasyncの前か、その中で呼び出せばOK。

val job = ui {
    try {
        val userJob = async { userApi.me() }
        val subscriptionShopsJob = async { subscriptionShopApi.getSubscriptionShops(userJob.await().id) }
        val subscriptionShops = subscriptionShopsJob.await()
        // success
    } catch (e: Exception) {
        // error
    }
}

並列の実行

並列で実行したいasyncを呼び出したあとにawaitすればよい。

val job = ui {
    try {
        val userJob = async { userApi.me() } // start immediately
        val shopJob = async { shopApi.getShop(10L) } // start immediately
        val user = userJob.await()
        val shop = shopJob.await()
        // success
    } catch (e: Exception) {
        // error
    }
}

キャンセル

launch(UI)から返るJobcancel()を呼び出せばよい。

job.cancel()

するとコルーチンの中でCancellationExceptionが飛ぶ。

job = ui {
    try {
        val shop = async { shopApi.getShop(10) }.await()
        // success
    } catch(e: CancellationException) {
        // cancel
    } catch (e: Exception) {
        // error
    }
}

感想

特にデメリットもなさそうだし圧倒的に簡潔だし、もう非同期処理はasync/awaitでいいやって思った。 なんてったって非同期処理のための実装だからね。 このほかproducerやactorなどを使うと更にUIイベントのストリームとかイベントバスみたいなこともできそうだけど、 この辺はそのために用意されているかでいうと微妙な気もするのでどちらでもいい気もしている。 一応experimentalなんだけど、裏側の実装が変わる事はあっても利用コード側はそこまで影響受けないだろうしいいんじゃないかなとか。 プロダクトでも入れ始めているしそうしようみたいな気持ち。

参考

これ読んだらもう使ってよしだと思う。

KotlinでViewDataBindingをシュッとinflateするやつ

RecyclerViewなどでViewDataBindingを使う時に次のように書くのめんどくさくて。

class ViewHolder(val binding:ListItemCommentBinding)
: RecyclerView.ViewHolder(binding.root)
override fun onCreateViewHolder(parent: ViewGroup, type: Int) = 
  ViewHolder(ListItemCommentBinding
    .inflate(LayoutInflater.from(parent.context), parent, false))

こういう感じにViewGroupに関数生やすと、

ViewExtensions.kt

inline fun <reified T : ViewDataBinding> 
  ViewGroup.inflateBinding(): T {
    return T::class.java
            .getDeclaredMethod(
              "inflate",
              LayoutInflater::class.java, 
              ViewGroup::class.java, 
              Boolean::class.javaPrimitiveType
            )
            .invoke(null, LayoutInflater.from(context), this, false) as T
}

良さそう。

override fun onCreateViewHolder(parent: ViewGroup, type: Int) =
  ViewHolder(parent.inflateBinding()) 

ViewHolderが複数種類のViewDataBindingを取り扱う場合は型引数が要る。

override fun onCreateViewHolder(parent: ViewGroup, type: Int) =
  ViewHolder(parent.inflateBinding<ListItemCommentBinding>()) 

追記 2017/05/23

proguardで死ぬので、使うときは次の設定が必要になります。ひょえ〜

-keep class * extends android.databinding.ViewDataBinding {
    public static ** inflate(android.view.LayoutInflater, android.view.ViewGroup, boolean);
}

DataBindingが原因のビルドエラー時にエラーを抽出するスクリプト

AndroidでDataBinding周りミスるとめっちゃエラー出て辛いですね。辛いのでDataBindingのエラーを抽出するスクリプトを書きました。スクリプトはかなり雑なので適宜いい感じにしてください。

extract_data_binding_error.rb

#! /bin/sh
exec ruby -S -x "$0" "$@"
#! ruby

state = 0
while str = STDIN.gets
  break if str.chomp == "exit"
  case state
  when 0
    state = 1 if str.match(/.*Found data binding errors.*/)
  when 1
    state = 2 if str.match(/.*e: .*/)
    next if state == 2
    print str
  end
end

gradleのコマンドに2>&1を足してextract_data_binding_error.rbに流せばok

$ ./gradlew assembleDebug 2>&1 | ./extract_data_binding_error.rb
Identifiers must have user defined types from the XML file. user is missing it
file:///hoge/foo/git/android-app/app/src/main/res/layout/list_item_comment.xml Line:60


    at android.databinding.tool.processing.Scope.assertNoError(Scope.java:110)
    at android.databinding.annotationprocessor.ProcessDataBinding.process(ProcessDataBinding.java:89)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)
    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
    at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1068)
    at org.jetbrains.kotlin.kapt3.AnnotationProcessingKt.doAnnotationProcessing(annotationProcessing.kt:73)
    ... 50 more

こんな感じ。やったね

mastodon4j v0.0.6 をリリースしました

mastodon4jをリリースしました - visible true では0.0.3でしたが、0.0.6まで出ました。

差分はReleases · sys1yagi/mastodon4j · GitHubに書いてますがここでも軽く書きます。

v0.0.4

Release v0.0.4 · sys1yagi/mastodon4j · GitHub

mastodon4j

  • 各メソッドにContractを追加。PublicとAuthRequiredに分かれている。
    • 認証が必要なものと不要なものを明示するのが目的だったが、interfaceは@JvmOverloadsが使えないため0.0.7でやめる予定
  • Breaking メソッドの各関数にMastodon4jRequestExceptionのチェック例外を付与
  • Breaking booleanのgetter名をisXXXに変更
  • いくつかの関数に@JvmOverloadsを付与

mastodon4j-rx

なし

v0.0.5

Release v0.0.5 · sys1yagi/mastodon4j · GitHub

mastodon4j

  • Timelinesのpublicとtagにlocalパラメータを追加。これをつけるか付けないかでローカルタイムライン、連合タイムラインを切り替えるらしい。それに伴い次の変更を入れた
    • Deprecated Timelines#getPublic()
    • Add Timelines#getLocalPublic()
    • Add Timelines#getFederatedPublic()
    • Deprecated Timelines#getTag()
    • Add Timelines#getLocalTag()
    • Add Timelines#getFederatedTag()

mastodon4j-rx

なし

v0.0.6

Release v0.0.6 · sys1yagi/mastodon4j · GitHub

mastodon4j

  • Timelinesのlocalパラメータは、falseの時はパラメータを付与してはいけないという事で修正
  • Accounts.getStatusesにonly_mediaフラグを追加。メディアを持つ投稿を抽出する時に使うっぽい
  • 次のDeprecated関数を削除
    • Delete Timelines#getTag()
    • Delete Timelines#getPublic()
  • Link Headerをサポート。そのためにList<T>の代わりにPageable<T>Linkを導入

mastodon4j-rx

mastodon4jの変更に追従

その後

  • 0.0.7 Milestone · GitHub
    • raw jsonを取り出す仕組みを入れる
    • Mastodon4jRequestExceptionはResponseを内包しているけど、Mastodon4jRequestException自身にcode()とかを持たせる
    • Contractを捨ててアクセストークンが不要なメソッドはPublicクラスに集約する
    • できればStreaming APIをサポートする

所感

PR投げてくれる人がいたり(fix only_media param by takke · Pull Request #39 · sys1yagi/mastodon4j · GitHub)、

設計周りでアドバイスを頂けたりしてありがたいです。

mastodon4jをリリースしました

mastodon4jをリリースしました。Kotlinで書かれていて、Javaからでも使えるように今後チューニングしていきます。現在の最新は0.0.3です。 最初はDroiDonの副産物としてmastodon4jを実装していて、まぁだれか出すだろうと思っていたけど1週間経っても出てこないので自分で出すことにしました。 公式ドキュメントのAvailable librariesに載せてもらえてやっぴー。

github.com

mastodon4j

github.com

0.0.1

  • mastodon4jでmastodonAPI documentにかかれているデータ、メソッドをすべて実装
  • mastodon4j-rxで一部のメソッドを実装

0.0.2

Release v0.0.2 · sys1yagi/mastodon4j · GitHub

  • ユーザ名/パスワードで認証する Apps#postUserNameAndPassword() を追加
  • Statues内でRangeを利用するようにした。(0.0.1でもRangeはあったが、Statuesではmax_id, since_id, limitを個別のパラメータにしていた)
  • mastodon4j-rxですべてのメソッドを実装

0.0.3

Release v0.0.3 · sys1yagi/mastodon4j · GitHub

  • Mastodon4jRequestExceptionでResponseオブジェクトを持つようにした(401などのハンドリングのため)。
  • Scopeのコンストラクタが可変長引数で、空のまま実行するとエラーになるのでデフォルト引数を追加した

その後

所感

mastodon4jを実装して改めて思ったのはAndroidアプリケーションの開発って大変だなーということ。DroiDonの進捗はせいぜい5%くらいでまだまだ先は長い。

github.com

React NativeでFirebase Storageに画像を上げるときにputStringが上手くいかないのでbase-64を入れてatob関数を補完する

React Nativeを、ペーパープロトタイピングprottなどを使ったモックアッププロトタイピングの次のフェーズとして動くプロトタイピングツールに使えないかなぁと思ってちょこちょこ触ってます。

うまくいくと両ユーザ向けに同時に動くプロトタイプを提供できてフィードバックが捗るのとAndroidiOSの両方のチームで同時に一つの仕様をいじれるので仮説や価値の理解や共有らなんやら色々捗るんじゃないかなぁとか思ってます。

バックエンド側もFirebaseを使うと結構カジュアルに色々やれそうだな〜とか思っていて色々試し始めたんですがFirebase Storageにデバイス上の画像をアップロードする処理ではまりました。

環境

  • React Native: 0.42.3
  • Firebase: 3.7.3

問題

react-native-image-pickerなんかを使って写真を撮ったりデバイス上の写真を選択すると、ファイル名やContentTypeやbase64に変換された実データを取得できます。次のコードはFirebase StorageにputString関数で画像をアップロードする例です。

firebase.initializeApp(config);
const storage = firebase.storage().ref();

const ref = storage.child(response.fileName);
const metadata = {contentType: response.type};

ref.putString(response.data, 'base64', metadata).then((snapshot) => {
  done();
});

putString関数の第一引数のresponse.dataには画像をbase64に変換した文字列が詰まっており、第二引数はデータフォーマットを示すためにbase64を渡しています。これをReact Nativeで実行すると次のようにInvalid character foundとなります。

f:id:sys1yagi:20170326215741p:plain:w300

どーもよくわからないのでBlobやUint8Arrayを使う方法を試みるも、そもそもReact NativeにはBlobはないらしいという事がわかり、react-native-fetch-blobというBlob周りのポリフィルを提供しているライブラリを導入して試してみるもうまくいかず途方にくれてました。

原因

万策尽きたのでしぶしぶFirebase Storageのクライアントコードを読むことにしました。エラー画面にstacktraceが吐かれてるのでそんなに追いかけるのは難しくなかったです。

f:id:sys1yagi:20170326220926p:plain

こんな感じでtry-catchがあって、atob関数しか呼び出してないのでこれがちゃんと動いてないんだな〜という事がわかりました。

対応

Blobを使ったりするところであれこれ試す中で、

javascript - How to convert base64 into Blob in React Native? - Stack Overflow

とかを試していたのでピンときて、

npm install --save base-64

して(base64)、

const atob = require('base-64').decode;
window.atob = atob;

コンポーネントの冒頭に書いたらうごいた。わいわい。

f:id:sys1yagi:20170326221919p:plain

雑感

React Nativeのポリフィル集ありそうだけどどーなんだろ。 React.parts – A catalog of React componentsとかを眺めていると結構色々あって面白い。一方で改廃も激しいので大変そう。

Kotlin 1.1で追加された標準ライブラリの関数をざっくり見る

Kotlin 1.1でいくつか標準ライブラリに追加された関数があるのでちら見しながら感想を述べます。

Kotlin 1.1: What’s coming in the standard library | Kotlin Blog

T.also()

let(), apply(), with(), run()に新たな仲間が。

@kotlin.internal.InlineOnly
@SinceKotlin("1.1")
public inline fun <T> T.also(block: (T) -> Unit): T { block(this); return this }

内容としてはlet()の型1つ版って感じです。let()は引数と戻り値の型が別の定義になっていたのでラムダ式の末尾に戻り値を書かないといけませんでした。also()では引数が戻り値になるのでそうした対応が不要になります。

applyに近いですが、applyはラムダ式のスコープがレシーバとなるため呼び出し元のthisとの衝突が起こります。alsoはラムダ式のスコープを汚さずにapplyに近い処理を書けるようになります。

用途としては次のような感じになると思います。

val binding = HogeBinding.inflate(inflator).also {
  it.root.setOnClickListener(this) // thisのスコープが外側のクラスになる
}

T.takeIf()とT.takeUnless()

グローバルな拡張関数が2つ。ある条件を満たした時|満たさない時自身を返す。

@kotlin.internal.InlineOnly
@SinceKotlin("1.1")
public inline fun <T> T.takeIf(predicate: (T) -> Boolean): T? = if (predicate(this)) this else null
@kotlin.internal.InlineOnly
@SinceKotlin("1.1")
public inline fun <T> T.takeUnless(predicate: (T) -> Boolean): T? = if (!predicate(this)) this else null

用途としてはこんな感じかな〜

val params = request.takeIf{ isValidParameter(it) }.params ?: throw RuntimeException()

わりと便利。

Iterable.groupingBy()

groupBy()はリストをkey selectorでグルーピングしてMap<key, list>に変換する。一方でgroupingBy()はkey selectorでグルーピングした結果を次のようにGrouping<T>で返す。

@SinceKotlin("1.1")
public inline fun <T, K> Iterable<T>.groupingBy(crossinline keySelector: (T) -> K): Grouping<T, K> {
    return object : Grouping<T, K> {
        override fun sourceIterator(): Iterator<T> = this@groupingBy.iterator()
        override fun keyOf(element: T): K = keySelector(element)
    }
}

Grouping<T>はfold関数, reduce関数, eachCount関数を持っていて、key selectorでグルーピングしたリストに対してそれぞれの処理を行える。

listOf(1, 2, 3, 4, 5, 6, 7, 8, 9)
  .groupingBy { it % 2 == 0 }
  .fold(0, { a, b ->
    a + b
  }) // Map<key, list>を返す
  .forEach { t, u ->
    println("$t=$u") // false=25, true=20
  }

使いみちはなんか出現文字の頻度を数えるとからしいけどうーんて感じた。mapとかあると便利そうなんだけどな〜と思った。

minOf() and maxOf()

minOf()とmaxOf()はトップレベル関数として定義されている。引数を比較して最小、最大を返す。引数は2つと3つがある。次のコードはIntの実装だがプリミティブ型毎に実装があるほかT型の実装もある

@SinceKotlin("1.1")
@kotlin.internal.InlineOnly
public inline fun minOf(a: Int, b: Int): Int {
    return Math.min(a, b)
}

T型は次の通り。TはComparableである必要がある。

@SinceKotlin("1.1")
public fun <T: Comparable<T>> maxOf(a: T, b: T): T {
    return if (a >= b) a else b
}

引数の最後にComparator<in T>を受け取るバージョンもある。

@SinceKotlin("1.1")
public fun <T> maxOf(a: T, b: T, comparator: Comparator<in T>): T {
    return if (comparator.compare(a, b) >= 0) a else b
}

Collectionには合ったけどカジュアルに比較するやつがないから追加されたのかな。地味に便利ではありそう。

Map.getValue()

Mapのget関数の戻り値はV?であり、keyがない場合はnullを返す。一方で今回追加されたgetValue関数はVを返す。もしもkeyがない場合はNoSuchElementExceptionをスローする。

@SinceKotlin("1.1")
public fun <K, V> Map<K, V>.getValue(key: K): V = getOrImplicitDefault(key)

get関数の戻り値がnull許容型で利用時にめんどくさいってのがあるのでよさそう。 withDefaultをあわせて使えばNoSuchElementExceptionはなくなるがまぁそれならnull許容型使うのと同じかな。

mapOf(
  1 to "a",
  2 to "b"
)
.withDefault { "c" }
.getValue(100) // "c"

Map.minus() operator

Mapにマイナスオペレータが追加された。

var a = mapOf(
                1 to "a",
                2 to "b"
        )
a += Pair(3, "c") // 1="a", 2="b", 3="c"
a -= 1 // 2="b", 3="c"

なるほどな〜。実装としてはこんな感じ。

@SinceKotlin("1.1")
public operator fun <K, V> Map<out K, V>.minus(key: K): Map<K, V>
        = this.toMutableMap().apply { minusAssign(key) }.optimizeReadOnlyMap()

@SinceKotlin("1.1")
@kotlin.internal.InlineOnly
public inline operator fun <K, V> MutableMap<K, V>.minusAssign(key: K) {
    remove(key)
}

Array-like List instantiation functions

Array型と同様にコンストラクタに要素数を指定して、各インデックスの値の初期化をラムダ式で記述できるようになった。

List(3) { i -> "value$i" } // "value0","value1","value2"
MutableList(3) { i -> "value$i" }

使う機会はパッとは思いつかないけどまぁよさそう。

String to number conversions

StringのtoInt関数などで失敗した場合NumberFormatExceptionをスローするが、新たにtoIntOrNull関数が追加された。

@SinceKotlin("1.1")
public fun String.toIntOrNull(): Int? = toIntOrNull(radix = 10)

このほかtoDoubleOrNull関数やtoFloatOrNull関数などがある。try-catchいちいち書かなくていいので便利そう。

Iterable.onEach()

forEach()は戻り値がUnitだけど、onEachは自身を返す。

@SinceKotlin("1.1")
public inline fun <T, C : Iterable<T>> C.onEach(action: (T) -> Unit): C {
    return apply { for (element in this) action(element) }
}

途中にデバッグ用に出力するとかかな〜〜〜。

return listOf(1, 2, 3)
  .onEach {
    println(it) // 1, 2, 3
  }
  .map(Int::toString) // ["1", "2", "3"]

Map.toMap() and Map.toMutableMap()

Mapにコピー関数であるtoMap関数とtoMutableMap関数が追加された。

@SinceKotlin("1.1")
public fun <K, V> Map<out K, V>.toMap(): Map<K, V> = when (size) {
    0 -> emptyMap()
    1 -> toSingletonMap()
    else -> toMutableMap()
}

内部的にはLinkedHashMapが作られるみたい。

@SinceKotlin("1.1")
public fun <K, V> Map<out K, V>.toMutableMap(): MutableMap<K, V> = LinkedHashMap(this)

Abstract collections

読み取り専用としてAbstractCollection、AbstractList、AbstractSet、AbstractMapが、変更可能な値としてAbstractMutableCollection、AbstractMutableList、AbstractMutableSet、AbstractMutableMapが追加された。抽象クラスを継承して独自のコレクションクラスを実装できるようになった。今までなかったのか〜

雑感

also()とtakeIf()はガンガン使っている。めっちゃ便利。どんどん便利になってよい〜