Mempelajari coroutine lanjutan dengan Flow dan LiveData Kotlin

Dalam codelab ini, Anda akan mempelajari cara menggunakan builder LiveData untuk mengombinasi coroutine Kotlin dengan LiveData di aplikasi Android. Kita juga akan menggunakan Flow Asinkron Coroutines, yang merupakan jenis dari library coroutines untuk mewakili urutan (atau aliran) asinkron nilai, guna mengimplementasikan hal yang sama.

Anda akan memulai dengan aplikasi yang ada, dibuat menggunakan Komponen Arsitektur Android, yang menggunakan LiveData untuk mendapatkan daftar objek dari database Roomdan menampilkannya di tata letak petak RecyclerView.

Berikut ini beberapa cuplikan kode untuk memberikan ide tentang apa yang akan Anda lakukan. Berikut adalah kode yang ada untuk membuat kueri database Room:

val plants: LiveData<List<Plant>> = plantDao.getPlants()

LiveData akan diupdate menggunakan builder LiveData dan coroutine dengan logika pengurutan tambahan:

val plants: LiveData<List<Plant>> = liveData<List<Plant>> {
   val plantsLiveData = plantDao.getPlants()
   val customSortOrder = plantsListSortOrderCache.getOrAwait()
   emitSource(plantsLiveData.map { plantList -> plantList.applySort(customSortOrder) })
}

Anda juga akan mengimplementasikan logika yang sama dengan Flow:

private val customSortFlow = plantsListSortOrderCache::getOrAwait.asFlow()

val plantsFlow: Flow<List<Plant>>
   get() = plantDao.getPlantsFlow()
       .combine(customSortFlow) { plants, sortOrder ->
           plants.applySort(sortOrder)
       }
       .flowOn(defaultDispatcher)
       .conflate()

Prasyarat

• Pengalaman dengan Komponen Arsitektur ViewModel, LiveData, Repository, dan Room.
• Pengalaman dengan sintaks Kotlin, termasuk fungsi ekstensi dan lambda.
• Pengalaman dengan Coroutine Kotlin.
• Pemahaman dasar tentang menggunakan thread pada Android, termasuk thread utama, thread latar belakang, dan callback.

• Untuk pengenalan tentang Komponen Arsitektur yang digunakan dalam codelab ini, lihat Room dengan View.
• Untuk pengenalan sintaks Kotlin, lihat Bootcamp Kotlin untuk Pemrogram
• Untuk pengantar tentang Coroutine Kotlin, lihat Menggunakan Coroutine Kotlin di Aplikasi Android Anda

Yang akan Anda lakukan

• Mengonversi LiveData yang ada untuk menggunakan builder LiveData yang cocok untuk coroutine Kotlin.
• Menambahkan logika dalam builder LiveData.
• Menggunakan Flow untuk operasi asinkron.
• Mengombinasikan Flows dan mentransformasi beberapa sumber asinkron.
• Mengontrol secara serentak dengan Flows.
• Mempelajari cara memilih antara LiveData dan Flow.

Yang akan Anda butuhkan

• Android Studio 4.1 atau yang lebih baru. Codelab mungkin berfungsi dengan versi lain, namun beberapa hal mungkin hilang atau terlihat berbeda.

Jika Anda mengalami masalah (bug kode, kesalahan gramatikal, susunan kata yang tidak jelas, dll.) saat mengerjakan codelab ini, laporkan masalah tersebut melalui link "Laporkan kesalahan" di pojok kiri bawah codelab.

Download kode

Klik link berikut untuk mendownload semua kode untuk codelab ini:

Download zip

... atau membuat duplikat repositori GitHub dari command line dengan menggunakan perintah berikut:

$ git clone https://github.com/googlecodelabs/kotlin-coroutines.git

Kode untuk codelab ini ada di direktori advanced-coroutines-codelab.

Direktori codelab-coroutine-lanjutan dalam repositori ini berisi beberapa modul yang berbeda:

• start — kode yang akan diubah untuk codelab ini.
• finished_code — kode untuk codelab yang sudah selesai. Lihat modul ini jika Anda mengalami masalah.
• sunflower — mendukung kode aplikasi. Kami tidak akan melakukan modifikasi pada kode dalam modul ini.

Pertanyaan umum (FAQ)

• Bagaimana cara menginstal Android Studio?
• Bagaimana cara menyiapkan perangkat untuk pengembangan?

Pertama-tama, mari kita lihat bagaimana tampilan aplikasi contoh awal. Ikuti petunjuk ini untuk membuka aplikasi contoh di Android Studio.

1. Jika Anda mendownload file zip kotlin-coroutines, ekstrak zip file tersebut.
2. Buka direktori advanced-coroutines-codelab di Android Studio.
3. Pastikan start dipilih di drop-down konfigurasi.
4. Klik tombol Run , lalu pilih perangkat yang diemulasi atau sambungkan perangkat Android Anda. Perangkat harus dapat menjalankan Android Lollipop (SDK minimum yang didukung adalah 21).

Saat aplikasi pertama kali dijalankan, daftar kartu akan muncul, masing-masing menampilkan nama dan gambar tanaman tertentu:

Setiap Plant memiliki growZoneNumber, atribut yang mewakili wilayah tempat tanaman kemungkinan besar akan tumbuh. Pengguna dapat mengetuk ikon filter untuk beralih antara menampilkan semua tanaman dan tanaman untuk zona tumbuh tertentu, yang di-hardcode ke zona 9. Tekan tombol filter beberapa kali untuk melihat cara kerjanya.

Ringkasan arsitektur

Aplikasi ini menggunakan Komponen Arsitektur untuk memisahkan kode UI dalam MainActivity dan PlantListFragment dari logika aplikasi di PlantListViewModel. PlantRepository menyediakan jembatan antara ViewModel dan PlantDao, yang mengakses database Room untuk menampilkan daftar objek Plant. UI kemudian mengambil daftar tanaman ini dan menampilkannya dalam tata letak petak RecyclerView.

Repositori adalah jembatan antara ViewModel dan data

Selain menjadi jembatan, repositori dapat diakses oleh ViewModel mana pun yang ingin menggunakan logikanya. Ini juga dapat mengombinasikan logika dari beberapa sumber data, yang akan kita implementasikan nanti.

Sebelum kita mulai mengubah kode, mari lihat sekilas bagaimana data mengalir dari database ke UI. Berikut adalah bagaimana daftar tanaman dimuat di ViewModel:

PlantListViewModel.kt

val plants: LiveData<List<Plant>> = growZone.switchMap { growZone ->
    if (growZone == NoGrowZone) {
        plantRepository.plants
    } else {
        plantRepository.getPlantsWithGrowZone(growZone)
    }
}

GrowZone adalah class inline yang hanya berisi Int yang merepresentasikan zonanya. NoGrowZone menunjukkan tidak adanya zona, dan hanya digunakan untuk pemfilteran.

Plant.kt

inline class GrowZone(val number: Int)
val NoGrowZone = GrowZone(-1)

growZone dialihkan saat tombol filter diketuk. Kami menggunakan switchMap untuk menentukan daftar tanaman yang akan ditampilkan.

switchMap menerapkan fungsi yang diberikan ke input LiveData (dalam kasus ini growZone) dan menampilkan hasil yang ditransformasi sebagai LiveData.

Berikut adalah tampilan repositori dan Objek Akses Data (DAO) untuk mengambil data tanaman dari database:

PlantDao.kt

@Query("SELECT * FROM plants ORDER BY name")
fun getPlants(): LiveData<List<Plant>>

@Query("SELECT * FROM plants WHERE growZoneNumber = :growZoneNumber ORDER BY name")
fun getPlantsWithGrowZoneNumber(growZoneNumber: Int): LiveData<List<Plant>>

PlantRepository.kt

val plants = plantDao.getPlants()

fun getPlantsWithGrowZone(growZone: GrowZone) =
    plantDao.getPlantsWithGrowZoneNumber(growZone.number)

Meskipun sebagian besar modifikasi kode berada di PlantListViewModel dan PlantRepository, ada baiknya Anda meluangkan waktu untuk memahami struktur project, yang berfokus pada bagaimana data tanaman ditampilkan melalui berbagai lapisan dari database ke Fragment. Pada langkah berikutnya, kita akan memodifikasi kode untuk menambahkan pengurutan khusus menggunakan builder LiveData.

• Aplikasi codelab ini didasarkan pada contoh open source Android Sunflower
• Fakta menarik: growZoneNumberberbeda tampilannya pada Peta Zona Ketahanan Tanaman Departemen Pertanian Amerika Serikat

Daftar tanaman saat ini ditampilkan dalam urutan abjad, tetapi kami ingin mengubah urutan daftar ini dengan mencantumkan tanaman tertentu terlebih dahulu, lalu sisanya dalam urutan abjad. Ini serupa dengan aplikasi belanja yang menampilkan hasil bersponsor di bagian atas daftar item yang tersedia untuk dibeli. Tim produk kami menginginkan kemampuan untuk mengubah rangkaian pengurutan secara dinamis tanpa mengirimkan versi baru aplikasi, sehingga kita akan mengambil daftar tanaman untuk diurutkan terlebih dahulu dari backend.

Berikut tampilan aplikasi dengan pengurutan khusus:

Daftar rangkaian pengurutan khusus terdiri dari empat tanaman: Jeruk, Bunga Matahari, Anggur, dan Alpukat. Perhatikan bagaimana urutan tersebut muncul pertama dalam daftar, lalu diikuti oleh tanaman lainnya dalam urutan abjad.

Sekarang, jika tombol filter ditekan (dan hanya GrowZone 9 tanaman yang ditampilkan), Bunga Matahari menghilang dari daftar karena GrowZone-nya bukan 9. Tiga tanaman lainnya dalam daftar urutan khusus berada di GrowZone 9, sehingga akan tetap berada di bagian atas daftar. Satu-satunya tanaman lainnya di GrowZone 9 adalah Tomat, yang muncul terakhir dalam daftar ini.

Mari kita mulai menulis kode untuk mengimplementasikan pengurutan khusus.

Kita akan mulai dengan menulis fungsi penangguhan untuk mengambil rangkaian pengurutan khusus dari jaringan, lalu meng-cache-nya dalam memori.

Tambahkan kode berikut ke PlantRepository:

PlantRepository.kt

private var plantsListSortOrderCache =
    CacheOnSuccess(onErrorFallback = { listOf<String>() }) {
        plantService.customPlantSortOrder()
    }

plantsListSortOrderCache digunakan sebagai cache dalam memori untuk urutan khusus. Objek ini akan kembali ke daftar kosong jika terjadi error jaringan, sehingga aplikasi kami masih dapat menampilkan data meskipun rangkaian pengurutan tidak diambil.

Kode ini menggunakan class utilitas CacheOnSuccess yang disediakan di modul sunflower untuk menangani penyimpanan ke cache. Dengan memisahkan detail pengimplementasian cache seperti ini, kode aplikasi dapat menjadi lebih sederhana. Karena CacheOnSuccess sudah diuji dengan baik, kita tidak perlu menulis terlalu banyak pengujian untuk repositori kami guna memastikan perilaku yang tepat. Sebaiknya perkenalkan abstraksi tingkat tinggi yang serupa dalam kode Anda saat menggunakan kotlinx-coroutines.

Sekarang mari kita gabungkan beberapa logika untuk menerapkan pengurutan ke daftar tanaman.

Tambahkan kode berikut ke PlantRepository:

PlantRepository.kt

private fun List<Plant>.applySort(customSortOrder: List<String>): List<Plant> {
    return sortedBy { plant ->
        val positionForItem = customSortOrder.indexOf(plant.plantId).let { order ->
            if (order > -1) order else Int.MAX_VALUE
        }
        ComparablePair(positionForItem, plant.name)
    }
}

Fungsi ekstensi ini akan mengatur ulang daftar, menempatkan Plants yang ada di customSortOrder di bagian depan daftar.

Setelah logika pengurutan diterapkan, ganti kode untuk plants dan getPlantsWithGrowZone dengan LiveData builder di bawah:

PlantRepository.kt

val plants: LiveData<List<Plant>> = liveData<List<Plant>> {
   val plantsLiveData = plantDao.getPlants()
   val customSortOrder = plantsListSortOrderCache.getOrAwait()
   emitSource(plantsLiveData.map {
       plantList -> plantList.applySort(customSortOrder)
   })
}

fun getPlantsWithGrowZone(growZone: GrowZone) = liveData {
    val plantsGrowZoneLiveData = plantDao.getPlantsWithGrowZoneNumber(growZone.number)
    val customSortOrder = plantsListSortOrderCache.getOrAwait()
    emitSource(plantsGrowZoneLiveData.map { plantList ->
        plantList.applySort(customSortOrder)
    })
}

Sekarang jika Anda menjalankan aplikasi, daftar tanaman yang diurutkan khusus akan muncul:

Builder LiveData memungkinkan kita menghitung nilai secara asinkron, karena liveData didukung oleh coroutine. Di sini kita memiliki fungsi penangguhan untuk mengambil daftar LiveData tanaman dari database, selagi memanggil fungsi penangguhan untuk mendapatkan rangkaian pengurutan khusus. Kami kemudian menggabungkan kedua nilai ini untuk mengurutkan daftar tanaman dan menampilkan nilai, semuanya dalam builder.

Anda dapat menampilkan beberapa nilai dari LiveData dengan memanggil fungsi emitSource() setiap kali Anda ingin menampilkan nilai baru. Perlu diperhatikan bahwa setiap panggilan ke emitSource() akan menghapus sumber yang telah ditambahkan sebelumnya.

Coroutine memulai eksekusi ketika diamati, dan dibatalkan ketika coroutine berhasil diselesaikan atau jika panggilan database atau jaringan gagal.

Jika salah satu panggilan fungsi penangguhan gagal, seluruh blok dibatalkan dan tidak dimulai ulang, yang membantu menghindari kebocoran.

Pada langkah berikutnya, kita akan mempelajari variasi getPlantsWithGrowZone menggunakan Transformasi.

Sekarang kita akan memodifikasi PlantRepository untuk mengimplementasikan transformasi yang ditangguhkan karena setiap nilai diproses, sambil mempelajari cara membuat transformasi asinkron yang kompleks di LiveData. Sebagai prasyarat, mari kita buat versi algoritma pengurutan yang aman digunakan di thread utama. Kita dapat menggunakan withContext untuk beralih ke petugas operator lain hanya untuk lambda dan melanjutkan di petugas operator yang sudah digunakan sejak awal.

Tambahkan kode berikut ke PlantRepository:

PlantRepository.kt

@AnyThread
suspend fun List<Plant>.applyMainSafeSort(customSortOrder: List<String>) =
    withContext(defaultDispatcher) {
        [e-mail](customSortOrder)
    }

Untuk beralih antara petugas operator, coroutine menggunakan withContext. Memanggil withContext akan mengalihkan ke petugas operator lain hanya untuk lambda kemudian kembali ke petugas operator yang memanggilnya dengan hasil lambda tersebut.

Secara default, coroutine Kotlin menyediakan tiga Petugas Operator: Main, IO, dan Default. Petugas operator IO dioptimalkan untuk pekerjaan IO seperti membaca dari jaringan atau disk, sedangkan petugas operator Default dioptimalkan untuk tugas yang menggunakan CPU secara intensif.

Kemudian kita dapat menggunakan pengurutan utama yang aman ini dengan builder LiveData. Update blok untuk menggunakan switchMap, yang memungkinkan Anda menunjuk ke LiveData baru setiap kali nilai baru diterima.

PlantRepository.kt

fun getPlantsWithGrowZone(growZone: GrowZone) =
   plantDao.getPlantsWithGrowZoneNumber(growZone.number)
       .switchMap { plantList ->
           liveData {
               val customSortOrder = plantsListSortOrderCache.getOrAwait()
               emit(plantList.applyMainSafeSort(customSortOrder))
           }
       }

Dibandingkan dengan versi sebelumnya, setelah rangkaian pengurutan khusus diterima dari jaringan, penyortiran khusus ini dapat digunakan dengan applyMainSafeSort utama baru yang aman. Hasil ini kemudian ditampilkan ke switchMap sebagai nilai baru yang ditampilkan oleh getPlantsWithGrowZone.

Mirip dengan LiveData plants di atas, coroutine memulai eksekusi ketika teridentifikasi dan dihentikan baik saat penyelesaian atau jika panggilan database atau jaringan gagal. Perbedaannya di sini adalah aman karena melakukan panggilan jaringan di peta karena di-cache.

Sekarang mari kita lihat bagaimana kode ini diimplementasikan dengan Flow, dan bandingkan penerapannya.

Kita akan membuat logika yang sama menggunakan Flow dari kotlinx-coroutines. Sebelum melakukannya, mari kita lihat apa itu flow dan bagaimana Anda bisa memasukkannya ke dalam aplikasi Anda.

Flow adalah versi asinkron dari Urutan, yaitu jenis kumpulan yang nilainya dibuat dengan sangat lambat. Sama seperti urutan, flow menghasilkan setiap nilai sesuai permintaan setiap kali nilai dibutuhkan, dan flow dapat berisi jumlah nilai yang tak terbatas.

Jadi, mengapa Kotlin memperkenalkan jenis Flow baru, dan apa bedanya dengan urutan reguler? Jawabannya ada pada keajaiban asinkronik. Flow mencakup dukungan penuh untuk coroutine. Artinya, Anda dapat membuat, mentransformasi, dan memakai Flow dengan coroutine. Anda juga dapat mengontrol konkurensi, yang berarti mengoordinasikan eksekusi beberapa coroutine secara deklaratif dengan Flow.

Cara ini membuka banyak kemungkinan yang menarik.

Flow adalah urutan nilai asinkron

Flow menghasilkan nilai satu per satu (bukan sekaligus) yang dapat menghasilkan nilai dari operasi asinkron seperti permintaan jaringan, panggilan database, atau kode asinkron lainnya. Kode ini mendukung coroutine di seluruh API-nya, sehingga Anda juga dapat mengubah flow dengan menggunakan coroutine.

Flow dapat digunakan dengan gaya pemrograman yang sepenuhnya reaktif. Jika Anda pernah menggunakan fitur seperti RxJava sebelumnya, Flow menyediakan fungsi yang serupa. Logika aplikasi dapat digambarkan secara ringkas dengan mentransformasi flow dengan operator fungsional seperti map, flatMapLatest, combine, dan seterusnya.

Flow juga mendukung fungsi penangguhan pada sebagian besar operator. Ini memungkinkan Anda melakukan tugas asinkron berurutan di dalam operator seperti map. Dengan menggunakan operasi penangguhan di dalam flow, seringkali menghasilkan kode yang lebih pendek dan lebih mudah dibaca daripada kode setara dalam gaya yang sepenuhnya reaktif.

Dalam codelab ini, kita akan mempelajari perbandingan menggunakan kedua pendekatan tersebut.

Bagaimana flow berjalan

Agar terbiasa dengan cara Flow menghasilkan nilai sesuai permintaan (atau secara lambat), lihat flow berikut yang menampilkan nilai (1, 2, 3) dan dicetak sebelum, selama, dan setelah masing-masing item diproduksi.

fun makeFlow() = flow {
   println("sending first value")
   emit(1)
   println("first value collected, sending another value")
   emit(2)
   println("second value collected, sending a third value")
   emit(3)
   println("done")
}

scope.launch {
   makeFlow().collect { value ->
       println("got $value")
   }
   println("flow is completed")
}

Jika Anda menjalankan ini, akan menghasilkan output berikut:

sending first value
got 1
first value collected, sending another value
got 2
second value collected, sending a third value
got 3
done
flow is completed

Anda dapat melihat bagaimana eksekusi memantul antara lambda collect dan builder flow. Setiap kali builder flow memanggil emit, akan suspends hingga elemen selesai diproses. Kemudian, ketika nilai lain diminta dari flow, nilai resumes akan dibiarkan dari posisi terakhir hingga panggilan menyala lagi. Saat builder flow selesai, Flow dibatalkan dan collect dilanjutkan, memungkinkan dan coroutine yang memanggil akan mencetak "flow selesai".

Panggilan ke collect sangat penting. Flow menggunakan operator yang menangguhkan seperti collect alih-alih memaparkan antarmuka Iterator sehingga selalu mengetahui saat digunakan secara aktif. Yang lebih penting, operator mengetahui kapan pemanggil tidak dapat meminta nilai lebih sehingga dapat membersihkan resource.

Flow dibuat dari awal sampai selesai menggunakan coroutine. Dengan menggunakan mekanisme suspend dan resume coroutine, mereka dapat menyinkronkan eksekusi producer (flow) dengan konsumen (collect).

Jika Anda telah menggunakan streaming reaktif dan sudah memahami konsep tekanan balik, ini akan diterapkan di Flow dengan menangguhkan coroutine.

Kapan flow berjalan

Flow pada contoh di atas mulai berjalan saat operator collect berjalan. Membuat Flow baru dengan memanggil builder flow atau API lain tidak akan menyebabkan eksekusi apa pun. Operator yang menangguhkan collect disebut operator terminal di Flow. Ada operator terminal lain yang menangguhkan seperti toList, first dan single yang dikirim dengan kotlinx-coroutines, dan Anda dapat membuatnya sendiri.

Secara default, Flow akan menjalankan:

• Setiap kali operator terminal diterapkan (dan setiap pemanggilan baru terpisah dari yang dimulai sebelumnya)
• Sampai coroutine yang sedang dijalankan dibatalkan
• Saat nilai terakhir telah diproses sepenuhnya, dan nilai lain telah diminta

Aturan ini adalah perilaku default dari Flow dan memungkinkan untuk membuat Flow yang telah berbagi status dengan operasi sebelumnya, tidak dapat dimulai ulang untuk setiap operator terminal, dan dijalankan secara terpisah dari koleksi dengan transformasi bawaan atau khusus dari Flow.

Menjalankan Flow disebut mengumpulkan flow. Secara default, Flow tidak akan melakukan apa pun hingga dikumpulkan, yang berarti menerapkan operator terminal apa pun.

myFlow.toList() // toList collects this flow and adds the values to a List

Kami juga mengatakan bahwa nilai individu dikumpulkan dari Flow oleh operator terminal.

myFlow.collect { item -> println("$item has been collected") }

Karena aturan ini, Flow dapat berpartisipasi dalam konkurensi terstruktur, dan aman untuk memulai coroutine yang berjalan lama dari Flow. Tidak mungkin Flow akan membocorkan resource, karena resource selalu bersih menggunakan aturan pembatalan kerja sama coroutine saat pemanggil dibatalkan.

Mari ubah flow di atas untuk hanya melihat dua elemen pertama menggunakan operator take, lalu kumpulkan dua kali.

scope.launch {
   val repeatableFlow = makeFlow().take(2)  // we only care about the first two elements
   println("first collection")
   repeatableFlow.collect()
   println("collecting again")
   repeatableFlow.collect()
   println("second collection completed")
}

Menjalankan kode ini, Anda akan melihat output ini:

first collection
sending first value
first value collected, sending another value
collecting again
sending first value
first value collected, sending another value
second collection completed

flow lambda dimulai dari atas setiap kali collect dipanggil. Hal ini penting jika flow melakukan pekerjaan yang mahal seperti membuat permintaan jaringan. Selain itu, karena kita menerapkan operator take(2), flow hanya akan menghasilkan dua nilai. Operator tidak akan melanjutkan lambda flow lagi setelah panggilan kedua ke emit, sehingga baris "nilai kedua yang dikumpulkan..." tidak akan dicetak.

Secara default, Flow akan dimulai ulang dari atas setiap kali operator terminal diterapkan. Hal ini penting jika Flow melakukan pekerjaan yang mahal, seperti membuat permintaan jaringan.

Oke, jadi Flow lambat seperti Sequence, tetapi bagaimana kode ini juga asinkron? Mari kita lihat contoh urutan asinkron–yang mengamati perubahan ke database.

Dalam contoh ini, kita perlu mengkoordinasikan data yang dihasilkan pada kumpulan thread database dengan observer yang aktif di thread lain, seperti thread utama atau UI thread. Dan, karena kita akan memublikasikan hasil secara berulang saat data berubah, skenario ini cocok untuk pola urutan asinkron.

Bayangkan Anda diberi tugas untuk menulis integrasi Room untuk Flow. Jika Anda memulai dengan dukungan kueri penangguhan yang ada di Room, Anda dapat menulis seperti ini:

// This code is a simplified version of how Room implements flow
fun <T> createFlow(query: Query, tables: List<Tables>): Flow<T> = flow {
    val changeTracker = tableChangeTracker(tables)

    while(true) {
        emit(suspendQuery(query))
        changeTracker.suspendUntilChanged()
    }
}

Kode ini bergantung pada dua fungsi penangguhan imajiner untuk membuat Flow:

• suspendQuery – fungsi utama yang aman yang menjalankan kueri penangguhan Room reguler
• suspendUntilChanged – fungsi yang menangguhkan coroutine sampai salah satu tabel berubah

Saat dikumpulkan, flow awalnya emits nilai pertama kueri. Setelah nilai tersebut diproses, flow akan dilanjutkan dan memanggil suspendUntilChanged, yang akan berfungsi seperti yang dilakukannya–menangguhkan flow sampai salah satu tabel berubah. Pada titik ini, tidak ada yang terjadi dalam sistem sampai salah satu tabel berubah dan flow dilanjutkan.

Saat flow dilanjutkan, flow akan membuat kueri aman utama lainnya, dan emits hasilnya. Proses ini berlanjut selamanya dalam loop tak terbatas.

Flow dan konkurensi terstruktur

Tapi tunggu dulu–kami tidak ingin membocorkan pekerjaan. Coroutine tidak terlalu mahal, namun berulang kali menyala sendiri untuk melakukan kueri database. Ini adalah hal yang cukup mahal apabila terjadi kebocoran.

Meskipun kami telah membuat loop tak terbatas, Flow membantu kami dengan mendukung konkurensi terstruktur.

Satu-satunya cara untuk menggunakan nilai atau melakukan iterasi pada flow adalah menggunakan operator terminal. Karena semua operator terminal adalah fungsi yang ditangguhkan, pekerjaan terikat dengan masa berlaku cakupan yang memanggilnya. Saat cakupan dibatalkan, flow akan otomatis dibatalkan dengan sendirinya menggunakan aturan pembatalan kerja sama coroutine reguler. Jadi, meskipun kita telah menulis loop tak terbatas dalam builder flow, kita dapat menggunakannya dengan aman tanpa kebocoran karena konkurensi terstruktur.

Flow mendukung konkurensi terstruktur

Karena flow memungkinkan Anda untuk menggunakan nilai hanya dengan operator terminal, flow dapat mendukung konkurensi terstruktur.

Jika konsumen flow dibatalkan, seluruh Flow dibatalkan. Karena konkurensi terstruktur, tidak mungkin membocorkan coroutine dari langkah menengah

Pada langkah ini, Anda akan mempelajari cara menggunakan Flow dengan Room dan mentransfernya ke UI.

Langkah ini umum untuk banyak penggunaan Flow. Jika digunakan dengan cara ini, Flow dari Room beroperasi sebagai kueri database yang dapat diobservasi, yang mirip dengan LiveData.

Update Dao

Untuk memulai, buka PlantDao.kt, dan tambahkan dua kueri baru yang menampilkan Flow<List<Plant>>:

PlantDao.kt

@Query("SELECT * from plants ORDER BY name")
fun getPlantsFlow(): Flow<List<Plant>>

@Query("SELECT * from plants WHERE growZoneNumber = :growZoneNumber ORDER BY name")
fun getPlantsWithGrowZoneNumberFlow(growZoneNumber: Int): Flow<List<Plant>>

Perhatikan bahwa kecuali untuk jenis nilai yang ditampilkan, fungsi ini identik dengan versi LiveData. Namun, kami akan mengembangkannya secara berdampingan untuk membandingkannya.

Dalam codelab ini, kita akan membuat transformasi database yang sama menggunakan builder LiveData dan Flow. Dalam aplikasi produksi, Anda hanya akan menyertakan salah satunya, tetapi akan berguna untuk membandingkannya satu sama lain untuk melihat cara kerjanya.

Dengan menentukan jenis nilai yang ditampilkan Flow, Room menjalankan kueri dengan karakteristik berikut:

• Main-safety – Kueri dengan jenis nilai yang ditampilkan Flow selalu berjalan di eksekutor Room, sehingga kueri tersebut selalu aman. Anda tidak perlu melakukan apa pun dalam kode untuk membuatnya menjalankan thread utama.
• Mengamati perubahan – Room secara otomatis mengamati perubahan dan memunculkan nilai baru ke flow.
• Urutan asinkron – Flow memunculkan seluruh hasil kueri pada setiap perubahan, dan tidak akan menampilkan buffer. Jika Anda menampilkan Flow<List<T>>, flow akan memunculkan List<T> yang berisi semua baris dari hasil kueri. Flow akan berjalan seperti urutan – memunculkan satu hasil kueri pada satu waktu dan menangguhkannya hingga diminta untuk hasil berikutnya.
• Dapat dibatalkan – Jika cakupan yang mengumpulkan flow ini dibatalkan, Room akan membatalkan pengamatan ini.

Jika digabungkan, ini akan membuat Flow menjadi jenis nilai yang ditampilkan yang bagus untuk mengamati database dari lapisan UI.

Update repositori

Untuk melanjutkan penyiapan nilai pengembalian yang baru ke UI, buka PlantRepository.kt, dan tambahkan kode berikut:

PlantRepository.kt

val plantsFlow: Flow<List<Plant>>
   get() = plantDao.getPlantsFlow()

fun getPlantsWithGrowZoneFlow(growZoneNumber: GrowZone): Flow<List<Plant>> {
   return plantDao.getPlantsWithGrowZoneNumberFlow(growZoneNumber.number)
}

Untuk saat ini, kita hanya meneruskan nilai Flow ke pemanggil. Ini sama persis dengan saat kami memulai codelab ini dengan meneruskan LiveData ke ViewModel.

Update ViewModel

Di PlantListViewModel.kt, mari kita mulai dengan cara sederhana dan cukup tampilkan plantsFlow. Kami akan kembali dan menambahkan zona pertumbuhan yang beralih ke versi flow dalam beberapa langkah berikutnya.

PlantListViewModel.kt

// add a new property to plantListViewModel

val plantsUsingFlow: LiveData<List<Plant>> = plantRepository.plantsFlow.asLiveData()

Sekali lagi, kami akan tetap menggunakan versi LiveData (val plants) untuk perbandingan.

Karena kita ingin menyimpan LiveData dalam lapisan UI untuk codelab ini, kita akan menggunakan fungsi ekstensi asLiveData untuk mengonversi Flow menjadi LiveData. Sama seperti builder LiveData, ini menambahkan waktu tunggu yang dapat dikonfigurasi untuk LiveData yang dihasilkan. Ini bagus karena mencegah kita memulai ulang kueri setiap kali konfigurasi berubah (misalnya dari rotasi perangkat).

Operator asLiveData mengonversi Flow menjadi LiveData dengan waktu tunggu yang dapat dikonfigurasi.

Sama seperti builder liveData, waktu tunggu akan membantu Flow supaya tidak perlu selalu memulai ulang. Jika layar lain diamati sebelum waktu tunggu, Flow tidak akan dibatalkan.

Karena flow menawarkan main-safety dan kemampuan untuk membatalkan, Anda dapat memilih untuk meneruskan Flow ke lapisan UI tanpa mengonversinya ke LiveData. Namun, untuk codelab ini, kami akan tetap menggunakan LiveData di lapisan UI.

Selain itu, di ViewModel, tambahkan update cache ke blok init. Langkah ini bersifat opsional untuk saat ini, tetapi jika Anda mengosongkan cache dan tidak menambahkan panggilan ini, Anda tidak akan melihat data apa pun di aplikasi.

PlantListViewModel.kt

init {
    clearGrowZoneNumber()  // keep this

    // fetch the full plant list
    launchDataLoad { plantRepository.tryUpdateRecentPlantsCache() }
}

Update Fragmen

Buka PlantListFragment.kt, dan ubah fungsi subscribeUi agar mengarah ke plantsUsingFlow LiveData baru.

PlantListFragment.kt

private fun subscribeUi(adapter: PlantAdapter) {
   viewModel.plantsUsingFlow.observe(viewLifecycleOwner) { plants ->
       adapter.submitList(plants)
   }
}

Menjalankan aplikasi dengan Flow

Jika menjalankan aplikasi lagi, Anda akan melihat bahwa Anda sedang memuat data menggunakan Flow. Karena kita belum menerapkan switchMap, opsi filter tidak melakukan apa pun.

Di langkah berikutnya, kita akan membahas transformasi data dalam Flow.

Pada langkah ini, Anda akan menerapkan rangkaian pengurutan ke plantsFlow. Kami akan melakukannya menggunakan API deklaratif dari flow.

Apa itu deklaratif?

Deklaratif adalah gaya API yang berarti mendeskripsikan apa yang harus dilakukan program Anda, bukan cara melakukannya. Salah satu bahasa deklaratif yang lebih umum adalah SQL, yang memungkinkan developer untuk mengekspresikan apa yang mereka inginkan sebagai kueri database, bukan cara melakukan kueri.

Dengan menggunakan transformasi seperti map, combine, atau mapLatest, kita dapat mengekspresikan bagaimana kita ingin mengubah setiap elemen saat bergerak melalui flow secara deklaratif. Itu bahkan memungkinkan kita untuk mengekspresikan konkurensi secara deklaratif, yang benar-benar bisa menyederhanakan kode. Di bagian ini, Anda akan melihat cara menggunakan operator untuk memberi tahu Flow agar meluncurkan dua coroutine dan menggabungkan hasilnya secara deklaratif.

Untuk memulai, buka PlantRepository.kt dan tentukan flow pribadi baru yang disebut customSortFlow:

PlantRepository.kt

private val customSortFlow = flow { emit(plantsListSortOrderCache.getOrAwait()) }

Ini menentukan Flow yang, saat dikumpulkan, akan memanggil getOrAwait dan emit rangkaian pengurutan.

Karena flow ini hanya memunculkan nilai tunggal, Anda juga dapat membuatnya langsung dari fungsi getOrAwait menggunakan asFlow.

// Create a flow that calls a single function
private val customSortFlow = plantsListSortOrderCache::getOrAwait.asFlow()

Kode ini membuat Flow baru yang memanggil getOrAwait dan menampilkan hasilnya sebagai nilai pertama dan satu-satunya. Hal ini dilakukan dengan mereferensikan metode getOrAwait menggunakan :: dan memanggil asFlow pada objek Function yang dihasilkan.

Kedua flow ini akan melakukan hal yang sama, memanggil getOrAwait dan menampilkan hasilnya sebelum selesai.

Menggabungkan beberapa flow secara deklaratif

Sekarang kita memiliki dua flow, customSortFlow dan plantsFlow, mari kita gabungkan secara deklaratif!

Tambahkan operator combine ke plantsFlow:

PlantRepository.kt

private val customSortFlow = plantsListSortOrderCache::getOrAwait.asFlow()

val plantsFlow: Flow<List<Plant>>
   get() = plantDao.getPlantsFlow()
       // When the result of customSortFlow is available,
       // this will combine it with the latest value from
       // the flow above.  Thus, as long as both `plants`
       // and `sortOrder` are have an initial value (their
       // flow has emitted at least one value), any change
       // to either `plants` or `sortOrder`  will call
       // `plants.applySort(sortOrder)`.
       .combine(customSortFlow) { plants, sortOrder ->
          plants.applySort(sortOrder)
       }

Operator combine menggabungkan dua flow secara bersamaan. Kedua flow akan berjalan di coroutine masing-masing, kemudian setiap flow menghasilkan nilai baru, transformasi akan dipanggil dengan nilai terbaru dari salah satu flow.

Dengan menggunakan combine, kita dapat menggabungkan pencarian jaringan dalam cache dengan kueri database. Keduanya akan berjalan di coroutine yang berbeda secara bersamaan. Itu berarti bahwa saat Room memulai permintaan jaringan, Retrofit dapat memulai kueri jaringan. Kemudian, setelah hasilnya tersedia untuk kedua flow tersebut, pemroses akan memanggil combine lambda tempat kita menerapkan rangkaian pengurutan yang dimuat untuk tanaman yang dimuat.

Transformasi combine akan meluncurkan satu coroutine untuk setiap flow yang digabung. Ini memungkinkan Anda menggabungkan dua flow secara bersamaan.

Ini akan menggabungkan flow dengan cara "fair", artinya flow tersebut akan mendapatkan kesempatan untuk menghasilkan nilai (meskipun salah satunya dihasilkan oleh loop yang ketat).

Untuk menjelajahi cara kerja operator combine, ubah customSortFlow untuk menampilkan dua kali dengan penundaan yang cukup lama di onStart seperti ini:

// Create a flow that calls a single function
private val customSortFlow = plantsListSortOrderCache::getOrAwait.asFlow()
   .onStart {
       emit(listOf())
       delay(1500)
   }

Transformasi onStart akan terjadi ketika observer mendengarkan sebelum operator lain, dan dapat memunculkan nilai placeholder. Jadi di sini kita menampilkan daftar kosong, menunda pemanggilan getOrAwait dengan 1500 md, lalu melanjutkan flow yang asli. Jika Anda menjalankan aplikasi sekarang, Anda akan melihat bahwa kueri database Room langsung dikembalikan, dikombinasikan dengan daftar kosong (yang berarti sekarang akan diurutkan berdasarkan abjad). Lalu, sekitar 1500 md kemudian, akan diterapkan penyortiran khusus.

Sebelum melanjutkan dengan codelab, hapus transformasi onStart dari customSortFlow.

Anda dapat menggunakan onStart untuk menjalankan kode penangguhan sebelum flow berjalan. Ini bahkan dapat emit nilai tambahan ke dalam flow, sehingga Anda dapat menggunakannya untuk menampilkan status Loading pada flow permintaan jaringan.

Flow dan main-safety

Flow dapat memanggil fungsi main-safe, seperti yang kita lakukan di sini, dan akan mempertahankan jaminan main-safety normal dari coroutine. Baik Room maupun Retrofit akan memberikan main-safety kepada kami, dan kami tidak perlu melakukan apa pun untuk membuat permintaan jaringan atau kueri database dengan Flow.

Flow ini menggunakan thread berikut yang sudah ada:

• plantService.customPlantSortOrderberjalan di thread Retrofit (panggilan ini Call.enqueue)
• getPlantsFlow akan menjalankan kueri di Eksekutor Room
• applySort akan berjalan pada petugas operator pengumpul (dalam kasus ini Dispatchers.Main)

Jadi, jika yang kami lakukan hanyalah memanggil fungsi penangguhan di Retrofit dan menggunakan flow Room, kami tidak perlu merumitkan kode ini dengan masalah main-safety.

Namun, seiring bertambahnya ukuran set data, panggilan ke applySort mungkin menjadi cukup lambat untuk memblokir thread utama. Flow menawarkan API deklaratif yang disebut flowOn untuk mengontrol thread yang menjalankan flow.

Tambahkan flowOn ke plantsFlow seperti ini:

PlantRepository.kt

private val customSortFlow = plantsListSortOrderCache::getOrAwait.asFlow()

val plantsFlow: Flow<List<Plant>>
   get() = plantDao.getPlantsFlow()
       .combine(customSortFlow) { plants, sortOrder ->
          plants.applySort(sortOrder)
       }
       .flowOn(defaultDispatcher)
       .conflate()

Memanggil flowOn memiliki dua efek penting pada cara kode dieksekusi:

1. Luncurkan coroutine baru di defaultDispatcher (dalam kasus ini, Dispatchers.Default) untuk menjalankan dan mengumpulkan flow sebelum panggilan ke flowOn.
2. Memperkenalkan buffer untuk mengirim hasil dari coroutine baru ke panggilan berikutnya.
3. Lepaskan nilai dari buffer tersebut ke dalam Flow setelah flowOn. Dalam hal ini, asLiveData adalah di ViewModel.

Hal ini sangat mirip dengan cara kerja withContext untuk beralih petugas operator, tetapi hal ini memperkenalkan buffer di tengah transformasi kami yang mengubah cara kerja flow. Coroutine yang diluncurkan oleh flowOn diizinkan untuk memberikan hasil yang lebih cepat daripada yang digunakan pemanggil, dan akan membuat buffer dalam jumlah besar secara default.

Dalam hal ini, kami berencana mengirimkan hasil ke UI, jadi kami hanya akan peduli dengan hasil terbaru. Itulah yang dilakukan operator conflate–ini memodifikasi buffer flowOn untuk menyimpan hasil terakhir saja. Jika hasil lain muncul sebelum hasil sebelumnya dibaca, hasil akan ditimpa.

Operator flowOn meluncurkan coroutine baru untuk mengumpulkan flow di atasnya dan memperkenalkan buffer untuk menulis hasilnya.

Anda dapat mengontrol buffer dengan lebih banyak operator, seperti conflate yang mengatakan untuk menyimpan nilai terakhir yang dihasilkan dalam buffer.

Penting untuk mengetahui buffer saat menggunakan flowOn dengan objek besar seperti hasil Room karena mudah digunakan dalam jumlah besar hasil buffering memori.

Jalankan aplikasi

Jika menjalankan aplikasi lagi, Anda akan melihat bahwa Anda sedang memuat data dan menerapkan rangkaian pengurutan khusus menggunakan Flow. Karena kita belum menerapkan switchMap, opsi filter tidak melakukan apa pun.

Pada langkah berikutnya, kita akan melihat cara lain untuk memberikan main-safety menggunakan flow.

Untuk menyelesaikan versi flow API ini, buka PlantListViewModel.kt, tempat kita akan beralih di antara flow berdasarkan GrowZone seperti yang kita lakukan di versi LiveData.

Tambahkan kode berikut di bawah plants liveData:

PlantListViewModel.kt

private val growZoneFlow = MutableStateFlow<GrowZone>(NoGrowZone)

val plantsUsingFlow: LiveData<List<Plant>> = growZoneFlow.flatMapLatest { growZone ->
        if (growZone == NoGrowZone) {
            plantRepository.plantsFlow
        } else {
            plantRepository.getPlantsWithGrowZoneFlow(growZone)
        }
    }.asLiveData()

Perhatikan, contoh ini menggunakan beberapa @ExperimentalCoroutinesApis, dan kemungkinan akan ada versi yang lebih ringkas pada versi final Flow API.

Pola ini menunjukkan cara mengintegrasikan peristiwa (perubahan zona pertumbuhan) ke dalam flow. Ini melakukan hal yang sama persis seperti versi LiveData.switchMap–beralih antara dua sumber data berdasarkan peristiwa.

Melewati kode

PlantListViewModel.kt

private val growZoneFlow = MutableStateFlow<GrowZone>(NoGrowZone)

Ini menentukan MutableStateFlow baru dengan nilai awal NoGrowZone. Ini adalah jenis khusus dari pemegang nilai Flow yang hanya berisi nilai terakhir yang diberikan. Ini adalah primitif konkurensi thread-safe, jadi Anda bisa menulis dari beberapa thread sekaligus (dan mana saja yang dianggap "terakhir" akan menang).

Anda juga dapat berlangganan untuk mendapatkan informasi terbaru tentang nilai saat ini. Secara keseluruhan, ini memiliki perilaku yang mirip dengan LiveData–hanya menyimpan nilai terakhir dan memungkinkan Anda mengamati perubahan pada nilai tersebut.

StateFlow berbeda dari flow reguler yang dibuat menggunakan, misalnya, builder flow{}. StateFlow dibuat dengan nilai awal dan mempertahankan statusnya bahkan tanpa dikumpulkan dan di antara koleksi berikutnya. Anda dapat menggunakan antarmuka MutableStateFlow (seperti yang ditunjukkan di atas) untuk mengubah nilai (status) StateFlow.

Anda akan sering menemukan bahwa flow yang berperilaku seperti StateFlow disebut hot, bukan flow cold biasa yang hanya dijalankan ketika dikumpulkan.

PlantListViewModel.kt

val plantsUsingFlow: LiveData<List<Plant>> = growZoneFlow.flatMapLatest { growZone ->

StateFlow juga merupakan Flow biasa, jadi Anda dapat menggunakan semua operator seperti biasa.

Di sini kami menggunakan operator flatMapLatest yang sama persis dengan switchMap dari LiveData. Setiap kali growZone mengubah nilainya, lambda ini akan diterapkan dan harus menampilkan Flow. Kemudian, Flow yang ditampilkan akan digunakan sebagai Flow untuk semua operator downstream.

Pada dasarnya, ini memungkinkan kita beralih di antara flow yang berbeda berdasarkan nilai growZone.

flatMapLatest Ekstensi flow memungkinkan Anda beralih di antara beberapa flow.

PlantListViewModel.kt

if (growZone == NoGrowZone) {
    plantRepository.plantsFlow
} else {
    plantRepository.getPlantsWithGrowZoneFlow(growZone)
}

Di dalam flatMapLatest, kami beralih berdasarkan growZone. Kode ini cukup mirip dengan versi LiveData.switchMap, dengan satu-satunya perbedaan adalah bahwa kode tersebut menampilkan Flows, bukan LiveDatas.

PlantListViewModel.kt

   }.asLiveData()

Dan terakhir, kami mengonversi Flow menjadi LiveData, karena Fragment kami akan menampilkan LiveData dari ViewModel.

Operator asLiveData akan mengonversi Flow menjadi LiveData dengan waktu tunggu yang dapat dikonfigurasi.

Sama seperti builder liveData, waktu tunggu akan tetap mengaktifkan flow melalui rotasi sehingga koleksi Anda tidak dimulai ulang.

Mengubah nilai StateFlow

Untuk memberi tahu aplikasi tentang perubahan filter, kita dapat menyetel MutableStateFlow.value. Inilah cara mudah untuk mengomunikasikan peristiwa ke dalam coroutine seperti yang kita lakukan di sini.

PlantListViewModel.kt

fun setGrowZoneNumber(num: Int) {
    growZone.value = GrowZone(num)
    growZoneFlow.value = GrowZone(num)

    launchDataLoad {
        plantRepository.tryUpdateRecentPlantsForGrowZoneCache(GrowZone(num)) }
    }

fun clearGrowZoneNumber() {
    growZone.value = NoGrowZone
    growZoneFlow.value = NoGrowZone

    launchDataLoad {
        plantRepository.tryUpdateRecentPlantsCache()
    }
}

Menjalankan kembali aplikasi

Jika Anda menjalankan aplikasi lagi, filter sekarang berfungsi untuk versi LiveData dan versi Flow.

Pada langkah berikutnya, kami akan menerapkan penyortiran khusus untuk getPlantsWithGrowZoneFlow.

Salah satu fitur yang paling menarik dari Flow adalah dukungan kelas satu untuk fungsi penangguhan. Builder flow dan hampir setiap transformasi memperlihatkan operator suspend yang dapat memanggil fungsi penangguhan apa pun. Akibatnya, main-safety untuk panggilan jaringan dan database serta mengatur beberapa operasi asinkron dapat dilakukan menggunakan panggilan ke fungsi penangguhan reguler dari dalam flow.

Akibatnya, ini memungkinkan Anda untuk secara alami menggabungkan transformasi deklaratif dengan kode penting. Seperti yang akan Anda lihat dalam contoh ini, di dalam operator peta reguler, Anda dapat mengatur beberapa operasi asinkron tanpa menerapkan transformasi tambahan. Di banyak tempat, hal ini dapat menghasilkan kode yang jauh lebih sederhana daripada pendekatan deklaratif sepenuhnya.

Jika Anda telah menggunakan library seperti RxJava secara luas, ini adalah salah satu perbedaan utama yang diberikan oleh Flow.

Saat memulai Flow, pertimbangkan dengan cermat bagaimana Anda dapat menggunakan transformasi penangguhan untuk menyederhanakan kode. Dalam banyak kasus, Anda dapat mengekspresikan kode asinkron secara alami dengan mengandalkan operasi penangguhan di dalam operator seperti map, onStart, dan onCompletion.

Operator yang sudah dikenal dari Rx seperti combine, mapLatest, flatMapLatest, flattenMerge, dan flatMapMerge paling baik digunakan untuk mengatur konkurensi dalam Flow.

Menggunakan fungsi menangguhkan untuk mengatur kerja asinkron

Untuk mengakhiri penjelajahan Flow, kami akan menerapkan penyortiran khusus menggunakan operator yang ditangguhkan.

Buka PlantRepository.kt dan tambahkan transformasi peta ke getPlantsWithGrowZoneNumberFlow.

PlantRepository.kt

fun getPlantsWithGrowZoneFlow(growZone: GrowZone): Flow<List<Plant>> {
   return plantDao.getPlantsWithGrowZoneNumberFlow(growZone.number)
       .map { plantList ->
           val sortOrderFromNetwork = plantsListSortOrderCache.getOrAwait()
           val nextValue = plantList.applyMainSafeSort(sortOrderFromNetwork)
           nextValue
       }
}

Dengan mengandalkan fungsi menangguhkan reguler untuk menangani pekerjaan asinkron, operasi peta ini menjadi main-safe meskipun menggabungkan dua operasi asinkron.

Karena setiap hasil dari database dikembalikan, kita akan mendapatkan rangkaian pengurutan dalam cache–dan jika belum siap, tindakan ini akan menunggu di permintaan jaringan asinkron. Setelah kita selesai mengurutkan, akan aman untuk memanggil applyMainSafeSort, yang akan menjalankan penyortiran pada petugas operator default.

Kode ini sekarang sepenuhnya main-safe dengan menunda masalah main-safety ke fungsi penangguhan reguler. Ini sedikit lebih sederhana daripada transformasi yang sama yang diterapkan di plantsFlow.

Di Flow, map dan operator lainnya menerima lambda yang ditangguhkan.

Dengan menggunakan mekanisme penangguhan dan melanjutkan coroutine, Anda sering kali dapat mengatur panggilan asinkron berurutan secara mudah tanpa menggunakan transformasi deklaratif.

Ini adalah error untuk menampilkan nilai dari coroutine yang berbeda dengan yang disebut transformasi penangguhan.

Jika Anda meluncurkan coroutine lain dalam operasi flow seperti yang kami lakukan di sini dalam getOrAwait dan applyMainSafeSort, pastikan nilai dikembalikan ke coroutine asli sebelum emitting.

Namun, perlu diperhatikan bahwa ini akan dijalankan sedikit berbeda. Nilai yang disimpan dalam cache akan diambil setiap kali database memunculkan nilai baru. Ini tidak masalah karena kami menyimpannya dengan benar di plantsListSortOrderCache, tetapi jika permintaan jaringan baru dimulai, penerapan ini akan membuat banyak permintaan jaringan yang tidak diperlukan. Selain itu, pada versi .combine, permintaan jaringan dan kueri database dijalankan secara bersamaan, sedangkan dalam versi ini, permintaan tersebut dijalankan secara berurutan.

Karena perbedaan ini, tidak ada aturan yang jelas untuk menyusun kode ini. Umumnya, bukan masalah apabila menggunakan transformasi penangguhan seperti apa yang kita lakukan di sini, yang akan membuat semua operasi asinkron berbentuk berurutan. Namun, dalam kasus lain, sebaiknya gunakan operator untuk mengontrol konkurensi dan memberikan main-safety.

Anda hampir selesai! Sebagai langkah terakhir (opsional), mari memindahkan permintaan jaringan ke dalam coroutine berbasis flow.

Dengan melakukannya, kami akan menghapus logika untuk melakukan panggilan jaringan dari pengendali yang dipanggil oleh onClick dan mengarahkannya dari growZone. Ini membantu kami membuat satu sumber kebenaran dan menghindari duplikasi kode–tidak mungkin kode apa pun dapat mengubah filter tanpa menyegarkan cache.

Buka PlantListViewModel.kt, dan tambahkan ke blok init:

PlantListViewModel.kt

init {
   clearGrowZoneNumber()

   growZone.mapLatest { growZone ->
           _spinner.value = true
           if (growZone == NoGrowZone) {
               plantRepository.tryUpdateRecentPlantsCache()
           } else {
               plantRepository.tryUpdateRecentPlantsForGrowZoneCache(growZone)
           }
       }
       .onEach {  _spinner.value = false }
       .catch { throwable ->  _snackbar.value = throwable.message  }
       .launchIn(viewModelScope)
}

Kode ini akan meluncurkan coroutine baru untuk mengamati nilai yang dikirim ke growZoneChannel. Anda dapat mengomentari panggilan jaringan dalam metode di bawah sekarang karena hanya diperlukan untuk versi LiveData.

PlantListViewModel.kt

fun setGrowZoneNumber(num: Int) {
    growZone.value = GrowZone(num)
    growZoneFlow.value = GrowZone(num)

    // launchDataLoad {
    //    plantRepository.tryUpdateRecentPlantsForGrowZoneCache(GrowZone(num))
    // }
}

fun clearGrowZoneNumber() {
    growZone.value = NoGrowZone
    growZoneFlow.value = NoGrowZone

    // launchDataLoad {
    //    plantRepository.tryUpdateRecentPlantsCache()
    // }
}

Menjalankan kembali aplikasi

Jika menjalankan aplikasi lagi sekarang, Anda akan melihat bahwa penyegaran jaringan sekarang dikontrol oleh growZone. Kami telah meningkatkan kode secara nyata, karena lebih banyak cara untuk mengubah filter yang ada di saluran berfungsi sebagai satu sumber kebenaran untuk filter yang aktif. Dengan demikian, permintaan jaringan dan filter saat ini tidak dapat disinkronkan.

Melewati kode

Mari kita ikuti semua fungsi baru yang digunakan satu per satu, mulai dari luar:

PlantListViewModel.kt

growZone
    // ...
    .launchIn(viewModelScope)

Kali ini, kami menggunakan operator launchIn untuk mengumpulkan flow di dalam ViewModel kami.

Operator launchIn membuat coroutine baru dan mengumpulkan setiap nilai dari flow. Coroutine akan diluncurkan dalam CoroutineScope yang disediakan–dalam hal ini, viewModelScope. Ini sangat bagus, karena artinya jika ViewModel ini dihapus, koleksi akan dibatalkan.

Tanpa menyediakan operator lainnya, ini tidak terlalu besar–namun karena Flow menyediakan penangguhan lambda di semua operatornya untuk memudahkan tindakan asinkron berdasarkan setiap nilai.

Menggunakan Flow, mengumpulkan data di ViewModel, Repository, atau lapisan data lainnya adalah hal yang wajar jika diperlukan.

Karena Flow tidak terkait dengan UI, Anda tidak memerlukan observer UI untuk collect flow. Ini adalah perbedaan besar dari LiveData yang selalu memerlukan observer UI untuk berjalan. Sebaiknya jangan coba observe LiveData di ViewModel Anda karena tidak memiliki siklus proses pengamatan yang sesuai.

PlantListViewModel.kt

.mapLatest { growZone ->
    _spinner.value = true
    if (growZone == NoGrowZone) {
        plantRepository.tryUpdateRecentPlantsCache()
    } else {
        plantRepository.tryUpdateRecentPlantsForGrowZoneCache(growZone)
    }
}

Di sinilah letak keajaibannya–mapLatest akan menerapkan fungsi peta ini untuk setiap nilai. Namun, tidak seperti map yang reguler, ini akan meluncurkan coroutine baru untuk setiap panggilan ke transformasi peta. Kemudian, jika nilai baru dikeluarkan oleh growZoneChannel sebelum coroutine sebelumnya selesai, nilai tersebut akan membatalkannya sebelum memulai yang baru.

Kita dapat menggunakan mapLatest untuk mengontrol konkurensi bagi kita. Alih-alih membuat sendiri logika pembatalan/memulai ulang, transformasi flow dapat menanganinya. Kode ini menyimpan banyak kode dan kerumitan dibandingkan dengan menulis logika pembatalan yang sama secara manual.

Pembatalan Flow mengikuti aturan pembatalan kerja sama normal dari coroutine.

Jika menggunakan RxJava, Anda dapat menggunakan mapLatest sama seperti menggunakan switchMap.

Perbedaan utamanya adalah memberikan lambda penangguhan untuk Anda dalam coroutine baru, sehingga Anda dapat memanggil fungsi penangguhan reguler langsung dari mapLatest.

PlantListViewModel.kt

.onEach {  _spinner.value = false }
.catch { throwable -> _snackbar.value = throwable.message }

onEach akan dipanggil setiap kali flow di atas memunculkan nilai. Di sini kami menggunakannya untuk menyetel ulang spinner setelah pemrosesan selesai.

Operator catch akan menangkap setiap pengecualian yang ditampilkan di atasnya di flow. Ini dapat memunculkan nilai baru ke flow seperti status error, menggabungkan kembali pengecualian ke flow, atau melakukan pekerjaan seperti yang kita lakukan di sini.

Saat terjadi error, kami hanya meminta _snackbar untuk menampilkan pesan error.

Menyelesaikan

Langkah ini menunjukkan cara mengontrol serentak menggunakan Flow, serta menggunakan Flows dalam ViewModel tanpa bergantung pada observer UI.

Sebagai langkah tantangan, coba tentukan fungsi untuk enkapsulasi pemuatan data flow ini dengan tanda tangan berikut:

fun <T> loadDataFor(source: StateFlow<T>, block: suspend (T) -> Unit) {