no I dont, maybe you should look at dependency inv...

# android-architecture

[ursus]

no I dont, maybe you should look at dependency inversion

[Al Warren]

Let me just throw this final thought out there as far as architecture, ViewModel, and android resources goes. Yes, R classes are "pure java". Some are framework specific. And some are application specific. Things like string resources are application specific. When your view model depends on application specific details like resources, it becomes coupled to the application. Not only that, now we have a higher level module depending on low level details which breaks DIP. To fix that, we use an abstraction, we'll call it State, that contains no details. It's just a semantic way of representing some condition. Now both high level and low level modules rely on the same abstraction and DIP is restored.

Then, any interactions between ViewModel and View need to happen elsewhere. Depending on complexity, it can be in some other abstraction or, for simpler applications, right in the view. At that point, we have decoupled both the presentation logic and the details (resources). That ViewModel would work for any application with the same state and data requirements. And when I say state, I'm talking about the "shape" of the data. Not details like actual values.

Not long ago, I was thinking about that stuff and how it ties together with architecture, MVVM, and ViewModel. So I threw together a short blog post on my thoughts. It's just my take on things so your mileage may vary.

https://ntxdroid.com/we-are-in-flight

[Al Warren]

I might also add that I used the phrase "semantically describe" in the post. That means we're talking about describing behavior. Not details.

[rkeazor]

@Al Warren it is "pure java" in the sense its generated Java Code. but it is tied completely to the SDK. Coupling ,is one issue. But lets not forget how android. The more android framework stuff you add to your Viewmodel, the more harder it becomes to test. You end up with using something like Roboelectric or creating millions of mocks,just to handle to the android stubs. But it is your codebase, choose what you want. But the best practice is keeping the android framework away from the viewmodel, and letting the View observe ot

[Al Warren]

@rkeazor That's my point. Vlastimil was the one that seemed to be advocating to use android resources in the viewmodel. I was arguing against it and trying to explain why since this is an architecture channel. I'd also like to add there's a google sample todo app that does that which I completely disagree with. 😎

[Al Warren]

Just because you "can" doesn't mean you should.

[Al Warren]

That's also why I start almost all development on android projects in IntelliJ instead of Android Studio. It forces me to avoid anything android related. Once that stuff is tested it's simple to drag and drop it right into the app as long as you maintain the same package structure.

[Al Warren]

In my opinion, using anything from R in a ViewModel violates DIP which means it violates SOLID.

[rkeazor]

gotcha, sorry i misread