The Anatomy of RIBs

An Android App demonstrating Uber RIBs architectural framework. Presentation given at Droidcon India 2019.

Transcript

1. The Anatomy of RIBs
2. 01 Introduction 02 Why RIBs? 03 RIB internals 04 Live Demo 05 Advantages 06 Questions Agenda
3. RIBs is a cross-platform, single activity, mobile architectural framework suitable for large teams working on Android and iOS platforms and for apps dealing with nested states. Introduction
4. Router Interactor Builder View (optional) Presenter (optional)
5. Why RIBs? There are already many architectures and frameworks out there • MVC • MVP • MVVM • MVI • VIPER • Clean
6. Why RIBs? Mobile engineering at Uber • 100s of mobile engineers • Deep nested states (scopes) • Shared vocabulary and common patterns across iOS & Android • Testability & Isolation • Tooling for developer productivity RIBs help with all of these
7. Why RIBs? What makes RIBs different? • Not really an architecture, but a framework • Business logic drives the app, not the view tree • Strong opinion on hierarchical state communication • Hierarchical DI scoping (with Dagger/Motif)
8. RIB Internals • Single Activity which acts as entry point into an app • This activity provides lifecycle event hooks • Under the hood, UI is manipulated by directly manipulating the root ViewGroup (addView, removeView) • App functionality and features are split into separate hierarchical components called RIBs (with or without UI)
9. RIB Internals • Each component forms a independent “RIB” • Each RIB can be made up 5 elements (independent, single responsibility) • Router, Interactor and Builder are mandatory • Presenter and View are optional • Viewless RIBs can handle non-UI business logic in hierarchical way
10. RIB Internals
11. View Contains the actual UI logic to show/hide/animate different parts of the UI and set its properties Presenter Optional interface between interactor and view Router Contains routing logic to attach/detach child RIBs and other view components Interactor Contains all business logic (Rx subscriptions, where to store data, state management, what other RIBs should be attached as children, etc.) Builder Instantiates the RIB’s constituent classes and the builders for all of its children. Usually coupled with DI component for dependency management RIB Internals
12. Interactor Business Logic All business logic should go here (Single Responsibility). This includes Rx Subscriptions, complex state management, business logic, when to attach or detach child RIBs, etc. Lifecycle Receives callback for lifecycle events and appropriately handles business logic and invokes router to perform routing tasks accordingly.
13. Routing Simple and repetitive routing logic kept away from interactor, so as to keep interactor small Router Abstraction Decouples interactors and child RIBs Testability Abstraction and decoupling makes it easy to test complex interactor logic by simply mocking the router
14. Building Instantiates the router, interactor & (optionally) presenter, along with the builders of all child RIBs Builder & Component DI Component Only part of a RIB that should be aware of DI and satisfy dependencies. Each Builder has a component which builds some dependencies for the RIB and receives remaining dependencies from its parent RIB’s Builder. Seperation Builder adds a separation between the DI mechanism and rest of the RIB architecture - we can reuse the rest of the RIB code with a different DI mechanism by replacing the builder
15. Presenter & View (Optional) Presenter Abstraction between interactor and View - stateless class that transforms business models into view-related models. Generally only used for complex views View Contains actual view logic to build and update the UI. These are designed to be as “dumb” as possible, and generally should just display information
16. Live Demo
17. Madrasi Masala Github Sample https://github.com/chetdeva/Madrasi
18. Root Onboarding Order (Viewless RIB) Menu <Listener> Checkout <Listener> ThankYou <Listener> Madrasi Masala MenuToolbar
19. Advantages Cross platform collaboration Engineers across both android and iOS can share a single, co-designed architecture along with a shared vocabulary across features that they are building. Shared vocabulary helps in writing common technical documents as well. Minimize global state RIBs encourage encapsulating states with deep hierarchy of well isolated individual RIBs, thus avoiding global state. This minimizes side-effects and unintended consequences. Single responsibility, Testability, Isolation Hierarchical decoupling and isolation improves testability and helps to ensure that classes follow single-responsibility wherever possible.
20. Advantages Structured around business logic There is no need for apps business logic to mirror its UI. For example, the view hierarchy may be shallower than RIB hierarchy to improve performance, or a single RIB may control the appearance of three different views at different places on the screen. Deep scope nested states Having deeply hierarchical RIBs helps to isolate and reason about changes within the required scope, while minimizing changes outside and eliminating side-effects. In practice, scoped dependency management also becomes easier Open-Closed Principle Developers can add new code without affecting existing code - for example, you can add a complex child RIB to a parent RIB with almost no changes to the parent RIB
21. Questions?
22. References https://github.com/uber/RIBs https://github.com/uber/RIBs/wiki https://github.com/uber/RIBs/wiki/An droid-Specific-Questions https://github.com/chetdeva/Madrasi
23. Thank You! Chetan Sachdeva Software Engineer at Uber @chetsachdeva