The Uber rider app has a shockingly large number of features as a consequence of operating in hundreds of different cities with varying constraints and optimizations, so a two level scope hierarchy quickly becomes unmanageable.Īre Three Level Scope Hierarchies Better?
#DRIVE SCOPE UPDATE#
Hard to update and test : When adding a new substate, engineers need to consider how dozens of controllers, such as AirportController, and utility classes should behave in this new state.This requires engineers to write larger classes with more error-prone state condition logic. State combinatorics : Since objects and controllers remain in memory for the duration of the entire LoggedInScope, classes need to know how they should behave during every LoggedIn substate.This forces engineers to write error-prone reset logic for AirportController’s utility objects when AirportController is hidden and then later shown again on the screen. Stale state : All utility objects used by AirportController exist in memory after AirportController has finished displaying itself on the screen.This inevitably leads to coupling between unrelated controllers and features. Coupling : Other controllers, such as CommuteController, can read and write from AirportController’s utility objects since they share a scope.See the dagger snippet = LoggedInActivityModule.class, dependencies = AppComponent.class)Ĭonsider controllers such as the AirportController (refer to the middle screen in Figure 1): this AirportController exists in memory for the entire duration of LoggedInActivity. Some of these sub-controllers are shown below in Figure 3: Figure 3: Old rider app controller and scope hierarchy.Īll 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. Therefore, LoggedInActivity is composed of one additional layer of sub-controller classes that handles different UI and business logic. There are multiple distinct screens within LoggedInActivity that perform drastically different behaviors. Most of the old rider app is contained inside a single activity, called LoggedInActivity, that behaves like a controller with a single scope. Figure 2: The old Uber rider app with the vehicle selection slider, which was retired in November 2016. The Old Uber Rider App: A Two Level Scope Hierarchyīy 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. Different architectural frameworks and how they support deep scope hierarchies.
The deep scope pattern we used in the rewritten rider app and its improvements.The shallow scope pattern we used in the old rider app and its problems.So, how did we do this? In this article, we discuss:
#DRIVE SCOPE ANDROID#
In short, we needed an effective scoping pattern to support the new Android Uber rider app. To address this, a pattern is needed to control how objects are shared between screens and subscreens. HomeActivity, AirportActivity, and ProductSelectionActivity) unless shared objects are stored as singletons in global scope. The existence of shared objects between different screens means the application cannot be composed of a distinct set of Activities (e.g. 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: Figure 1: Three application states: Home (left), Product Selection (center), and Airport (right). Uber’s Rider app is an example of how this difficulty can be worth overcoming to solve structural challenges. As a result, writing Android applications with deep scope hierarchies is difficult and uncommon.
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. 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. When we rewrote the Uber iOS and Android rider apps in 2016, we subdivided the app into a deep hierarchy of dependency injection scopes.
0 kommentar(er)
