Hi everyone, small question about your practices, let’s say I have a list of restaurants, and then I...

# android-architecture

[Antoine Gagnon]

Hi everyone, small question about your practices, let’s say I have a list of restaurants, and then I want to get a detail view when I click one of those.
What would you pass as an argument to the detail fragment?
1. The restaurant’s ID and then retrieve the proper data via the ViewModel
2. The restaurant’s detail view data as a serializable
I’m currently doing the first one, but I’d like your opinion on this.

[Javier]

it depends of how you have your current structure

[Javier]

second is easier, but I like first more. But for first you need to have, at least, a in memory caching.

[Antoine Gagnon]

You mean so that it doesn’t retrieve the proper data again when recreating the fragment?

[Javier]

first allow you to use deeplinks too, and compose, even having support for objects, it is oriented to how web routing works

[Javier]

if you go to the detail fragment and you have only the id, you need to retrieve the info from some place, if you don't want to do a network request, you need to cache the previous list in memory or in a database

[Antoine Gagnon]

Oh yeah, in this example we can assume I have a local DB or something similar

[FunkyMuse]

The id and you'll load it from your repository

You won't be passing the whole object, serializable is slow and the parcelable implementation has size limit

[Marko Novakovic]

just don't over engineer it. if Restaurant object is not too big for Parcelable, less than 1MB, and it contains everything you need to display you can pass object directly

[Alex Prince]

I'd go with the ID as well. The other thing to keep in mind is how big your app is, and how deep your backstack may get. If / when you get tombstoned, that limit is cumulative, not per fragment. Speaking from experience, it'll bite you.

[OG]

Pretty much echoing what everyone else is saying.. but I wanted to point some additional things out:

• Point 2 is not scalable. If further metadata is added to the model then this could spill over the 1MB limit and cause you a big pain when refactoring to fix this issue later on.
• With Point 1, for the best user experience, it will require a bit more work up front but worth it.. where you would expose a single load API via your repository/manager pattern, which fetches the item from cache/local DB, and probably kicks off some refresh/download of the item from your backend. Unless this data is client side only which makes it even simpler...
• As someone mentioned before, point 1 provides easier integration/support with deep links, plus allows you to pass in additional configurations that may be needed later on without risk of spoiling over the argument size limit
• Last point I can think of (1:30AM and I'm having trouble falling asleep haha)... but passing around in-memory objects like this can become an easy source of bugs later on when maintaining + adding new features. An example is where you pass in an in-memory object, and then based on user action or something similar, the data source should get updated. You would then need to properly manage updating the in-memory object in addition to saving the changes to your local DB or backend etc. Whereas providing a more "single source of truth" and always passing ID and fetching the model via your repo, allows you to more easily manage updates from both directions up to your UI state, along with the case where the view possibly gets destroyed than recreated.