https://kotlinlang.org logo
Join Slack
Powered by
In an app with both d-pad and touch event support,...
# compose
h
In an app with both d-pad and touch event support, what would be the best way to react to any touch event to reset and hide the d-pad focus?
An immediate problem is that if lazy content is scrolled with touch drag so that the d-pad focus is left outside of the screen to an element that no longer exists, using the d-pad crashes the app.
a
D-pad navigation is a high-priority feature in our roadmap that we're actively working on. we have barebones support, but especially with LazyRow or polished scrolling animations, there are some things that are not really possible to do right now (especially when focusing an offscreen item is required)
🙌 2
but in a future version of Compose, things should work better by default in cases like this, so keep an eye on https://issuetracker.google.com/issues/184670295
h
Thank you @Alexandre Elias [G]! We've tried to balance how much effort we should spend on D-pad navigation ourselves and what we can expect from future Compose versions, so it indeed helps to know that this is high-priority on the roadmap.
@Alexandre Elias [G] what's the current need for feedback regarding d-pad navigation in compose 
1.1.0-alpha02
? I tried d-pad focus with LazyColumn and custom scrolling with RelocationRequester, but it's still too easy to crash the app as the focus ends up in a composable that is not yet active.
a
we don't need additional feedback right now as the top known issues are pretty clear and affect everyone, but as we land improvements in the next few months, we might find feedback useful after that point to let us know about (for example) corner cases we missed in our initial fix
👍 1
n
@Heikki Rauhala how did you go with dpad scrolling? Currently trying to strike the same balance between what to wait for / what to implement. Any learnings you can share?
h
@Nathan Castlehow we have not tried to perfect the compose 1.0.0 version of the dpad support. It kind of works, but there are a couple of sharp corners that can throw exceptions if the focus is moved too fast. Compose 1.1.0-beta01 was just released yesterday, so now we'll update to that and see about the results.
n
@Heikki Rauhala makes sense. Was your approach just to call animateScrollToItem once it is focused (in my case I look for has focused on a parent as my ui is a list of lists)?
w
@Nathan Castlehow In essence, yes. We also did some considerations in the scroll offset parameter to ensure that the next and previous items always are visible too, otherwise focus cannot be moved to them.
👍 1
h
Ok, now we have updated to 
1.1.0-beta01
, but the d-pad navigation in a lazy column still crashes occasionally with 
java.lang.IllegalStateException: KeyEvent can't be processed because this key input node is not active.
when focus is moved. That's expectable as the issue https://issuetracker.google.com/issues/184670295 is not yet fixed in 1.1.0.
n
Do you get the same issue as the last comment on that ticket? Where the focus randomly jumps away. I get it pretty consistently on a lazy row when I start scrolling back towards the start. I wasn't able to get it to happen on a really basic list (just using boxes) but when i have an image etc it does. I wonder if it is timing related?
h
Yes, just wrote the last comment 😄 https://issuetracker.google.com/issues/184670295#comment6
And I agree, it seems to be timing related. If you run a release build (that's at least for us significantly faster than the debug build), it works better, but still can crash.
n
Did you find any of the previous compose versions more reliable? (trying to get this app to be shippable)
h
@Nathan Castlehow unfortunately no. We've been at this since 
1.0.0-alpha11
n
Ouch. No worries. If I work anything out I'll chuck in this thread. Agreed release works a ton better! I wonder if we could get one of the google guys to chime in here to see if it'll be in the next stable release. I'm not hopeful as we are up to beta now without it.
🤞 1
😬 1
h
If non-lazy is an option, it does work. Really interested if you have can find something that does work reliably with lazy. We did do an experiment with the RelocationRequester, (now BringIntoViewRequester) for the scroll, whether that would be more reliable, but it did not at the time improve reliability.
n
Non Lazy was too slow for me. One option I have is to stop having such big lists I guess. I've found that the whole thing feels like it crashes less when I set a focus order on everything instead of letting it pick default.
h
Do you set focus order also within the lazy list?
n
I set focus order on all the items inside of each LazyList (see screenshot below of my UI).
Copy code
.focusOrder(focusRequester, focusOrder)
I've started trying to wrap stuff up to make it reusable but damn it's a touch ugly at the moment (happy to share it if i manage to break it up a bit more). Issue I'm having now is for up / down key presses how to get it to focus the item its currently up to in current / previous the list. My current thinking was to capture the up / down press and somehow get a reference to the correct focus requester. Have you had to do this?
Thats a really ugly gist of what I'm sort of doing now
Currently running beta01. Focus works relatively well however have put focus order on everything to try make the page more predictable to move around. Wasn't able to fix the issues with the lazy lists so made the lists shorter and added a view all button at the end of them to get around it for now 😞
With that being said we aren't jumping around to items that are optionally hidden so that could change some things I guess.
h
Turns out that our problem was the clickable elements. We're using clickable to prevent clicks going through for example surfaces on top of other elements, and the beta02 made all 
clickables
to be focusable when the dpad is used, more discussion here: https://issuetracker.google.com/u/1/issues/202856230
👍 1
n
Hi @Heikki Rauhala Not sure what device you are testing on but just wondering if you have had any weird not responding issues. We are currently testing using the Chromecast with Google TV. We get into a state where the google tv stops responding to key presses (except for the assistant button). Even after the app is killed the google tv still only responds to the assistant button until the power is reset. This means bluetooth is still working and the ui isn't frozen just somehow the key presses are getting swallowed. Have you seen this one before?
h
@Nathan Castlehow Sorry, we are not targeting chromecast at all. We have had issues that would cause the focus to be sent to an element where it can't get out from, but in our target platform we always have the option of using touch so those situations have been easy to identify and fix.
n
ah ok. No worries, thanks for getting back to me 🙂
11 Views
Open in Slack
PreviousNext
Powered by