android-architecture-components VS livedata-combinetuple-kt

google wrote this

Historically it used to be a one-panda army, however I haven't really had the time or energy to even look at Stack Overflow. I got fed up with them when they complained when I posted livedata-combinetuple-kt as a solution to a problem, them saying "if you want to self-promote, you should pay us money". I don't really answer any questions since.

Correct. With just MutableLiveData + combining with MediatorLiveData you can get the same results, and make state handling reactive.

And then if I need to define anything to be triggered on the change of these fields, I can use https://github.com/Zhuinden/livedata-combinetuple-kt/ or the flow variant with asFlow() or the Rx variant and then boom I have a working app in minutes 😅

using MediatorLiveData and writing some minimal code on top of MediatorLiveData you can easily do

If you want less observers, just combine them

If you're using Google's defaults, then you use a ViewModel created by Hilt and getting a reference to a SavedStateHandle, your state would be created of multiple MutableLiveDatas (each holding 1 property) created via savedStateHandle.getLiveData(), then you use MediatorLiveData (you can use a library like this or this) to combine the changes of the mutable properties into a single immutable state object observed by the "UI" (read: the view controller, aka the Fragment) using the viewLifecycleOwner property of Fragments.

See, that's why typically it's just you register or log in and you get a token and the token just works (until it becomes invalidated, which then means you can refresh it) and that's as far as it goes, on the other hand "my authentication depends on MediatorLiveData" is scary because mediator is for custom operators and you typically never need to actually interact with it once you have the combiners defined

MutableLiveData (java combiner/kotlin combiner) == BehaviorRelay (kotlin combiner) == MutableSharedFlow (kotlin combiner) conceptually, so it's not important to me which one it is, as long as you can throw combiners at it.

Yep, that's why I have this kotlin combiner/java combiner for LiveData, but map/switchMap also rely on MediatorLiveData.