Migrate in-app gallery to Jetpack Compose

[MHShetty]

No description provided.

[muhomorr]

What's the purpose of new (de)serializers for CapturedItem and Uri? They can be (de)serialized already since they implement the Parcelable interface.

[MHShetty]

Both the Kotlin Serializable and the new Parcelable implementations are needed for using type-safe navigation/custom objects in nav types. Initially, we were passing CapturedItem and List of CapturedItem (s) to specific routes/screen as parameters, but we later switched to having an activity-level repository to manage the captured items which is a much better and cleaner approach.

The only serializer and parcelable implementation we are currently using in the app is VideoUriSerializer class and the Parcelable implemented within the VideoUri class itself. I have kept the other classes just in case if we need them later within the camera app or the gallery app. Type-safe navigation isn't very well documented unfortunately, a lot of the limitations it has isn't very clearly mentioned, so having the other serializable and nav type classes as reference would be helpful for future use

[muhomorr]

What I'm saying is that Kotlin (de)serializers can reuse the implementation of Parcelable (de)serializers instead of duplicating them.

[MHShetty]

I'm sorry but am really unable to get you, serializer/serialization and parcelable are two different concepts/techniques. Is there some library to encode/decode a parcelable to/from a string or work directly with parcelables?

[muhomorr]

Parcelization is a form of serialization. Any Parcelable object can be transformed into a sequence of bytes by writing it to a Parcel and then calling Parcel#marshall().

[muhomorr]

A better solution in this case would probably be to not use route objects at all, since they don't work well with Parcelables. There's an option to pass route arguments as a Bundle instead. Bundle supports Parcelables directly.

[MHShetty]

Route objects help us to do type-safe navigation by ensuring the right parameters are called (with respect to their type, order and in avoiding null check/assertions), and also improving the code readability while performing navigate calls apart from the compile-time checks it provides. Since we have already written the code for the same, I feel it's better to go ahead with the standard type-safe navigation approach