There s been some conversation here about how your Compose a

Question

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 amp 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 · Answer

Seems like some content for < C0B8M7BUY|android> that wouldn t get immediately tagged as not kotlin stuck out tongue

Adam Powell · Answer

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

Adam Powell · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

it s considered a runtime resource overlay change not a configuration change

Adam Powell · Answer

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 · Answer

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 · Answer

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

Vinay Gaba · Answer

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 · Answer

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 · Answer

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