IssueTracker

Definitely want to support this. Currently investigating moving the Callbacks to interfaces so that wrapping/conversion can be done:

    private abstract class WrapperDataSource<in A, B>(private val source: PositionalDataSource<A>)
            : PositionalDataSource<B>() {
        override fun loadInitial(params: LoadInitialParams, callback: LoadInitialCallback<B>) {
            source.loadInitial(params, object: LoadInitialCallback<A> {
                override fun onResult(data: List<A>, position: Int, totalCount: Int) {
                    callback.onResult(convert(data), position, totalCount)
                }

                override fun onResult(data: List<A>, position: Int) {
                    callback.onResult(convert(data), position)
                }
            })
        }

        override fun loadRange(params: LoadRangeParams, callback: LoadRangeCallback<B>) {
            source.loadRange(params) { data -> callback.onResult(convert(data)) }
        }

        protected abstract fun convert(source: List<A>): List<B>
    }

Making them interfaces makes it easy to wrap/test. Downside is that external callers can't use some of the guts of the callback impl (like validating non-negative positions), but this should make it much more reasonable to wrap, decorate, or otherwise post-process data loaded from e.g. Room. In the network case, the equivalent might be post-processing a network request in a way that's awkward to inject into network loading code.

Fixed internally by making Params constructors public, and Callbacks abstract. Will go out with next alpha release.

We're also investigating making it easier to wrap and do decoration/type conversions, since the example in #2 mostly works, but is incomplete - it needs to handle invalidates.

Released: https://developer.android.com/topic/libraries/architecture/release-notes.html#paging

@4 That actually won't technically fix as isHidden() will technically mismatch with the state passed into the child fragment.  Each child fragment legitimately needs to have their state set to hidden.

Yeah, I realized that as I kept working further on it. Nevermind that solution, it doesn't work.

@6 I don't know what the ramifications are, but when you iterate, you can save the "currentState" and then hide them all via a transaction. When restoring to visible, restore to the original state.

Project: platform/frameworks/support
Branch: androidx-main

commit 02290cddca3d5e4dc94e2c5f77a6728ad970b204
Author: Jeremy Woods <jbwoods@google.com>
Date:   Thu Oct 07 13:11:45 2021

    Dispatch onHiddenChanged to child fragments
   
    When a parent fragment is hidden all of its children will automatically
    be hidden, but we never call onHiddenChanged on any of the children.
   
    We should dispatch onHiddenChanged down parent's entire hierarchy and
    ensure that `isHidden()` also considers the parent's state.
   
    RelNote: "Parent fragments will now dispatch `onHiddenChanged()` down
    their entire hierarchy before launching their own call back."
    Test: added test
    Bug: 77504618
   
    Change-Id: Iedc201ab435cb963e81bc02d203d4d37ff827e01

M       fragment/fragment/src/androidTest/java/androidx/fragment/app/FragmentViewTest.kt
M       fragment/fragment/src/main/java/androidx/fragment/app/FragmentStateManager.java
M       fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M       fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java

https://android-review.googlesource.com/1850016