Abstracting the Map in Android Architecture
summary
Proposes a concrete architecture that keeps map SDK objects confined to the view layer so swapping providers takes minutes, not months. Uses Android ViewModel + LiveData, Kotlin data/sealed classes for immutability, repositories + interactors for unidirectional flow, and an adapter layer using the mapme adapter plus DiffUtil to avoid wholesale redraws. Shows a working open‑source demo with Google, HERE and Mapbox adapters where only the adapter changes; demonstrates handling 100 markers without clearing and recreating them.
AI-written summary · about
chapters (12)
- 0:00Introduction and context
- 1:03Why abstract map dependencies
- 2:49Initial MVP structure issues
- 3:53Single responsibility principle
- 4:54ViewModel and data flow
- 6:43Immutability in map objects
- 9:31Unidirectional data flow
- 10:53Interactors for cross-view communication
- 12:41Optimizing map updates with adapters
- 15:51Adapter pattern benefits
- 16:12Multi-provider demo example
- 16:55Next steps and complexity
related talks
41mComposifying Your Not-Compose Code
28mHands-on Android Architecture & Architecture Components
47mAndroid Architecture Component
41mViewModels, LiveData and Lifecycles, oh my!
47mArchitecting your Android app with Jetpack
42mArchitecture Round Table
07mInterview with
36mLessons Learned Migrating the Maps SDK to Compose