tivi VS livedata-combineutil-java

Look no more: https://github.com/chrisbanes/tivi

It's definitely the most verbose part of our app and one of the weakest parts of the Jetpack library. We used https://github.com/chrisbanes/tivi for some inspiration on how to organize your navigation structures.

I have considered a few variants around this route. One easy way out would be just to launch a ComponentActivity with a PreferenceFragment like what Chris Banes does in TiVi ... but if you go with PreferenceFragment(Compat) it seems you are kinda stuck with SharedPreferences. If one attempts to supply DataStore wrapped in PreferenceDataStore, it seems types get messed up (TextPreference will store as a String, even if the InputType is number, etc).

Thanks I think what's confusing is that UI events are recommended to be modeled as Flows, which I guess is why Tivi uses Flows for even the simplest actions, but it does a lot of very fancy things. Most repository interactions seem to have an entire class extending an Interactor (e.g.) which catches and emits errors, progress and handles timeouts and does all that crazy queuing stuff with UI "messages" Flow

I would read and study nowinandroid and tivi apps.

Check out the approach from tivi https://github.com/chrisbanes/tivi/blob/main/app/src/main/java/app/tivi/AppNavigation.kt as an idea.

They probably want you to do a module split like in https://github.com/chrisbanes/tivi or https://github.com/igorwojda/android-showcase, but what they probably don't realize is that modularization is a trade-off, namely greatly increased build configuration complexity for... well, having modules.

3.) the MutableLiveDatas in the ViewModel initialized by SavedStateHandle.getLiveData should contain the fromDate and the toDate, and with the combination of these LiveDatas you can evaluate what to show on the screen

well the third-party libraries help but internally it's just MediatorLiveData which does ship with LiveData

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.

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.

people exposing 11 public LiveData fields for 11 private MutableLiveData fields instead of using MediatorLiveData as combiners to reduce the number of exposed LiveData fields

While it is possible to combine these properties into a single emission using MediatorLiveData, if the MutableLiveData is exposed as MutableLiveData, then the fields can be directly two-way databound to XML, which is kinda the original goal and purpose of databinding.

If you need help with combiners you can also check https://github.com/Zhuinden/livedata-combineutil-java/

If you can't join them, you can combine LiveDatas and then map them to a common representation so that the adapter can treat it as a single list. And use itemViewType to determine which view to show per each item.