IssueTracker

It will be great to have two variants, one that unsubscribes on pause/stop (e.g. for location updates) and one that unsubscribes on destroy of LifecycleOwner (e.g. for one shot network calls)

What do you think about having something like a ReactiveLiveData that wraps a Flowable and in LiveData#onActive subscribes to the Flowable and in LiveData#onInactive, unsubscribes.

There's one scenario that might make things unexpected:
We create liveData1 based on flowableX.
observable1 registers as observer to liveData1
flowableX emits value A so, liveData1 now contains value A and observable1 notifies value A
observable1 unregisters as observer, therefore, liveData1 unsubscribes from flowableX.
flowableX emits values B and C.
observable2 registers as observer to the liveData1. Since liveData1 contains A, observable2 will be notified of value A.

If the observable is basically hot, I think that makes sense as the LiveData auto-subscribes and disposes based on the life cycle. I think that would be OK and expected. If you would do the same in rx only, but using a composite disposable for example, the result would be the same.

The only thing that might be unexpected, as you point out, is that the LiveData will still start with A and then continue to catch up with the flowable as events are emitted.

This is also the case using a cold observable: the observable emits A, which is cached on the LiveData. When the LiveData observer is unregistered and later a new observer is registered, A is emitted again and the observable is subscribed again. This would (should) usually produce a new event from the observable, which would probably be A again.

Thinking out loud, maybe a ReactiveLiveData should therefore clear it's value when it's no longer active? Or maybe this should be an option?

I think ReactiveLiveData idea looks sound. In the described scenario, liveData containing value A is totally expected (basically the same as a BehaviorRelay).
What doesn't make much sense in the described scenario is the step "flowableX emits values B and C", since in previous step liveData1 unsubscribed from flowableX, I would expect flowableX to not emit any more items, the only way it can keep emitting items are these two cases:
- flowableX is hot and keeps getting items (e.g. mouse moves or GPS coordinates) and therefore as creator of this flowableX I understand the implications (you unsubscribe from GPS updates and your liveData1 has the last know GPS location)
- flowableX is a multicast observable and keeps emitting items because there is another subscriber besides the original observable1, then the creator of flowableX must be definitely aware of and responsible for this other subscriber and therefore see the behavior in the described scenario as expected.

One thing that should be considered is completion of the source publisher. If it has completed, then there's no need to resubscribe again; the latest value can be cached forever in the LiveData in that case. This prevents duplicate events.

we've changed the default behavior to unsub and also documented it throughly.