Inconvénients du RIB (Routeur, Interacteur, Constructeur) | par Mehdi Yari

Inconvénients des semi-rigides

1. Inconvénients de BT
2. Pas beaucoup d’aide dans la communauté
3. Découvert
4. Dépendance à certaines bibliothèques (RxJava, Dagger2)
5. Courbe d’apprentissage
6. Aucune orientation d’écran de prise en charge complète
7. Code standard
8. Mauvaise documentation
9. Accompagner uniquement les activités en tant que composant de base

1. Inconvénients de BT

BT est entré dans le monde du développement Android à partir de l’industrie du jeu et de l’IA. Uber RIBs BT est différent du BT utilisé dans l’industrie du jeu et ce qu’Uber a fait est un arbre de décision avec un ensemble de règles. Mais dans l’ensemble, BT peut compliquer la base de code de l’application Android. Dans BT, tout concerne les états, mais l’arbre de décision RIB concerne les fonctionnalités qui peuvent / ne peuvent pas contenir d’états.

2. Pas beaucoup d’aide dans la communauté

Nous sommes des développeurs et nous avons besoin de communautés, de forums et de documentation pour nos outils. Cet élément est essentiel lorsqu’un problème ou un bug survient car vous ne trouverez presque rien sur RIB dans les communautés et les forums comme Stackoverflow et etc. De nombreux problèmes et questions se posent lors du développement de l’application par les RIBs et, ces problèmes doivent être résolus par l’équipe de développement, ce qui est très chronophage.

3. Découvert

Une application peut dessiner plusieurs fois le même pixel dans une même image, un événement appelé découvert

Je sais que l’overdraw n’est plus un gros problème sur les smartphones modernes, mais si vous avez travaillé avec RIB, vous devez savoir que les vues de chaque RIB sont ajoutées à la vue parente et que les vues se chevauchent, ce qui entraîne un overdraw. L’overdraw est directement lié à la profondeur de l’arbre, ce qui signifie que si la profondeur de l’arbre est plus profonde, l’overdraw est également plus important.

4. dépendance à certaines bibliothèques (RxJava, Dagger2)

RIB a une dépendance concrète sur Dagger2 (framework d’injection de dépendances) et RxJava2 (bibliothèque de programmation réactive pour Java); ces outils sont entièrement couplés dans l’architecture et le framework RIBs.
Ce problème empêche les développeurs d’utiliser d’autres bibliothèques telles que les coroutines, etc.

Uber
Pourquoi le couplage avec RxJava2 ?

Nous ne pensons pas que cette architecture ait beaucoup de sens sans un cadre réactif. Si vous utilisez un framework réactif, vous devriez utiliser Rx2. Nous n’avons donc pas donné la priorité à la suppression de cette dépendance.

5. Courbe d’apprentissage

La courbe d’apprentissage est l’un des facteurs les plus critiques pour le choix des outils par les grandes équipes car elle fait perdre beaucoup de temps. Les RIB ont une courbe d’apprentissage élevée principalement à cause de la structure arborescente, ce qui est difficile à comprendre pour la plupart des développeurs Android (car ce n’est pas une façon courante de faire les choses sur Android). De plus, travailler et développer avec les RIB n’est pas aussi simple que de travailler avec d’autres architectures et frameworks.

6. Aucune orientation d’écran de support complet

Tout le monde convient que l’architecture ou le framework ne doit pas restreindre les développeurs sur des choses comme l’orientation de l’écran, etc. Mais les RIB le font parce que les applications uber ne prenaient pas en charge l’orientation de l’écran.

7. Code standard

Si vous avez travaillé avec des semi-rigides, vous devez écrire de nombreuses classes pour créer des unités et de nombreux codes de colle pour attacher ou détacher des unités. Ce problème est une préoccupation pour les grandes équipes avec de nombreux ingénieurs car beaucoup de temps est perdu juste pour écrire des codes Glue dupliqués. La solution d’Uber utilise le plugin de génération de code RIBs, qui ne résout pas entièrement ce problème.

8. Mauvaise documentation

Que se passe-t-il si Google MVVM n’a aucun document ou wiki ? La réponse à cette question est évidente. Cela peut causer de nombreux problèmes, des conceptions de système moche, publier de mauvaises pratiques, etc.
La chose la plus importante pour un outil est sa documentation, en particulier pour les architectes et les frameworks. Malheureusement, uber n’a pas écrit de bons documents pour RIB ; même les échantillons RIB sont insuffisants, et les articles du blog Uber articulent de manière très abstraite les concepts. En outre, ce numéro a répété pour d’autres idées qui s’appuient sur les semi-rigides.

9. Juste soutenir les activités comme composant de base

Que se passe-t-il si vous ne rédigez qu’un seul élément de votre candidature avec RIB ?
Ce problème n’est pas un inconvénient considérable pour RIB, mais parfois seule la partie complète de votre application doit écrire avec RIB, et le reste devrait être plat avec une autre architecture. Dans ces cas là, si vous souhaitez utiliser RIB, vous devez utiliser un hack pour créer votre arborescence basée sur une autre architecture. Vous ne pouvez pas le faire dans certaines conceptions de système à activité unique, car les RIB sont conçus pour fonctionner uniquement avec des activités en tant que parents.