I'm not an expert on RxJava sorry if my question is a dummy question, I notice that my project is using RxLifeCycle dependency, I want to rid of it from the project due to the author advice, I wonder how I should remove it, it's just enough to create a composite disposable and dispose all my disposables at onDestroy() method? or is necessary to something else?
Thank you so much.
EDIT:
I provide some examples of the code
First, everything inherits from a base activity, this activity has this method which is used across all activities
public <T> Observable<T> bindRxToActivity(Observable<T> observable, boolean isSilent) {
if (!isSilent) {
loading(true);
hideKeyboard();
}
return observable
.compose(bindToLifecycle())
.subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread())
.doOnEach(r -> handleDoOnEach())
.doOnNext(this::handleDoOnNext);
}
And it is used like this:
bindRxToActivity(intentApi.evaluation(), false)
.subscribe(
{ this.handleTransferEvaluationSuccess(it) },
{ this.evaluateTransferFailed(it) }
)
In all scenarios of the activities is used as above.
and for fragments:
public <T> Observable<T> bindRxToFragment(Observable<T> observable, boolean silent) {
if (!silent) {
this.loading(true);
listener.hideKeyboard();
}
return observable
.compose(bindToLifecycle())
.subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread())
.doOnEach(r -> handleDoOnEach())
.doOnNext(this::handleDoOnNext);
}
And it is used like this in all fragments:
baseFragment.bindRxToFragment(baseFragment.r.loginApi().login(login), true)
.subscribe(
login1 -> loginSuccess(BaseActivity, login1, listener),
baseFragment::handleError
);
So what could be the best approach to use manual disposing of the observers?
Thanks
Related
I've upgraded to Android Studio 3.1 today, which seems to have added a few more lint checks. One of these lint checks is for one-shot RxJava2 subscribe() calls that are not stored in a variable. For example, getting a list of all players from my Room database:
Single.just(db)
.subscribeOn(Schedulers.io())
.subscribe(db -> db.playerDao().getAll());
Results in a big yellow block and this tooltip:
The result of subscribe is not used
What is the best practice for one-shot Rx calls like this? Should I keep hold of the Disposable and dispose() on complete? Or should I just #SuppressLint and move on?
This only seems to affect RxJava2 (io.reactivex), RxJava (rx) does not have this lint.
The IDE does not know what potential effects your subscription can have when it's not disposed, so it treats it as potentially unsafe. For example, your Single may contain a network call, which could cause a memory leak if your Activity is abandoned during its execution.
A convenient way to manage a large amount of Disposables is to use a CompositeDisposable; just create a new CompositeDisposable instance variable in your enclosing class, then add all your Disposables to the CompositeDisposable (with RxKotlin you can just append addTo(compositeDisposable) to all of your Disposables). Finally, when you're done with your instance, call compositeDisposable.dispose().
This will get rid of the lint warnings, and ensure your Disposables are managed properly.
In this case, the code would look like:
CompositeDisposable compositeDisposable = new CompositeDisposable();
Disposable disposable = Single.just(db)
.subscribeOn(Schedulers.io())
.subscribe(db -> db.get(1)));
compositeDisposable.add(disposable); //IDE is satisfied that the Disposable is being managed.
disposable.addTo(compositeDisposable); //Alternatively, use this RxKotlin extension function.
compositeDisposable.dispose(); //Placed wherever we'd like to dispose our Disposables (i.e. in onDestroy()).
The moment the Activity will be destroyed, the list of Disposables gets cleared and we’re good.
io.reactivex.disposables.CompositeDisposable mDisposable;
mDisposable = new CompositeDisposable();
mDisposable.add(
Single.just(db)
.subscribeOn(Schedulers.io())
.subscribe(db -> db.get(1)));
mDisposable.dispose(); // dispose wherever is required
You can subscribe with DisposableSingleObserver:
Single.just(db)
.subscribeOn(Schedulers.io())
.subscribe(new DisposableSingleObserver<Object>() {
#Override
public void onSuccess(Object obj) {
// work with the resulting todos...
dispose();
}
#Override
public void onError(Throwable e) {
// handle the error case...
dispose();
}});
In case you need to directly dispose Single object (e.g. before it emits) you can implement method onSubscribe(Disposable d) to get and use the Disposable reference.
You can also realize SingleObserver interface by your own or use other child classes.
As was suggested you may use some global CompositeDisposable to add the result of the subscribe operation there.
The RxJava2Extensions library contains useful methods to automatically remove created disposable from the CompositeDisposable when it completes. See subscribeAutoDispose section.
In your case it may look like this
SingleConsumers.subscribeAutoDispose(
Single.just(db)
.subscribeOn(Schedulers.io()),
composite,
db -> db.playerDao().getAll())
You can use Uber AutoDispose and rxjava .as
Single.just(db)
.subscribeOn(Schedulers.io())
.as(AutoDispose.autoDisposable(AndroidLifecycleScopeProvider.from(this)))
.subscribe(db -> db.playerDao().getAll());
Make sure that you understand when you unsubscribe based on the ScopeProvider.
Again and again I find myself coming back to the question of how to correctly dispose of subscriptions, and to this posting in particular. Several blogs and talks claim that failing to call dispose necessarily leads to a memory leak, which I think is a too general statement. In my understanding, the lint warning about not storing the result of subscribe is a non-issue in some cases, because:
Not all observables run in the context of an Android activity
The observable can be synchronous
Dispose is called implicitly, provided the observable completes
Since I don't want to suppress lint warnings I recently started to use the following pattern for cases with a synchronous observable:
var disposable: Disposable? = null
disposable = Observable
.just(/* Whatever */)
.anyOperator()
.anyOtherOperator()
.subscribe(
{ /* onSuccess */ },
{ /* onError */ },
{
// onComplete
// Make lint happy. It's already disposed because the stream completed.
disposable?.dispose()
}
)
I'd be interested in any comments on this, regardless of whether it's a confirmation of correctness or the discovery of a loophole.
There's another way available, which is avoiding to use Disposables manually (add and remove subscriptions).
You can define an Observable and that observable is going to receive the content from a SubjectBehaviour (in case you use RxJava). And by passing that observable to your LiveData, that should work. Check out the next example based on the initial question:
private val playerSubject: Subject<Player> = BehaviorSubject.create()
private fun getPlayer(idPlayer: String) {
playerSubject.onNext(idPlayer)
}
private val playerSuccessful: Observable<DataResult<Player>> = playerSubject
.flatMap { playerId ->
playerRepository.getPlayer(playerId).toObservable()
}
.share()
val playerFound: LiveData<Player>
get() = playerSuccessful
.filterAndMapDataSuccess()
.toLiveData()
val playerNotFound: LiveData<Unit>
get() = playerSuccessful.filterAndMapDataFailure()
.map { Unit }
.toLiveData()
// These are a couple of helpful extensions
fun <T> Observable<DataResult<T>>.filterAndMapDataSuccess(): Observable<T> =
filter { it is DataResult.Success }.map { (it as DataResult.Success).data }
fun <T> Observable<DataResult<T>>.filterAndMapDataFailure(): Observable<DataResult.Failure<T>> =
filter { it is DataResult.Failure }.map { it as DataResult.Failure<T> }
If you are sure that disposable handled correctly, for example using doOnSubscribe() operator, you may add this to Gradle:
android {
lintOptions {
disable 'CheckResult'
}}
I want to call multiple Rest Api's in a Sequence and having each Response Dto is different from each other.
Please help me to get rid from this situation that, How can i call these Api's using Rx Java Observables in Android.
no, you should use map() or doOnNext(), it will look like this
Observable.just(1)
.doOnNext(value -> {
someRequestX().execute();
})
.map(value -> {
return nextRequestY().execute();
})
.doOnNext(requestYResponse-> {
someRequesZ(requestYResponse.someValue).execute();
})
.map(requestYResponse-> {
return someRequesK(requestYResponse.someValue).execute();
})
.map(requestKResponse -> {
return someRequesJ(requestKResponse.someValue).execute();
})
.subscribe(requestJResponse -> {
doSOmethingWithFinalResponse(requestJResponse );
})
First of all, for network requests is better to use Single then Observable, because there always will be only one item. To switch from one requests to another, you can use flatMap.
Assuming your code is similar, you can try this:
class Dto1 {}
class Dto2 {}
class Dto3 {}
public interface Api {
Single<Dto1> getDto1();
Single<Dto2> getDto2();
Single<Dto3> getDto3();
}
private Api api;
public void callApi() {
api.getDto1()
.doOnSuccess(dto1 -> {/*do something with dto1*/})
.flatMap(dto1 -> api.getDto2())
.doOnSuccess(dto2 -> {/*do something with dto2*/})
.flatMap(dto2 -> api.getDto3())
.doOnSuccess(dto3 -> {/*do something with dto3*/})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe()
}
For the same scenario, i use concat operator which takes multiple Observables and concatenates their sequence
If response sequence doesn't require then you can use merge operator also.
Concat VS Merge operaror
try doOnNext() or map() method of Observable and use sync execute() of each response and pass them further
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()
}
})
}
}
I'm developing a whole application in RxJava/Android, trying to make the things the most Rx-way possible.
I think I'm achieving what I wanted, but now I've encountered an issue that I'm sure that exists a better way to do it.
It consists of:
Get a Boolean from an Observable
A: If it's true, you are done, return true. B: If it's false, make a request (call it firstRequest) and receive an Observable.
A: The same, if it's true, you are done, return true. B: If it's false, then make another request (secondRequest).
A: If it returns true, then again you are done. If it's false, launch processFailed();
Right now I've implemented it in a very naive way (and sub-optimal):
public void startProcess(){
dataRepository.getStatus()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(status -> {
if(status){
processCompleted();
} else {
makeFirstRequest();
}
});
}
private void makeFirstRequest(){
dataRepository.firstRequest()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(status -> {
if(status){
processCompleted();
} else {
makeSecondRequest();
}
});
}
private void makeSecondRequest(){
dataRepository.firstRequest()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(status -> {
if(status){
processCompleted();
} else {
processFailed();
}
});
}
I would like to know how to combine those operations in a way that made more sense (I peeked at combine, but I think it's not the intended use case for this), and subscribing three times it's not right, I think.
I thought about flatMapping (as it makes sense returning an Observable), but the nested chain of operations (flatMap inside flatMap inside flatMap) made me think that there has to be a simpler way of achieving the same result with some operators.
Thanks in advance.
flatMap to the rescue:
dataRepository.getStatus()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.flatMap(status -> status ? Observable.empty() : dataRepository.firstRequest())
.flatMap(status -> status ? Observable.empty() : dataRepository.secondRequest())
.defaultIfEmpty(false)
.subscribe(status -> {
if(status){
processCompleted();
} else {
processFailed();
}
});
You can also replace Observable.empty with Observable.just(status).
I have a code like this:
service.getUserById(10)
.subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread())
.concatMap(getFullUserFromDto())
.subscribe(doSomehingWithUser());
private Func1<UserDto, Observable<User>> getFullUserFromDto() {
return new Func1<UserDto, Observable<User>>() {
#Override
public Observable<User> call(final UserDto dto) {
return dao.getUserById(dto.getUserId());
}
};
}
and in my DAO, I have:
public Observable<User> getUserById(final Long id) {
return api.getUserById(id).map(//more things...
}
Note there are two levels of "concatenation": service -> dao -> api. Method api.getUserById(id) make a network call.
I'm getting NetworkOnMainThreadException error. Why? I'm using and subscribeOn and observeOn operators, but it seems that it is not applied to the "final" built Observable.
If I use this operators in the API call, in the DAO, it works:
return api.getUserById(id)
.subscribeOn(Schedulers.newThread())
.observeOn(AndroidSchedulers.mainThread())
.map(//more things...
Is there a way to use just once in the "root" Observable?
So, concatMap subscribes on Observables. What thread is used to perform this operation? Well, the thread that called onNext for the concatMat, given that it doesn't change threads/schedulers. So, one simple transposition should help with this:
service.getUserById(10)
.subscribeOn(Schedulers.newThread())
.concatMap(getFullUserFromDto())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(doSomehingWithUser());
I'd also suggest to use Schedulers.io(), as it will re-use threads.
Short answer: use observeOn before chained operations to controll on which schedulers they are executed:
service.getUserById(10)
.subscribeOn(Schedulers.newThread())
.observeOn(Schedulers.io())
.concatMap(getFullUserFromDto())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(doSomehingWithUser());
In the example above, .concatMap will be executed in Schedulers.io()
More details can be found here:
http://tomstechnicalblog.blogspot.com/2016/02/rxjava-understanding-observeon-and.html