Our Android Team Goes for Modular Architectures
Last Friday, just before taking a well deserved weekend, our Android team got reunited for a very important meeting, discussing key issues on architecture and process development.
The key discussion was centered around the architecture used by our Android developers which apparently was not the most suitable in developing our projects. In comparison, for the most recent project that we’ve worked on, FieldVibe, which will soon be launched, our developers tried to modularize the project. What do we mean by this?
First, every feature should have his own separate module. The modular architecture was used in building FieldVibe. The team debated on how communication is made between different modules. By modularizing we mean structuring the programming process. Every developer participated by sharing personal opinions on how the development process worked by using Android modules and explained the gains and the advantages of using them. Moreover, they had to suggest various solutions and the disadvantages as well. Everyone involved in the process had to participate with their own views on the process.
The discussion was also centered around the architecture used in Android for the recent FieldVibe app. In what ways did the development process for FieldVibe differ from the other projects that we’ve worked on? First, there were more and various modules for coding. The architecture was very different: developers used MVVM (module view view module) on Android. The pros of modularizing were encapsulating the code but at the same time, the same encapsulation didn’t help us to overcome the main problem that we encountered which is the inter-module communication. In our approach, we faced issues at the bidirectional communication between modules. The main issue was Android’s unpredictable life cycle. In an example, this means that if we want to open Client details from Jobs it works perfectly fine. But if we want to tell the Jobs that the Client edited then things got complicated. Android devs used dependency injection to initialize the module so they are sure that the beans are there when needed.
Another positive effect of the debate was using the modularization experience and the design patterns as a foundation for the next iteration of this architecture. The next step would be to keep the same modular structure but instead of effectively creating modules they will use packages to hide the internals of a “module”. This will give them the advantage to use a dependency injection framework like Koin.
Other topics covered in this meetup were: the utility of using data binding in apps and if they should use it anymore. The conclusion was that it will only be used where it helps with the development and it shouldn’t be used if it over complicates things. LocationManager which is highly used in FieldVibe was another topic. The debate was on how it shall be used so we don’t drain the user’s battery in the context that the requirements were to provide a location history of the team lead to the organization’s admin. Another topic was data storage, a better alternative to data transmitting (both-ways).
The modular architecture is used to design systems composed of separate components interconnected. What was efficient in using it was that devs can replace or add components without affecting the rest of the system.
Sebastian Sarca – Technical Team Lead
