I think watching <this talk> is a good start to see why you may want to give molecule a try.

# squarelibraries

[Stylianos Gakis]

I think watching

this talk▾

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

[Davide Giuseppe Farella]

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)

[efemoney]

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

[Davide Giuseppe Farella]

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

[Davide Giuseppe Farella]

https://github.com/cashapp/molecule/blob/1f38393da6801fb970209c86a91add0953674c61/[…]c/main/java/com/example/molecule/viewmodel/presentationLogic.kt

[efemoney]

Can you link the sample you’re talking about?

[efemoney]

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.

[Stylianos Gakis]

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.

[Davide Giuseppe Farella]

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

[Stylianos Gakis]

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.

[efemoney]

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 🔥.

[Stylianos Gakis]

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.

[efemoney]

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

[Davide Giuseppe Farella]

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

[chris-horner]

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

[Davide Giuseppe Farella]

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 🙂