Disadvantages of RIB(Router, Interactor, Builder)
Do you use architecture in your apps? If yes, you must know that architectures solve some problems we have, but like other tools, they have disadvantages too and can cause many problems. In the previous article, I talked about the Advantages of the RIB. In this article, I want to discuss about the dark side of RIBs.
RIBs Disadvantages
- BT Disadvantages
- Not much help in the community
- Overdrawing
- Dependency on some libraries(RxJava, Dagger2)
- Learning Curve
- No full support screen orientations
- Boilerplate code
- Poor documentation
- Just support activities as the base component
1. BT Disadvantages
BT has entered the world of android development from the game industry and AI. Uber RIBs BT is different from BT used in the gaming industry and what Uber has made is a decision tree with a set of rules. But overall, BT can complicate the code base of the android application. In BT, all things are about states, but the RIB decision tree is about features that can/can’t contain states.
2. Not much help in the community
We are developers, and we need communities, forums, and documentation for our tools. This item is essential when a problem or bug arises because you will find almost nothing about RIB in communities and forums like Stackoverflow and etc. Many issues and questions arise during the development of the application by RIBs and, these problems must be solved by the development team, which is very time-consuming.
3. Overdrawing
An app may draw the same pixel more than once within a single frame, an event called overdraw
I know the overdraw is not a big problem anymore on modern smartphones, but If you worked with RIB, you should know the views of each RIB are added to the parent view, and the views overlap, which leads to overdraw. Overdraw is directly related to the depth of the tree, which means that if the depth of the tree is more profound, the overdraw is also greater.
4. dependency on some libraries(RxJava, Dagger2)
RIB has a concreate dependency on Dagger2(dependency injection framework) and RxJava2(Reactive programming library for java); these tools are fully coupled in the RIBs architecture and framework.
This problem prevents developers from using other libraries such as coroutines, etc.
Uber
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.
5. Learning curve
The learning curve is one of the most critical factors for choosing tools by large teams because it wastes a lot of time. RIBs have a high learning curve mainly because of the tree structure, which is difficult for most Android developers to understand (because it is not a common way to do things on Android). Also, working and developing with the RIBs is not easy as working with some other architectures and frameworks.
6. No full support screen orientation
Everyone agrees that architecture or framework must not restrict developers on things like screen orientation, etc. But RIBs do that because uber apps did not support screen orientation.
7. Boilerplate code
If you worked with RIBs, you have to write many classes for creating units and many Glue Codes for attaching or detaching units. This Problem is a concern for large teams with many engineers because a lot of time is wasted just for writing duplicated, Glue codes. Uber’s solution uses the RIBs code generation plugin, which does not entirely solve this issue.
8. Poor documentation
What happens if Google MVVM does not have any documents or wiki? The answer to this question is obvious. It can cause many problems, lousy system designs, publish bad practices, etc.
The most important thing for a tool is its documentation, especially for architectures and frameworks. Unfortunately, uber did not write good documents for RIB; even RIB samples are insufficient, and Uber blog posts articulate very abstractly about the concepts. Also, this issue repeated for some others ideas that build on RIBs.
9. Just support activities as the base component
What happens if you write only one piece of your application with RIB?
This issue is not a considerable disadvantage for RIB, but sometimes only the state-full part of your app needs to write with RIB, and the rest should be flat with another architecture. In these cases, if you want to use RIB, you must use a hack to create your tree structure based on another architecture. You can’t do it in some single-activity system designs because RIBs are designed to only work with activities as parents.
Final Conclusion
RIBs had advantages and disadvantages like any tools we use, which we discussed in these two articles.
Uber RIBs is powerful architecture and framework in state-full apps that work on a single screen and were developed by many engineers(Ride-hailing apps, Maps like google maps, etc.) RIBs with good SOC and state handling concepts easily allow many engineers to work on a single extensive codebase.
On the other hand, there’s no reason to use RIBs inside regular apps with no-states or use it inside the team with a few engineers. Based on needs, these apps and the teams that work on them can efficiently work with MVVM, MVI, etc.
