Android: Leveraging RecyclerView Effectively with ViewModel
Article Summary
Ninad MG from JioHotstar challenged Android best practices and won. His team's unconventional approach to RecyclerView architecture now powers a social feed with 20+ card types across multiple teams.
JioHotstar's social feed needed to support dozens of heterogeneous card types with different teams working in parallel. The standard Android approach—centralizing all business logic in a Fragment ViewModel—was creating bloat, computational overhead, and code fragmentation.
Key Takeaways
- Assigned one ViewModel per RecyclerView cell instead of centralizing logic
- Eliminated DiffUtils overhead for card updates, only runs on insert/delete
- Used LiveData with custom LifeCycle owners to bind ViewModels to cells
- Enabled parallel development across teams with modular, isolated card logic
By breaking from Google's recommended pattern and giving each RecyclerView cell its own ViewModel, JioHotstar eliminated computational overhead and enabled true modularization for complex feeds.
About This Article
Hotstar's social feed had about 20 different card types, each with its own layout, interactions, and business logic. This made the Fragment ViewModel a bottleneck because DiffUtils had to process the entire list every time a card updated or the user interacted with it.
Ninad MG's team created a separate ViewModel for each RecyclerView cell using Android's DataBinding library. Each card now handles its own business logic and state updates through LiveData without relying on a shared base ViewModel.
DiffUtils only runs when cards are added, removed, or reordered. It no longer runs on every update, which cuts down on processing overhead. This also lets different teams build new card types at the same time without creating code fragmentation or dependency conflicts.