Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Building a SuperApp

Ahmed El-Helw
December 31, 2020

Building a SuperApp

Lessons from merging multiple apps into one

Given online at 360|AnDev on July 23rd, 2020.

Ahmed El-Helw

December 31, 2020
Tweet

More Decks by Ahmed El-Helw

Other Decks in Technology

Transcript

  1. Ahmed El-Helw { helw.dev / @ahmedre } Building a SuperApp

    Lessons from merging multiple apps into one
  2. Why talk about this? • Refreshing way to think about

    Android development and architecture • Provides a new lens to view multiple Android teams in a company • Smaller teams can use it as a look into a potential future • It’s fun
  3. The World Before • Silos • Very little sharing between

    projects (almost no common libraries). • No mobile platform team • Lean Co f f ee
  4. • App will ship using the applicationId of our largest

    app • Apps can continue shipping their standalone apps until the business decides to remove them
  5. Two Options • Convert the RideHailing App into the SuperApp

    • pros: • easier to begin with, just add the other apps • cons: • lack of separation of concerns • lots of non-platform code • standalone app and MiniApp will diverge
  6. Two Options • Make a new git repository for our

    SuperApp • Be able to use our current largest app (ride hailing) from this new app • Repeat for other apps and build a shell interface. • Pros: • cleaner, more correct • standalone app and SuperApp implementations can converge • Cons: • more upfront cost
  7. Librarisizing the App • How is our app di f

    f erent from any random library module? • com.android.library vs com.android.application • Gradle con f i gurations relevant to apps and not to libraries
  8. Librarisizing the App apply plugin: 'com.android.application' apply plugin: 'kotlin-android' apply

    plugin: 'kotlin-kapt' apply plugin: 'net.ltgt.errorprone' android { compileSdkVersion deps.android.build.compileSdkVersion defaultConfig { minSdkVersion deps.android.build.minSdkVersion targetSdkVersion deps.android.build.targetSdkVersion versionCode 3010 versionName "3.0.1" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" multiDexEnabled true } signingConfigs { . . . } productFlavors { . . . } buildTypes { . . . } testOptions.unitTests.all { . . . } } dependencies { . . . } apply plugin: 'com.android.library' apply plugin: 'kotlin-android' apply plugin: 'kotlin-kapt' android { compileSdkVersion deps.android.build.compileSdkVersion defaultConfig { minSdkVersion deps.android.build.minSdkVersion targetSdkVersion deps.android.build.targetSdkVersion } } dependencies { . . . }
  9. Librarisizing the App • change app to be a com.android.library

    • create a new “container” module • should be com.android.application • should depend on app • move relevant code into container module
  10. Librarisizing the App • run it and make sure all

    is good • publish artifacts to company maven • try from new repo - it works!
  11. Librarisizing the App aar apk Dependencies aar aar Ride Hail

    aar jar aar jar aar SuperApp Food aar jar aar jar aar … aar jar aar jar aar
  12. A two-MiniApp SuperApp • make sure our new app requires

    both set of dependencies • make a simple 2 button activity, one to launch each MiniApp
  13. Initial Complications • AndroidManifest con f l icts • minSdk

    version • FileProviders • Application subclass
  14. Initial Complications • Silent Manifest con f l icts •

    launch Activity • API keys • Application theme • Analytics • Push Noti f i cations
  15. Unwinding the Knots • SuperApp will be the shipping app,

    so… • minSdk overridden by SuperApp (gate mini apps until bump minSdk) • owns the Application subclass • owns other shared components • MiniApp con f l icting pieces move to their container
  16. Application Subclasses class App : MultiDexApplication() { lateinit var applicationComponent:

    ApplicationComponent override fun onCreate() { super.onCreate() initialize() applicationComponent = initializeInjector() } private fun initialize() { / / initialize Crash reporting, analytics, and app etc } private fun initializeInjector(): ApplicationComponent { / / . . . } }
  17. Application Subclasses class App : MultiDexApplication() { lateinit var applicationComponent:

    ApplicationComponent override fun onCreate() { super.onCreate() initialize() applicationComponent = initializeInjector() } private fun initialize() { / / initialize Crash reporting, analytics, and app etc } private fun initializeInjector(): ApplicationComponent { / / . . . } }
  18. Application Subclasses class App : MultiDexApplication() { lateinit var applicationComponent:

    ApplicationComponent override fun onCreate() { super.onCreate() initialize() applicationComponent = initializeInjector() } private fun initialize() { / / initialize Crash reporting, analytics, and app etc } private fun initializeInjector(): ApplicationComponent { / / . . . } }
  19. Application Subclasses • critical initialization logic • long living objects

    • (context as FooApplication).component.inject(this)
  20. Application Subclasses • Move initialization logic into a separate Initializer

    class • Move singleton object references to singleton classes • container is responsible for calling initialization logic
  21. Application Singletons object RideHailAppInitializer { lateinit var applicationComponent: ApplicationComponent fun

    initialize(context: Context) { initialize() applicationComponent = initializeInjector() } private fun initialize() { / / initialize Crash reporting, analytics, and app etc } private fun initializeInjector(context: Context): ApplicationComponent { / / . . . } }
  22. Application Singletons object RideHailAppInitializer { fun initialize(context: Context) { initialize()

    Injector.applicationComponent = initializeInjector() } private fun initialize() { / / initialize Crash reporting, analytics, and app etc } private fun initializeInjector(context: Context): ApplicationComponent { / / . . . } } object Injector { lateinit var applicationComponent: ApplicationComponent }
  23. Application Singletons class App : MultiDexApplication() { override fun onCreate()

    { super.onCreate() RideHailAppInitializer.initialize(this) } }
  24. Application Singletons class App : MultiDexApplication() { override fun onCreate()

    { super.onCreate() RideHailAppInitializer.initialize(this) FoodInitializer.initialize(this) } }
  25. Application Singletons • Existing Application classes migrated to MiniApp containers

    • Consequently, all ui tests have to move to the container as well
  26. RideHail Splash Screen <?xml version="1.0" encoding="utf-8"?> <FrameLayout xmlns:android="http: / /

    schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" xmlns:tools="http: / / schemas.android.com/tools" xmlns:app="http: / / schemas.android.com/apk/res-auto" android:background="@color/careem_green_100"> <ImageView android:id="@+id/splash_logo" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="center" android:alpha="0" tools:alpha="1" app:srcCompat="@drawable/careem_wink_logo_white" / > < / FrameLayout>
  27. Food Splash Screen <FrameLayout android:id="@+id/splashRootLayoutFl" xmlns:android="http: / / schemas.android.com/apk/res/android" xmlns:app="http:

    / / schemas.android.com/apk/res-auto" xmlns:tools="http: / / schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" android:background="@color/careemGreen100"> <View android:id="@+id/splashGradientView" android:layout_width="match_parent" android:layout_height="match_parent" android:alpha="0" android:background="@color/careemGreen100" / > <ProgressBar android:id="@+id/progressBar" android:layout_width="wrap_content" android:layout_height="wrap_content" android:layout_gravity="bottom|center_horizontal" android:layout_marginBottom="@dimen/screen_vertical_margin_4x" android:visibility="gone" / > <ImageView android:id="@+id/logoImageView" android:layout_width="154dp" android:layout_height="88dp" app:layout_constraintStart_toStartOf="parent" app:layout_constraintEnd_toEndOf="parent" app:layout_constraintBottom_toBottomOf="@id/guideline" android:layout_gravity="center" tools:src="@drawable/ic_careem_now" / > < / FrameLayout>
  28. Resource Name spacing • RideHail has R.layout.activity_splash • Food has

    R.layout.activity_splash • SuperApp gets… R.layout.activity_splash • which one? ¯\_(ツ)_/¯ • it just picks one. • This is also why appcompat, etc pre f i x
  29. Resource naming <dimen name="abc_action_bar_content_inset_material">16dp < / dimen> <dimen name="abc_action_bar_content_inset_with_nav">72dp <

    / dimen> <dimen name="abc_action_bar_default_height_material">56dp < / dimen> <dimen name="abc_action_bar_default_padding_end_material">0dp < / dimen> <dimen name="abc_action_bar_default_padding_start_material">0dp < / dimen> <dimen name="mtrl_bottomappbar_fabOffsetEndMode">60dp < / dimen> <dimen name="mtrl_bottomappbar_fab_cradle_margin">5dp < / dimen> <dimen name="mtrl_bottomappbar_fab_cradle_rounded_corner_radius">8dp < / dimen> <dimen name="mtrl_bottomappbar_fab_cradle_vertical_offset">0dp < / dimen> <dimen name="mtrl_bottomappbar_height">56dp < / dimen>
  30. Resource Name spacing • Resources in general (layout, strings, dimens,

    themes, …) • Database names must be unique • SharedPreferences f i les should be unique
  31. Library Versioning • Given two versions of the same artifact,

    Gradle picks the latest • this is generally ok • but sometimes it’s dangerous • ex minSdk 21 OkHttp/Retro f i t • ex breaking api changes
  32. Library Versioning • Build order Manifest to the rescue •

    Helps control dependencies from a single place • Removes surprises
  33. Library Versioning apply plugin: 'java-platform' def okhttp_version = "3.12.10" dependencies

    { constraints { / / okhttp / / minSdk 21 is required for 3.13.0+ api('com.squareup.okhttp3:okhttp') { version { strictly okhttp_version } } / / newer versions of Lottie break animations on customer and Now api('com.airbnb.android:lottie') { version { strictly '2.8.0' } } } }
  34. Library Versioning dependencies { api platform(“com.careem.superapp.core:platform:$platform_version”) / / okhttp &

    lottie implementation "com.squareup.okhttp3:okhttp" implementation "com.airbnb.android:lottie" }
  35. Questions • Does initializing every MiniApp on app start make

    sense? • Why does every MiniApp initialize… • Firebase? • Experimentation framework? • Analytics providers?
  36. Questions • How will push noti f i cations work?

    • How do we handle deep links?
  37. Application Initialization class App : MultiDexApplication() { override fun onCreate()

    { super.onCreate() RideHailAppInitializer.initialize(this) FoodInitializer.initialize(this) } }
  38. Initializers class ListInitializer(private val initializers: List<Initializer>) : Initializer { override

    fun initialize(context: Context) { initializers.forEach { it.initialize(this) } } }
  39. Initializing MiniApps class SuperApp : MultiDexApplication() { @Inject lateinit var

    listInitializer: ListInitializer override fun onCreate() { super.onCreate() setupAndInject() / / run all the initializers listInitializer.initialize(this) } }
  40. Initializing MiniApps class SuperApp : MultiDexApplication() { @Inject lateinit var

    listInitializer: ListInitializer override fun onCreate() { super.onCreate() setupAndInject() / / run all the initializers listInitializer.initialize(this) } }
  41. Initializing MiniApps class SuperApp : MultiDexApplication() { @Inject lateinit var

    listInitializer: ListInitializer override fun onCreate() { super.onCreate() setupAndInject() / / run all the initializers listInitializer.initialize(this) } }
  42. MiniApps interface MiniApp { /** * Provide an initializer for

    initializing the MiniApp. * Keep this as light as possible. * / fun provideInitializer(): Initializer? }
  43. Initializing MiniApps class SuperApp : MultiDexApplication() { @Inject lateinit var

    miniApps: List<@JvmSuppressWildcards MiniApp> override fun onCreate() { super.onCreate() setupAndInject() / / run mini app initializers when needed } }
  44. Solving More Problems • Handle multiple analytics initialization • SuperApp

    should own analytics and provide an interface • Goal: Apps shouldn’t care what third parties we use
  45. Analytics interface AnalyticsAgent { fun setUserAttribute(name: String, value: Any?): Boolean

    fun logEvent(eventName: String, eventType: EventType = EventType.GENERAL, attributes: Map<String, Any>? = null): Boolean }
  46. MiniAppFactory interface Dependencies { fun provideAnalytics(): AnalyticsProvider } interface MiniAppFactory

    { fun provideMiniApp(appContext: Context, dependencies: Dependencies): MiniApp }
  47. Container Library • Part of the SuperApp itself, but exported

    to maven • depends on “MiniApp Library”
  48. Container Library • Implementation of SuperApp libraries • Declare its

    own initializers where it makes sense • Base application subclass • used by SuperApp itself • used by standalone apps’ containers as well
  49. Initializers class CrashlyticsInitializer(private val isEnabled: Boolean) : Initializer { override

    fun initialize(context: Context) { val crashlytics: Crashlytics = Crashlytics.Builder() .core(CrashlyticsCore.Builder().disabled(!isEnabled).build()) .build() Fabric.with(context, crashlytics, CrashlyticsNdk()) } }
  50. Initializers abstract class BaseSuperApp : MultiDexApplication(), MiniAppProvider { @Inject lateinit

    var initializers: List<@JvmSuppressWildcards Initializer> @Inject lateinit var miniApps: Map<MiniAppType, @JvmSuppressWildcards MiniApp> override fun onCreate() { setupAndInject() / / run all the SuperApp initializers (analytics, crash reporting, etc) initializers.forEach { it.initialize(this) } super.onCreate() } override fun provideMiniApps(): Map<MiniAppType, MiniApp> = miniApps }
  51. Initializers abstract class BaseSuperApp : MultiDexApplication(), MiniAppProvider { @Inject lateinit

    var initializers: List<@JvmSuppressWildcards Initializer> @Inject lateinit var miniApps: Map<MiniAppType, @JvmSuppressWildcards MiniApp> override fun onCreate() { setupAndInject() / / run all the SuperApp initializers (analytics, crash reporting, etc) initializers.forEach { it.initialize(this) } super.onCreate() } override fun provideMiniApps(): Map<MiniAppType, MiniApp> = miniApps }
  52. Initializing MiniApps (application as? MiniAppProvider) ? . provideMiniApps() ? .

    get(MiniAppType.RideHail) ? . provideInitializer() ? . initialize(applicationContext)
  53. Initializing MiniApps (application as? MiniAppProvider) ? . provideMiniApps() ? .

    get(MiniAppType.RideHail) ? . provideInitializer() ? . initialize(applicationContext)
  54. Initializing MiniApps (application as? MiniAppProvider) ? . provideMiniApps() ? .

    get(MiniAppType.RideHail) ? . provideInitializer() ? . initialize(applicationContext)
  55. Initializing MiniApps (application as? MiniAppProvider) ? . provideMiniApps() ? .

    get(MiniAppType.RideHail) ? . provideInitializer() ? . initialize(applicationContext)
  56. Implications • MiniApps can test on their own • just

    depend on the container library! • no-op packages make it easy to mock out full MiniApps
  57. Api Changes • Let’s support push noti f i cations

    • server will send us an app_id for routing
  58. Initializers class SuperMessagingService : FirebaseMessagingService() { . . . override

    fun onMessageReceived(remoteMessage: RemoteMessage) { super.onMessageReceived(remoteMessage) val messageType = remoteMessage.data["app_id"] val receiver = miniApps.entries.firstOrNull { it.key.pushNotificationAppId = = messageType } ? . value receiver ? . providePushRecipient() ? . onMessageReceived(remoteMessage) } }
  59. Initializers class SuperMessagingService : FirebaseMessagingService() { . . . override

    fun onMessageReceived(remoteMessage: RemoteMessage) { super.onMessageReceived(remoteMessage) val messageType = remoteMessage.data["app_id"] val receiver = miniApps.entries.firstOrNull { it.key.pushNotificationAppId = = messageType } ? . value receiver ? . providePushRecipient() ? . onMessageReceived(remoteMessage) } }
  60. Initializers class SuperMessagingService : FirebaseMessagingService() { . . . override

    fun onMessageReceived(remoteMessage: RemoteMessage) { super.onMessageReceived(remoteMessage) val messageType = remoteMessage.data["app_id"] val receiver = miniApps.entries.firstOrNull { it.key.pushNotificationAppId = = messageType } ? . value receiver ? . providePushRecipient() ? . onMessageReceived(remoteMessage) } }
  61. Initializers class SuperMessagingService : FirebaseMessagingService() { . . . override

    fun onMessageReceived(remoteMessage: RemoteMessage) { super.onMessageReceived(remoteMessage) val messageType = remoteMessage.data["app_id"] val receiver = miniApps.entries.firstOrNull { it.key.pushNotificationAppId = = messageType } ? . value receiver ? . providePushRecipient() ? . onMessageReceived(remoteMessage) } }
  62. Initializers interface MiniApp { /** * Provide an initializer for

    initializing the MiniApp. * Keep this as light as possible. * / fun provideInitializer(): Initializer? /** * Provide logic to handle a push message. * Push messages received here will only be those that have an app_id of * this particular app (unless it's the only app) * / fun providePushRecipient(): PushMessageRecipient? = null }
  63. Binary Compatibility • issues can occur when • compile against

    one version of the library • at runtime, a di f f erent version is present • these versions are not backward compatible
  64. Binary Compatibility • Solutions • upgrade all dependent libraries on

    the new version before calling it • make the change backward compatible
  65. Backward Compatibility interface MiniApp { /** * Provide an initializer

    for initializing the MiniApp. * Keep this as light as possible. * / fun provideInitializer(): Initializer? /** * Provide logic to handle a push message. * Push messages received here will only be those that have an app_id of * this particular app (unless it's the only app) * / fun providePushRecipient(): PushMessageRecipient? = null }
  66. Backward Compatibility class SuperMessagingService : FirebaseMessagingService() { . . .

    override fun onMessageReceived(remoteMessage: RemoteMessage) { super.onMessageReceived(remoteMessage) val messageType = remoteMessage.data["app_id"] val receiver = miniApps.entries.firstOrNull { it.key.pushNotificationAppId = = messageType } ? . value (receiver as? PushRecipientMarker) ? . providePushRecipient() ? . onMessageReceived(remoteMessage) } }
  67. Backward Compatibility class SuperMessagingService : FirebaseMessagingService() { . . .

    override fun onMessageReceived(remoteMessage: RemoteMessage) { super.onMessageReceived(remoteMessage) val messageType = remoteMessage.data["app_id"] val receiver = miniApps.entries.firstOrNull { it.key.pushNotificationAppId = = messageType } ? . value (receiver as? PushRecipientMarker) ? . providePushRecipient() ? . onMessageReceived(remoteMessage) } }
  68. Some time later… @Deprecated( message = "Please do not use

    this. The method here is already on MiniApp", level = DeprecationLevel.ERROR ) interface PushRecipientMarker { fun providePushRecipient(): PushMessageRecipient? = null }
  69. Things that would have saved us time • Look for

    modularization opportunities • sharing is closer than you might imagine • helps lead to cleaner code • opens up opportunities for open source in the future • Consider a shared design library early on • Establish regular conversations with Android devs throughout the company
  70. Moving Forward • Performance • What else should move to

    platform? • App size • Resources • Shared design system / UI library
  71. Moving Forward • How do we speed up MiniApp development?

    • How do we improve our testing story? • How do we do large refactors across all the MiniApps? • How do we enforce good programming practices?
  72. Ahmed El-Helw (helw.dev / @ahmedre) We were asked to merge

    our apps,
 so all are reachable in just a tap,
 we didn’t have a lot of time,
 so here’s a summary through a rhyme. Convert the apps into libraries,
 resolving manifest ambiguities,
 library dependencies can be a mess,
 Build order manifests make the pain less.
 Handling singletons was next in line,
 Casting to an application is no longer f i ne,
 the Application may not be the same,
 and so our dependencies we need to tame. After all was said and done,
 everything was great under the sun,
 well except the storm brewing about,
 resource con f l icts causing many a doubt.
 
 Once everything agreed to coexist,
 we could walk down our wish list,
 start o f f with building an API,
 in the KDocs we try not to lie.
 Backward compatibility we must do,
 in order to save a day or two,
 of updating MiniApps one by one,
 can be tedious and not quite fun.
 
 Work continues on platform turf,
 with a focus on speed and perf,
 not to mention quality of code,
 which is a never ending winding road.
 All of this is not to ignore,
 critical features to our core,
 tokens, login, and identity too,
 the home screen developed by the crew.
 
 Work like this needs a single team,
 combining our silos was always a dream,
 one that we’re realizing day by day,
 improving the process since release in May.
 
 I hope smaller companies share aars,
 design systems and utility jars,
 communication is an absolute must,
 that and action help build trust.
 
 That is all I have to say,
 Hope you enjoy the rest of your day.