Is this still pretty the goto way to implement dar...

# compose-android

[Colton Idle]

Is this still pretty the goto way to implement dark/light colors with a custom design system that doesn't match up with material theme?

https://github.com/android/compose-samples/blob/main/Jetsnack/app/src/main/java/com/example/jetsnack/ui/theme/Theme.kt

[Joel Denke]

Quite messy setup, but the principle yes I would say thats the way to go. Would check more in material 3 code, like https://androidx.tech/artifacts/compose.material3/material3/1.0.1-source/androidx/compose/material3/MaterialTheme.kt.html
https://androidx.tech/artifacts/compose.material3/material3/1.0.1-source/androidx/compose/material3/ColorScheme.kt.html

[Colton Idle]

Not using m3 unfortunately. not sure if that actually makes a different though.

[Joel Denke]

No I dont use M3 either but as compose structure in code nice check imo. Names of tokens and such can be any names. I think its good having color tokens collected in one interface and hide implementation within an aggregated Theme class. Logic how to switch dark and light can be hidden and actual hex colors inside system.

[itnoles]

is it me that M3 themes are getting more complicated than Flutter one?

[Chris Sinco [G]]

Yes Jetsnack is still a good example, even if it’s based on Material2, since with both Material2 and Material3 theming, they are constructed with the same foundation APIs, just different/more token names due to design system changes from Material.

[Chris Sinco [G]]

And I would agree that looking at how Material3 ColorScheme is implemented can also be helpful if your custom system is just as complex. Though again, same foundational APIs were used in Material2.

[Chris Sinco [G]]

is it me that M3 themes are getting more complicated than Flutter one?

I don’t think it’s really a Flutter vs Compose thing here - Material3 as a system is more complex than Material2, so I expect more complexity with using all Material3 libraries, compared to Material2.

[Colton Idle]

Cool. I'll implement our stuff based on @Joel Denke reccomendation. we currently do isSystemDark() in like all of our files

[Colton Idle]

lmaoo. it hurts

[Chris Sinco [G]]

isSystemDark() should ideally be only used in one place, that is where the Theme Composable is declared so you can swap out colors as needed, which will recompose the hierarchy that the Theme wraps

[Chris Sinco [G]]

The project templates demonstrate that with the app theme generated

[Ben Trengrove [G]]

We have docs on this as well. https://developer.android.com/jetpack/compose/designsystems/custom

[Colton Idle]

@Chris Sinco [G] yeah. ive done that in other projects. i joined a new project though that uses materialTheme for like 50% of their colors. so basically half of the colors in the app work with light/dark.

But then the rest of the colors are just grabbed by AppColor.Something and so we just completely lose out on night/dark.

So I wanna be able to move us away from using MaterialTheme since we dont really use it.

[Colton Idle]

thanks ben for the docs. ACE

[Chris Sinco [G]]

@Colton Idle gotcha that makes sense. I have something similar in my Pokemon sample wherein I use a base Material3 AppTheme (generated from Theme Builder), and then have specific themes for each Pokemon type, both used in the same screens depending on the component to theme. All themes support light and dark, with the type themes extending Material theming, which is an approach I took from the docs link above. Here’s the implementation: https://github.com/c5inco/compose-pokedexer/blob/main/app/src/main/java/des/c5inco/pokedexer/ui/theme/AppTheme.kt

[Chris Sinco [G]]

I originally only had a light theme, so I was also just referencing colors directly for the components styled by type. But when adding a dark theme, it was much cleaner to refactor things into themes. At some point the types theme was fully custom, not extending Material, but I actually found I didn’t need that complexity because the Material color tokens were semantically what I needed, and it felt like overkill to create a fully custom, non-Material theme just to have my own token names 😅 especially because I wasn’t working with an established custom design system. But the great part is either way, it’s all reusing the same foundation APIs

[Florian N'Gbala]

Hi 👋
I don’t know if you still need help but we write an article to help your create a custom them with Compose 😉
https://lunabee-studio-dev.medium.com/create-a-custom-theme-with-jetpack-compose-3720fc18e01

[Colton Idle]

Thanks! Yes, I didn't work on it yet so that helps. Thanks @Florian N'Gbala

[Colton Idle]

Fun issue. My color system has 60 tokens (crazy... i know), but I get an issue now

Rejecting invocation, expected 52 argument registers, method signature has 53

I think data classes have a limit size. What do I do? lol