Bloated ViewModels? What Next
summary
Android ViewModel usage narrows to one concrete claim: dumping business logic into Android Architecture Components ViewModels turns them into 900–2,000 lines god objects that cause UI lag and hard-to-maintain multi-module code. Fixes attempted include split by UI components (creates dependency and duplication), cohesive data boundaries with wrapper classes (reduces noise but adds files, complex boundaries and more tests), and many small ViewModels. Practical guardrails that work: enforce metrics (flag large files, block PRs) and clear boundary guidelines; each approach trades simplicity for test and onboarding cost.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 2:33Starting with ViewModels
- 6:52ViewModel Bloat Problem
- 8:36Causes of Bloated ViewModels
- 11:26Solutions to Consider
- 12:33Splitting by UI Components
- 15:22Grouping by Cohesive Data
- 19:20No One-Size-Fits-All
- 20:21Proactive Quality Checks
- 21:48Q&A
related talks
41mBreaking ViewModels into smaller self-contained UI models
45mAndroid Architecture Components Considered Harmful
40mComposing ViewModels: Breaking ViewModels into smaller self-contained UI models
30mArchitecting an app with MVP and ViewModels
35mBreaking Up with Big ViewModels
40mComposing ViewModels:Breaking ViewModels into smaller self-contained UI models
07mInterview with
47mAndroid Architecture Component