Ahmed El-Helw { helw.dev / @ahmedre } Building a SuperApp Lessons from merging multiple apps into one 

Multiple Apps 

One App - a Super App 

No content

No content

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 

The World Before • Silos • Very little sharing between projects (almost no common libraries). • No mobile platform team • Lean Co f f ee 

How? 

• App will ship using the applicationId of our largest app • Apps can continue shipping their standalone apps until the business decides to remove them 

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 

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 

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 

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 { . . . } 

Librarisizing the App Dependencies apk app aar jar aar jar aar 

Librarisizing the App Dependencies aar aar jar aar jar aar apk SuperApp apk Standalone lib 

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 

Librarisizing the App • run it and make sure all is good • publish artifacts to company maven • try from new repo - it works! 

Repeat and we’re Good? 

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 

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 

Initial Complications • AndroidManifest con f l icts • minSdk version • FileProviders • Application subclass 

Initial Complications • Silent Manifest con f l icts • launch Activity • API keys • Application theme • Analytics • Push Noti f i cations 

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 

After lots of tinkering… 

It compiles! 

But it Insta-crashes. 

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 { / / . . . } } 

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 { / / . . . } } 

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 { / / . . . } } 

Application Subclasses • critical initialization logic • long living objects • (context as FooApplication).component.inject(this) 

Application Subclasses • Move initialization logic into a separate Initializer class • Move singleton object references to singleton classes • container is responsible for calling initialization logic 

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 { / / . . . } } 

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 } 

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

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

Application Singletons • Existing Application classes migrated to MiniApp containers • Consequently, all ui tests have to move to the container as well 

Compile and Run 

… and it works! 

Kinda 

RideHail Splash Screen < / FrameLayout> 

Food Splash Screen < / FrameLayout> 

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 

Resource naming 16dp < / dimen> 72dp < / dimen> 56dp < / dimen> 0dp < / dimen> 0dp < / dimen> 60dp < / dimen> 5dp < / dimen> 8dp < / dimen> 0dp < / dimen> 56dp < / dimen> 

Resource Name spacing • Resources in general (layout, strings, dimens, themes, …) • Database names must be unique • SharedPreferences f i les should be unique 

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 

Library Versioning • Build order Manifest to the rescue • Helps control dependencies from a single place • Removes surprises 

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' } } } } 

Library Versioning dependencies { api platform(“com.careem.superapp.core:platform:$platform_version”) / / okhttp & lottie implementation "com.squareup.okhttp3:okhttp" implementation "com.airbnb.android:lottie" } 

Now What? 

Questions • Does initializing every MiniApp on app start make sense? • Why does every MiniApp initialize… • Firebase? • Experimentation framework? • Analytics providers? 

Questions • How will push noti f i cations work? • How do we handle deep links? 

Detour: Two Sets of Libraries 

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

MiniApp Library • Interfaces • Constants • sealed classes and enums 

MiniApp Library • Initializer interface 

Initializers interface Initializer { fun initialize(context: Context) } 

Initializers class ListInitializer(private val initializers: List) : Initializer { override fun initialize(context: Context) { initializers.forEach { it.initialize(this) } } } 

Initializers class OneTimeInitializer(private val initializer: Initializer) : Initializer { override fun initialize(context: Context) { . . . } } 

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

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

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

MiniApp Library • Initializer interface • MiniApp interface 

MiniApps interface MiniApp { /** * Provide an initializer for initializing the MiniApp. * Keep this as light as possible. * / fun provideInitializer(): Initializer? } 

Initializing MiniApps class SuperApp : MultiDexApplication() { @Inject lateinit var miniApps: List<@JvmSuppressWildcards MiniApp> override fun onCreate() { super.onCreate() setupAndInject() / / run mini app initializers when needed } } 

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 

Analytics interface AnalyticsAgent { fun setUserAttribute(name: String, value: Any?): Boolean fun logEvent(eventName: String, eventType: EventType = EventType.GENERAL, attributes: Map? = null): Boolean } 

MiniApp Library • Initializer interface • MiniApp interface • MiniApp Factory interface 

MiniAppFactory interface Dependencies { fun provideAnalytics(): AnalyticsProvider } interface MiniAppFactory { fun provideMiniApp(appContext: Context, dependencies: Dependencies): MiniApp } 

Container Library • Part of the SuperApp itself, but exported to maven • depends on “MiniApp Library” 

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 

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()) } } 

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

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

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

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

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

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

Implications • MiniApps can test on their own • just depend on the container library! • no-op packages make it easy to mock out full MiniApps 

Api Changes • Let’s support push noti f i cations • server will send us an app_id for routing 

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) } } 

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) } } 

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) } } 

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) } } 

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 } 

Binary Compatibility What do we get from Maven? 

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 

Binary Compatibility • Solutions • upgrade all dependent libraries on the new version before calling it • make the change backward compatible 

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 } 

Backward Compatibility interface PushRecipientMarker { fun providePushRecipient(): PushMessageRecipient? = null } 

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) } } 

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) } } 

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 } 

Wrapping Up 

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 

Moving Forward • Performance • What else should move to platform? • App size • Resources • Shared design system / UI library 

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? 

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.