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

Vinay Gaba

06/16/2022, 8:38 PM
There's been some conversation here about how your Compose apps/features should handle config changes manually - https://kotlinlang.slack.com/archives/CJLTWPH7S/p1618760581089700?thread_ts=1618691113.058800&cid=CJLTWPH7S This makes sense to me and I've been lucky to follow these conversations from the early days. However, I'm not seeing this recommendation in the official docs to be able to share with my team. Is there any documentation available that I might've missed. If not, I'm sure this is on your radar but I want to flag it anyway.
a

Adam Powell

06/16/2022, 9:03 PM
Seems like some content for #android that wouldn't get immediately tagged as 😶 😛
😂 5
More seriously though, no, we haven't published strong recommendations about this yet
Part of it has to do with the larger story of state management recommendations; without some additional context the idea is likely to be interpreted as, "just
remember {}
anything you need and don't worry about the rest"
androidx
ViewModel
has a lot of guidance yet to write about as it relates to compose, and we have a number of ideas around a smaller, more deliberate
rememberRetained
companion to
rememberSaveable
💡 2
Even in a world with activity recreation out of the way, there are still reasons to retain data across composition recreation, such as with navigation frameworks and data held on other active back stack entries
Add to that Android S's dynamic color extraction from user info like the wallpaper was implemented in such a way that still causes activity recreation in some cases that can't be disabled, which is a bit unfortunate
(it's considered a runtime resource overlay change, not a configuration change)
Plus a lot of initial integrations into existing apps start small, at a finer granularity than the full activity, and the rest of the UI often still needs activity recreation to handle resource changes
In short, the list of things that you still need to think about is long enough that we'd like to work on this a bit more before publishing universal guidance
The general space of state scoping still draws a lot of questions as is
v

Vinay Gaba

06/16/2022, 9:19 PM
Thanks for the context. It does seem like we might need to take into account more things that I wasn't even aware of (like the Android S example you pointed out). My use case was for pure Compose activities and I was trying to nudge us in a direction where Compose handles these changes (as I remembered your original conversation around the subject). I still think that's the more Compose way of handling it but knowing some of these blindspots before we start using it might be a good idea.
a

Adam Powell

06/16/2022, 9:22 PM
Yeah I still stand behind it being a good idea, but it's not a silver bullet that lets you suddenly forget about data scoping beyond composition
👍 4
👍🏼 2
a

Alex Vanyo

06/17/2022, 7:44 PM
I think another good starting step down this direction, even before getting anywhere near changing
android:configChanges
or dealing with retained state, is to write UI without that built-in, implicit “oh, activity recreation will wipe away all of this and let me start this from scratch” Compose generally make that a lot easier to do, and therefore have more robust handling for components that can react to both app-generated changes and system-generated changes. Things like: “what if the window size changes?” “what if the font size changes?” “what if the locale changes?” might not be at the front of your mind when relying on activity recreation to handle them. Compose makes it a lot easier to observe and react to those changes, without relying on the system to recreate the world for you. And then you also get a more reusable component that can do the right thing when you’re resizing it yourself due to an animation or state update hiding or showing something somewhere else.
🙏🏼 1
19 Views