Can we avoid using xml files for theming like colo...

# compose

[Lilly]

Can we avoid using xml files for theming like colors.xml, theme.xml in the near future? Currently theming is a mix of xml and MaterialTheme composable.
Another question would be if we can set the color of the system bar via compose or is it only via theme.xml possible?

[Adam Powell]

You can take it down to just the one theme file for the starting window if you want. Check out some of the insets work @cb has done in his accompanist library for how to style the system bars and such

[cb]

Accompanist doesn't currently have anything in there explicitly for the status/nav bars. The accompanist-insets library helps you handle WindowInsets so you can draw behind them.

@nickbutcher wrote this utility, which allows easier setting of the colors:
https://gist.github.com/chrisbanes/ab31bf7b67b77948157687af010f0667

[cb]

We have spoken about shipping this in Accompanist, but haven't gotten around to it yet

[Adam Powell]

I always just take over the drawing of bar backgrounds via insets and do my own thing 🤷‍♂️

[Lilly]

@cb Interesting utility, thanks for sharing. @Adam Powell

You can take it down to just the one theme file for the starting window if you want

Wouldn't I need two, one default theme.xml and one theme.xml with night modifier for dark mode? Otherwise like u said

so you could imagine why you might want to make that light/dark aware; you wouldn't want someone using the app in dark mode to get a sudden bright flash on their screen when your app first loads.

So we can't expect that xml system is dropped anytime (so we don't need to have theme.xml)?

[Adam Powell]

while we might reopen some build-time dsl explorations we did a couple years back, so long as compose supports old platform versions, the starting window configuration has to be something that exists in the resources of an apk that the system can load and use before loading the app's actual code

[Adam Powell]

you can disable the starting window entirely (again, via a theme) and rely only on what you do in compose dynamically at runtime, but I think you'll find that the perceived startup latency of your app is much higher when you do. This little smoke and mirrors trick is quite effective. 🙂

[Adam Powell]

https://cyrilmottier.com/2013/01/23/android-app-launching-made-gorgeous/ goes into a bit more of the mechanism at play. Despite how old the post is, the info there is still relevant

[Adam Powell]

specifically, you can try out a fully dynamic way in your app by setting android:windowDisablePreview attribute to true in the theme

[Adam Powell]

even though we've consistently seen android runtime optimizations and devices getting faster, apps have also gotten more sophisticated, perform a lot of initialization on startup that ends up blocking the critical path to first activity draw

[Adam Powell]

often you're still looking at 100-200ms on mid to high end devices for a cold start of an otherwise "empty" app

[Lilly]

Your extensive explanations are great! Thanks a lot ❤️

[cb]

I always just take over the drawing of bar backgrounds via insets and do my own thing 🤷‍♂️

Same, but I feel like we might be a bit on our own in thinking that’s the easiest way 😂

[Cicero]

Just double checking this conversation, is there any way, even a hacky way or still nothing on sight?

[Cicero]

So, whoever ends up stumbling on this place, you can still chop off most of your theme.xml anyway and you might know now that you can configure most of your app without it but when it comes down to system configuration (status bar and sorts of) you might feel limited by the offered APIs.

Fear no more: https://google.github.io/accompanist/systemuicontroller/