Status Update
Comments
vi...@google.com <vi...@google.com> #2
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
cc...@google.com <cc...@google.com> #3
du...@google.com <du...@google.com> #4
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
an...@gmail.com <an...@gmail.com> #5
Assuming I have different data sources, which I have to merge before providing the result to UI. Whenever one datasource is changed, I have to invalidate the other one, to refresh the data and perform mapping from <dataSource1> results to <dataSource1 + dataSource2> results.
For example, it can be an application, which uses public API to get e.g. movies list, but stores information about favorite films locally. In this case, whenever "favorite" flag is changed, movies list data source should be invalidated. And it can not be done from UI. For such situation should be a possibility to invalidate data source e.g. via Pager object or something.
du...@google.com <du...@google.com> #6
Whil I understand your idea of internal invalidates of PagingSources, I can provide you an example where it is not possible. Assuming I have different data sources, which I have to merge before providing the result to UI. Whenever one datasource is changed, I have to invalidate the other one, to refresh the data and perform mapping from <dataSource1> results to <dataSource1 + dataSource2> results.
This sounds like something that the .map
transform operator on PagingData
would help with.
For example, it can be an application, which uses public API to get e.g. movies list, but stores information about favorite films locally. In this case, whenever "favorite" flag is changed, movies list data source should be invalidated. And it can not be done from UI. For such situation should be a possibility to invalidate data source e.g. via Pager object or something.
It doesn't make sense for the UI / Presentation layer to handle invalidation, it already does this via .refresh()
. Invalidation is simply a signal for PagingSource
updates. I'm not sure that a favorite flag should warrant multiple layers of PagingSource
, but I think I'm not really understanding what's preventing you from hooking up multiple sources of invalidation.
In this case I would recommend to have one DB table / local cache that PagingSource
loads directly from, and any updates from the API or from favorite flag flipping would get written to the cache and also invalidate PagingSource
. This way you only need to hook up invalidate callbacks from a single source, and you can have independent components writing to the same place.
cl...@gmail.com <cl...@gmail.com> #7
du...@google.com <du...@google.com> #8
Sounds good! Just noting for posterity, my prototype will need to kick out invalidated pagingSources to minimize memory pressure.
cl...@gmail.com <cl...@gmail.com> #9
ap...@google.com <ap...@google.com> #10
Branch: androidx-master-dev
commit 5ac03b4d8c4a234d8c91aecb03361d8d1b856ad3
Author: Clara F <clarafok3@gmail.com>
Date: Thu Nov 19 21:07:43 2020
[GH] A PagingSource Factory that can be invalidated
## Proposed Changes
A PagingSource Factory that stores references to PagingSources for PagingSource invalidation
## Testing
Test: ./gradlew paging:paging-common:test
This is an imported pull request from
Resolves #98
Github-Pr-Head-Sha: 63d2bc166414d4b5134ba1dd5998a2a175ccbe25
GitOrigin-RevId: 037f4fe9037bd1aa255a212091f5b955fe9e4693
Fixes: 160716447
Relnote: "A new abstract class InvalidatingPagingSourceFactory has been added
with an `.invalidate()` API that forwards invalidate to all of the PagingSources
it emits"
Change-Id: Ie71fc1cc974dbc72f42572234ea9053e31b44039
M paging/common/api/current.txt
M paging/common/api/public_plus_experimental_current.txt
M paging/common/api/restricted_current.txt
A paging/common/src/main/kotlin/androidx/paging/InvalidatingPagingSourceFactory.kt
A paging/common/src/test/kotlin/androidx/paging/InvalidatingPagingSourceFactoryTest.kt
Description
Artifact used: androidx.paging:paging-runtime & rxjava2 Version used: 3.0.0-alpha02
In order to call
pagingSource.invalidate()
to deal with the user of my app deleting a row from the paged RV they're looking at, I had to do the following in my ViewModel:Then, elsewhere in the VM I have a reference to the source to call
invalidate
. This feels really, really ugly. I'm aware that I have to pass a factory intoPager
because it can get recreated, but this feels like it's not something I should really have to worry about.It's hard to say what I would prefer, which is why I imagine it's like this!
Keeping a reference to the
Pager
feels less gross than it does forPagingSource
. PerhapsPager
could internally keep a reference to the existingPagingSource
so I could just callPager.invalidate()
and it would do a similar hack internally?Very happy for better or other suggestions. Currently it feels very awkward, and it was super hard to discover that the
.invalidate()
method even existed to call!