Uncle Bob's clean architecture approach - what is recommended package structure? - android

I'd like to know if I'm using Clean Architecture the right way. I am trying to lay it like this diagram:
I've read that the package structure should be arranged by use case but I'm having difficulty following how that would be done.
Let's take a look at my package structure:
notice I don't know where to really put the activities in the UI folder, could you recommend ? does it matter?
In the data folder, I have my repositories I use for repository design pattern.
my retrofit network calls are on the same level as the UI folder. likewise for my dependency injection framework.
My concern comes after reading this publication I am now wondering if I did the package structure correctly?

One aspect Uncle Bob is emphasizing is that the clean architecture is screaming. That means that the top-level structure and names should express your business domain and not technical details and frameworks u use. On the second level we should separate the different circles.
In an e-commerce app things like cart, search and product catalog would shape the top-level structure. Use cases, controller and presenters would be on the second level.
I have blogged about this with more detailed example: Implementing Clean Architecture - Make it scream.

I would suggest you have a look to this repository. You can have a lot of feedback from the discussions in the issues section. I'll would read specially this discussion.
Now in orther to answer your question.
Does it matter? I would say no, it does not matter. Package structure is only a convinient way to structure your code to make it more readable and mantaiable. As long as you respect the Clean-Architecture principles it does not matter where you have your classes. Remember you can always do a refactor while you are progressing and your project is growing.
Where to put activities? If you already separate your UI package in components, you should stick to it and have an activities folder.
Recomendations: first I like to have one package or even a module for each layer (e.g. data, domain, presentation, infrastructure...) then within each package you can make your own decisions that you prefer. For example, I like to separate the presentation layer into features but the domain and data layer by components. The benefits of having one module for each layer is that if a new developer is going to contribute to the project you can enforce the clean architecture principles since they wont be able to reference a data class inside a domain usecase.

Related

Android: MVVM and separation of concerns

I'm almost finishing migrating my app to MVVM with databinding and livedata (still java though) and now I have much more than a decent architectured Android app (which I'm showing below). I'm happy with that, but would like to go one step further.
Talking about clean architecture, I'm trying to figure out how to do a proper separation of concerns in Android (database, business, services, etc).
I work in .net and in that platform, what you do to separate layers is to create a different proyect for each layer (database, bussiness, presentation) and then you reference them in the correct order, but projects are mostly independent one of the others.
In Android, and as far as I know, you have an app module and even though I have a nice package agrupation, all is "together" into the same project.
I'm not sure if this is the best approach to really follow clean architecture principles. I've heard about Dagger, heard you can create modules with it, but not sure if it is intended for what I'm trying to do.
Any help/hints about a good way to implement separation of concerns in Android?
My current app structure:
com
xxx
xxx
dto
class_1_dto.java
...
class_N_dto.java
helpers
helper_http.java
helper_json.java
helper_utils.java
helper_enum.java
helper_file.java
helper_smtp.java
helper_date.java
...
model
model_class_1
model_class_2
...
all_model_classes_linked_to_AWS_database
poco
some_poco_classes
repository
aws
IAWSDAO
AWS_Repository
...
all_stuff_related_to_AWS_database_query
local
model_class_1_repo
model_class_2_repo
...
all_stuff_related_to_SQLite_database_query
services
model_class_1_serv
model_class_2_serv
...
all_stuff_related_to_local_repos_query
ui
activities
activity_1
activity_1_viewmodel
activity_2
activity_2_viewmodel
...
activity_N
activity_N_viewmodel
component
custom_view_1
custom_view_2
...
helpers
view_helper_1
...
view_helper_N
assets
res
...
You can segregate your concerns like (app, core, network, service, repository) by making multiple modules. Just like 'app' is a module, you can create an independent module for each concern and you can use Koin for dependency injection between the modules.
For reference here is an example github repo:
https://github.com/Fahad-github/Bykea-CaseStudy-MusicApp

Files structure in MVVM (Android)

using MVVM or MVP should i name packages like model, viewmodel, view and put proper classes and interfaces there or is it just a logical structure that should not be visible in classes structure?
If you want to go by the book, the current "correct" way to implement MVVM in Android is the Android Architecture Components set of libraries.
Read more about it here, and try this code lab. These will also show you how to name and place your classes.
But in general, you should go with what matches your app best. For smaller apps I would recommend going with M V P folders, while for bigger, more long-term ones tend to work better with folder-per-feature structure.
Google in it's sample Android Architecture project uses Model(Data) V(views) VM(view-models) file structure
Google sample sunflower app to show architecture components
Probably that's the best approach
Additionnaly you may find this resource interesting https://overflow.buffer.com/2016/09/26/android-rethinking-package-structure/
An implementation is visible here https://github.com/SamYStudiO/beaver
I also would like to indicate watching this TUTORIAL.
This guy goes well on teaching about the Architecture MVVM and also uses the ROOM Persistence Library.
It is worth giving a look at it.

How should we deal with the growing Repository in a mvp project's model layer?

Google has launched a project on Github in order to demonstrate different architecture implementations.
todo-mvp
In its' simple MVP implementation's model layer, which applies the Repository pattern, it simply contains one POJO(Task) and we already have a bloated model layer here.
It's quite common to have dozens of POJOs in a REAL project. And it's easy to imagine how big the repository would grow.
Whenever I want to add or amend something, like adding a Owner(of a Task), I have to add so many lines of code in each one of the classes in the model layer. No need to mention that we have to write so many hard-coded SQL statements.
Is there a better way to avoid these things?
That project structure is good. If you want to save your time and avoid writing many lines of boring SQL statements, you can adopt some ORM libraries such as Realm, GreenORM etc. Same for the other stuffs.
Also checkout a new MVP framework here: http://robo-creative.github.io/mvp. With it, you can avoid writing tangled logic for view-presenter binding. The framework also supports Dependency Injection as well.

Android Studio best practices on app modules

I'm trying to understand the concept of modules on Android. I've read this article on the official documentation, but I'm a bit confused. Here is stated:
An Android Application Module is the container for your application's source code, resource files, and application level settings, such as the module-level build file, resource files, and Android Manifest file. The application module contents are eventually built into the .apk file that gets installed on a device.
and that's pretty much all the documentation I've found on this. I still don't understand in which cases would make sense to create different modules. I know that it may be vary from case to case, but ideally what would be the minimum logical size of a module?
A practical example
I'm building an app with a drawer view. Each button of the drawer will open a fragment which will have some logic to it. Would it make sense to make a module that contains only a fragment and a few java classes with no activities in it?
I'd really like to know which are the best practices on this.
Thank you.
Perhaps the best argument for breaking code and resources into modules is reusability. If not for multiple dependents of such a module, why would you need to separate this code out into a module at all? If you only ever have one application, there's not much need to have this code broken out into a module.
As soon as you have multiple applications sharing the same code, then I think a module is justified. A module could be many things. It could be a base application that contains the bulk of the code. It could contain the "Model" aspect of your application, or maybe an API or networking layer. It could be a container for proprietary algorithms. It could be some generalized code that you're planning to open-source. Who knows?
Consider it from the opposite angle. What's the risk of doing this now if you don't really need to? Maybe mental overhead? Having to think about and maintain this module may be more trouble than its worth if you don't have a good reason to do it in the first place.
What is the cost of deferring this decision? Is there any compelling reason why this code couldn't be refactored out of the main application into a module at some later point?
Something as small as a single Fragment for a single UI component sounds like something that doesn't need to be in its own module.

What are the benefits of a multi-project build in Android?

I'm reading the source code of Android : Clean Architecture, mostly to learn how to properly organize an application into layers, and for the MVP pattern, and also to match it with what I've been reading on MVP here.
However, as pretty as I find the structure, I don't really understand the benefit of order a single application into multiple sub-projects or modules. Considering they (data, presentation, domain) depend on one another, and eventually will be part of the same executable, it looks more like configuration hell.
dependencies {
...
compile project(':domain')
compile project(':data')
What are the benefits of compartmentalizing an Android application into multiple subprojects (modules), rather than keep them in one project but separate them merely by packages?
Actually this question is not Android-specific but more software architecture related as it applies to almost any software you develop (e.g. why does any app consists of several modules and not all in one package).
Splitting the code into modules would provide you at least the following benefits (these are the first 3 that comes to my mind):
Clear isolation between the modules. The whole goal of the MVP pattern is to make sure your business logic and presentations layer are not tightly coupled together. By defining these in different modules it makes this separation more clear and encourages you to stick to this pattern.
Code reuse - consider the case where you have one application that you'd to sell for several customers, but each of these customers would like to get a different look and feel. If you'll have all of your code in one monolithic project you'll have to either have many forks of your project, one for each customer or otherwise bloat the provided app code with the customization options. Now, if on the other hand you had separated your modules, then you could just prepare a different presentation layer for each customer and bundle it with the other common modules.
Splitting your project into sub-project allows more efficient build and testing as you can rebuild and test only the modules that changed rather than recompiling the whole project whenever there's a change in one of the files.
I hope that this makes sense to you.
The main benefit of using multi-module projects, instead of just packages, is that the code usage between modules goes in one direction only.
Any code inside the module can have a back-and-forth relationship:
A -> uses classes from -> B
and
B -> uses classes from -> A
If A and B are in separate modules, this only goes one-way:
A -> (uses classes from) -> B...
But B can't see anything in A.
This splits up your thinking into smaller, bite-sized chunks. If you need to understand how a class in module B works, you only need to look at the other classes in B.
But in the first scenario, you have to look at the all the classes in both A and B.
As an added bonus, if you do want to reuse any code, you can copy that module right over to the next project.
I usually put the bulk of my code in modules, with a thin app layer connecting them all together. I recommend using dependency inversion to make any connections between modules.
Another Android specific advantage of splitting into modules apart from faster build time is that the update size of your app will be less.

Categories

Resources