i have a subscription which i want to outlast the ...
# rx
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
for my entire application containing similar subscriptions or can i ignore the return value of
imo, if you really can't think of a scenario where the subscription should terminate it's fine to ignore the return value of
but I'm always skeptical of the times where I have done that. I feel like I'm probably not considering something.
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.
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
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.
Its not fine to ignore them, if you subscribe to it in a fragment, because youre leaking
👍 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
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