#iOS | #Android Fashion News

【Android】Kotlin でモダンな concurrency その4

Last updated : 2022-06-19 15:53

Channel を使ってコールバック不要に

Channel の定義 (JetBrains のドキュメントより):

Channel は、概念的に BlockingQueue とよく似ています。主な違いの一つは、Put の代わりに「送信中断」をを持ち、Take の代わりに「受信中断」を持つことです。

Blocking Queues

Actor

Channel をシンプルに使えるツールが Actor です。

Actor は Handler と非常によく似ており、コルーチンのコンテキスト（つまり、アクションを実行するスレッド）を定義し、シーケンシャルに実行します。

コルーチンを使っており、キャパシティを決めて実行を中断することができます。

Actor は基本的に、処理をコルーチンチャンネルに転送します。実行順序と実行するコンテキストを限定することを保証します。

これで、synchronize は不要となり、すべてのスレッドはフリーです。


protected val updateActor by lazy {
  actor<Update>(UI, capacity = Channel.UNLIMITED) {
    for (update in channel) when (update) {
      Refresh -> updateList()
        is Filter -> filter.filter(update.query)
        is MediaUpdate -> updateItems(update.mediaList as List<T>)
        is MediaAddition -> addMedia(update.media as T)
        is MediaListAddition -> addMedia(update.mediaList as List<T>)
        is MediaRemoval -> removeMedia(update.media as T)
    }
  }
}

// 使い方
suspend fun filter(query: String?) = updateActor.offer(Filter(query))

この例では、実行するアクションを選択する際、sealed クラスを利用しています。


sealed class Update
object Refresh : Update()
class Filter(val query: String?) : Update()
class MediaAddition(val media: Media) : Update()

すべてのアクションはキューとなり、決してパラレルには実行されません。mutable なものを密閉するにはいい方法です。

(つづく)

【Android】Kotlin でモダンな concurrency その1
【Android】Kotlin でモダンな concurrency その2
【Android】Kotlin でモダンな concurrency その3

【Android】Kotlin でモダンな concurrency その3

Last updated : 2022-06-19 15:54

Coroutine コンテキスト

Coroutine コンテキストでは、そのコードをどのスレッドで実行するか、exception がスローされたときの処理の方法、キャンセルを伝える親のコンテキストを定義します。


val job = Job()
val exceptionHandler = CoroutineExceptionHandler {
    coroutineContext, throwable -> whatever(throwable)
}

launch(CommonPool+exceptionHandler, parent = job) { ... }

job.cancel() は、それの保持しているすべての coroutine をキャンセルします。
そして exceptionHandler は、それらの中でスローされたすべて Exception を受け取ります。

(つづく)

【Android】Kotlin でモダンな concurrency その1
【Android】Kotlin でモダンな concurrency その2

【Android】Kotlin でモダンな concurrency その2

Last updated : 2022-06-22 22:35

Dispatch

Dispatch は coroutine のキーとなる概念で、スレッド間を移動するアクションとなります。

現在の Java でいう runOnUiThread と等価です。


public final void runOnUiThread(Runnable action) {
  if (Thread.currentThread() != mUiThread) {
    mHandler.post(action);
  } else {
    action.run();
  }
}

Kotlin Android でのUIコンテキストは、Handlerをベースとして dispatcher が実装されています、

以下のように使います。


launch(UI) { ... }

launch(UI, CoroutineStart.UNDISPATCHED) { ... }

launch(UI) では、Handler 内の Runnable に postされますので直接実行されません。

それに対して、launch(UI, CoroutineStart.UNDISPATCHED) は、そのスレッドですぐにラムダ部分を実行します。

UI は、メインスレッドが resume されたとき、coroutine がそれに対して dispatch されるのを保証しており、メインルーパーに post するというネイティブAndroidの Handler が使われています。


val UI = HandlerContext(Handler(Looper.getMainLooper()), "UI")

(つづく)

【Android】Kotlin でモダンな concurrency その1

Last updated : 2022-06-19 15:54

現在の Java/Android の concurrency フレームワークはコールバック地獄の原因となります。

それは、スレッドセーフを保証するシンプルな方法がないからです。

kotlin coroutine は、concurrency を管理するための効果的でシンプルなフレームワークです。

Suspending と Blocking

coroutine は、スレッドを置き換えるものではなく、それを管理するフレームワークのようなものです。

元のスレッドをブロックすることなく、バックグラウンド処理完了に対しての wait を可能にする実行コンテキストを定義しています。

コールバックを避けて、簡単に concurrency を行ってみましょう。

基本

最初は非常にシンプルな例です。UIコンテキストで coroutine を起動し、その中でIOコンテキストでイメージを取得します。

その後、UIコンテキストに戻ります。


launch(UI) {
    val image = withContext(IO) { getImage() } 
    imageView.setImageBitmap(image) 
}

シングルスレッドのように直感的なコードです。

getImage() がIOスレッドで実行されている間、メインスレッドは、自由に他の処理を行うことができます。

withContext は、その coroutine を getImage() が実行されている間は中断します。

getImage() のあとすぐに、メインlooperが利用可能になり、coroutine はメインスレッドを再開します。

そして imageView.setImageBitmap(image) が呼ばれます。

次の例は、2つのバックグラウンド処理を完了させ、その結果を利用する、というものです。

async/await を使ってパラレルに実行し、それら両方の結果取得のあとメインスレッドでそれを利用した処理を行います。


val job = launch(UI) {
    val deferred1 = async { getFirstValue() }
    val deferred2 = async(IO) { getSecondValue() }
    useValues(deferred1.await(), deferred2.await())
}

job.join()

async は launch に似ていますが、deferred (Kotlin版 Future) を返します。

そして、await() で結果を取得します。パラメータなしで実行した場合は、CommonPool コンテキストで実行されます。

前の例と同様に、2つの結果を待っている間は、メインスレッドは自由に処理を行うことができます。

例にあるように、launch は処理が完了するのを待つのに利用できる Job を返します。

「スレッドをブロックせず coroutine をブロックする」ということを除けば、他の言語と同様です。

(つづく)

Android Architecture Components: Room の Migration で IllegalStateException

Last updated : 2018-07-09 13:38

データを移行せずに捨ててしまうのなら、以下でいいのですが。


Room.databaseBuilder(context, RepoDatabase.class, DB_NAME)
    .fallbackToDestructiveMigration()
    .build();

きっと捨てることができませんよね。

テーブル定義を変更しながら、データを移行しますよね。


Room.databaseBuilder(context, RepoDatabase.class, DB_NAME)
    .addMigrations(FROM_1_TO_2)
    .build();

static final Migration FROM_1_TO_2 = new Migration(1, 2) {
    @Override
    public void migrate(final SupportSQLiteDatabase database) {
        database.execSQL("ALTER TABLE Repo
                         ADD COLUMN createdAt TEXT");
        }
    };

database.execSQL()でSQLをベタに実行しながらデータを別テーブルにRENAME後、CREATE→INSERT→DROP というかんじでスキーマを変更していますが。

すると、こんなのに遭遇します。

java.lang.IllegalStateException: Room cannot verify the data integrity. Looks like you’ve changed schema but forgot to update the version number. You can simply fix this by increasing the version number.

データベースのバージョンナンバーは上げることは、まあ上げるとして、それでもインデクスなどうまく意図通りに移行できてない場合があります。

データモデルにアノテーションで記述した「Room が利用しようとしているスキーマ」と、Migration部分にベタ記述した「SQLiteのスキーマ」が合致しないといけません。

また、最近のAndroidでは、.dbファイルが、OS上で取り回しづらく、実態を把握しづらかったりします。

Roomが認識しようとしているテーブルスキーマは以下で書き出すことができます。


android {
    javaCompileOptions {
        annotationProcessorOptions {
            arguments = ["room.schemaLocation":
                         "$projectDir/schemas".toString()]
            }
        }
    }
}


"tableName": "Repo",
"createSql": "CREATE TABLE IF NOT EXISTS `${TABLE_NAME}` (`id` INTEGER NOT NULL, `name` TEXT, `url` TEXT, PRIMARY KEY(`id`))"

モデルクラスに記述したアノテーションのRoomが認識している状態(expected)をSQLで書き出してくれます。

これと、MIGRATION部分のベタSQL(found)を比較すると、意味が分かってきます。

複数フィールドに対してのUNIQUE なインデクスなど、公式ドキュメントとは違う内部的絶賛更新中な処理な部分など、書き出してみると先に進むことができます。