coroutine の使い方 - Android Architecture Blueprints v2 #1

気がついたら「v2」です。MVVM のみとなって、 RxJava は姿を消していますが。

👉 googlesamples/android-architecture: A collection of samples to discuss and showcase different architectural tools and patterns for Android apps. 



現在、4つのバリエーションが公開されていますが、以下は共通。


- kotlin
- coroutine
- single activity
- architecture component
- navigation component + fragment
- presentetion layer(per page) = fragment + view model
- reactive ui = live data + data binding
- data layer = repositpory + local(room) + remote
- datalayer one shot operations(no listener or data streams)

非同期処理には、どのバリエーションも「coroutine」使う。

どのように coroutine を使っているか、を定型化しておきたい。

関数 coroutineScope

「kotlinx-coroutines-core」の関数の「coroutineScope」 が目についたので見ておく。


suspend fun <R> coroutineScope(
    block: suspend CoroutineScope.() → R
): R (source)

CoroutineScope を作成し、このスコープで指定された suspend ブロックを呼び出します。その外側のスコープから coroutineContext を継承しますが、そのコンテキストのJobをオーバーライドします。

この関数は、処理の並列分解用に設計されています。 このスコープ内のいずれかの子コルーチンが失敗すると、このスコープは失敗し、残りのすべての子はキャンセルされます(supervisorScope との違いを参照してください)。 与えられたブロックとそのすべての子コルーチンが完了するとすぐに戻ります。
スコープの使用例は次のようになります。


suspend fun showSomeData() = coroutineScope {

  val data = async(Dispatchers.IO) { // <- extension on current scope
     // ... load some UI data for the Main thread ...
  }

  withContext(Dispatchers.Main) {
    doSomeWork()
    val result = data.await()
    display(result)
  }
}

この例のスコープの意味は次のとおりです。

1. showSomeDataは、データがロードされてUIに表示されるとすぐに戻ります。
2. doSomeWorkが例外をスローすると、非同期タスクはキャンセルされ、showSomeDataはその例外を再スローします。
3. showSomeData の外部スコープが取り消されると、開始された async ブロックとwithContext ブロックの両方が取り消されます。
4. 非同期ブロックが失敗すると、withContext はキャンセルされます。

現在のジョブが外部でキャンセルされた場合、メソッドは CancellationException をスローします。このスコープ内に未処理の例外がある場合(たとえば、このスコープ内の起動で開始されたクラッシュコルーチンから)は、対応する未処理のThrowableをスローします。

coroutineScope - kotlinx-coroutines-core

実際の記述

coroutine を使った非同期処理は 各 ViewModel を起点に記述されています。


class TasksViewModel(
    private val tasksRepository: TasksRepository
) : ViewModel() {

    fun loadTasks(forceUpdate: Boolean) {
        viewModelScope.launch {

            // 対応する Repository メソッドをコール
            // val tasksResult = tasksRepository.getTasks(forceUpdate)

        }
    }

}

👉 android-architecture/TasksViewModel.kt at master · googlesamples/android-architecture 

Repository を展開して、スコープ周りを抜き出してみると、


class TasksViewModel(
    private val tasksRepository: TasksRepository
) : ViewModel() {

    fun loadTasks(forceUpdate: Boolean) {
        viewModelScope.launch {

            withContext(ioDispatcher) {
            
                // ...            

            }

        }
    }

}

というこれまで通り withContext() を使った dispatcher の切り換え。

他には、

前述の coroutineScope 関数を使った記述が、単独、並列、入れ子の3種類。


override suspend fun saveTask(task: Task) {
    coroutineScope {
        launch { tasksRemoteDataSource.saveTask(it) }
        launch { tasksLocalDataSource.saveTask(it) }
    }
}


override suspend fun clearCompletedTasks() {
    coroutineScope {
        launch { tasksRemoteDataSource.clearCompletedTasks() }
        launch { tasksLocalDataSource.clearCompletedTasks() }
    }
    withContext(ioDispatcher) {
        cachedTasks?.entries?.removeAll { it.value.isCompleted }
    }
}


override suspend fun deleteAllTasks() {
    withContext(ioDispatcher) {
        coroutineScope {
            launch { tasksRemoteDataSource.deleteAllTasks() }
            launch { tasksLocalDataSource.deleteAllTasks() }
        }
    }
}

👉 android-architecture/DefaultTasksRepository.kt at master · googlesamples/android-architecture 

今後、さらに簡潔に記述されていくのだろうが、意図は今のが理解しやすいと思いメモ。




Android Q で 画面録画機能は利用できるのか。Can we use Screen Recording on Android Q stable release?

beta1 のころは設定画面から「設定を有効化」することで可能でしたが、Screen Recording。

👉 【Android Q】 端末画面動画 (screenrecord) が簡単に録画録音できるのよ、アプリ不要! 

beta5 となった今では、設定画面から有効化する項目一覧が表示されません。

adb コマンドにて有効化します。


~ $ adb shell settings put global settings_screenrecord_long_press true
~ $ adb shell settings get global settings_screenrecord_long_press
true

録画スタートから順調に進んでいきますが、録画停止したあとに、

うまく保存できないようです。



Android Q 安定版リリース時には、利用できるようになってくれたらいいな。

👉 Android Q beta gets a screen recorder, how to access it - 9to5Google 
👉 サポートが切れた Pixel に Android 10 相当の Lineage OS 17 を 
👉 Android標準リカバリ「Android Recovery」を使う方法 


Android-Q beta5 ジェスチャーナビゲーション【動画有り】

賛否両論あるようですが。



薄いボタンが一つとなります。

Android OSでは画面下部にあるナビゲーションバーが担当している操作は以下の5つ。

1. アプリドローワーを引き出す
2. ホームの表示
3. アプリ切り換え
4. アシスタント起動
5. 戻る

これら5つの操作を1つの薄いボタンでどう操作するのでしょうか。

1. アプリドローワーを開く

ボタンを上へ長くスワイプ。

これまでと同じです。
直感的に使えます。

2. ホームの表示

ボタンを上へ長くスワイプ。

「1. アプリドローワーを開く」時の操作と同じですが、ホーム画面以外から使うことで区別できます。

3. アプリ切り換え

ボタンを上へ短くスワイプ。

アプリ切り換え画面が表示されます。

または、
ボタンを左右にスワイプで直接切り換えることもできます。

4. アシスタント起動

画面左右下隅を中央に向けてスワイプします。

5. 戻る

画面左右端を中央に向けてスワイプします。

スワイプ前に、一度ホールドすると、アプリ内のナビゲーションメニューとの操作の衝突は避けれる。

まとめ?

まだ、慣れていないためか、イライラ→絶叫してしまいます(泣)


この操作の1ボタンのジェスチャーナビゲーションを、デフォルト設定として、Qは正式リリースとなるか?

ならないよなあ。


Android Paging Library と Retrofit

例えば、このパターン、Network only。

ここでは、PositionalDataSource を拡張するが、他のタイプのDataSource拡張でも同じ。

compositeDisposable のように viewModelScope をはるばる持ってきたにもかかわらず、


class RemoteDataSource(
  private val coroutineScope: CoroutineScope,
  private val service: RemoteService,
  private val s: String
) : PositionalDataSource<Item>() {

  @ExperimentalCoroutinesApi
  override fun loadInitial(params: LoadInitialParams, callback: LoadInitialCallback<Item>) {
    Timber.d("RemoteDataSource#loadInitial: ${Thread.currentThread().name}")
    ...

loadInitial() 内は、メインスレッドではなく、別スレッドで実行されている。


Timber.d("RemoteDataSource#loadInitial: ${Thread.currentThread().name}")


D/RemoteDataSource: RemoteDataSource#loadInitial: arch_disk_io_0
D/RemoteDataSource: RemoteDataSource#loadInitial: arch_disk_io_1
D/RemoteDataSource: RemoteDataSource#loadInitial: arch_disk_io_3

これらは、Android Architecture Component が作成した独自スレッド。

よって、同期なRetrofitの実行処理で良い、となる。

If I use enqueue with Retrofit 2.3 it will doesn't work but if i do a .execute() the LiveData is correctly triggered

Retrofit 2.3で、enqueue() を使用しても機能しませんが、execute() を実行するとLiveDataが正しくトリガーされます。

Android Paging Library LiveData> is triggered before the end of the api call

公式リファレンスにも記述はあるという。

To display data from a backend server, use the synchronous version of the Retrofit API to load information into your own custom DataSource object.

バックエンドサーバーからのデータを表示するには、同期バージョンのRetrofit APIを使用して、独自のカスタムDataSourceオブジェクトに情報をロードします。

Network only - Paging library overview

しかし、DiffUtilを使ったリフレッシュなアニメーションが実行されない。

「手間がかかる」でなく「沼にハマる」ことが最近は多くなった。

APIの仕様がおせっかいすぎやしないか。

しきいを下げようとして、余計に混乱させるばかり。

👉 あなたは Android Architecture Component をどう思いますか? 
👉 Fragment と Toolbar の歴史の話 - Qiita 


あなたは Android Architecture Component をどう思いますか?

ある人々のTwitter上の会話。ザクッと翻訳サービスを利用して眺めてみます。

Frankly, the expectation is that all applications of a considerable size already use some form of DI. Thus providing yet another way to pass dependencies via context is an overkill. All "non-DI" facilities are just gimmicks/workarounds for cases when there is no DI.

率直に言って、かなりの数のアプリケーションがすでにDIを使用している。したがって、コンテキストを介して依存関係を渡すためのさらに別の方法を提供するのはやり過ぎです。すべての「非DI機能」は、DIがない場合のギミック/回避策にすぎません。

On Android this sadly isn't the case. We seem to relish in bad architecture.

It's either "Why do I have to pass an executor/scheduler/dispatcher? So much boilerplate!" or "Why can't I test on the JVM? This library is poorly designed!"

Maybe KEEP-87 will save us from ourselves?

Androidでは、これは悲しいことではありません。悪いアーキテクチャーで大喜びしているようです。

「executor / scheduler / dispatcher を渡す必要があるのはなぜですか? かなりのボイラープレートです。」、「なぜJVMでテストできないのですか?このライブラリは適切に設計されていません。」

多分KEEP-87は私達を私達自身から救うのだろうか?

👉 [Kotlin] KEEP87 brings compiler-driven dependency injection without frameworks : androiddev 

On unrelated note. (disclaimer: I'm not an Android developer) I have a feeling that something is broken in testing or architecture approaches here. I've been writing huge (1M+ LOCs) UI apps for more than a decade and never had to use either DI or statics to make them testable.

無関係なメモについて。 (免責事項:私はAndroidの開発者ではありません)何かがここでテストやアーキテクチャのアプローチで壊れていると感じています。私は10年以上にわたって巨大な(1M + LOC)UIアプリを書いてきました。そしてそれらをテストするために DI や statics を使う必要は決してありませんでした。

Android never had architecture guidelines and the docs encouraged doing all the wrong things to make the tutorials easy. Basically equivalent to writing everything in main(). Even now almost all of the architecture offerings treat symptoms of this legacy and not the disease.

Androidはアーキテクチャのガイドラインがなかったので、チュートリアルを簡単にするためにすべての間違ったことをすることをドキュメントを奨めてきました。基本的にmain() ですべてを書くのと同じです。現在でも、ほとんどのアーキテクチャがこの遺産の症状を治療していて、疾患を治療していません。

👉 Roman Elizarov on Twitter: "@JakeWharton Frankly, the expectation is that all applications of a considerable size already use some form of DI. Thus providing yet another way to pass dependencies via context is an overkill. All "non-DI" facilities are just gimmicks/workarounds for cases when there is no DI." / Twitter 

みなさんはどう思っていますか?

Roman Elizarov
@relizarov
Team Lead @JetBrains, working on @Kotlin coroutines and libs, sports programming/ICPC, concurrency & algorithms, math/quantitative finance; formerly @Devexperts

👉 Roman Elizarov (@relizarov) / Twitter 

Jake Wharton
@JakeWharton
Opinions expressed here are my own, not those of my company. They made me write this because I complain about Inbox going away so much.

👉 Jake Wharton (@JakeWharton) / Twitter