https://kotlinlang.org logo
#compose
Title
# compose
l

Lilly

01/22/2021, 3:25 AM
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?
a

Adam Powell

01/22/2021, 4:35 AM
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
c

cb

01/22/2021, 6:36 PM
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
We have spoken about shipping this in Accompanist, but haven't gotten around to it yet
a

Adam Powell

01/22/2021, 6:56 PM
I always just take over the drawing of bar backgrounds via insets and do my own thing 🤷‍♂️
l

Lilly

01/22/2021, 8:10 PM
@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)?
a

Adam Powell

01/22/2021, 8:15 PM
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
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. 🙂
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
specifically, you can try out a fully dynamic way in your app by setting
android:windowDisablePreview
attribute to
true
in the theme
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
often you're still looking at 100-200ms on mid to high end devices for a cold start of an otherwise "empty" app
l

Lilly

01/22/2021, 8:45 PM
Your extensive explanations are great! Thanks a lot ❤️
🙏 1
c

cb

01/22/2021, 9:08 PM
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 😂
🤷‍♂️ 1
😆 2
c

Cicero

08/15/2021, 11:25 AM
Just double checking this conversation, is there any way, even a hacky way or still nothing on sight?
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/
2 Views