Refactoring Plaid App – A reactive MVP approach
summary
Refactors Plaid (5,000+ stars) into a reactive MVP with concrete changes: introduce a Source DAO, Router and Page classes, replace shared‑prefs with a SQL-backed store, and make queries observable so UI updates propagate automatically. Uses RxJava for streams, SQLBrite over SQLite for reactive queries, Retrofit for network, and OkHttp MockWebServer plus Espresso/JUnit rules for reproducible tests. Result is unidirectional data flow, fewer UI state bugs, and full test coverage enabling safer iterative changes.
AI-written summary · about
chapters (28)
- 0:00Refactoring Plaid app intro
- 1:34Bad code slows development
- 2:15Test-driven development safety
- 2:35SOLID principles
- 4:00Immutability benefits
- 5:04AutoValue for Java classes
- 6:32MVC modern flaws
- 7:58Plaid app architecture
- 10:10Code and UI smells
- 11:34Plaid's tangled architecture
- 14:21Mocking network responses
- 16:08Mock server setup
- 17:31Clean architecture explained
- 18:56Breaking clean architecture
- 20:00Refactoring SourceManager with TDD
- 21:47RxJava basics
- 22:30SourceDAO with SQLBrite
- 23:17TDD workflow in practice
- 24:20Circular dependencies in adapters
- 25:44Event bus pitfalls
- 26:26MVP pattern and testing
- 27:09Refactoring DataManager
- 28:13Unidirectional data flow
- 30:43Services and intent updates
- 31:24Refactoring cost vs value
- 32:04Move fast safely
- 32:49Refactor summary
- 33:09Q&A
related talks
15mRe-stitching Plaid with Kotlin
35mShaping your app’s architecture with Kotlin and Architecture Components
29mShaping Your App's Architecture with Kotlin and Architecture Components
48mGoing Reactive, An Android Architectural Journey
37mPragmatic crafting
31mPatterns for Safe Refactoring of Android Apps
47mThe Reactive Workflow Pattern Update
30mArchitecting an app with MVP and ViewModels