Does Compose draw each Composable directly to screen or does it first composite each composable to a texture which ultimately ends up on screen Eg Row Text Would Compose first draw Row directly to screen, and then draw Text directly to screen Or would Compose first draw Text to a texture, and then draw Text's texture to Row's texture, and then draw Row's texture to screen

How can I detect that the application is in the background?Disposable Effect not working for me

Does Compose have a concept of padding like Android View System does

Where can I find the source code for how compose draws its contents to the screen? Specifically the stuff that deals with converting padding/spacing, relative locations and so on, into absolute placement positions for graphics api to render to within the region specified

How do I get my bottom sheet to cast a shadow? I only see the shadow if the

sheetBackgroundColor

and the

backgroundColor

of the

BottomSheetScaffold

are the same. I'm not sure if the shadow is there in the first image but I clearly cannot see it, it all looks flattened to me.

I'm having some issues understanding how the layout work exactly. I have a LazyColumn that fills a part of the screen. If I wrap that in a SelectionContainer, it no longer fills the screen until there's enough content, and then it pushes the TextField off the screen. The following works as expected:

Column(modifier = Modifier.fillMaxSize()) {
    LazyColumn(
        modifier = Modifier
            .fillMaxWidth()
            .weight(1f)
    ) {
        items(lines) { line ->
            Text(line)
        }
    }
    TextField(...)
}

If I put a SelectionContainer around the LazyColumn with the same modifier, it doesn't work as I expected. Anyone know why?

Does the order of these modifiers matter?

Modifier.padding

Modifier.offset

(or any other position modifier)

Modifier.requiredHeight

(or any other size modifier) For example

Text(
    modifier = Modifier
        .padding(horizontal = 16.dp)
        .requiredHeight(50.dp)
        .offset(10.dp)
)

And

Text(
    modifier = Modifier
        .requiredHeight(50.dp)
        .offset(10.dp)
        .padding(horizontal = 16.dp)
)

In which both have a height of 50 and offset of 10, and a padding of 16

How is

Modifier

implemented such that

this

or

it

does not need to be passed to it or any of its methods? As the only way I can think of is as a command list builder or similar As

Modifier

seems to immediately be a very powerful tool to implement parameters and such with due to its simplicity and everything that can be modified is in a single class so it is easy to find a parameter of interest instead of having to search through lots of additional methods and such that might not be related to parameters at all

Could someone share a good example of production level navigation with compose? I found this by accident and now I'm questioning some decisions. When I play my app I start with the splash screen, I verify the user state. and then decide where to go. I just learned that this might be incorrect. So shouldn't I use my splash screen to load new information? Should I have some sort of dynamic destination that does this information loading and lands you in whatever the "correct" destination might be?

I'm creating

Button()

and fill it with white color, but it gets filled with theme's primary color and not the white color.

Button(
        modifier = Modifier
            .size(80.dp)
            .clip(CircleShape)
            .background(Color.White)
//            .background(MaterialTheme.colors.surface) //It's also not working
            .border(5.dp, Color.White, CircleShape),
        onClick = {  })
    {

    }

why I can't find

scaleIn()

?

How does Compose compute where to place each child? And which source file is responsible for this?

Has anyone noticed that

SoftwareKeyboardController#show

doesn’t work super reliably for their composable? I’m using it to auto-show the keyboard when a dialog is shown but I’m forced to use a small delay. I was wondering how are others showing keyboard?

val keyboardController = LocalSoftwareKeyboardController.current
val requester = remember { FocusRequester() }

TextField(
  modifier = Modifier.focusRequester(requester),
  value = ...,
  onValueChange = ...
)

LaunchedEffect(Unit) {
  delay(50)
  focusRequester.requestFocus()
  keyboardController?.show()
}

Regarding lifecycle behavior etc., do I get the exact same result if I use

collectAsState

on a Flow vs

observeAsState

from LiveData?

It's good practice to declare an optional

modifier

parameter on my own composables and apply them to the outer-most composable in that function, right? Is the same also the case for my composable that just holds the entire screen content? it's not reusable and I don't need to pass any modifiers to it since it's handled internally.

Can I get better alternatives for detecting the scroll direction in a

LazyColumn

. Here is what I have but it looks too hacky to me even though it works really well. Code in thread....

Like in Swift, can we somehow shorten

Column(horizontalAlignment = Alignment.CenterHorizontally)

to?

Column(horizontalAlignment = .CenterHorizontally)

to improve readability? It would be a, seemingly, simply thing but would increase the readbility to codebases massively.

I think I found a bug in compose. This should display the text "blah" if I'm not mistaken.

Hi Guys, Just wondering whether anyone could explain the

resistance

in:

Modifier.swipeable(
    state = swipeableState,
    anchors = anchors,
    reverseDirection = false,
    thresholds = { _, _ -> FractionalThreshold(0.0f) },
    resistance = resistanceConfig(anchors.keys, 0f, 0f), // This right here...
    orientation = Orientation.Vertical,
)

No matter what value I set it in, I can’t seem to see the difference in the Swipe behavior

Hi, is there will be a iOS version of Compose soon ?

This message was deleted.

Hi, I'm using the

modifier.draggable(...)

to detect dragging from user. I want to know when user stops dragging, what's the best way to get this information? Is it possible with

draggable(...)

or there's other modifier that provides this exact information?

I'm looking at the JetNews sample app for its navigation structure and I see that it nests a

Scaffold

within a

Scaffold

. At the top level it has a Scaffold with a

NavHost

in the lambda, and each screen listed in the NavHost (

composable

) has a Scaffold (no lambda). I think I see at least one reason why it does this -- to have a single NavHost at the top and to give each screen its own

topBar

-- but I wasn't expecting nested Scaffolds to be a thing (I had thought of it, obviously incorrectly, as a once-per-screen construct). In any case, I wanted to confirm that this is the best (only?) way to structure an app when using navigation.

Hi, Any one faced compose tooling being very slow while rendering in larger project? My build runs faster than compose preview and sometimes it takes forever to preview. I am on

AS Artic fox 2020.3.1 Patch 2

compose version -

1.0.1

🧪 Compose Testing `createAndroidComposeRule`: Is it a good practice to create a separate activity to test composables that need android resources ? 🤔

🧪 Compose Testing: When to use

assertIs[Not]Displayed

and

assert[DoesNot]Exists

? 🤔

Sadly,

AndroidComposeTestRule

is not of much use for me, the implementation basically has two issues: 1. It doesn't work with Fragments, since

setContent

is directly called on the

Activity

of an

ActivityScenario

, ignoring fragment semantics completely. 2. It's impossible to test the UI with the viewmodel in integration, as one basically has to manually connect the `ViewModel`s state flow to a separate

setContent

call on the test rule, ignoring the beef of the viewmodel / view integration altogether. I wish the test architecure in compose would have been written around the fact to have an injectable

Recomposer

for testing purposes.

Is there an (3rd-party) API for a horizontal list UI's, but instead of regular horizontal scrolling, it's like swiping/sliding, like a slideshow?

Hey, I believe that the documentation for

derivedStateOf

is misleading, and it that SideEffect should be declared in

remember

using no keys to really benefit from its caching mechanism. Here’s a documentation using keys with remember with derivedStateOf:

<https://developer.android.com/jetpack/compose/side-effects#derivedstateof>

And here’s a documentation that doesn’t use keys in remembers:

<https://developer.android.com/reference/kotlin/androidx/compose/runtime/package-summary#derivedStateOf(kotlin.Function0)>

Any thoughts on that?