Status Update
Comments
su...@google.com <su...@google.com> #2
Please ensure this works with LazyColumn
, LazyRow
and LazyVerticalGrid
when this change is implemented. Thanks!
ct...@google.com <ct...@google.com> #3
Thanks Nick, LazyList is the internal component that all these composables are built out of.
ma...@gmail.com <ma...@gmail.com> #4
If I could add a small additional feature request here:
Hopefully the implementation of focus scrolling in lazy lists leaves room for the easy customization / overriding of the behavior, since TV UI often has unique snapping requirements around the focused item.
I've started to come up with my own compose API for this, and while I'm happy with the results so far, I'm hoping that any future built-in scrolling functionality will play nicely with it, or as a better alternative - provide all of the necessary configurations.
su...@google.com <su...@google.com> #5
To add a specific case to #4's comment on configurability:
In View Android apps, scrolling typically occurs once focus is moved to an item outside the viewport. With such behavior, however, the user is given no indication that there are more items to see. To solve this, it would be useful to be able to specify a scroll offset or similar that triggers scrolling even before reaching an item that is outside of the scroll viewport. This could for instance be a fixed dp value or .5
"list item heights" ahead. That way, the user would be informed that there is more to see.
In any case, glad to see this being of high priority!
ma...@gmail.com <ma...@gmail.com> #6
Looks like focus support for LazyLists did not make it to 1.1.0-beta01
.
Custom implementation that scrolls a LazyList to bring the focused element to view still almost works, but occasionally the focus moves to a random input node. The random input node can be uninitialized causing an exception at:
2021-11-01 09:54:51.247 E/MessageQueue-JNI: java.lang.IllegalStateException: KeyEvent can't be processed because this key input node is not active.
at androidx.compose.ui.input.key.KeyInputModifier.processKeyInput-ZmokQxo(KeyInputModifier.kt:75)
at androidx.compose.ui.platform.AndroidComposeView.sendKeyEvent-ZmokQxo(AndroidComposeView.android.kt:439)
at androidx.compose.ui.platform.AndroidComposeView.dispatchKeyEvent(AndroidComposeView.android.kt:446)
ct...@google.com <ct...@google.com> #7
Apologies for pinging this thread. I'm also having the IllegalState exception issue from above. Should this be pulled out into a separate ticket as opposed to part of this one or is it all sort of the same thing? From our perspective we can get by with a custom implementation similar to above if it's stable (until the out of the box implementation is sorted later on).
As an aside thanks for all your hard work on this. Compose is a pleasure to work with!
su...@google.com <su...@google.com>
su...@google.com <su...@google.com> #8
<3
ma...@gmail.com <ma...@gmail.com> #9
Branch: androidx-main
commit ef81023fc0de83421e4779f6bef8e14d4ef6a158
Author: Ralston Da Silva <ralu@google.com>
Date: Mon Feb 14 18:00:04 2022
Refactor focus search to accept a lambda
Refactoring the focus search code so that it runs a lambda
once it finds the next item. This is needed so that we can
request focus on the next item when the next item is beyond
visible bounds. We need this because beyond bounds layout
requests return a block and the items are guaranteed to be
available only within the scope of the block.
For more info, see go/compose-focus-beyondbounds
Bug: 184670295
Test: Internal refactoring, existing moveFocus() tests
Change-Id: I6545ef1a094f5bbe37eb6f861d1ea5ab6a7ec926
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/OneDimensionalFocusSearch.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusTraversal.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusManager.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/TwoDimensionalFocusSearch.kt
su...@google.com <su...@google.com> #10
Branch: androidx-main
commit 3b4ce572c2fa394843ff0082cc985c8d02228560
Author: Ralston Da Silva <ralu@google.com>
Date: Tue Feb 15 16:57:08 2022
BeyondBoundsLayout ModifierLocal
This CL adds a BeyondBoundsLayout modifier local.
Bug: 184670295
Test: ./gradlew compose:ui:ui:cC -P android.testInstrumentationRunnerArguments.class=androidx.compose.ui.layout.BeyondBoundsLayoutTest
Relnote: Added a BeyondBoundsLayout modifier local
Change-Id: If8b51c6e08a375d1c733588e53c9b07474c0855c
A compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/BeyondBoundsLayoutTest.kt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/api/current.txt
A compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/layout/BeyondBoundsLayout.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
ma...@gmail.com <ma...@gmail.com> #11
Branch: androidx-main
commit e5cb882c220a13f87054aa5ddcf6410b59c12d9a
Author: Ralston Da Silva <ralu@google.com>
Date: Fri Feb 11 14:11:09 2022
Adding Focus Group API
Add an API to specify groups of composables that should be treated
as a focus group. ie, we give priority to the items within the group
before we move focus to items outside the group.
Bug: 213508274
Bug: 184670295
Test: ./gradlew compose:f:f:cC -P android.testInstrumentationRunnerArguments.class=androidx.compose.foundation.focus.FocusGroupTest
Relnote: Added FocusGroup modifier
Change-Id: I64bc0b945bf172ad37b64d011d7055f4a99bfeca
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/Focusable.kt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
A compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/focus/FocusDemos.kt
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/FocusGroupTest.kt
M compose/foundation/foundation/samples/src/main/java/androidx/compose/foundation/samples/FocusableSample.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/FoundationDemos.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/FocusableTest.kt
yo...@gmail.com <yo...@gmail.com> #12
Branch: androidx-main
commit fec4977a16aec28d1f56b80a941c4890189e35bc
Author: Ralston Da Silva <ralu@google.com>
Date: Wed Mar 16 01:15:29 2022
Change BeyondBoundsLayout API
The current API accepts two lambdas. This simplifies
it so that we use only one lambda parameter.
Bug: 184670295
Test: ./gradlew compose:ui:ui:cC -P android.testInstrumentationRunnerArguments.class=androidx.compose.ui.layout.BeyondBoundsLayoutTest
Relnote: N/A
Change-Id: Ic41edde9b83cd5f3a602f332e5f441cd00b0be47
M compose/ui/ui/src/androidAndroidTest/kotlin/androidx/compose/ui/layout/BeyondBoundsLayoutTest.kt
M compose/ui/ui/api/restricted_current.txt
M compose/ui/ui/api/current.txt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/layout/BeyondBoundsLayout.kt
M compose/ui/ui/api/public_plus_experimental_current.txt
Description
Version used: android.arch.work:work-runtime:1.0.0-alpha03
Devices/Android versions reproduced on: any
Stacktrace:
Caused by: java.lang.NullPointerException:
at androidx.work.impl.background.systemjob.SystemJobService.onCreate (SystemJobService.java:52)
at android.app.ActivityThread.handleCreateService (ActivityThread.java:3267)
at android.app.ActivityThread.-wrap5 (ActivityThread.java)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1641)
at android.os.Handler.dispatchMessage (Handler.java:102)
at android.os.Looper.loop (Looper.java:163)
at android.app.ActivityThread.main (ActivityThread.java:6379)
at java.lang.reflect.Method.invoke (Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:904)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:794)
Description:
Hi,
Yes, I know its a duplicate of
We released first version of our app with WorkManager with alpha02 library and without any explicit calls to WorkManager.initialize(...) and received a lot of NPEs in our tracker for all the places with WorkManager.getInstance() calls in our code and internally in the library. We don't have multiple processes so I was sure you default initialization with empty ContentProvider should work. But looks like its not always working! (maybe it is not always working on devices based on modified Android forks?) I can't reproduce it manually, but I have a lot of submitted crashes.
Well, we added WorkManager.initialize(this, new Configuration.Builder().build()); inside our Application.onCreate() before calling super.onCreate(); and it indeed helped. We had no such exceptions on the next release.
But for the next release after it we updated library version to alpha03 and it started crashing a lot again. Even as we still have WorkManager.initialize(...) inside Application.onCreate(). Guys, issues like this are making adapting your library into real applications quite complicated, please consider reworking of the library initialization to make it more predictable.
I see that mostly it is crashing on Xiaomi devices, attaching screenshot with devices list.