@gildor The solution could also be used for

onPermissionsRequestResult

, which has been a real pain for Android developers, given the count of permissions helper libraries

Yes, exactly!

@gildor I'm really interested in what you can do! Let me know if you need help for implementation or design

@louiscad Thanks!

@gildor For the vast majority of use cases serialization could be omitted as it is not likely to be needed, but the user could decide to go and play some heavy game after their phonecall and your state is then jammed if you didn't support serialization.

@pdvrieze This definitely deserves to be easier for apps to get their state saved properly regardless of what happens to the RAM

The reason I set about doing this. My use case is some really horrible horrible mess with an account manager that needs to be downloaded on demand. (So my students can just download chat messages without worrying about how to install the authenticator). It has many retries, callbacks etc. The coroutine use has made this actually comprehensible.

@pdvrieze yes, of course, it's especially important for start activity for result, but in case of permission request an activity is visible during request and cannot be killed by the system (at least I never saw such situation), so you can easily omit serialization. If user switched to a heavy application and activity destroyed and will be recreated without permission request I think it's not a big deal

i've used something similar for USB permission requesting: https://gist.github.com/bj0/cf32761740029b4caeef3289f4d914a6

@gildor You are right on the permissions request not being likely an issue (and the permission intent may in fact be a dialog which keeps the underlying activity active). As it does serialization anyway there is no reason not to use it (it uses regular android serialization so will not serialize until requested to do so).