Q: Android Architecture Components usage in clean architecture?

[GediminasZukas]

In Google I/O 2017 event Android team has presented new classes (so called Android Architecture Components): LiveData, ViewModel, LifecycleObserver, LifecycleOwner. It looks like a nice tools to solve some Android life cycle or logic separation problems. But how these new classes could fit in pure clean architecture project? For example, in my view presenter I can't just simply map domain layer User model to presentation layer User model based on ViewModel or LiveData because these classes is "an Android thing" and view presenters should not have Android dependencies and be framework independent.

Would be nice to see some opinions or examples about a wise usage (e.g. not braking dependency rules in abstraction layers) of these new classes in clean architecture. Because from the first glance, looks like Android Architecture Components is the best fit for MVVM based architecture and not for the clean architecture. Thanks!

[arekz-mj]

have you find solution/answer?

[brianguertin]

In a "pure clean architecture project", the 3rd party implementations would not matter, they would be hidden behind an interface.

So sure, use those classes if they are helpful, but they should not dictate your app overall app architecture or permeate your business logic.

[PrashamTrivedi]

I think all these Android Architecture Components fit on Presentation layer.

Data layer should focus on defining data and following business rules in pure form, there should not be any platform related implementation here. Domain layer should focus on generating platform related implementation for data layer, and convert data coming from presentation layer to be used in data layer.

Lifecycle, ViewModel and anything that observes these are purely UI related. Means their use is in Presentation layer. I would also say that thread modeling (what to execute on which thread) should also fits in presentation layer, unless business rule dictates it.

tl;dr:
Data layer says what to do in terms of business rules and domain layers helps us to define how to do that.

Lifecycle related classes and any lifecycle observing utilities are part of Presentation layer. Because it's important for user that there is no uninformed-unauthorized background execution.

[kevin-barrientos]

The way I see it MVVM is just another design pattern that you can implement in and for the Presentation Layer, everything else may remain the same. So I would fit all this components in the presentation layer.

[crjacinro]

How about Room? Shouldn't it be in the data layer?

[PrashamTrivedi]

@crjacinro Rule of thumb for me is: If it's explicitly mentioned on Business Rule. Put it on Data layer.

For room I am fine about having it in Domain layer. I also use Gson/Moshi in domain layer. Because domain layer is about having fine grained implementations.

That reminded me about one thing I have experienced recently.

Kotlin Multiplatform kind of forces this clean architecture on us. We have base module and we have platform modules. Their philosophy for multiplatform is ability to share important business rules across platforms. Thus base modules (Pure kotlin, no platform definitions) are data layer, Platform modules (fine grained actual implementations) are domain layer. And presentation layer can be anything, platform module or some other module dependent on platform module.

Even in this case, room can't be in Data module. Domain or presentation layer is fine.