New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to Material 3 (M3) #691
Comments
These themes reflect our current color scheme in M3: material-theme-classic.zip |
We should also follow the recommended App Architecture more when refactoring. Like having more clear and separated UI state holders, using Compose state in ViewModels etc. |
I've read a bit more into the color scheming of M3 and it seems unless we want to define everything (!) on our own we can't use our brand color green (with orange in addition) anymore. I've adapted our colors a bit and here is an updated version for now that looks more appealing: material-theme-moreappealing.zip It now looks like this: |
Well, this definetly makes for a better integration with jtxBoard. They look the same now 🥂 |
but we're still green, while jtx is yellow :P wooow |
This comment was marked as resolved.
This comment was marked as resolved.
Updated Color Schemes: material-theme-colors-updated.zip |
We plan to make a public beta soon, and then release maybe in 1 week or so – if everything goes well |
Time to have fun
https://developer.android.com/develop/ui/compose/designsystems/material2-material3#phased-approach
This is a meta-issue and can be closed when everything is M3. Please don't add things here yourself.
When rewriting things to M3, please apply the new App Architecture as discussed as well as it's possible without rewriting core features (for instance, I wouldn't touch data layer things too much during the rewrite):
SomeScreen.kt
with the@Composable SomeScreen()
(only UI, no or little UI logic)SomeScreenModel.kt
with the ViewModel for SomeScreen (UI logic and interface to data layers, if required); usually contains a UI state data class + methods to calculate state for the UI + methods for events that come from the UISomeActivity.kt
with the Activity (if the screen is an Activity) – should only contain the contractUiState
classes as described in App Architecture. One explicit UI state data class +mutableStateOf(UiState()) private set
in the model is preferred, but you may have to use Flows or other methods like multiple states if it fits better.Tasks:
The text was updated successfully, but these errors were encountered: