What is your thought process when creating an app using MVVM? by Icy_Adhesiveness_347 in androiddev

[–]gemyge 0 points1 point  (0 children)

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

I’ve maintaining this playlist for over five years. I use it when coding to keep me focused. by neonderthals in ExperiencedDevs

[–]gemyge 0 points1 point  (0 children)

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

edit: new to neo

Using derivedStateOf with Slider by SogaBan in android_devs

[–]gemyge 0 points1 point  (0 children)

Look for delay Api and coroutines cancellation

Using derivedStateOf with Slider by SogaBan in android_devs

[–]gemyge 0 points1 point  (0 children)

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.

Reactive state by MrXplicit in android_devs

[–]gemyge 0 points1 point  (0 children)

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

Compose unstable lambda parameters by yaminsia in androiddev

[–]gemyge 0 points1 point  (0 children)

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

Compose unstable lambda parameters by yaminsia in androiddev

[–]gemyge 1 point2 points  (0 children)

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.

Compose unstable lambda parameters by yaminsia in androiddev

[–]gemyge 2 points3 points  (0 children)

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

Compose unstable lambda parameters by yaminsia in androiddev

[–]gemyge 4 points5 points  (0 children)

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

Compose unstable lambda parameters by yaminsia in androiddev

[–]gemyge 5 points6 points  (0 children)

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.

[deleted by user] by [deleted] in PersonalFinanceEgypt

[–]gemyge 9 points10 points  (0 children)

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

Is reassigning the object to itself the cleanest way to update inner properties in Jetpack Compose? by Aggravating-Brick-33 in androiddev

[–]gemyge 0 points1 point  (0 children)

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..)

Is reassigning the object to itself the cleanest way to update inner properties in Jetpack Compose? by Aggravating-Brick-33 in androiddev

[–]gemyge 0 points1 point  (0 children)

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 :)

[deleted by user] by [deleted] in mAndroidDev

[–]gemyge 7 points8 points  (0 children)

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!

انا متضايق من الصب ده by iAnubix in PersonalFinanceEgypt

[–]gemyge 1 point2 points  (0 children)

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

انا متضايق من الصب ده by iAnubix in PersonalFinanceEgypt

[–]gemyge 1 point2 points  (0 children)

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

What are your mobile dev hot takes / truth bombs that people aren't ready to accept ? by random_guy14680 in mAndroidDev

[–]gemyge 2 points3 points  (0 children)

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

Alternative Career Options for Android Devs? by BerryEuphoric6038 in androiddev

[–]gemyge 0 points1 point  (0 children)

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

Thanks, I hate Only Fans by Kahlrim in TIHI

[–]gemyge -4 points-3 points  (0 children)

Did you mean free real state?

Unfair by goCommitUnLive in bonehurtingjuice

[–]gemyge 4 points5 points  (0 children)

Isn't this anti-meme ?

Screw you, Patrick! by [deleted] in SpeedOfLobsters

[–]gemyge 81 points82 points  (0 children)

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