- Between the three there was use of MVP, MVVM and MVI architectural approaches
- Persistence was handled using Room
- For the MVVM and MVI examples, the Lifecycle Architecture components were used
- Dependency injection using Dagger 2
- Orchestration of data flow using RxJava
- Network operations with retrofit
- Unit testing using mockito
- Espresso UI tests
- Android framework code, and much more…
Whilst this is great and he repositories gave a look into how all of these tie together for projects wanting to take on a clean approach, it’s a lot to digest. If you’re new to Android or even have experience, learning a new way of something can be difficult if there are other areas of uncertainty in place also. Whilst I was aware this may be an issue, the boilerplates were created to house all of the required things for starting a new project with these tools in place. The projects display a high level of abstraction which can be easily reduced on a per-project requirement, but adding new tools or structures in place which you may not be familiar with can be much more difficult and time consuming.
Clean Architecture is a great practice to dive in with. Whilst it’s not suitable for all projects and easy to get out of hand with abstraction, you don’t have to take it by the book. Like everything we learn, we can take approaches and ideas from the way things are done and apply those to our projects without the need to re-architect our whole app. But regardless, we need to get some experience of how this practice is implemented and how its works — which can be difficult to grasp from a repository alone. For this reason, I decided to create a course on Caster.io which breaks done every single step of creating a new project influence by Clean Architecture.
Throughout the course we build up a project layer-by-layer to create an application that has clear separations of concerns throughout it’s structure, displaying a high level of maintainability and test-ability. We’ll be creating a modularized android project that splits out it’s code into a collection of modules:
- Domain — We’ll create a Domain layer to house the business objects and Use Case classes, these are the operations which your application can perform. This layer will also contain Unit tests for these classes.
- Data — We’ll create a layer which will be used to orchestrate the flow of data between the external remote / cache layers through to the Domain layers operational requests. This layer will contain Unit tests to ensure that this orchestration of data is operating as intended.
- Remote — We’ll create a layer which will contain all of the remote operations with the API being used for our project, allowing us to abstract this responsibility out of our project. We’ll also write unit tests here to ensue that these operations are working as intended.
- Cache — We’ll create a layer to store our applications data in a local database using the Room architecture component, allowing our application to be efficient when loading data and have offline capabilities in place.
- Presentation — We’ll create a layer to house the presentation logic of our application, this will be in the form of MVVM and immutable models using the Lifecycle Architecture Components. Again, we’ll have tests here for these view model classes.
- Mobile UI — Finally, we’ll create a layer that will contain the user interface for our mobile application. This will consist of the activities used to display our data, as well as the Espresso tests to ensure that the operate as intended.
Now, like previously mentioned, this level of abstraction and implementation detail may not be suitable for your project — but it is easier to earn these approaches and reduce them, than it is to create something simpler and try to abstract things yourself. We’ll cover some ideas about how we can simplify these things during the course.
The course is live now and will be free for the next week, you can check it out over on Caster.io here and I look forward to seeing everyone adding some of these practices to their tool belt 🙂