Disadvantages of RIB(Router, Interactor, Builder)

In the previous article, I talked about the Advantages of RIB in general. In this article, I will try to describe the disadvantages of RIB. below you can see the list of the RIBs disadvantages

  1. BT disadvantages
  2. Not much help in the community
  3. Overdrawing
  4. dependency on some libraries(RxJava, Dagger2)
  5. Complicated framework
  6. No full support screen orientations
  7. Boilerplate code
  8. Poor documentation
  9. Just support activities as the base component
BT — photo from youtube.com

As you may know, BT has entered the world of android development from the game industry and AI. Uber RIB BT is different from BT used in the gaming industry. What Uber has made is a decision tree with a set of rules. But overall, BT can complicate the code base of a application. In BT, each state is separated from the rest of the states, while in RIB, the nodes are separated by a feature which of course this cause a lot of problems.

RIB BT

If you use RIB and you have a problem or ambiguity or even you find a RIB bug, you will find almost nothing about RIB in communities and forums like Stackoverflow. Many problems and questions arise during the development of the application by RIBs and, these problems must have to be solved by the development team, which is very time-consuming.

An app may draw the same pixel more than once within a single frame, an event called overdraw

If you have worked with RIB, you should know the views of each RIB are added to the parent view and the views overlap and this leads to overdraw. Overdraw is directly related to the depth of the tree, which means that if the depth of the tree is deeper, the overdraw is also greater.

RIB — Overdraw

RIB has a dependency on dagger2 and RxJava, and these two tools are fully used in the RIBs and its framework. This prevents developers from using the other libraries such as kotlin coroutines and other DI frameworks. You can replace RxJava with coroutines or other tools in RIBs by forking the RIBs project, but it is time-consuming and can cause a lot of bugs.

Uber
Question: Why the coupling with RxJava2?

We don’t think this architecture makes much sense without some reactive framework. If you’re using a reactive framework you should be using Rx2. So we haven’t prioritized removing this dependency.

The complexity of architecture or framework can create two disadvantages

Learning curve

This is one of the most important factors for choosing tools by large teams because it has an effect on new joiners’ on-boarding process and may waste a lot of time from the team.

The main reason RIB has a high Learning Curve is the tree structure, which is difficult for most Android developers to understand (because it is not a common way to do things on Android). Ride-hailing businesses that have a lot of states should use state machines while most businesses in the world work flat and use designs pattern like MVVM, MVP, MVI.

Hard to fix bugs

Sometimes there are bugs in RIBs that are extremely difficult to fix because the RIB and its framework are not yet complete and bug-free and even you can not get help from the community to fix these bugs because RIBs has a poor community.

Because Uber itself does not support screen rotation, RIB does not do so completely. Below you can see Uber explanation.

Uber

What about screen orieantation ?
You can handle saving view state in RIBs with savedInstanceState or custom data stores. Uber rarely supports rotation in order to increase engineering and design efficiency. Therefore there aren’t strongly held best practices around screen rotation yet.

If you have worked with RIBs, you see that you have to write the number of classes for each RIBs. This is a problem for large teams because a lot of time is wasted just for writing duplicated codes. The solution that Uber has proposed for this is to use the RIBs code generation plugin.

I think the most important thing for a tool is its documentation, especially if it is a new concept. Unfortunately uber did not write good documents for RIB, even RIB examples are incomplete.
The Uber blog posts talk very abstractly about the concepts and do not talk about the details at all. Even several other concepts built on RIBs and published by Uber do not have complete documentation.

This may not be a big disadvantage for RIB, but sometimes only one part of the APP may need RIBs and the rest should be flat with another architecture. In these cases, if you want to use RIB, you must use activity for the part you want to have a tree structure and you can not use fragments as a base because RIBs only support activities as the base component.

Conclusion

RIBs architecture and framework have their own advantages and disadvantages which are discussed in the previous article and this article. My advice is that if you have a big app and it has a lot of states, which are implemented on one screen(Ride-hailing apps, Google Maps), I think RIBs is a wise choice. RIB with its SOC and its state handling easily allows a large number of engineers to work on a single code base.

At Snapp! (The largest Ride-hailing app in the Middle East), we use a
RIBs-based architecture on production for both passenger and driver android apps. This architecture and framework are being developed by snapp!, and many tools(IDE plugins, gradle plugins, etc) are being developed alongside to speed up the development.

Senior Android Engineer at snapp.ir