Browse Page Refactoring on Android
Article Summary
Jintin from Carousell reveals how a 3,000+ line Presenter became their team's productivity nightmare. Their solution? A strategic mix of refactoring AND rewriting that didn't require months of downtime.
The Carousell Android team faced a classic tech debt crisis: their Browse page had become a monolithic single Activity with over 10 view types, making every change risky and slow. Instead of choosing between a risky full rewrite or painful incremental refactoring, they took a hybrid approach that delivered immediate wins.
Key Takeaways
- Split monolithic 3,000 line Presenter into feature specific Domain classes
- Used ConcatAdapter to eliminate complex manual section indexing logic
- Deployed feature flags as Plan B when issues hit production
- Broke components small first, then decided rewrite vs refactor per piece
By splitting large components into smaller pieces first, then evaluating each independently, the team reduced complexity while keeping the business moving forward.
About This Article
Carousell's Browse page RecyclerView had over 10 view types all managed by one complex Adapter. The team had to manually track indices whenever they inserted or deleted items across different sections.
They switched to Google's ConcatAdapter to handle each section independently. This removed the need for manual index tracking. For single-item cases, they used SoloAdapter and MonoAdapter.
Now each Adapter manages its own data, which made the code simpler. The team could move forward with confidence on other refactoring work like migrating to Kotlin and adopting MVVM without disrupting the business.