Status Update
No update yet.
Comments
yb...@google.com
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
sh...@google.com
cc...@google.com
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
ku...@gmail.com
I personally think the name MergeAdapter is fine. My team created this exact abstraction years ago, and independently named that class "MergeAdapter". Though obviously since I have already made this connection for years; I am bias.
The fact that "MergeAdapter" reminds us of "MergeSort" reminds of "interleaving behavior" is quite a few mental hops. I think we'd all be better off by trying to disassociate that, and instead treat all words by their actual definition.
The bad part about naming this something much more specific like "ConcatenationAdapter", is that those definitions are a bit narrowly scoped. A nice thing you can accomplish with the "MergeAdapter" API is you can add and remove adapters in the middle of the list dynamically to render "collapsible" and "expandable" items or lists. I don't think the term "concatenate" captures this behavior very well, but I do think the word "merge" is broad enough to convey this.
ap...@google.com
Branch: androidx-master-dev
commit a678d10f76e2c1da8f6857538474fbf87f919ed0
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Jun 02 18:09:39 2020
Rename merge adapter to concat adapter
Bug: 158019211
Test: existing tests
Change-Id: I71dbfc22d4c757cdc2c94ec25fc9a9b780431c2c
M paging/runtime/api/3.0.0-alpha02.txt
M paging/runtime/api/current.txt
M paging/runtime/api/public_plus_experimental_3.0.0-alpha02.txt
M paging/runtime/api/public_plus_experimental_current.txt
M paging/runtime/api/restricted_3.0.0-alpha02.txt
M paging/runtime/api/restricted_current.txt
M paging/runtime/build.gradle
M paging/runtime/src/main/java/androidx/paging/LoadStateAdapter.kt
M paging/runtime/src/main/java/androidx/paging/PagedListAdapter.kt
M paging/runtime/src/main/java/androidx/paging/PagingDataAdapter.kt
M recyclerview/recyclerview/api/1.2.0-alpha04.txt
M recyclerview/recyclerview/api/current.txt
M recyclerview/recyclerview/api/public_plus_experimental_1.2.0-alpha04.txt
M recyclerview/recyclerview/api/public_plus_experimental_current.txt
M recyclerview/recyclerview/api/restricted_1.2.0-alpha04.txt
M recyclerview/recyclerview/api/restricted_current.txt
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/ConcatAdapterSubject.kt
M recyclerview/recyclerview/src/androidTest/java/androidx/recyclerview/widget/ConcatAdapterTest.kt
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/ConcatAdapter.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/ConcatAdapterController.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/NestedAdapterWrapper.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/RecyclerView.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/StableIdStorage.java
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/ViewTypeStorage.java
yb...@google.com
ad...@google.com
Years ago the term MergeAdapter was common for ListViews, but that was before other APIs like RxJava and Flow entered the common Android development lexicon and brought along much more precise definitions of these terms. These APIs build very strong distinctions between interleave (merge) and strict ordered sequence of groups (concat) and we benefit from consistency with the more contemporary usage here, especially when these APIs are often used in close proximity to one another.
Normally we try to encourage spelling out terms in API rather than abbreviating, but concat is a special case here. String, Rx and others standardized on concat so long ago that many people aren't even familiar with the fully expanded term; better to be consistent with the ecosystem here.
ap...@google.com
Branch: androidx-master-dev
commit c0540c10cc7ea5027d3fc3b22024de7e66c41a9d
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Jun 02 18:38:41 2020
ConcatAdapter API improvements
Accept extends bound in constructor arguments
Make Config & Config.Builder final
Bug: 158019211
Test: existing tests
Change-Id: I60bc0da651935b35a4dd64a0117aae532a278452
M recyclerview/recyclerview/api/1.2.0-alpha04.txt
M recyclerview/recyclerview/api/current.txt
M recyclerview/recyclerview/api/public_plus_experimental_1.2.0-alpha04.txt
M recyclerview/recyclerview/api/public_plus_experimental_current.txt
M recyclerview/recyclerview/api/restricted_1.2.0-alpha04.txt
M recyclerview/recyclerview/api/restricted_current.txt
M recyclerview/recyclerview/src/main/java/androidx/recyclerview/widget/ConcatAdapter.java
Description
Comment on Florina's blogpost (https://medium.com/p/294d2942127a ) mentioned that the name made it sound like it could interleave items, and I recently saw someone else make the same wrong assumption elsewhere.
Something like SequenceAdapter or ConcatAdapter or similar may be clearer.