I'm at a weird crossroads where i'm building an ap...

# compose-destinations

[Suhaib Kazi]

I'm at a weird crossroads where i'm building an application where i have to fill in a lot of data across the screens in a flow and at the end of it, either save to DB or hit an API endpoint based on internet availability.

Current approach, use the same viewmodel instance across the destinations and i basically have a UIState to hold the data i fill in, using UIEvents

Pretty vanilla, only problem? It's getting crowded in the viewmodel. And also everything is getting tightly coupled to that flow.

What would you guys suggest. I was thinking DataStore with ProtoBufs or DataStore with kotlinx.serialization data class. Both type safe and thread safe.
And i would essentially have different viewmodels for each screen and keep saving data to either DataStore solutions.

(idk if its appropriate to ask this here 💀👀)

[Stylianos Gakis]

If the data you're carrying across the flow is in fact getting crazy, I wouldn't hate storing it just as-is in androidx.Datastore using kotlinx serialization to turn it to and from a String. And for your destinations just keep an ID which will point to that datastore entry if you need a way to store more than one at the same time.
I've done this exact same thing as well in one place and I was quite happy with how it turned out. It fit my requirements quite well.

[Stylianos Gakis]

You could also just always keep it in your DB which you would end up storing it to anyway. Potentially with a clear separation of in-progress entries and the fully completed ones that you'd store as you say already there if you do not hit the backend instead.

[Suhaib Kazi]

Im not carrying data across flows, but im storing all the data entered in a screen and saving it in the UIState in the viewmodel, Which is common for all the screens in that flow.

[Suhaib Kazi]

I kinda wanted to implement a draft like functionality with the provision for just one draft possible at a time. And override it when trying to start from scratch.

[Stylianos Gakis]

Yeah what I said should still apply. What are you concerned about with storing it in a persistent storage while it's still being edited?

[Suhaib Kazi]

I think that removes the need to have an ID attached to it

[Stylianos Gakis]

Yep if you can't have two of them at the same time you definitely don't.
That's why I said:

if you need a way to store more than one at the same time.

[Suhaib Kazi]

My concern was primarily attached to whats a better approach in dealing with data that is collected from multiple screens and then finally hitting the endpoint source

[Suhaib Kazi]

The reason why approach with DB was less preferred is that i wanted an easy to store and access mechanism without the added overhead of schemas and all to achieve this functionality.

[Stylianos Gakis]

You could always just store a String in the DB as well and do the same with kotlinx serialization 😅
Datastore or DB is just a question of what is more convenient for your existing project 😄

[Suhaib Kazi]

When i was diving into DataStore i came across datastore protobuf.

[Stylianos Gakis]

The persistent storage solution sounds pretty good to me though in any case. You also are safe in scenarios of process death where you will come back to any point in the flow and you'll still have the data persist, without risking going over the memory limit if you had it all in your destination instead.

[Suhaib Kazi]

Agreed. String is a String.
What approach would you have preferred between DB vs DataStore Prefs vs Protobuf.

[Stylianos Gakis]

Depends on if you've already got a DB setup, but wouldn't it be just as much overhead to do the protobuf approach?
I've never done that myself tbh. Either go all in with proper DB support (room or whatever) or use the Datastore approach and use kotlinx.serialization to make it "type-safe".
As long as the stuff you store in there does not need to be backwards compatible with old versions and so on and you add migrations and whatever that solution tbh is just perfectly fine and quite quick.
Since it sounds like you're just storing drafts of something, do you know if you will want to always allow people to close the app, go install a new version, come back into the app and then be able to resume on that draft? If yes you might wanna be careful with how you do migrations, and perhaps a DB schema is even a better idea in order to make sure you do not break the compatibility by accident.

[Suhaib Kazi]

Yes, protobuf and DB both have similar setup and overhead.
The only differentiating factor looks like the future scope and migration related, rest pretty vanilla as kotlinx.serialization provides a pretty type safe way of converting back and forth

[Suhaib Kazi]

Thanks a lot @Stylianos Gakis
Really appreciate your replies always. ✅