ACTIVITIES AND FRAGMENTS ARE NOT MVX VIEWS
summary
Argues that Activities and Fragments should not be the MVx view but should hand UI work to standalone view classes, so extract UI logic into standalone view classes and make Activity/Fragment the lifecycle-focused controller that handles lifecycle and navigation. Shows a small API: bind/unbind, getRootView, listener registration, and reuses view classes as list item renderers to avoid viewholder hacks. Benefits: true decoupling, easier outsourcing and reuse, simpler unit testing; cost: more boilerplate and a mental model shift.
AI-written summary · about
chapters (14)
- 0:00Introduction and setup
- 1:51Personal journey with Android architecture
- 3:38Understanding MVX patterns
- 6:47History of MVC and MVP on Android
- 8:59Joshua Bloch’s breakthrough with MVC
- 10:45Key advantage of MVX: decoupling UI logic
- 13:59Why UI logic should be decoupled
- 18:10Problems with UI logic in Activities
- 22:49Activities as controllers not views
- 26:22Extracting UI logic from Activities
- 29:59Advantages of decoupled UI logic
- 33:37Costs and challenges of the approach
- 35:42Why this MVX is battle-tested
- 37:49Fragments and final thoughts
related talks
24mMVVM & Nested Fragments/Views: ViewModel Contracts
46mModern Android: How to ditch Activities and Fragments
56mYou've been told lies about Fragments
30mFragments: What are they good for.
35mModel View Intent, Embracing Reactive UI's
30mArchitecting an app with MVP and ViewModels
26mSingle activity navigation so simple even I can understand it
18mFragments: The good (non-deprecated) parts