Fixed
Status Update
No update yet.
Comments
yb...@google.com
Project: platform/frameworks/support
Branch: androidx-main
Author: George Mount <
Link:
Fix focus move within child AndroidViews
Expand for full commit details
Fix focus move within child AndroidViews
Fixes: 389994198
Fixes: 391378895
Relnote: "Fixes focus travel within child AndroidViews where it
can sometimes jump out of the child to the ComposeView"
Sometimes the native FocusFinder doesn't act properly and finds
the wrong View when searching. This CL changes the FocusFinder to
use a newer copy of FocusFinder for all focus search operations
in AndroidComposeView.
Test: new test, manual testing
Change-Id: I678c864afe086879c5c45b018dd82da4f23be440
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/AndroidManifest.xml - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/FocusListenerTest.kt - A
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/test/TestActivity2.kt - A
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/viewinterop/MixedFocusChangeTest.kt - M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/AndroidComposeView.android.kt - M
compose/ui/ui/src/androidMain/kotlin/androidx/compose/ui/platform/FocusFinderCompat.android.kt
Hash: b028bcc322095634123da91c7146bac9e23c13c7
Date: Tue Jan 14 13:48:11 2025
mm...@commonsware.com
Project: platform/frameworks/support
Branch: androidx-main
Author: Ralston Da Silva <
Link:
Disabling isViewFocusFixEnabled and isRemoveFocusedViewFixEnabled
Expand for full commit details
Disabling isViewFocusFixEnabled and isRemoveFocusedViewFixEnabled
Disabling these flag to unblock 1.8 RC.
These were features/bug-fixes that were not regressions
from 1.7
Bug: 406327273
Bug: 369256395
Bug: 378570682
Bug: 376142752
Bug: 384056227
Bug: 388590015
Bug: 389994198
Bug: 391378895
Test: Ran presubmits and added TODOs to the affected tests
Change-Id: I5ffb7ff27c662838c8b464560d1df830751f015c
Files:
- M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/FocusViewInteropTest.kt - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/OwnerFocusTest.kt - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/focus/RequestFocusTest.kt - M
compose/ui/ui/src/androidInstrumentedTest/kotlin/androidx/compose/ui/viewinterop/MixedFocusChangeTest.kt - M
compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/ComposeUiFlags.kt
Hash: 1a33d21734ef7f68d4cad37c8d333831f304a339
Date: Tue Apr 01 17:46:50 2025
de...@gtempaccount.com
How would I load all the relation objects immediately without a relation? I see in your documentation that you have a query like "@Query("SELECT user.name AS userName, pet.name AS petName "
+ "FROM user, pet "
+ "WHEREuser.id = pet.user_id")
public LiveData<List<UserPet>> loadUserAndPetNames();", but how would you load complete objects with it, not just certain fields? I tried using something like "SELECT * , * as comments FROM users, comments", but it was throwing an error?
+ "FROM user, pet "
+ "WHERE
public LiveData<List<UserPet>> loadUserAndPetNames();", but how would you load complete objects with it, not just certain fields? I tried using something like "SELECT * , * as comments FROM users, comments", but it was throwing an error?
sk...@gmail.com
I'm interested in this feature along with the ability to use a projection like "[expression] AS [column-name]" and map to a single value. Additionally, since the @Relation annotation is never mentioned on the Room page, will it be maintained?
be...@google.com
It will be maintained, and added to the Room page.
yb...@google.com
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit c5dad6522e6c20bbd5ca8e53b8406a94cb84cfe8
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Jun 12 16:43:53 2019
Allow single-value @Relation field.
This change lifts the restriction of @Relation annotated fields needing
to be List or Set allowing for a more seamless representation of a
one-to-one relationship.
Changes in the generated code is so that it is not always assumed that
the relation field is a collection, thus not needing a temporary
collection when collecting the relating objects.
Bug: 62905145
Test: ./gradlew room:room-compiler:test \
room:integration-tests:room-testapp:cC
Change-Id: I462d59e89b55c43842df43cb84c1aeca0b2b743e
M room/common/src/main/java/androidx/room/Relation.java
M room/compiler/src/main/kotlin/androidx/room/processor/PojoProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/vo/RelationCollector.kt
M room/compiler/src/main/kotlin/androidx/room/writer/RelationCollectorMethodWriter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/PojoProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/dao/PetDao.java
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PojoWithRelationTest.java
A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/vo/PetAndOwner.java
https://android-review.googlesource.com/982373
https://goto.google.com/android-sha1/c5dad6522e6c20bbd5ca8e53b8406a94cb84cfe8
Branch: androidx-master-dev
commit c5dad6522e6c20bbd5ca8e53b8406a94cb84cfe8
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Jun 12 16:43:53 2019
Allow single-value @Relation field.
This change lifts the restriction of @Relation annotated fields needing
to be List or Set allowing for a more seamless representation of a
one-to-one relationship.
Changes in the generated code is so that it is not always assumed that
the relation field is a collection, thus not needing a temporary
collection when collecting the relating objects.
Bug: 62905145
Test: ./gradlew room:room-compiler:test \
room:integration-tests:room-testapp:cC
Change-Id: I462d59e89b55c43842df43cb84c1aeca0b2b743e
M room/common/src/main/java/androidx/room/Relation.java
M room/compiler/src/main/kotlin/androidx/room/processor/PojoProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/processor/ProcessorErrors.kt
M room/compiler/src/main/kotlin/androidx/room/vo/RelationCollector.kt
M room/compiler/src/main/kotlin/androidx/room/writer/RelationCollectorMethodWriter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/PojoProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/dao/PetDao.java
M room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/PojoWithRelationTest.java
A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/vo/PetAndOwner.java
Description
Version used: 1.0.0-alpha3
Devices/Android versions reproduced on: n/a
@Relation must return a List<> or Set<>. This includes cases where we know that there should only be one value (e.g., the parent on a 1:N relation). As it stands, we then need to get the 0th entry out of the List or something to get to our one-and-only entity.
IMHO, @Relation should support return types of a single entity instance. If the query returns 2+ rows, I can see three possible responses:
- Throw an exception
- Return the first row's entity
- Either, configurable via an annotation property (and ideally configurable based on build type, as we might throw the exception on debug builds but stagger along with boffo results in production)
After all, in principle, we should have the exact same code ourselves to deal with the current collection-based response.
I'm uncertain how popular @Relation will turn out to be, so I certainly can't characterize this as especially important. I'm just putting it out there for tracking purposes.
Thanks!