RoboSpice within the MVVM pattern

[bogdanzurac]

How would RoboSpice interact within the new MVVM Architecture Components introduced at Google IO 2017? Considering we'd have a data layer consisting of repositories which fetch data from a web API and store that data inside an ORM, all of this without taking life-cycle into account and the view layer not knowing anything about the data layer (thus not being able to start/stop the SpiceManager inside Activities and Fragments).

I've tried to search the issues for relevant threads and the best I could find was this one from 3 years ago: #211

Architecture Components reference: https://developer.android.com/topic/libraries/architecture/index.html

[stephanenicolas]

Quite a question :) Arch has different components, that's probably the best approach to answer it: *ViewModel:* Cool, at lest there is a way to survive rotation that is not so hacky, well if you don't consider that it relies on the old recipe of retaining fragments... RoboSpice has a very different approach to surviving configuration changes. A service will still be running, even if your activity is destroyed (memory pressure scenario), so there, we do a bit better, if that matters. But actually making the 2 libs playing well together is not that easy, and it can mean multiple things: putting your data in a view model after a RS request, knowing that the view model might be destroyed. That's doable, for instance if you stop RS requests when the view model is destroyed, or just unplug your listeners there instead of onDestroy. *LifeCycleObserver:* You can probably use it to simplify your spice manager life cycle. I don't see anything else that could be done here. *Room:* Obviously you can use it to store RS request results. We could contribute a module for RS. *Live Data:* I am really not a big fan of LiveData. I prefer Rx and from far. The main difference is composition, richer operations, more functional approach, to say the least. Though RS doesn't play that well with Rx neither. Actually, I don't use RS anymore personally in my projects as I prefer to use Rx. RS is still a valid approach and probably more traditional in its way of thinking. Could RS be more compatible with Rx or Live Data ? I honestly don't see how, or maybe Rs be a service lived scheduler. But that's more or less needed. 2017-06-24 23:23 GMT-07:00 bogdanzurac <[email protected]>:

…

How would RoboSpice interact within the new MVVM Architecture Components introduced at Google IO 2017? Considering we'd have a data layer consisting of repositories which fetch data from a web API and store that data inside an ORM, all of this without taking life-cycle into account and the view layer not knowing anything about the data layer (thus not being able to start/stop the SpiceManager inside Activities and Fragments). I've tried to search the issues for relevant threads and the best I could find was this one from 3 years ago: #211 <#211> Architecture Components reference: https://developer.android.com/ topic/libraries/architecture/index.html — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#471>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABv33Uz6ZkgrZ0VG9YlXV4PCkv1P9xxiks5sHfzrgaJpZM4OEhym> .

[bogdanzurac]

putting your data in a view model after a RS
request, knowing that the view model might be destroyed. That's doable, for
instance if you stop RS requests when the view model is destroyed, or just
unplug your listeners there instead of onDestroy.

True, but then we'd just move something that only the Data layer should know about (RoboSpice) from the View layer to the ViewModel layer. I strongly believe that data layer implementation specifics (that is, if we are using RS or any other caching/network mechanism, such as Room or in memory caching, etc.) should reside inside the data layer only; and not bubble up towards upper layers.

Currently, we've been using RS inside the View layer directly, which, in more complex apps, does hinder refactoring and feature changes, compared to a more clean MVVM approach.

So I guess what I'm basically asking is, if RS can be more tightly integrated into a MVVM app arch, without sacrificing its core principles (which you already mentioned, such as the foreground service approach).

PS: Yeah, I've noticed the hackish method of using retained Fragments for VMs as well :))