Fixed
Status Update
Comments
il...@google.com <il...@google.com>
sa...@google.com <sa...@google.com>
sa...@google.com <sa...@google.com>
ap...@google.com <ap...@google.com> #2
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.
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.
ap...@google.com <ap...@google.com> #3
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.
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.
sa...@google.com <sa...@google.com>
na...@google.com <na...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.appcompat:appcompat:1.7.0-alpha03
co...@gmail.com <co...@gmail.com> #6
Coco73g11@gmail.com
Galaxy 3571881034
199001
On Wed, Mar 29, 2023, 11:36 PM <buganizer-system@google.com> wrote:
Galaxy 3571881034
199001
On Wed, Mar 29, 2023, 11:36 PM <buganizer-system@google.com> wrote:
Description
Version used: 1.5.1 (also tested on 1.7.0-alpha01)
Devices/Android versions reproduced on: Pixel 5 API 30 emulator
Description:
The linked repo or ZIP contains a reproduction of an issue with the AppCompatDialog & Componentdialog. It shows that the ComponentDialog does not set the ViewLifecycleTreeOwner correctly when setContentView is called. AppCompatDialog (the subclass of ComponentDialog) does not call super.setContentView and instead calls a delegate which never reaches ComponentDialog. When trying to access the ViewTreeLifecycleOwner of the dialog, a null pointer exception is thrown.
If this is a bug in the library, we would appreciate if you could attach:
-
- ZIP also attached