https://kotlinlang.org logo
Title
s

Stylianos Gakis

03/19/2023, 8:41 AM
I think watching

this talk

is a good start to see why you may want to give molecule a try.
d

Davide Giuseppe Farella

03/19/2023, 8:56 AM
Thank you for the source; I will surely take a look! But I noticed my question was unclear 🙂 I meant what are the benefits of using a Presenter, over keeping the logic in the ViewModel (updating the post)
e

efemoney

03/19/2023, 9:15 AM
Presenter, ViewModel, Controller, Coordinator, you call it whatever you want. They ALL (usually) refer to the same thing, heck you can call it
StuffThatManagesViewState
and that’ll be fine too, the idea remains the same: Some business layer object mediating between your data layer (where your data is stored/ retrieved/ transformed etc) and the view layer (what the application user sees & interacts with) and is responsible for encoding whatever business rules your application has
d

Davide Giuseppe Farella

03/19/2023, 9:17 AM
I asked because in the same ViewModel + Presenter has been used. The question was more oriented to: what are the benfits of moving the logic from ViewModel to Presenter, since I see the ViewModel is basically empty in the sample
e

efemoney

03/19/2023, 9:17 AM
Can you link the sample you’re talking about?
Okay I understand now. ViewModel in that sample is referring to the androidx ViewModel itself and is used to keep the presenters state across config changes. You can chose to not extract the logic out to a function like they did in the sample, just structure it however it makes sense for your project.
s

Stylianos Gakis

03/19/2023, 9:56 AM
I think this “interop” sample was so that people can see how to easily start using molecule in their existing architecture which uses ViewModels. And keep all the ViewModel-y things there, like how your DI hooks up dependencies to it, getting the SavedStateHandle and so on, but then defer the presentation logic to Molecule. So it isn’t a recommendation, but more of a sample to show how to easily try it out for people who are invested in a different style using AAC VMs.
d

Davide Giuseppe Farella

03/19/2023, 10:07 AM
Thank you! That was my doubt. I'm seeing a few small benefits under testing but still don't know if they're worth it
s

Stylianos Gakis

03/19/2023, 5:59 PM
Yeah that makes sense. It really depends what you are going away from too, and how complicated that was. Maybe what you got is already good enough. Maybe you’ve got a spaghetti that you might as well improve upon 😅 Please do reply back here again after you’ve played with it for a bit, we’re also in a situation where we’re using AAC VM without molecule, and I would love to hear from other people who may have also tried introducing it in their codebase and how it went for them.
e

efemoney

03/19/2023, 6:35 PM
Well for one, once you're past the initial mental model hurdle, writing business logic in compose is just so much easier. Being able to succinctly represent both streams of values and their dependencies on one other over time is 🔥.
s

Stylianos Gakis

03/19/2023, 6:36 PM
Yes, but the entire team needs to be on-board with compose and how it works. I personally really do enjoy it, but I don’t think this is the same for everyone. In fact I’d say it’s quite challenging to start with.
e

efemoney

03/19/2023, 6:37 PM
Yeah it's a mental shift and a little bit of a learning curve but i find once you get comfortable then it's so much easier
d

Davide Giuseppe Farella

03/19/2023, 7:55 PM
I'm coming from MVI + Reducer. So far I already called the classical
collectAsLazyPagingItems
in the VM, being able to integrate paged data in my state and that's already an immense win
c

chris-horner

03/19/2023, 10:48 PM
I meant what are the benefits of using a Presenter, over keeping the logic in the ViewModel (updating the post)
Hope the presentation was useful! My take on this - AAC ViewModel serves as an integration piece between your app’s logic and the OS. In the same way you wouldn’t want to put presentation logic in an Activity or Fragment, I wouldn’t want to put it in a ViewModel subclass either. You get better control over testing, and you aren’t forced to use a base class you don’t own. If you wanted to experiment with other approaches to integrating with Android / storing state, you could. ViewModel is just one way of doing it. All personal opinion of course! Do what’s right for your team and the problem at hand
d

Davide Giuseppe Farella

03/20/2023, 4:33 AM
Thank you for explaining!
you aren’t forced to use a base class you don’t own
This is a very good point! You convinced me 🙂