What are the (hidden) costs regarding performance of

CompositionLocalProvider

? https://developer.android.com/reference/kotlin/androidx/compose/runtime/package-summary#CompositionLocalProvider(kotlin.Array,kotlin.Function0)

Is there an easy way to display a collection of

DropdownMenuItem

s where one has a selection state (check mark)?

Want to re-ask this question

I have a question about LazyColumn/Row. Does it still recycle/remember composables that scroll off screen? Or does it just create a new composable everytime a new one comes into view? I assume there has to be some sort of caching going on since you can put

remember { X }

inside LazyColumn/Row items and the next time you scroll to that item it remembers that state. Or maybe I've gotten lucky in that and there's a cache amount that I haven't scrolled past yet.

Started seeing a

No static method stickyHeader$default

after upgrading to

1.2.0-alpha03

. Seems to only affect my design systems module, e.g. I can place a

LazyColumn

with stickyHeaders in other modules just fine. Proguard is temporarily disabled, and my dependencies are exactly identical between the modules. Any other clues as to what I should look for (Ive tried invalidate caches + clean)?

On compose 1.1.0 tests are not running 😞

Just reposting this I asked a couple days ago in hopes that maybe some folks with ideas had missed it... 🙈🙊🙉 https://kotlinlang.slack.com/archives/CJLTWPH7S/p1644267546408289?thread_ts=1644267546.408289&cid=CJLTWPH7S

Can I render a

@Composable

outside of

setContent {}

so that I could get the size of one child

Composable

within? I don’t care doing that in the UI thread right now, just want to know if it’s possible!

Not fully Compose specific but is there a way to easily detect no more needed Opt-In like ExperimentalMaterialApi ?

Can someone point me to the issue in issue tracker where even after pressing and holding the delete button, while using numeric keyboard with a TextField, digits are only removed one at a time?

Is there any official word on efforts to improve preview rendering times? It seems to be a pain point for many developers, especially when getting started with Compose. I'm happy to patiently wait for improvements, and I'm sure this is a priority, but it would be nice to be able to point my colleagues to a plan or roadmap, something tangible that indicates that we can expect improvements in this area. I'd also love to hear from the Jetpack team what it is exactly that contributes to slow preview rendering times, and what challenges they face in improving this.

Is there a way to initially select all the text in a

SelectionContainer { Text(...) }

right now it only selects the word that was pressed.

I'm trying to implement something like a fillViewPort functionality for scrollable content. Basically, I want the content to fill the remaining size of the screen when the content is not bigger than the screen, but I want to be able to scroll when the content is bigger, Does anyone know how to solve this issue?

I'm getting a

ViewModel has no zero argument constructor

error when trying to construct a hilt view model in a compose function. Anyone else experiencing this? I'm not using the jetpack navigation component, just trying to inject a view model scoped to LocalViewModelStoreOwner.current. I get this error when trying to inject even a simple class with no sub-dependencies. My view model is provided like this:

viewModel: MyViewModel = viewModel()

, and I'm using the @HiltViewModel annotation on my view model. My activity and application all support hilt injection properly. I'm using the "androidx.lifecycle:lifecycle-viewmodel-compose" dependency for creating my view model. Let me know if you need more information. Edit: this also only happens when trying to create the view model with any injected dependencies. If the view model has no dependencies, it works fine. The

hiltViewModel()

is only supposed to be used with the navigation component, which I am not using. I am using an alternate navigation library (this one: https://github.com/olshevski/compose-navigation-reimagined), but from my understanding, it sets the LocalViewModelStoreOwner properly, and that's what the

viewModel()

function uses. I'm assuming it's something to do with the view model factory.

I'm trying to achieve this design with compose. I want to open dialpad with number input keyboard, this action triggers once I click FAB icon. I do not have TextField so cannot call the keyboard by default, in my case keyboard should open clicking on FAB. I have tried few things, but keyboard won't show up, any clue?

Scaffold(
    floatingActionButton = {
        FloatingDialButton(
            keyboardController,
            focusRequester
        )
    },
    modifier = Modifier.focusRequester(focusRequester)
) {
    ScreenContent(uiState)
}
@Composable
fun FloatingDialButton(
    keyboardController: SoftwareKeyboardController?,
    focusRequester: FocusRequester,
) {
    FloatingActionButton(
        onClick = {
            focusRequester.requestFocus()
            keyboardController?.show()
        },
    ) {
        Icon(
            painterResource(id = R.drawable.ic_dialpad),
            contentDescription = "",
            tint = MaterialTheme.colors.onSecondary
        )
    }
}

Can I get a sanity check as to why my UI won’t recompose? I’ve got a simple 1 activity setup with corresponding

ViewModel

, along with a

data class MyUIState

. I’m initializing my property as such:

var uiState by mutableStateOf(MyUiState.empty)

. , where

empty

is just a default initializer with default values. I’m then updating individual properties of

uiState

as events happen, for instance

uiState.loading = true

The `ViewModel`s is passed into my composable

MyScreen

as such from

MyActivity

setContent { MyScreen(viewModel) }

Finally, inside of my composable

MyScreen

I'm doing

val uiState = viewModel.uiState

and driving changes off of those values, for instance

if (uiState.loading)

- however, this is the point at which they aren't recomposed. Most of the examples I can find use a very simple value like

mutableStateOf(true)

, so I'm assuming there is something going on where just updating a property isn't having the right effect.

Can I put the result of rememberNavController() into the ViewModel for route persistence？

Are there any articles on good navigation design like this(https://compose.academy/blog/modular_navigation_with_jetpack_compose)

What is the difference or what would the reasoning be behind using rememberScaffoldState as a peramitor instead of in the function itself. Such as... @Composable fun MyScreen( state: UiState<List<Movie>>, scaffoldState: ScaffoldState = rememberScaffoldState() ) { // Instead of // val scaffoldState = rememberScaffoldState() // If the UI state contains an error, show snackbar if (state.hasError) { //

LaunchedEffect

will cancel and re-launch if //

scaffoldState.snackbarHostState

changes LaunchedEffect(scaffoldState.snackbarHostState) { // Show snackbar using a coroutine, when the coroutine is cancelled the // snackbar will automatically dismiss. This coroutine will cancel whenever //

state.hasError

is false, and only start when

state.hasError

is true // (due to the above if-check), or if

scaffoldState.snackbarHostState

changes. scaffoldState.snackbarHostState.showSnackbar( message = "Error message", actionLabel = "Retry message" ) } } Scaffold(scaffoldState = scaffoldState) { /* ... */ } }

Hi guys! I’m experiencing a strange behaviour. My ViewModel

init {}

it’s called twice. I’m using jetpack compose (1.1.0 and it happened also with 1.1.0-rc01): • ActivityA has ViewModelA and everything is ok. • ActivityB has a

AnimatedNavHost

with 3 composable (“screens”). When they’re first created I get this 2 time problem, but after that, when I change between them, the

init {}

is called only once as expected. What could it be?

Hello, I’ve been experiencing some crashes lately when trying to pop a destination that, seemingly from the pattern, contains a nested navigation (either a NavHost or an AnimatedNavHost). It’s almost like when the screen containing the navhost is popped off the stack, it’s attempting to recompose during the time it’s being popped, and throws the following exception:

java.lang.IllegalStateException: You cannot access the NavBackStackEntry's ViewModels after the NavBackStackEntry is destroyed.
        at androidx.navigation.NavBackStackEntry.getViewModelStore(NavBackStackEntry.kt:207)
        at com.google.accompanist.navigation.animation.AnimatedNavHostKt.AnimatedNavHost(AnimatedNavHost.kt:144)
        at com.google.accompanist.navigation.animation.AnimatedNavHostKt$AnimatedNavHost$11.invoke(Unknown Source:23)
        at com.google.accompanist.navigation.animation.AnimatedNavHostKt$AnimatedNavHost$11.invoke(Unknown Source:10)
        at androidx.compose.runtime.RecomposeScopeImpl.compose(RecomposeScopeImpl.kt:140)
        at androidx.compose.runtime.ComposerImpl.recomposeToGroupEnd(Composer.kt:2158)
        at androidx.compose.runtime.ComposerImpl.skipCurrentGroup(Composer.kt:2404)
        at androidx.compose.runtime.ComposerImpl$doCompose$2$5.invoke(Composer.kt:2585)
        at androidx.compose.runtime.ComposerImpl$doCompose$2$5.invoke(Composer.kt:2571)
        at androidx.compose.runtime.SnapshotStateKt__DerivedStateKt.observeDerivedStateRecalculations(DerivedState.kt:247)
        at androidx.compose.runtime.SnapshotStateKt.observeDerivedStateRecalculations(Unknown Source:1)
        at androidx.compose.runtime.ComposerImpl.doCompose(Composer.kt:2571)
        at androidx.compose.runtime.ComposerImpl.recompose$runtime_release(Composer.kt:2547)
        at androidx.compose.runtime.CompositionImpl.recompose(Composition.kt:620)
        at androidx.compose.runtime.Recomposer.performRecompose(Recomposer.kt:786)
        at androidx.compose.runtime.Recomposer.access$performRecompose(Recomposer.kt:105)

This is on latest 2.5.0-alpha01, but was also occurring on 2.4.0-alpha01 (but with a different error message)

I think there is a bug with the preview tool in Android Studio Chipmunk 2021.2.1 Beta 2. The preview is not consistent with what you see on the device. The paddings displayed in preview do not reflect the real values given. Here's a screenshot.

Hello everyone) Tell me, is there some practical example when you need to use requiredSize modifier, but not size modifier. And is requiredSize always worth using when exact dimensions are needed?)

Does jetpack compose support view impression callbacks or any pointers that how we can implement a composable item impression callbacks?

I'm writing Compose tests for one of my projects that I recently started. I'm getting an ExceptionInInitializerError that is

caused by java.lang.RuntimeException: Method allowThreadDiskReads in android.os.StrictMode not mocked

. I wrote a simple test (in thread), which reproduced the issue. This only started when I added Compose tests.

where can I see the matrix of gradle wrapper/ gradle plugin/kotlin version/compose version that will work together ?

if I want to move keyboard focus to a

TextField

once my

ModalBottomSheet

is shown, is using the `ModalBottomSheetState`'s

confirmStateChange

the correct place to do that, or is there a better place? I understand it can work but it doesn't necessarily feel right.. is there a listener I can use which signals "the modal bottom sheet has finished appearing"?

I'm a situation where I want my view model to communicate a navigation event to the composition after completing some suspending work. For example, user types in a password, hits "login", and then the backend does some long-running work to do all the things necessary for authentication. My concerns are the following: • How to represent the nav event as part of the UI state. Simply setting a state property to "loginComplete = true" means it will be true still when the user navigates back (for whatever reason). • How to reliably cancel the work when the user leaves the composition, but not when the user changes orientations. For example, while the sign-in is happening, the user could press the back button, or navigate into an account recovery screen. If the user does either of these, I want any current sign-in activity to cancel (as opposed to it continuing while the user is off-screen). Navigating back should do this automatically by killing the view model scope, but navigating to the recovery screen doesn't do this. The sign-in can yield theoretically 3 results: normal success, verification required (nav to a verification screen), or sign in failed. While the sign-in is happening, I also want the UI state to be in a loading state. Specifically, my questions are: 1. What is best practice for cancelling any jobs/producers in the view model when navigating from a screen, without doing this on configuration changes and the like. I know of the

Activity.isChangingConfigurations

property, but is this reliable? Or should I just make sure to add a call to cancel jobs at every point where a navigation event happens, and make sure no navigation events happen higher up in the composition hierarchy? 2. What is the best practice for the view model communicating a nav event to the composable? I have a single UI state object for each screen, should I include a "nav event" property in the UI state? And how can I ensure this nav event only triggers up to one actual navigation event? I was thinking of creating an object which is like a "OneShotEvent" object, which has a "consume" method that suspends, and only consumes events that weren't already consumed. Or would a SharedFlow with no replay cache, or some application of producer channels be more idiomatic?

☝️ interestingly, this behavior does not happen if I set my modal bottom sheet to

HalfExpanded

. if I only open it half way, show the keyboard, then hide the keyboard, nothing strange happens.. but if I open it to

Expanded

, then as soon as I hide that keyboard, it re-animates back onto screen 🤯