Hi everyone! We published a couple of documentatio...
# compose
a
Hi everyone! We published a couple of documentation articles this week: • A summarized overview of Compose approach to Navigation as applied to Compose Multiplatform. This isn't meant to replace Jetpack's navigation guidance, but provide some context and terminology so that you don't have to go to Android docs to understand the navigation talk. • A deep links guide (as introduced in 1.8.0 beta). • A page on RTL support (also a preview feature). It would be great to hear from you all on what's missing, or confusing, or could be better illustrated, so that we could hopefully improve the docs before the stable release.
👍 1
p
I have a question related to complex arguments in navigation. I know that we are supposed to pass only the ID of an item and then in the detail destination retrieve the id in the viewmodel and get the full object from the repository. But what happens if the complex object is not in a local repository? what if it's an object that you have retrieved from retrofit and you don't need to store it on a room database? just painting it in a detail? how can we pass this complex object as an argument?
m
These documentation articles were REALLY helpful. It explains the basic concept of compose navigation and links to a sample. What I'd really appreciate though would be a simple step-by-step tutorial (similar to a google Codelabs) to really understand the material.
kodee loving 1
k
@Pablo the repository can be in memory.
p
@Konstantin Tskhovrebov please let me understand if this is the correct path: for passing a single "person" object with a few arguments, I need to create a MemoryPersonRepository, and a MemoryPersonDataSource, both with insert and get functions, with a List<Person> in te datasource, and then, inject with Koin the repository in both the first screen that retrieves the person from retrofit (and save it in the new repo), and the second screen that receives only the ID of the person (and recover it from the new repo) in the init block of his viewmodel?
k
it depends on your achitecture and I just say that repository can be in memory. this is wrong channel 🙂 better ask in #C5GB1NDGE or google
p
thank you konstantin, my architecture uses that pattern for repos, as google guides recommended. But on the other hand, and related to arguments... as far as I know, compose navigation doesn't let you to pass the full complex object as an argument, because "This approach helps prevent data loss during configuration changes and any inconsistencies when the referenced object is updated or mutated". Then, it forces you to pass just and ID, but... if I need to use a inmemory repository, I face exactly the same problem... and I don't see the benefits that avoid you to face "data loss during configuration changes and any inconsistencies when the referenced object is updated or mutated", because the object is in an online repo and not in a local database that can be mutated etc...
so If the problem is the same when the data is not available in a local database (for example, when working with retrofit online data that must be displayed to the user but not stored in any database), why force us to add more complexity on the app if the issues we will face are exactly the same but with more unnecesary added complexity? why not simple let us pass the complex parameter?
maybe @Aleksey Zamulla can help with this
I mean that probably will be better to let us decide if we want to pass the object, instead of forcing us to add complexity that can be unnecesary in some circunstances. After a huge research, I finally ended removing parcelable solution I tryed for pass the full parameter, and I found that almost everyone is parsing the complex object into a json string and passing it as an argument, and then, transforming it again in a data class. That is very ugly, but adding a repo and a datasource for this simple thing seems to be overprogramming
a
These is general advice which is not meant to be restrictive, more gently guiding people away from stumbling into a bad pattern. It's not that Navigation doesn't let you pass complex arguments — you can do that; we just warn you that generally it's inefficient in the long run. It sounds like you put a lot of thought into pros and cons for your setup, which puts you on a different level 🙂 If you're not sure that you've found the best solution for using Navigation here, I would agree with Konstantin — an Android-specific channel would be of more help here.
What I'd really appreciate though would be a simple step-by-step tutorial (similar to a google Codelabs) to really understand the material.
I agree, a step-by-step implementation example would be great; we aim to cover the basics first, but more practical content is also in the backlog. Thank you for reading!
🎉 1