https://kotlinlang.org logo
Join Slack
Powered by
i have a subscription which i want to outlast the ...
# rx
w
i have a subscription which i want to outlast the fragment which it is created in - basically i only want it to die if the application dies. Is the best thing to do to have a 
CompositeDisposable
for my entire application containing similar subscriptions or can i ignore the return value of 
.subscribe
?
g
imo, if you really can't think of a scenario where the subscription should terminate it's fine to ignore the return value of 
.subscribe
but I'm always skeptical of the times where I have done that. I feel like I'm probably not considering something.
a
Definitely don't have a big ol composite disposable for the whole application because there's no point - once your application is killed everything will be terminated anyways.
w
i currently do just ignore them if i want to keep them around forever. there is no risk of them getting garbage collected or something? @alexsullivan114 @Guillermo Alcantara
y
If that’s something which is must to complete, then I’d consider using WorkManager. Unless it could be a differed operation. Otherwise, I’d probably go with a Service.
u
Its not fine to ignore them, if you subscribe to it in a fragment, because youre leaking 
this
👍 1
have a component that is singleton and let it subscribe to the cold observable, pipe the results into a behavior relay, and expose it to the public
wether you dispose the disposable its up to you, if its singleton per app then technically you dont need to
but your components should in general have create and destroy callbacks, and there you should dispose your stuff, it just so happens you only have 2 layers so your top one doesnt need it
but your scopes could look like this: app > logged in > screen
lmk if not clear
w
they're likely not in fragments - ususally a view model. they aren't infinitely running things just like a network request that i want to succeed even if the hosting viewmodel is destroyed
Open in Slack
PreviousNext
Powered by