Split the Rocket.Chat.Android app in discrete units of functionality with one android app module and several library modules (android libraries or java libraries), using the multi-module architecture (1).
Decoupling units of functionality will allow:
For vendor-specific developers
- Create different android app modules: Easier to build custom rocket.chat android apps, keep the Rocket.Chat library modules in sync with the Rocket.Chat repo, create custom modules, or extend existing modules.
For Rocket.Chat.Android developers
- Develop, build, test independently each module
- Typical benefits decomposition: smaller pieces of functionality, easier to understand, strong module boundaries, reduce coupling and increase cohesion, …
- Speed up build time (2) and (3)
- Speed up app’s start time with module lazy loading (4)
- Create different android app module types: Phone & Tablet Module, Wear OS Module, Android TV Module, Glass Module
1: “Developer Android Modules” https://developer.android.com/studio/projects/#ApplicationModules
2: “How modularization can speed up your Android app’s built time” https://medium.freecodecamp.org/how-modularisation-affects-build-time-of-an-android-application-43a984ce9968
3: Google “Modular Architecture for faster Build Time by Hazem Saleh” (sorry I cannot add more links to this post)
4: Google “App modularization and module lazy loading at Instagram and beyond” (sorry I cannot add more links to this post)
We’re definitely interested in this. Can you explain what modules would you like to see and/or not include in your build?
1 Like
Probably the most difficult thing is to define the functional boundaries, and requires a deep knowledge of current features.
An example could be by functional unit:
- Chat room
- User profile
- Search messages
- Search rooms
- Push notifications
- …
And the android app module can orchestrate the configuration of each module. A vendor-specific android app can change slightly this configuration to add/remove features, or use extended features.
1 Like
@alexfdz First of all, thanks for bringing such important topic to this forum. 
We’re investigating this approach for both iOS and Android applications. The first step we made when we started the Android app was to complete separate all the networking work to a complete separated SDK. On iOS, we’re going to rewrite the composer of the app also in a modular way, probably as a external library to allow other apps to use such complex tool in an easy way.
I think it’s great to separate the app in modules, yes. It makes things easier, makes the compilar faster (specially for iOS) and reduce the noise when updating files. But we need to be careful on what we want to modularize, otherwise we’ll end up having a super complex application just because every screen/feature is modular. Also, many things today are “modular” in the app from a server settings: if the server allows the app do it, the app will do (both clients, no only Android).
IMHO the way to go is: let’s modularize when makes sense only. Good examples are the SDK, the composer and maybe other things like the caching layer, database management and parts of the app that the user will rarely use.
What I think we can do right now to improve the ability for others to create new apps using Rocket.Chat: write a decent documentation in our SDK, support more and more REST and RealTime methods and write more tests to make sure it’s solid like a rock. Our SDK today handles all the WebSocket connectivity, all the REST calls and deal with all this complexity to the app developer, witch reduces significantly the amount of time someone will take to develop a chat application.
Let’s keep the discussion flow, let me know if something I said is wrong or doesn’t make sense please.
Thank you!
1 Like
@rafael.kellermann thanks for your reply!
All your suggestions make a lot of sense, and it really looks like a good path to follow.
Our main purpose was to enable app customisation to vendor-specific developers, keeping the capability to sychronise with the Rocket.Chat.Android repo.
An option, and quite a good/cheap way to start a multi-module refactor is the proposed by Marvin Ramin’s talk at the droidcon London 2017 “Modularizing Android Applications” (the whole talk is worth watching, but for only the proposed approach go to 8:15 - 18:03).
Long story short (again, worth watching the video);
- Refactor the whole
:app android application to a:base android library, and create a more or less empty :app with only a AndroidManifest.xml
- Extract on demand functional or infrastructure slices in new modules
As I have mentioned in the #androidnativeapp rocket.chat channel, we are more than happy to help with the development/testing.
Modular architecture for Android app makes a lot of sense.
1 Like
I have pushed a PR with the multi-module refactor following the :base approach proposed by Marvin Ramin’s talk at the droidcon London 2017 “Modularizing Android Applications”.
https://github.com/RocketChat/Rocket.Chat.Android/pull/1251
- Keep in the android application module
:app the AndroidManifest application definitions and instrumentation tests
- New android library module
:base as container for views, configuration and logic previously placed in :app
Now we are in a much better place for the following:
- Rocket.Chat.Android developers can start an “as needed” refactor to extract modules from
:base and profit from the benefits of a multi-module architecture (check first post).
- Vendor-specific developers can add more
:my-own-app android application modules in their own forked repos and customize look and feel, extend activities and add their own magic. Some of this magic could easily be contained in another android library module and offered to the main Rocket.Chat repo.
Would be possible to review this PR with your team and discuss if is something you would like to pull in Rocket.Chat.Android?
1 Like