Part 1: Intro
Clean Architecture in iOS & Android
👋 Hi there! We are going to talk about the MobOS “Clean Architecture in iOS & Android” workshop by Jorge D. Ortiz Fuentes. The workshop took place last year in Cluj-Napoca, we attended it and had an amazing two days of coding. This was a deep dive into advanced architecture, design patterns, concurrency and network API consumption.
Jorge discussed important practices and also tips & tricks in mobile app development. But, after the theoretical part, he had an exercise prepared to show us how to apply these concepts to a project. First, we started by modifying an app from MVC to MVP and then we coded an app using Clean Architecture. On the second day, we continued with a new user story and added navigation.
So, as we learned a lot of cool info at the workshop, we decided to prepare a Cobalt Matters session. This way, we could share the knowledge from the workshop with the rest of the team. During the presentation, we talked about the exercises we had to apply and how these helped us write clean & reusable code and more framework-independent apps.
Recently, we decided to organise a second Cobalt Matters session on this topic, so we can put all the above in practice with the team.
We gathered all the necessary info and started the second part of the workshop.
Part 2: Workshop
Design Patterns in Mobile Apps
The workshop was designed as an iterative and constructive approach to advanced architectures in Android & iOS. The main goal was to obtain in-depth knowledge on how to implement an application using an advanced architecture, create more reusable and fully testable code and cover the most common concerns like concurrency or network API consumption.
From MVC to MVP
We split the workshop into four sessions of Cobalt Matters, two of them were presentations done in 2018. Then, we discussed the advantages of proper architecture and how we could implement it in our apps. This year, we came back fresh & eager to learn so we started to implement all the discussed concepts in our travel app, Ready Set Holiday!. We decided to migrate a page from the app to MVP. We chose the Photos by Unsplash page because it contains all the parts for a complete pattern migration:
- API calls
- Saving data in local preferences
- Lists with custom adapters
MVC → MVP → Clean Architecture
By default, Android & iOS application development doesn’t enforce any architectural pattern (although opinions might differ on iOS at least) . This can be an advantage because it allows you to develop your code in the way you want, but at the same time, it tends to make your code more vulnerable in more complex app scenarios.
The reason we want to migrate our app to MPV is precisely the advantages this architecture offers:
- Simplicity: every class will have a clearly defined purpose;
- Testability: classes with a clearly defined purpose can be easily tested;
- Maintenance: easy to add and remove features; a bug can be easily located in a clean project.
As the name implies, Model-View-Presenter (MVP) is divided into three different layers, defined as follows:
- Model: contains a data provider and the code which fetches and updates the data.
- View: contains the visual parts of our application, like showing messages, and also handles visibility. View contains only that part of the code which is related to UI and it does not contain any logic related to the displayed data. The View is controlled by the Presenter.
- Presenter: contains the application’s business logic and when an operation is performed or data is changed then it will notify the View that it needs to update.
Guidelines to properly implement the MVP architecture:
- Make the View as “dumb” as possible. All the logic should be moved to classes that do not contain UI elements.
- Make your Presenter independent of a framework to improve testability.
- Manage remote and local data sources in the Model.
- Use dependency injection for minimizing code redundancy.
MVP Demo iOS Project
As an example, we had a model class, called HolidayModel, which held two properties, city and country. The presenter class – HolidayPresenter – is doing the business logic by getting the data from HolidayModel and passing it further to the view. The HolidayView is just an interface, it’s not the actual view. By doing this we make sure that the presenter works only with non-platform specific code.
As an overview, after we migrated to MVP, we believe that the migration of an average-sized project is achievable, but sometimes it may take as long as starting from scratch. Also, our colleagues who did not previously work on an MVP project realized how important it is to structure the code correctly and to divide it according to well-established patterns from the very beginning. They have assigned most of the time to figure out to which MVP component each piece of code belongs to.
MVP is a definitely a nice way of organising code and we think it is 💯 worth it. Cheers! 😃
Join Our Newsletter
App news, know-hows and updates. Every few months, read our stories right in your inbox.