On Start

ScannerScreenContent

ist called twice and everytime

val state by viewModel.device.observeAsState()

is triggered,

ScannerScreenContent

is called again which leads to a list with always 1 item. Does someone have an idea?

How does

viewModel.device

work? Does it just emit every time there’s a new device?

Yes exactly.

val device: LiveData<BluetoothDeviceWrapper>
    get() = bluetoothManager.device

This isn’t really state then, so using

observeAsState()

isn’t really ideal. This would be a great use case for

launchInComposition

though. Basically you could do something like:

// Key the coroutine on the device Observable, so if the observable changes for some reason you'll resubscribe.
launchInComposition(viewModel.device) {
  // Now you're in a coroutine that will run
  // continuously across recompositions.
  viewModel.device.asFlow().collect { device ->
    modelList.add(device)
  }
}

This would replace lines 22-28 of your snippet. https://developer.android.com/reference/kotlin/androidx/compose/package-summary#launchincomposition_1

ok thanks, I will try it. And what do you think about the fact that Scaffold bodyContent is calling twice? I'm on dev13 but dev12 same problem, is this a bug?

When you say it’s being called twice, do you mean the lambda it returns is invoked twice? Like for example, line 23 is executed twice in a row?

Yes the lambda is called twice:

bodyContent = {
  Log.d("Debug", "This is called twice!")
}

That doesn’t seem surprising. It just means that somehow compose is deciding to do two composition passes of your function. Not sure why, but it shouldn’t really matter. As far as i can see the only reason why it’s an issue for your code is that you’re doing side effects directly in your function, which would be fixed by that

launchInComposition

snippet.

I dont know how to use channels, so I tried this:

@Composable
fun ScannerScreenContent(
    onItemAction: () -> Unit
): @Composable() (Modifier) -> Unit = { modifier ->
    val viewModel = ScannerViewModelAmbient.current

    val context = ContextAmbient.current as MainActivity

    val modelList = modelListOf<BluetoothDeviceWrapper>()

    launchInComposition(viewModel.device) {
        viewModel.device.observe(context, Observer {
            Log.d("Found", "here")
            modelList.add(it)
        })
    }

    AdapterModelListComponent(modelList, modifier, onItemAction)
}

but the AdapterList is not updating on new devices. modelList is not empty.

For duplicates, that works, although it would be more idiomatic kotlin to do

if (device in modelList)

, but that’s really just a style matter.

Hmm when I do this

@Composable
fun ScannerScreenContent(
    onItemAction: () -> Unit
): @Composable() (Modifier) -> Unit = { modifier ->
    val viewModel = ScannerViewModelAmbient.current

    val modelList = remember { mutableListOf<BluetoothDeviceWrapper>() }

    launchInComposition(viewModel.device) {
        viewModel.device.asFlow().collect { device ->
            if (device in modelList) return@collect
            modelList.add(device)
            Log.d("Found", "size: ${modelList.size}")
        }
    }

    AdapterModelListComponent(modelList, modifier, onItemAction)
}

The AdapterList is not updating, that says, no items are listed. Any ideas? 😕

Sorry, that should be

modelListOf

, not

mutableListOf

Haha wow my bad 😄 I didn't realize that, now it works!

You should always use one of the state memoization functions for initializing state because not doing so is brittle. It's brittle because it's really not under the control of the function how many times it's called. If any code calling the function decides to pass a different value for any of your parameters, it will be re-invoked. Even if your function is private and you have full control of all the callsites, this would be hard to maintain since it's unidiomatic and would need to be called out explicitly in the documentation, and easy to miss for new developers or remember for yourself when you come back to this code later. Basically, it would behave in a way that would be surprising compared to other Compose code, and it could break as the result of all kinds of seemingly unrelated changes over time. It's also easy to break by changing the code within the function to something that triggers recomposition of the function itself. Developers shouldn't have to think about the specifics of how often a composable function is invoked, and making the correct behavior of your code dependent on that is going to be hard to debug later. Also, the upper bound of the number of times a composable function is called is effectively an implementation detail of the compose runtime. The runtime guarantees, as a lower bound, that you will eventually be recomposed if some state you depend on changes, but afaik doesn't make guarantees about the upper bound of how often it will be called. The fact that it's only called when something changes is really an optimization, in my mind at least.

Nice explanation, thank you very much, I guess I got it now. And what about

launchInComposition

. Is it used to call blocking code + a concise way of doing something in a coroutine within a composable? I mean when I place

viewModel.device.asFlow().collect { device ->
            if (device in modelList) return@collect
            modelList.add(device)
            Log.d("Found", "size: ${modelList.size}")
        }

directly in the composable function it would block the code. What did you mean with side effect...I found these words in the docs too.

what about 

launchInComposition

. Is it used to call blocking code + a concise way of doing something in a coroutine within a composable?

It launches a new coroutine the first time it is included in the composition at a given position. That coroutine will remain running until the

launchInComposition

call is removed from the composition (i.e. if you surround the call in an

if

and eventually stop calling it). It is very useful for performing long-running asynchronous actions (such as collecting a flow/subscribing to an Observable), or for performing long-running side effects in the background.

Really nice explained, I got it. Thank you so much! 🙂 Where do you get those "best practice" informations?

Mostly just from following this channel and reading what the compose team members have to say about this stuff. There are also a few talks and podcasts with them that explain some of this stuff as well. One good thread about the dangers of performing side effects directly in Composables was this: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1591659323449600?thread_ts=1591653158.447300&cid=CJLTWPH7S

Makes sense. I guess the members with a [G] in the name are compose team members or at least members of google right?