Mobile Compose Refresh Architecture
Article Summary
Madeleine Chercover from Hootsuite tackled a 3,500-line Android activity that had become a maintenance nightmare. Her solution? A modular MVVM architecture that makes features easy to add and hard to break.
Hootsuite's mobile composer (the interface for posting to social networks) had grown unwieldy and fragile. The team needed to refactor before adding new features. This article walks through their new architecture that treats each composer section as an independent, reactive component.
Key Takeaways
- Each composer section (network picker, message body, attachments) operates independently in a stack
- View models subscribe to a central message model using RxSwift/RxJava for reactive updates
- Android activity reduced to just onCreate and onDestroy, preventing future bloat
- Components can be added or removed without breaking others, unlike the previous monolith
Hootsuite transformed their mobile composer from a fragile 3,500-line monolith into a modular MVVM architecture where components communicate through reactive subscriptions to a central message model.
About This Article
Hootsuite's Android composer activity had grown to 3,500 lines of code. Adding features became risky, and maintaining it was a struggle because everything was tightly coupled and fragile.
Madeleine's team broke it apart using MVVM with multiple components. Each section, like the network picker, message body, and attachments, got its own view and view model. They all connect to a shared message model through RxSwift and RxJava.
The ComposerActivity shrank down to just onCreate and onDestroy. This removed the easy path for developers to keep piling on code. New features can now be added or removed without breaking what already works.