There's been some conversation here about how your...

# compose

[Vinay Gaba]

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.

[Adam Powell]

Seems like some content for #android that wouldn't get immediately tagged as 😶 😛

[Adam Powell]

More seriously though, no, we haven't published strong recommendations about this yet

[Adam Powell]

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"

[Adam Powell]

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

[Adam Powell]

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

[Adam Powell]

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

[Adam Powell]

(it's considered a runtime resource overlay change, not a configuration change)

[Adam Powell]

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

[Adam Powell]

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

[Adam Powell]

The general space of state scoping still draws a lot of questions as is

[Vinay Gaba]

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.

[Adam Powell]

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

[Alex Vanyo]

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.