:point_right: Hello fellow Devs I finally had a ch...

# android

[igor.wojda]

👉 Hello fellow Devs
I finally had a chance to upgrade my most popular Android open-source project

This is still the most complete Android sample you can find around (Kotlin, Coroutines, Jetpack Compose, Jetpack Navigation, Material Design 3, Clean Architecture, Tests, Feature Modules, MVVM, Static Analysis, CI Config, Gradle Convention Plugins, and more).

If you spot something off or areas for improvement, please let me know!
https://github.com/igorwojda/android-showcase

[Guillaume B]

Nice repo! few things tho:
• use cases should never be single (use factory instead)
• the way modules are done doesn't really makes sense. There's one module per feature, but it would be better to have within a feature a module per layer (if tomorrow a new screen wants to access some album data, it'll be able to use the related uses cases via the dep featuresalbumdomain. Right now it will have the dep to features:album and will have access to everything, not really optimized in terms of separation of concerns and build velocity)
• in ui models, always prefer using immutable list (like PersistentList)
• maybe a module for networking could be interesting to isolate network related stuff
• maybe a navigation one also, and a persistent one for room

[Guillaume B]

Since you're using Room as source of truth, you could also make your screens reactive and observe a flow, like that any changes in the DB will be reflected on the screen automatically

[Guillaume B]

(Check this repo https://github.com/Beb3r/masterdetailshowcase)

[Chrimaeon]

Next time maybe consider posting this in #C0BJ0GTE2 . That’s where usually interesting links and projects should be posted.

[Hieu Vu]

Hi may I know more about build-logic package @igor.wojda? What is it for and in which case we need this?

[gildor]

> in ui models, always prefer using immutable list (like PersistentList)
Not really so necessary, just marking List as stable on compose compiler options is enough.

[Guillaume B]

@gildor no it doesn't, that's why such lib (kotlin.collections.*) exists

[Guillaume B]

you might want to read the doc again

[Guillaume B]

But you can mention strong skipping mode, that does help with recomposition and lists ("marking list as stable" doesn't change a thing)

[gildor]

No, it's not why this lib exists
It exists to experiment with truly immutable collections and potentially provide efficient collection modifications

Compose marking them as immutable is not the reason to existence

[gildor]

Thank you, I read all those docs before, not necessary to be so patronizing 🙂

I'm not talking about strong skipping mode,. I'm talking about stability configuration file
https://developer.android.com/develop/ui/compose/performance/stability/fix#configuration-file

I mean, fine, you can use PersistentList of course (or probably ImmutableList, not persistent, if you do not want to copy it too much)

My point that on practice mark List as stable is enough on practice.

[Guillaume B]

Was I ? Sorry man didnt mean to, no hard feelings.
I don't really get your point. What matters is user experience.
Marking a class with @Immutable or @Stable that includes a list as parameter will give you bad performance because of recomposition.
Using PersistentList (ImmutableList is deprecated, they do the same) avoids that.
So in practice, you always want to annotate your ui classes with @Immutable, and use PersistentList whenever they include a list.
There's absolutely no interest/gain advising people to do otherwise🤷‍♂️

[gildor]

It doesn't give you bad performance if you marked that normal List is Stable by default on level of compose compiler config

[Guillaume B]

by wrapping it you mean ?

[Guillaume B]

ah ok

[Guillaume B]

so you mean editing the config file ?

[gildor]

Yes, as doc which I shared explains, it's possible to mark any class as stable, after this it's up to you if it true or not
Yes, List coule be MutableList, but on practice on usual code it's not a big problem, because List can be used totally Read only and doesn't break contract

[Guillaume B]

Aaaah pfoulouh ok sorry my bad totally misread that😅 yes editing the file manually will do the same indeed!! But seriously who does that?

[Guillaume B]

I mean you do it @gildor on your side?

[Guillaume B]

Must be a pain in the ass to maintain no?

[gildor]

We do, and very happy that we get rid of error prone and unnecessary kotlinx.immutable

What kind of maintainance do you mean? It's 1 line of config kotlin.collections.*
The only issue if someone uses MutableList and modifies it, but it's very easy to spot such cases

[igor.wojda]

@Guillaume B thx for the feedback 🙏
@Hieu Vu build-logic module is used for storing Gradle conventions plugins (allows to encapsulate and share build logic for certain module types e.g. feature modules)

[Guillaume B]

Yeah the MutableList is really edge case. Editing a file located somewhere else (even once) while you're working on the UI class you just created/modified seems more error prone to me, but I guess it's just a matter of habit

[gildor]

It's 1 file per project
Also, isn't we discussing project templates?
So it can be done on the project template level in gradle configs

[Guillaume B]

yeah definitely!!