Using `LocalSaveableStateRegistry.current.register...

# compose

[Zoltan Demant]

Using LocalSaveableStateRegistry.current.registerProvider(..) eventually leads to TransactionTooLargeException. Given that rememberSaveable uses it under the hood, is there another way to store state in compose that is immune to this crash? Im looking to store a `Map<String, Parcelable>`that represents the entire apps navigation state.

[Ian Lake]

Nope, keeping only the minimal amount of saved state has always been the case and will always be the case.

[Ian Lake]

If your saved state is anywhere near that limit of data even with a 100+ screens on your back stack, you are already doing so, so much wrong already

[ste]

I had a similar problem. Although I could solve it using this ⚠️, you should stick with rememberSaveable and save only the bare minimum (text fields, navigation routes/arguments...). Querying the database a second time (after a configuration change occurs) is perfectly fine

[Zoltan Demant]

🤔 I am only storing the absolute bare minimum. That is, string identifiers and such, no actual data. Perhaps the issue is really elsewhere on my end?

[ste]

From my experience, you get a TransactionTooLargeException when you try to save a 800kB/1MB ish bundle (definitely a lot more than a bunch of strings)

[ste]

You should inspect the content of that bundle (https://stackoverflow.com/questions/47633002/how-to-examine-the-size-of-the-bundle-object-in-onsaveinstancestate)

[Zoltan Demant]

800 kb sounds like a lot of headroom! This crash is pretty rare, so I don't know how I'd recreate it, and of course no access to the bundle. I'll go through the entire hierarchy of screens when I get back home! Hopefully I'll get some insight from that too, I'll keep you posted!

[Afzal Najam]

Is it based on user text input by any chance?

[Zoltan Demant]

Im storing a searchQuery in the bundle, but thats it for user input. The searchQuery is often short, inputted into a singleLine field; and even if I copy-paste a ton of text into it, I cant reproduce this crash. All other cases are just enums, booleans and UUID strings.

Im actually surprised by how much data can be stored in the bundle before it crashes. I have a very hard time imagining that someone would navigate around in the app for so long, it would literary take years to accumulate that amount 😅 Any other ideas?

Also, interesting tidbit: Can't represent a size of 214748364 in Constraints is thrown when theres "too much" text input. Might be worth filing a bug report about this? I have seen this crash in the past, never figured it out until now.

[ste]

Perhaps this one? https://issuetracker.google.com/issues/240837359

[Zoltan Demant]

I do use a ton of lists, but their fix is probably also present in the release that crashed (using compose 1.4.0-alpha02).

[shikasd]

For constraints crash, definitely worth filing a bug

[Zoltan Demant]

https://issuetracker.google.com/issues/259385796 🛠️

[Zoltan Demant]

When in Rome... Ran into some other weirdness when investigating this.

https://issuetracker.google.com/issues/259275119

[Zoltan Demant]

I found a group of people experiencing the same issue! There are several duplicate reports of it and it looks like the root cause was fixed a while back, but crashes are still happening on devices running Android 9.

If you have the time and/or curiosity, feel free to check it out. This is affecting about 500 unique users every week for my application at this point, and given all the information thats available I still have no idea how I might go about solving it before an official fix rolls out!

- https://issuetracker.google.com/issues/242589959
- https://issuetracker.google.com/issues/212982463
- https://issuetracker.google.com/issues/260322832