Видео

Is the source available?

Please tell me does it works for iOS platform Thanks 😁😁😁😁😁

Hohooo cant wait brooo

Nice work! 👍

That looks impressive! Great job! 😍

Feels smooth 😮

one viewModel per screen, one state in it(data class). initialize it as mutableState inside viewModel and callect as lifecycle state in screen. one sealed class for events(if event should be handled in screen like navigation). initialize it as channel and observe it inside launchedEffect(unit) other user events can directly call vm function. I mean it is pretty good.

Alerts ON , can't wait to use it 🔥🔥

This looks great.❤ I can't wait to use it! This will help a LOT in development, especially since we don't have previews in common code yet

This is awesome! 🚀

this is 🔥!

Thats awesome

thats supersonic

how do i do a super like. lol. this is so awesome.

Cant wait to use this!!

Damn that's blazing fast! Super excited for this!

Does this work even when code is changed in a gradle submodule dependency?

That hot reloading is actually super hot 🔥 I am wondering if something similar would theoretically be possible for server applications written with ktor or spring boot? 😮

it doesn't need to compile again when you deal with code that's not composable and works just like that without resetting any state??? HOLY FUCK THIS IS GOOD

I gotta admit, this is both explosive, and hot at the same time 😅 I love that it just does not even lose track of the existing mutableState objects, they stay the way they were. This is definitely powered by magic, you won't convince me otherwise.

It was necessary to swap the webcam and the editor

Is Nothing in fact Everything?

Amazing video! It’s so exciting to see coroutines from this perspective. I gained a much deeper understanding of how they work under the hood!.

I didn’t know the existence of the method measure and the extension. Thanks for that! Also, how do you make the suggestion saying “Tab to complete” ?

Fascinating and presented fast enough to drive home your point that one really needs to do this on their own for a full understanding. Thanks for uploading!

Hey seb, you should upload more such videos. These are awesome and easy to understand

6:50 why not just put mavenCentral() above google()?

This is some insane content!

Great Stuff

Great talk!

In your example you missed a point: by rotating the screen the Activity is recreated and the code in the onCreate event is executed again. The ViewModel init method is invoked once when the Activity is created, and the onClear method when the Activity is removed; when the device rotates the activity is re-created but the init method is not invoked and you can reuse the data stored in the view model (state) to populate the composable in the activity. The best approach is to have 1 single state in the ViewModel, the View (Compose) invokes the methods exposed by the ViewModel (i.e: doSave, doFilter, etc) and these methods update the state (each ViewModel has 1 state always containing the 'val onLoading: Boolean = false' and 'val failure: FailureXXX? = null' properties, besides all the properties needed by the UI). The state is monitored by the XXXScreen using LiveData or Flow, and the updated state is a property of the '@Composabe private fun XXXScreenContent(state: State) {}'): all the components used inside XXXScreenContent know nothing about the viewModel. Each event created by the components are sent back to the XXXScreen, that it will invoke the viewModel.doXXX. This is the architecture I have used since moved to Composable, and it works very well: everything is testable, the components are all stateless (very few are stateful), and you can create a company component library very quickly and be highly productive. P.S.: using lifecycleScope instead of viewModelScope can create problems, because you interrupt every process linked to it, forcing the restart of every background activity (and the use of the global scope is highly discouraged)

I've seen for these types of perf tests, you'll also get more accurate results if you warm up before you start measuring. If you don't do warm up, you'll generally see the first operations being slower than the last ones, skewing the results.

Omfg, so detailed 😮

The flickering of the blur near your head vs background is really distracting. Maybe just disable it instead?

If you care about performance just use a serious language like Rust🚀

By using 100,000 iterations you are diluting the Iterator instantiation overhead. Maybe a better test would be to execute a (0..10) loop 10,000 times.

Additionally: your benchmark measures almost empty for loops. In practice, your for loop typically does several times more work inside than is taken up by the actual iteration (branch prediction + misses). So whatever difference there is, it is going to get massively reduced in practice with actual usage.

Nice one. I would also recommend this talk from Aleksey Shipilev ruclips.net/video/x3Vlze1mUj4/видео.html , which explains this black hole and other black magic on JVM benchmarking.

I believe the benchmarks shown in the video are not entirely accurate. The key advantage of using fastForEach is that it avoids allocating a new iterator each time it's used. In the benchmark example, the performance difference may seem negligible because it's a simple case. However, when dealing with nested loops, the gap between the two approaches becomes more significant. For instance, if we need to loop through a matrix with a large number of rows (say, 1,000,000) allocating a new iterator for every row becomes a costly operation. In my case, the results are: - forEach: 462,983 us/op - fastForEach: 309,201 us/op As we can see, fastForEach is 1.5x faster than forEach. Here is the benchmark I used, by the way: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MICROSECONDS) @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS) @State(Scope.Benchmark) open class ForeachBenchmark { private lateinit var list: List<List<Int>> @Setup fun setup() { list = List(10_000) { List(10_000) { it } } } @Benchmark fun forEach(blackhole: Blackhole) { list.forEach { sublist -> sublist.forEach { element -> blackhole.consume(element) } } } @Benchmark fun fastForEach(blackhole: Blackhole) { for (i in list.indices) { val sublist = list[i] for (j in sublist.indices) { val element = sublist[j] blackhole.consume(element) } } } }

Recently made a PR which I named "This fixes Nothing". Couldn't stop myself haha

Awesome video! Gradle always felt scary and complicated, this definitely broke the ice for me. Thanks!

Awesome stuff, learn lots of new things.

Quality content!! 👌

Good vid bud

I thought that was because of the way Java allocates collection objects in memory, which is quite random if I am not mistaken. Without benchmarking, I believe you would be getting the same results if you try that in Java. Never tried it though, just a guess. In c++ I believe you won't have such problem, because of the different nature of arrays.

Also look at the bytecode

You are doing this youtube thing very nicely Sebastian 😆, catchy titles and good videos, good job mate

i liked how you addressed all the common questions one has when working with compose and viewmodels. you've got yourself a new subscriber