https://kotlinlang.org logo
#compose
Title
# compose
t

Tolriq

08/18/2022, 8:13 PM
Is there a proper way to know if a Textview is visible on screen or have another composable over it?
z

Zach Klippenstein (he/him) [MOD]

08/19/2022, 1:02 AM
Idk what the api would be for views. For a composable, you can get the layout coordinates and ask for bounds with clipping enabled - if the rect has a positive size it's visible
t

Tolriq

08/19/2022, 6:11 AM
Do you have an example of that? The issue is that I have a screen with a textview that request focus when on screen. But at some point a user may open a bottomsheet from another part of the app that covers it (The components are not aware of each other and 0 code link) When they go to Android home then come back to the app the textview request focus but it should not 😞
z

Zach Klippenstein (he/him) [MOD]

08/19/2022, 7:04 PM
Not sure what that has to do with visibility. Are you using a dialog-based bottom sheet? It sounds like the text view is maybe grabbing focus when the window isn’t even focused
t

Tolriq

08/19/2022, 7:10 PM
This is a standard bottom sheet but the search composable have a
Copy code
LaunchedEffect(Unit) {
        focusRequester.requestFocus()
    }
to request the focus when the composable is rendered. When going home then back to the app, I'd like to not call this by detecting that there's something that makes the component not visible.
z

Zach Klippenstein (he/him) [MOD]

08/19/2022, 11:51 PM
It's not feasible to expose some state that says it's not the active screen? Using visibility for this seems brittle since it relies on layout, which isn't really the true signal here it sounds like.
t

Tolriq

08/20/2022, 6:26 AM
I can hack something ugly but it would be the last resort 😞 The app is highly modularized, the modules are contributed via dagger maps, the bottom sheet is a child of one component and the search view a complete autonomous one. Technically in that case the search view is the active screen and if the database change the screen will update to reflect it. It's really about being covered by something while being active. A state would mean that I push to everything in the app a state that says that there's a bottomsheet fully opened. I guess the other solution is to use some remembersaveable and that the users have to click again the search field when they come back to the app, less hacky and just one more click for them (Even if after 10 years doing end user apps, users are really complaining about the number of clicks)
Ok so @Zach Klippenstein (he/him) [MOD] actually this is not enough 😞 When requesting focus on the textfield then closing the keyboard the textfield keep the focus. And when coming back it triggers automatically the keyboard visibility because of this. If I clear the focus then no issue. Is there a proper way to detect keyboard closing so that the textfield release the focus?
30 Views