Develop Reference

Nested async functions in Android

I have asynchronous functions with firebase and other APIs that depend on each other. So, to start task B has to finish task A.
The async functions are retuning MyResult which can be a success or failure. Now I’m doing it in that way
when(val resullt1 = function1UseCase.getresult1()){
is MyResult.Success ->{
when(val result2 = function2UseCase.getResult2()){
is MyResult.Succes ->{
//Do something or call another async function
}
is MyResult.Failure ->{
//Do something or call another async function
}
}
}
is MyResult.Failure ->{
//Do something or call another async function
}
}
Is there a better way to do it? Because when I have more nested tasks the code doesn’t look very well.
Thanks!

You can create a simple extension. Something like that
inline fun <F, R> MyResult<F>.then(function: (F) -> MyResult<R>) = when (this) {
is MyResult.Succes -> {
try {
function(result)
} catch (throwable: Throwable) {
MyResult.Failure(your_error_handling_here)
}
}
is MyResult.Failure -> this
}
Annnd then it will be like that
when(val result = function1UseCase.getresult1().then { function2UseCase.getResult2() }) {
is MyResult.Success -> {
}
is MyResult.Failure -> {
//Do something or call another async function
}
}
You can slightly modify this if you need to have both results at the very end ;)

RxJava take(1) completes wheras Observable.just() does not

I use RXAndroidBle to connect to Bluetooth devices. I use establishConnection to get the connection observable and want to convert this Observable to an Completable. This code works and the completable completes as expected:
connectionObservable
.observeOn(AndroidSchedulers.mainThread())
.doOnNext {
...
startReadingData()
}
.doOnError { ... }
.take(1)
.ignoreElements()
whereas this never completes:
connectionObservable
.observeOn(AndroidSchedulers.mainThread())
.doOnNext {
...
startReadingData()
}
.doOnError { ... }
.flatMap { Observable.just(it) }
.ignoreElements() // flatMapCompletable { Completable.complete() } doesn't work either
So I'm purly asking out of interest, why does flatMap with Observable.just() not work, as Obsrevable.just() also completes immediately?

Problem
Never completes:
connectionObservable
.observeOn(AndroidSchedulers.mainThread())
.doOnNext {
...
startReadingData()
}
.doOnError { ... }
.flatMap { Observable.just(it) }
.ignoreElements() // flatMapCompletable { Completable.complete() } doesn't work either
This is actually quite simple. The connectionObservable is probably infinite. It will call onNext, but not onComplete. The downstream operators receive the onNext emit and process it accordingly. The flatMap operator only completes, when the upstream and the inner-stream emits onComplete. The inner-stream of flatMap completes, but not the source-observable. Therefore you do not get a terminal messages, ever.
Completes
connectionObservable
.observeOn(AndroidSchedulers.mainThread())
.doOnNext {
...
startReadingData()
}
.doOnError { ... }
.take(1)
.ignoreElements()
This stream completes, because there is a terminal operator. In this case you have a take(1). What does the Take-Operator do? It will wait for an onNext emit from source and transforms it to onNext(message) and onComplete(). You could add the flatMap with Observable.just as inner-stream below the take-Operator and it would still complete.
Take-Operator Impl
#Override
public void onNext(T t) {
if (!done && remaining-- > 0) {
boolean stop = remaining == 0;
downstream.onNext(t);
if (stop) {
onComplete();
}
}
}
The implementation of the Take-Operator in RxJava2 looks like this. It is clear, that a upstream onNext will result in a onNext and possibly a onComplete (downstream).

RxJava how to handle errors differently at different points in a chain

I have a chain of API calls in RxJava, and when one fails I need to abort the chain and handle the error. But each failure needs to be handled differently. I tried this:
netRequestOne()
.onErrorResumeNext {
handleErrorOne()
Single.error(it)
}
.flatMap {
netRequestTwo()
}
.onErrorResumeNext {
handleErrorTwo()
Single.error(it)
}
// more flatMaps with requests...
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(
{
// deal with success
},
{
// no-op
}
)
But if a request throws an exception, all of the subsequent onErrorResumeNext()'s are called, not just the one tied to that request.

You can achieve the requested behavior for example with this:
val requestOne = Single.just("Response 1")
//.doOnSuccess { throw RuntimeException("Fail second request") } // (1)
.doOnError {
println("handleErrorOne")
}
val requestTwo = Single.just(10)
//.doOnSuccess { throw RuntimeException("Fail second request") } // (2)
.doOnError {
println("handleErrorTwo")
}
requestOne
.flatMap { oneResult -> requestTwo.map { twoResult -> Pair(oneResult, twoResult) } }
.doOnSuccess { responses: Pair<String, Int> ->
println(responses)
}
.flatMap { Single.just("More flatMaps") }
.subscribe({}, {})
You can uncomment (1) and/or (2) to simulate a fail in the first or second request. In case, both requests end successfully, responses are combined and you do some other processing.

Chaining Calls on RxJava

There are cases when I need to chain RxJava calls.
The simplest one:
ViewModel:
fun onResetPassword(email: String) {
...
val subscription = mTokenRepository.resetPassword(email)
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
.subscribe(
//UI update calls
)
...
}
My Repository:
fun resetPassword(email: String): Single<ResetPassword> {
return Single.create { emitter ->
val subscription = mSomeApiInterface.resetPassword(email)
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
.subscribe({
emitter.onSuccess(...)
}, { throwable ->
emitter.onError(throwable)
})
...
}
}
My Question
Do I need to Add:
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
for both calls to avoid any app freeze? or the second one for API call is enough?

No, you don't need to add
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.io())
for the repo and the viewmodel.
.observeOn usually should be called right before handling the ui rendering. So usually, you'll need it in the ViewModel right before updating the ui or emitting the LiveData values.
Also, you properly don't need to subscribe to mSomeApiInterface in your repo, I think it would be better off to just return in as it's from your method up the chain, somthing like this:
fun resetPassword(email: String): Single<ResetPassword> {
return mSomeApiInterface.resetPassword(email);
}
and if you have any mapping needed you can chain it normally
fun resetPassword(email: String): Single<ResetPassword> {
return mSomeApiInterface.resetPassword(email)
.map{it -> }
}
This way you can write your ViewModel code as follow
fun onResetPassword(email: String) {
...
// note the switcing between subscribeOn and observeOn
// the switching is in short: subscribeOn affects the upstream,
// while observeOn affects the downstream.
// So we want to do the work on IO thread, then deliver results
// back to the mainThread.
val subscription = mTokenRepository.resetPassword(email)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(
//UI update calls
)
...
}
This will run the API request on the io thread, will returning the result on the mainThread, which is probably what you want. :)
This artical has some good examples and explanations for subscribeOn and observeOn, I strongly recommend checking it.

Observable<RequestFriendModel> folderAllCall = service.getUserRequestslist(urls.toString());
folderAllCall.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.map(result -> result.getRequested())
.subscribe(this::handleResults, this::handleError);
private void handleResults(List<Requested> folderList) {
if (folderList != null && folderList.size() != 0) {
usersList.addAll(folderList);
}
adapter.notifyDataSetChanged();
}
}
private void handleError(Throwable t) {
Toast.makeText(getContext(),t.getMessage(),Toast.LENGTH_LONG).show();
}
in interface:
#Headers({ "Content-Type: application/json;charset=UTF-8"})
#GET
Observable<RequestFriendModel> getUserRequestslist(#Url String url);
POJO model :
public class RequestFriendModel {
#SerializedName("requested")
#Expose
private List<Requested> requested = null;
public List<Requested> getRequested() {
return requested;
}
public void setRequested(List<Requested> requested) {
this.requested = requested;
}
}

RxJava Observable.create wrapping observable subscriptions

I used Observable.create so I could notify the subscriber when certain data was available. I am a little uncertain of subscribing to observables inside of my create method. Are these nested subscriptions going to give me any sort of issue? I'm not completely familiar with creating observables using Observable.create so I wanted to make sure I'm not doing anything out of the ordinary or misusing it. Thank you in advance!
abstract class NetworkResource<ApiType, DbType> constructor(private val schedulerProvider: SchedulerProvider) {
abstract fun fetchFromApi(): Single<ApiType>
abstract fun fetchFromDb(): Observable<Optional<DbType>>
abstract fun saveToDb(apiType: ApiType?)
abstract fun shouldFetchFromApi(cache: DbType?): Boolean
fun fetch(): Observable<Optional<DbType>> {
return Observable.create<Optional<DbType>> {
val subscriber = it
fetchFromDb()
.subscribe({
subscriber.onNext(it)
if(shouldFetchFromApi(it.get())) {
fetchFromApi()
.observeOn(schedulerProvider.io())
.map {
saveToDb(it)
it
}
.observeOn(schedulerProvider.ui())
.flatMapObservable {
fetchFromDb()
}
.subscribe({
subscriber.onNext(it)
subscriber.onComplete()
})
}
else {
subscriber.onComplete()
}
})
}
}
}

Yes, it will cause an issues.
First, it is not idiomatic to nest Observable like this, one of the strengths of Reactive approach, is composing Observables, and thus have single clean stream. with this way, you are breaking the chain, and the immediate result is intertwined code which is harder to read, and more code to wire up the notification events, basically it is like wrapping async callback methods with Observable.
here as you have already reactive components you can simply compose them instead of treating them with callback approach.
Second, as a result of breaking the chain, the most sever and immediate one - unsubscribing the outer Observable will not affect automatically the inner Observable. same goes for trying to add subscribeOn() and with different scenario where backpressure is important it's also apply.
an composing alternative might be something like this:
fun fetch2(): Observable<Optional<DbType>> {
return fetchFromDb()
.flatMap {
if (shouldFetchFromApi(it.get())) {
fetchFromApi()
.observeOn(schedulerProvider.io())
.doOnSuccess { saveToDb(it) }
.observeOn(schedulerProvider.ui())
.flatMapObservable {
fetchFromDb()
}
} else {
Observable.empty()
}
}
}
if from some reason, you want in any case the first fetchFromDb() result to be emitted separately, you can also do it using publish() with selector:
fun fetch2(): Observable<Optional<DbType>> {
return fetchFromDb()
.publish {
Observable.merge(it,
it.flatMap {
if (shouldFetchFromApi(it.get())) {
fetchFromApi()
.observeOn(schedulerProvider.io())
.doOnSuccess { saveToDb(it) }
.observeOn(schedulerProvider.ui())
.flatMapObservable {
fetchFromDb()
}
} else {
Observable.empty()
}
})
}
}