Clean architecture pattern Android

Question

I have read several documents over clean architecture in general and Android specific as well.

I totally like the idea of creating a separate module for each new feature but my concern is how do I organize my data layer objects ? As I want them to be re-usable.

Should the data layer be a separate module alongside all the feature modules or the data layer should be broken down into components as modules ? eg. separate module for network, database etc ?

Answer 1

Check out this project for a clean architecture framework for Android. https://github.com/Karumi/Rosie. To answer your question though - I personally separate the network components for each module, and inject them into the appropriate feature modules that need them. For example, imagine I'm creating some sort of twitter client - I might have a class FeedManager, which exposes methods to fetch the feed, and TweetManager, which exposes methods to create a new tweet. It's a little overkill for this example though, since FeedManager and TweetManager might be very small.

Be wary of over-architecting too early on. Having a single Network module that has methods for every network request in the app is a code smell and becomes hard to maintain as your app grows. But, if your app is small, having multiple Network classes that each do a tiny thing might also be overkill, and you'd likely benefit from having only a single networking module.

Also - don't feel like you have to go whole hog on Clean Architecture - it's ok to merge multiple layers into a single layer if it suits your app. I made this mistake while trying to implement VIPER (a clean architecture derivative) 'by the book', and ended up having several extra classes for each feature that basically did nothing but pass the data onto the next layer, and it became a huge hassle to maintain. Clean Architecture may be a godsend for a large complex project where separation of concerns to the extreme is necessary, but for most Android apps I've seen, the much simpler MVC, MVVM, or MVP will be good enough.

Answer 2

First thing I would like to correct that your package architecture should be based on feature not the module architecture as you mentioned. Second, to accomodate all database related stuffs, just create a dedicated pakcage for the same.

Here is the screenshot of one of the project. May be it would help you.

Ref & more detail