Thanks a lot for alpha11 release. It solved all my keyboard related issues 🥳🥳 Can’t wait to see what’s cooking up next. Just tried out this snippet to pre-focus a TextField on First load and it worked like charm. Let me know if anything is wrong doing it this way

val fieldFocus = remember { FocusRequester() }
LaunchedEffect(key1 = Unit) {
    addressFocus.requestFocus()
}

If you don’t need a coroutine (and I don’t think

requestFocus

is suspending), I would use

SideEffect

instead of

LaunchedEffect

.

Zach do you mean

DisposableEffect

? I think

SideEffect

runs after every recomposition. (Asking bc I’m using

DisposableEffect

to replace my

onCommit

calls, but having an empty

onDispose

lambda feels weird to me, so want to check I’m not missing an obvious API)

onCommit

->

SideEffect

. It is supposed to feel wrong using

DisposableEffect

if you have nothing to dispose

My bad, i remembered incorrectly (thought

SideEffect

replaced

onActive

, not

onCommit

).

onCommit

took a subject though right? Which

SideEffect

doesn’t as far as I can see

DisposableEffect(Unit)

is the equivalent to

onActive

, looking at the commit that made the changes: https://android-review.googlesource.com/c/platform/frameworks/support/+/1548515

It may feel wrong to have an empty

onDispose

, but I think that is the correct way to handle things right now. There isn't another effect api to use in place of it at the moment. If you want to save yourself some typing, you could make your own

DisposableEffect

with an empty

onDispose

and just import that one when you need it. Here are some examples with empty

onDispose

calls: Modifier.focusable Swipeable.rememberSwipeableStateFor Modifier.swipeable NavHost DemoFilter.FilterField

thanks all, good to know

Yup, having no cleanup isn't a problem, just note as per the deprecation messages on onCommit, etc that using

DisposableEffect

without any parameters is "usually incorrect" to use @Adam Powell's words

Yeah, as is using it with an empty

onDispose

clause

So if I want to request a focus on the text field when the screen is first shown - what would be the recommended approach for that?

I want to have TextField pre-focused, that's the only logic here. Where could I hoist the focus requester in this case? I picked

LaunchedEffect

because it's called once at the start and on subject changed afterwards, which in my case is

Unit

@Kshitij Patil what kind of issues did you have that were fixed?

All mainly related to opening and closing of keyboard. 1) Keyboard used to get stuck sometimes and didn't hide when clicked outside 2) Keyboard doesn't show up when TextField focused 3) It wasn't possible to pre-focus a TextField prior alpha11. It's now possible with the snippet I shared. 4) I'm not sure whether we do have to explicitly use

imePadding()

or

navigationBarsWithImePadding()

to prevent TextField from getting hidden by the Keyboard but now I'm using it everywhere I've

TextField

. This wasn't a case with native xml layouts.

softInputMode=adjustResize

in AndroidManifest and

fitsSystemWindow=true

used to do the job for us.

omg, that’s good news! We’ve been tracking these issues for a long time and gives a bad impression. I’m excited to update. Any critical issues when you updated?

No issues so far.

@Adam Powell Is this the valid case of using DisposableEffect? ColorToApply : Color which will change colorPrimary: Default color

DisposableEffect(ColorToApply) {
    systemUIController.setStatusBarColor(ColorToApply)
    onDispose {
        systemUIController.setStatusBarColor(colorPrimary)
    }
}

That'll probably get you pretty far. For something library-grade I'd probably try to give that sysuiController class an add/dispose mechanism with some sort of disambiguation for cases when more than one of these snippets is present in the composition at the same time. There would be cases where you wouldn't want to go back to the default, but instead you'd want to fall back to the other contributor.

Thank you, for detail answer, I agree it would be problem if multiple composable use this code at same time, but in my case only screen level composable uses this snippet.