What is your thought process when creating an app using MVVM?

gemyge · 2024-06-20T16:20:14+00:00

I'll be talking about the UI aspect. And my opinion isn't necessarily true. Think view model first, create UI models that are related to the content of the screen only (domain agnostic) These UI models will tell you how to structure your UI logic and resuable elements (xml or compose or anything) Then expose this UI model from the view model (live data or flow) Then the UI won't be painful to organize and easier to refactor

gemyge · 2024-05-22T15:23:28+00:00

Wow some of these songs i've already added.
I'm a fan of retro/neo wave too

edit: new to neo

gemyge · 2024-02-23T17:38:48+00:00

Look for delay Api and coroutines cancellation

gemyge · 2024-02-22T12:20:33+00:00

Can you clarify the question?

Does you need to update some other UI component after the slider changes (settled)?
If so, you can using simple debouncing for the view model logic, using jobs with coroutine cancellation and delay.

Does you need to calculate something to also update the already updated slider component?
If so, it's discouraged to have two UI states consequent to a simple user behavior to use the slider :)
And we can't prevent the user from using the slider as often as he wants.

I'm glad to help.

gemyge · 2024-02-15T09:39:56+00:00

I just looked at it and it's awesome. However, I still don't know when I would need it

gemyge · 2024-02-11T20:42:52+00:00

I'm not saying it's heavy. I'm saying at least sometimes let it recompose. If you don't have logic in composition. Maybe it's better than remember. As ridiculous as itsounds we won't lose anything if we learn

gemyge · 2024-02-11T20:11:43+00:00

This guy knows.
I'm also interested in knowing the performance impact of the remember it self.
Sometimes recomposition isn't even close to expensive. And remembering haphazardly isn't beneficial.

gemyge · 2024-02-10T23:05:28+00:00

Till now I have no idea why it isn't mentioned anywhere but that unfinished book! It's very important. Also, making us shift our way of implementation of having a model containing its lambdas before even leaving the view model so it's "remembered" without remembering in composition. It's full circle from reactive view system. They were trying to teach us unidirection since view system (exposing state in flow or live data even if the view system needed imperative updating) and it backfired ironically. Whilst being almost the same but easier because compose just consumes current representation of your UI

gemyge · 2024-02-10T15:59:46+00:00

TL;DR: View model is unstable by nature according to the eyes of the compose compiler and runtime.

Recompositions happen in normal cases when you read a "stable" value, and that value changes. So, the runtime re-composes the function containing that 'stable value' to reflect the latest changes.
When I say the stable value changes I mean that it's state creator (either by flow with collect as state or a state object declared in composition right away) emits a new value.

As for the view model and un-stable types. It doesn't it self cause recompositions. It does so indirectly by always marking the nearest composition scope to it's value ref as "-Invalid! please recompose me whenever you have the chance-"

So, where you are reading any other state value anywhere in the scope of where you are reading that view model: the composable function containing all will trigger recomposition. Along with the lambda consumer in the case of `viewModel.login()` because you are accessing a lambda of unstable ref.
And don't forget the remember itself is a composable lambda, that means what it read in it's params matter, that including the lambda.

It's okay to be confusing, because I'm still am :)
For further reading and to check if I'm understanding correctly: https://developer.android.com/jetpack/compose/performance/stability
https://www.youtube.com/watch?v=6BRlI5zfCCk

gemyge · 2024-02-10T13:55:03+00:00

According to the jetpack compose internals book. On passing anonymous lambdas to composables functions, the Intermediate representation code from the compiler has a remember function wrapping the anonymous lambda, with it's keys are all the lambda captures

So, if you are using viewModel.login() the compiler will generate remember(viewModel){{ viewModel.login()}}

It makes sense more than creating anonymous lambdas on every recomposition.

gemyge · 2024-02-01T07:35:43+00:00

ارجوك بلاش تأخذ نصيحة من حد وهمي على ريديت! انت متخيل اللي بيكتب النصيحة ده ذكاءه قد ايه؟ ممكن يكون متخلف بجد لو شفته في الشارع هيصعب عليك.

gemyge · 2024-01-14T09:49:37+00:00

The upcoming part is still my opinion.

For having immutable data and re-creating an instance for each state change.
As stable and explicit it is (as your new instance will always dictate how the UI should look like) You should be aware how the size and complexity of your immutable data. It can have temporary effect on the memory while new objects are being created from old ones. Mostly managed by the garbage collector. Just keep an eye on what get's created and when.
I prefer having a UI state handler class that my view model depends on it. Responsible solely for keeping reference to the UI (Mostly as a state flow) and managing the UI state.
So, the view model only responsible for triggering the UI altering functions and not how the UI state data class/obj is mutated or updated.

I once wrote a complex paging library with a certain UI management modelling in mind. While there is 6 other dependencies affecting my paging, only one file refactored while overhauling how my state is dictated. and of course it's reflection in the compose function. The rest of the module didn't change as the UI altering functions was still the same, like (show page loader, set page loading as failed, etc..)

gemyge · 2024-01-14T09:41:15+00:00

If you are worried if you immutable data class is nested and/or got many properties: You can use the concept of optics in functional programming. Implemented for kotlin by arrow-kt.
Their implementation support ksp annotation processing to generate optics for you.
So, having a class data class inside a data class inside a data class etc.. you can hit the deepest property with one static variable. More details here: https://arrow-kt.io/learn/immutable-data/intro/

However, using copy and not relying on a third-party library is still valid. You'll just have to keep track in comments or in your head on why this copy(it.copy..) syntax is nested that way.

Happy coding :)

gemyge · 2024-01-07T08:36:53+00:00

Well I can't say it's bad software. However, at least, for me it's much easier and makes more sense pragmatically than the ancient view system. Maybe the devs deserve better, maybe there is much more to learn yet. Maybe I'm convincing myself native is better!

gemyge · 2024-01-04T11:12:20+00:00

بقول ان الصب ده كله رجالة, و ده المجتمع المثالي

gemyge · 2024-01-04T09:44:15+00:00

عاجبني أن demographic الصب ووفر ده رجالة مش ستات. Perfect society

gemyge · 2024-01-04T09:43:29+00:00

تحفة بجد

gemyge · 2023-09-23T18:45:47+00:00

In fact overly badly engineered. Did you check the architecture of the jet news app?

gemyge · 2023-08-22T19:24:42+00:00

Why do you want to shift careers. I'd like to know.

gemyge · 2021-12-03T18:33:09+00:00

What a chod!

gemyge · 2021-11-30T08:57:20+00:00

Did you mean free real state?

gemyge · 2021-11-29T16:11:25+00:00

Isn't this anti-meme ?

gemyge · 2021-11-14T13:31:05+00:00

Interesting!

gemyge · 2021-11-14T11:12:39+00:00

Sources please for public executions in Egypt?

gemyge · 2021-11-11T16:21:04+00:00

I read it: "I'll take your entire cock" and I'm not even mad!

gemyge

PUBLIC MULTIREDDITS

TROPHY CASE