Rewriting Uber Engineering’s Android Rider App with Deep Scope Hierarchies

When we rewrote the Uber iOS and Android rider apps in 2016, we subdivided the app into a deep hierarchy of dependency injection scopes. This allows more features to be written without knowledge of one another and reduces the amount of stale state in the application, thereby increasing engineering velocity and facilitating growth.

While iOS frameworks have ViewControllers that always supported composite patterns, AOSP (Android Open Source Project) frameworks have not traditionally supported deeply nested controllers or scopes well. As a result, writing Android applications with deep scope hierarchies is difficult and uncommon. Uber’s Rider app is an example of how this difficulty can be worth overcoming to solve structural challenges.

The Uber rider app’s UX contains states that share common objects such as the map; for example, the home screen view, the product selection view, and the airport terminal view, shown in Figure 1:

The existence of shared objects between different screens means the application cannot be composed of a distinct set of Activities (e.g. HomeActivity, AirportActivity, and ProductSelectionActivity) unless shared objects are stored as singletons in global scope. To address this, a pattern is needed to control how objects are shared between screens and subscreens.

In short, we needed an effective scoping pattern to support the new Android Uber rider app.

So, how did we do this? In this article, we discuss:

By 2016, it became apparent that we had outgrown the existing Uber rider app, as it could no longer keep up with the scale and speed we needed to maintain and grow operations.

Most of the old rider app is contained inside a single activity, called LoggedInActivity, that behaves like a controller with a single scope. There are multiple distinct screens within LoggedInActivity that perform drastically different behaviors. Therefore, LoggedInActivity is composed of one additional layer of sub-controller classes that handles different UI and business logic. Some of these sub-controllers are shown below in Figure 3:

All of the sub-controllers such as CommuteController, PricingController, and AirportController live in the same LoggedInScope and all dependency injection objects can be shared between all sub-controllers. See the dagger snippet below:

@LoggedInScope

@Component(modules = LoggedInActivityModule.class, dependencies = AppComponent.class)

public interface LoggedInComponent {

   void inject(LoggedInActivity activity);

}

Consider controllers such as the AirportController (refer to the middle screen in Figure 1): this AirportController exists in memory for the entire duration of LoggedInActivity. This condition has several downsides:

With two layers of scopes, the old rider app is a drastic example of what happens when your scope hierarchy is too shallow. Unfortunately, creating an additional layer of scopes by giving each controller its own scope fails to solve most of the problems outlined above.

Objects often need to be shared between two or three controllers. With only three layers of scopes, these shared objects need to be stored in the LoggedInScope. Over time, the third scope layer becomes “thin” as many objects are refactored into the second layer of scopes.

Clearly, adding a third layer of scopes is an improvement. But this still causes a “fat” second scope layer with lots of the same problems.

Given that two and three level scope hierarchies have major problems, we did not limit ourselves to a set number of scope layers when we were developing the new app. Instead, we created new intermediary scope layers wherever useful. For example, the PreRequest scope is used to store objects that need to be shared by all PreRequest screen states such as Home, ProductSelection, and RefinementSteps.

This pattern results in a deep hierarchy of scopes (see Figure 4), providing two high-level benefits:

The problems in the old rider app caused by two level scope hierarchy disappear when we subdivide the application into a set of small scopes with short lifespans, per Figure 4. Consider how this new scope and hierarchy affects the Airport feature, below:

There are many different ways to create deep scope hierarchies, so we had to assess all our options before settling on one. We discuss the architectures considered before we decided to rewrite the rider app using RIBs (otherwise known as Riblets), our internal architectural framework, below:

The codebase engineering inherited from the old rider app followed the MVC (Model-View-Controller) pattern. Common textbook patterns like MVC or VIPER are general enough that they can support deeply nested scope hierarchies, but the controller hierarchies are typically dictated by view nesting. This is inconvenient for deep scope hierarchies since many scopes do not create any views.

So we didn’t go with MVC or VIPER.

Flow was primarily designed for the purpose of supporting multiple levels of nested scopes. Since you can create viewless scopes that contain nothing except shared objects (e.g., a LoggedInScope), Flow was a strong option. But other factors (for example, its lack of a corresponding iOS framework) prevented us from using it.

So we didn’t “go with the Flow.”

Frameworks like Conductor don’t explicitly support scoping or nested scoping. You can add scopes to every controller if you’re willing to overcome:

Given these constraints, we resisted choosing Conductor.

Other applications also contain shared view objects and business data between their screens. For example, Scoop was based on an early version of Flow to formalize a controller pattern that can share views like maps without creating global state.

The Scoop framework strongly emphasizes scopes. With Scoop, scopes are correlated with the navigation stack: going deeper in the navigation stack nests a scope below the current scope. For example, when transitioning from HomeController to ConfirmationController, objects can be shared between them by giving ConfirmationController access to HomeController’s scope.

Scoop’s design provides convenient navigation and animation patterns at the cost of encouraging greater coupling from controller to controller and from controller to activity, patterns we were determined to avoid.

So we didn’t Scoop up this option.

Since none of the pre-existing options we considered met Uber’s requirements, we created our own architectural framework for our new rider app: RIBs, which we detailed shortly after its debut. Unlike Scoop, the navigation stack and scopes are decoupled, and the only shared objects between Home and Confirmation exist inside an intermediate PreRequest scope. With RIBs, using a nested scope pattern for our rider app is easy because of two design decisions:

Deep scope hierarchies enable applications like our rider app, with its feature-dense screens and shared objects between subscreens, to increase separation of concerns, reduce possibilities for stale data, and increase developer velocity.

Once an app contains a deep scope hierarchy with highly decoupled controllers, it becomes easier to add powerful technologies such as static analysis to detect memory leaks, plugin-based programming, and various performance optimizations.

If this kind of work excites you, come be part of this story and improve the Uber rider experience for everyone through iOS and Android engineering. There’s plenty more to do with RIBs and beyond, and we will be writing more on the development architecture of Uber’s apps for the remainder of 2017.