Building Managers Over 3rd Party SDKs for Easy Access
summary
Claims a centralized Kotlin SDK manager cuts duplicated boilerplate — turning repeated ~200 lines to 6 lines across three places — and centralizes initialization, error handling and migrations so upgrades affect one file not many. Shows a concrete manager class: constructor DI for prefs and services, private state, an HD object, public initialize(token) and onActivityResult handler methods, plus event listeners. Examples: Google Sign-In, Stripe, Firebase and design advice: Singleton/SOLID patterns.
AI-written summary · about
chapters (6)
- 0:00SDK managers introduction
- 2:49Problems without SDK managers
- 7:19Benefits of SDK managers
- 10:32Building SDK manager step by step
- 13:21Q&A: SDKs vs libraries
- 17:14Closing remarks
related talks
29mDIY Dependency Injection with Kotlin
37mWrite once, ship multiple times
22mBest Practices When Building Mobile SDKs
33mAwesome Android SDK Design
27mUsing Dagger2 to Keep Android SDK Dependencies Clean
35mShaping your app’s architecture with Kotlin and Architecture Components
29mDon't reinvent the wheel, use libraries: Modern Android Stack
41mMaking a Kotlin, Architecture Components, Rx and Coroutines sandwich