How we developed a chat framework for Android applications - Chateau
Badoo is primarily a social network with a convenient full-featured chat. However, the requirements for such a chat are constantly growing. Developers of popular applications for network communication all the time add new features to please users and to compete.
Of course, Badoo does not remain aloof from these trends. We are constantly improving our chat and expanding its functionality, but the capabilities of the existing code base and architecture barely keep up with the requirements of modernity. The once-ordered and well-tested code grows in an unpredictable way, accumulating "technical debt." Analyzing ways to solve this problem, we are faced with a dilemma that any developer is familiar with: rewrite the code or do a refactoring?
In the end, we decided that it was better to rewrite it. This choice was due to the following reasons:
Chatto's impressive success (Badoo chat framework for iOS) helped us understand what we can achieve.
Since the development of our chat code base, several architectural concepts for Android have appeared and gained popularity, and some of them would help us greatly simplify the code.
Our commitment to the open source concept. We have always sought to take part in such projects and ourselves have initiated the development of solutions with open source. In addition, we had a chance to occupy an almost free niche for Android.
But this was only the beginning of a long way, there were still many questions. What kind of architecture do we want to create? How, when and which code will we open? What specific results do we want to achieve?
')
From the very beginning, we perfectly understood our internal needs and requirements. However, despite the fact that we initially set a goal to make Chateau an open source project, at the design stage we also had to lay the flexibility and extensibility of the framework. This approach is reflected in our design goals:
To solve the tasks, it was necessary to choose the right tools and the optimal architecture ...
The Chateau framework itself was written from scratch, but its architecture used many years of experience in writing components and functions for the Badoo chat.
Since we have already used the MVP (Model-View-Presenter) design pattern in our other applications and it allowed us to create well-tested code, this was a natural choice for Chateau. Of course, not all implementations of the MVP pattern are the same, and we needed to choose one of the many existing options. Read more about this in our documentation .
Another element of the mosaic was the concept of Clean Architecture ("pure architecture"), proposed by Robert Martin (Robert C. Martin), who is also known as @ unclebobmartin. In accordance with this concept, we divide the application into several layers, and for all interactions between layers the “dependency rule” should be followed. Dependencies in the code should always go from top to bottom (in our case, the upper layers are the user interface, and from top to bottom we go through the layers of views (View), "presenters" (Presenter), use cases (Data use cases) and data warehouses / sources) .
The benefits of the Clean Architecture concept for us were similar to those of the MVP concept implemented at the top levels of the application. Thanks to this, we were able to create independent components that can be tested separately using fast unit tests instead of tests on the Android platform. In addition, this approach allowed the Chateau framework to be completely modular, which allows the use of another data store, user interface or an alternative implementation of the network code.
The development of Chateau was very exciting (by the way, we are not finished yet!) And fun. In the process, we laughed, cried and stuffed cones. Here are some of the lessons learned:
For the time being, Chateau does not implement all the functionality (for example, user interface and view implementations, as well as support for certain server platforms). These functions must be added or implemented in the application itself, which uses Chateau. In the future, we plan to reduce the amount of code required for full integration with Chateau. Ideally, we would like to maximize the versatility of Chateau - assuming compatibility with the server platform, of course.
We are also working on creating an optimal test layout or platform that can be used with a sample application. Follow the news in our blog on Habré, as well as on the GitHub project page.
Of course, Badoo does not remain aloof from these trends. We are constantly improving our chat and expanding its functionality, but the capabilities of the existing code base and architecture barely keep up with the requirements of modernity. The once-ordered and well-tested code grows in an unpredictable way, accumulating "technical debt." Analyzing ways to solve this problem, we are faced with a dilemma that any developer is familiar with: rewrite the code or do a refactoring?
In the end, we decided that it was better to rewrite it. This choice was due to the following reasons:
Chatto's impressive success (Badoo chat framework for iOS) helped us understand what we can achieve.
Since the development of our chat code base, several architectural concepts for Android have appeared and gained popularity, and some of them would help us greatly simplify the code.
Our commitment to the open source concept. We have always sought to take part in such projects and ourselves have initiated the development of solutions with open source. In addition, we had a chance to occupy an almost free niche for Android.
But this was only the beginning of a long way, there were still many questions. What kind of architecture do we want to create? How, when and which code will we open? What specific results do we want to achieve?
')
Goal setting
From the very beginning, we perfectly understood our internal needs and requirements. However, despite the fact that we initially set a goal to make Chateau an open source project, at the design stage we also had to lay the flexibility and extensibility of the framework. This approach is reflected in our design goals:
- Ease of expansion . It is necessary to simplify the addition of new features as much as possible (for example, support for GIF files, stickers, voice messages) and ensure that adding them does not affect other chat features.
- Easy integration . It is necessary to provide a simple integration of the framework into applications, regardless of the type of architecture used or the server platform.
- Ease of understanding . The code should be simple and clear so that a person who is not a member of our development team can understand it.
- Ease of testing . Chat provides various complex functions of user interaction and, as a result, there is a wide scope for potential errors. To ensure the possibility of refactoring and expanding the code base, it is necessary to simplify testing as much as possible (both modular and integration).
- High performance . In the framework should not be used abstractions or templates that significantly reduce performance.
To solve the tasks, it was necessary to choose the right tools and the optimal architecture ...
Optimal architecture for Chateau
The Chateau framework itself was written from scratch, but its architecture used many years of experience in writing components and functions for the Badoo chat.
Since we have already used the MVP (Model-View-Presenter) design pattern in our other applications and it allowed us to create well-tested code, this was a natural choice for Chateau. Of course, not all implementations of the MVP pattern are the same, and we needed to choose one of the many existing options. Read more about this in our documentation .
Another element of the mosaic was the concept of Clean Architecture ("pure architecture"), proposed by Robert Martin (Robert C. Martin), who is also known as @ unclebobmartin. In accordance with this concept, we divide the application into several layers, and for all interactions between layers the “dependency rule” should be followed. Dependencies in the code should always go from top to bottom (in our case, the upper layers are the user interface, and from top to bottom we go through the layers of views (View), "presenters" (Presenter), use cases (Data use cases) and data warehouses / sources) .
The benefits of the Clean Architecture concept for us were similar to those of the MVP concept implemented at the top levels of the application. Thanks to this, we were able to create independent components that can be tested separately using fast unit tests instead of tests on the Android platform. In addition, this approach allowed the Chateau framework to be completely modular, which allows the use of another data store, user interface or an alternative implementation of the network code.
What we have learned
The development of Chateau was very exciting (by the way, we are not finished yet!) And fun. In the process, we laughed, cried and stuffed cones. Here are some of the lessons learned:
- It is not easy to find a middle ground between the two extremes - a full-featured chat (with user interface, caching and network code) and a platform that could be used as the basis for your own chat. Of course, it’s great to create something immediately ready for use, but still we must not forget about the possibility of completely replacing individual modules (for example, the user interface or the network layer). We decided to create a sample application for Chateau to show how we imagine a full-featured chat;
- Studying the RxJava library directly during the development of the framework in which it is used is not an easy task. In addition, in our case, this led to more frequent refactoring (another excellent reason for providing good code coverage);
- It is better to plan the creation of the library and its use options in advance to ensure that the development process meets both internal and external needs. We wanted to distribute libraries through jCenter , and also include them as a normal Gradle project dependency when creating our applications (to simplify cross-module refactoring). In addition, with the help of git subrepo we made it so that the Chateau libraries were displayed as a separate folder of the main git.
What's next?
For the time being, Chateau does not implement all the functionality (for example, user interface and view implementations, as well as support for certain server platforms). These functions must be added or implemented in the application itself, which uses Chateau. In the future, we plan to reduce the amount of code required for full integration with Chateau. Ideally, we would like to maximize the versatility of Chateau - assuming compatibility with the server platform, of course.
We are also working on creating an optimal test layout or platform that can be used with a sample application. Follow the news in our blog on Habré, as well as on the GitHub project page.
Source: https://habr.com/ru/post/302534/
All Articles