RxJava digunakan dalam sejumlah besar aplikasi android, tetapi pada saat yang sama banyak yang tidak tahu sumber acara lainnya, kecuali untuk Observable dan mungkin Flowable. Mereka lupa tentang kelas khusus Single, Maybe, dan Completable, yang seringkali dapat menambah kejelasan kode.
Di bawah kucing Anda akan menemukan lembar contekan pada sumber acara yang ada di RxJava.
Completable sebenarnya adalah analog Rx dari Runnable. Ini adalah operasi yang dapat dilakukan atau tidak. Jika kita menggambar analogi dengan Kotlin, maka ini
menyenangkan diselesaikan () dari dunia Rx. Dengan demikian, untuk berlangganan, Anda perlu menerapkan onComplete dan onError. Itu tidak dapat dibuat dari nilai (Observable # just, ...) karena tidak dirancang untuk ini.
Callable
tunggal - reaktif, karena di sini dimungkinkan untuk mengembalikan hasil operasi. Melanjutkan perbandingan dengan Kotlin, kita dapat mengatakan bahwa Single is fun single (): T {}. Dengan demikian, untuk berlangganan, Anda harus menerapkan onSuccess (T) dan onError.
Mungkin - persilangan antara Single dan Completable, karena mendukung satu nilai, tidak ada nilai, dan kesalahan. Lebih sulit untuk menggambar paralel yang jelas dengan metode, tapi saya pikir Mungkin menyenangkan mungkin (): T? {}, yang mengembalikan null ketika tidak ada hasil. Mudah ditebak bahwa untuk berlangganan Anda perlu mendefinisikan onSuccess (T), onComplete, dan onError.
Penting untuk dicatat bahwa onSuccess (T) dan onComplete saling eksklusif. Yaitu dalam hal memanggil yang pertama, Anda tidak bisa menunggu yang kedua.
Dapat diamati adalah sumber yang paling umum, karena fleksibilitasnya. Dia tahu bagaimana tidak menghasilkan acara sama sekali, dan menghasilkan banyak dari mereka, sehingga dia dapat digunakan selalu ketika opsi lain tidak cocok. Meskipun demikian, Observable memiliki kelemahan - ia tidak tahu bagaimana menangani tekanan balik. Untuk berlangganan, Anda perlu onNext (T), onError, dan onComplete.
Backpressure - situasi ketika acara baru tiba lebih cepat daripada waktu yang mereka miliki untuk memproses, dan mulai menumpuk di buffer, meluap. Ini dapat menyebabkan masalah seperti OutOfMemoryError. Rincian lebih lanjut dapat ditemukan di sini .
ConnectableObservable - versi panas dari Observable. Semua sumber data mulai mengeluarkan aliran acara mereka pada saat berlangganan. Tapi bukan orang ini. Untuk melakukan ini, ConnectableObservable menunggu panggilan untuk terhubung. Ini dilakukan agar beberapa pengamat dapat meninjau satu aliran acara tanpa memulai lagi di setiap langganan. Sebagai ilustrasi, saya akan memberi Anda cuplikan berikut:
val observable = Observable.fromCallable { Log.d("RxLogs", "observable fromCallable executed") Thread.sleep(1000) }.subscribeOn(Schedulers.computation()) observable.subscribe() observable.subscribe() observable.subscribe() observable.subscribe()
Di konsol akan menjadi:
diamati dari Panggilan dieksekusi
diamati dari Panggilan dieksekusi
diamati dari Panggilan dieksekusi
diamati dari Panggilan dieksekusi
val connectedObservable = Observable.fromCallable { Log.d("RxLogs", "connectedObservable fromCallable executed") Thread.sleep(1000) }.subscribeOn(Schedulers.computation()) .publish() connectedObservable.subscribe() connectedObservable.subscribe() connectedObservable.subscribe() connectedObservable.subscribe() connectedObservable.connect()
Dan dalam hal ini: observable fromCallable dieksekusi
Flowable - sumber yang menyediakan operator tambahan untuk memproses tekanan balik. Ketika Anda perlu menangani lebih dari 10.000 peristiwa yang terjadi dengan cepat satu demi satu, disarankan untuk menggunakannya daripada diobservasi.
Yang terakhir dapat membuat ConnectableFlowable, membuka kemungkinan yang sama seperti ConnectableObservable.
Berbicara tentang generator acara, orang tidak bisa tidak menyebutkan Subjek dan Prosesor.
Subjek - kelas yang bisa menjadi sumber dan browser. Ini memungkinkan Anda untuk menggunakannya, misalnya, dalam berbagai jenis pengontrol, yang akan memberikannya sebagai Pengamatan dan pemberitahuan di dalam sebagai Pengamat. Selanjutnya, kita akan melalui implementasi yang berbeda dari kelas ini.
AsyncSubject / AsyncProcessor mengadakan acara terakhir hingga utas selesai dengan benar, dan kemudian mengirimkannya ke pelanggan. Jika kesalahan terjadi, tidak ada acara yang akan diteruskan.
PublishSubject / PublishProcessor meneruskan kejadian yang datang lebih jauh sampai sinyal terminal tiba. Setelah akhir streaming atau kesalahan, ini mengembalikan acara yang sesuai.
BehaviorSubject / BehaviorProcessor bekerja mirip dengan PublishSubject / PublishProcessor, tetapi setelah berlangganan ia mengembalikan acara terakhir, jika ada, dan jika Subjek belum beralih ke keadaan terminal.
ReplaySubject / ReplayProcessor - BehaviourSubject / BehaviorProcessor pada steroid. Ia mengembalikan bukan satu peristiwa terakhir, tetapi sebanyak yang diinginkan jiwa. Jika Anda berlangganan ReplaySubject atau ReplayProcessor yang sudah lengkap, maka semua data yang terakumulasi akan diterima.
Dengan demikian, ReplaySubject.createWithSize (1) dan BehaviourSubject.create () bekerja secara berbeda setelah transisi ke keadaan terminal. Selama berlangganan, yang pertama akan mengembalikan acara terakhir, dan yang kedua tidak. Itu juga berlaku untuk ReplayProcessor.
CompletableSubject ,
MaybeSubject dan
SingleSubject bekerja mirip dengan PublishSubject, masing-masing hanya dirancang untuk digunakan dengan Completable, Maybe dan Single.
UnicastSubject / UnicastProcessor sebenarnya adalah ReplaySubject yang memastikan bahwa ia hanya memiliki satu pelanggan. Itu melempar IllegalStateException ketika mencoba berlangganan kembali.
Yaitu cuplikan berikutnya
val subject = UnicastSubject.create<String>(3) repeat(3) { subject.onNext(it.toString()) } subject.onComplete() subject.subscribe({ Log.d("RxLogs", it) }, { }, { Log.d("RxLogs", "complete") })
akan ditampilkan ke log
0
1
2
lengkap
MulticastProcessor bekerja mirip dengan PublishProcessor, dengan pengecualian satu fitur kecil. Dia tahu bagaimana menangani tekanan balik untuk aliran masuk. MulticastProcessor memungkinkan Anda untuk mengatur ukuran buffer di mana ia akan melakukan pra-permintaan elemen dari hulu untuk pelanggan di masa mendatang.
Dalam diagram di bawah, prosesor dibuat dengan penyimpanan untuk 2 elemen, yang langsung diminta dari sumbernya. Oleh karena itu, ketika pengamat pertama berlangganan, itu segera mengeluarkan isi buffer, yang langsung diisi dengan peristiwa baru. Setelah peristiwa terminal, MulticastProcessor membersihkan penyimpanannya dan pelanggan baru segera menerima penyelesaian aliran.
