Quels sont les avantages et les inconvénients de la liaison de données Android ?

Question

Mon collègue et moi avons tous deux de l'expérience en MVVM d'application Web, alors que nous sommes nouveaux dans le développement natif d'Android. Nous avons maintenant des avis contraires sur les liaisons de données Android : j'en suis un fan, lui non.

Mes arguments :

• Réduit le code passe-partout, ce qui apporte
  • Moins de couplage
  • Une meilleure lisibilité
• Attributs et vues personnalisés puissants et faciles à mettre en œuvre.
• Encore plus rapide que findViewById ( détails )

Ses arguments :

• Le fichier .class généré automatiquement augmente la taille de l'application.
• Plus difficile à déboguer

J'ai fait quelques recherches mais il n'y a pas beaucoup de discussions à ce sujet. Maintenant, je veux rassembler les avantages et les inconvénients de la liaison de données Android.

Les aspects de la discussion incluent, mais ne sont pas limités à :

• test unitaire
• Taille de l'application
• performance
• courbe d'apprentissage
• lisibilité
• accouplement

Answer 1

Je vais d'abord commenter vos arguments, puis je donnerai mon avis :

1. supprimer le code passe-partout - il en supprimera une partie, il en déplacera simplement une autre dans le système. xml ou cela nécessitera des classes supplémentaires. Vous devez donc être prudent et équilibrer l'utilisation de la liaison de données.

2. une meilleure lisibilité - si vous êtes un nouveau développeur, vous pouvez l'apprendre facilement, mais si vous avez déjà travaillé sur Android, vous aurez besoin de plus de temps pour l'apprendre.

3. puissant - le code a plus de pouvoir, vous pouvez implémenter tout ce que vous voulez dans le code. Pensez-y de cette façon, tout ce que vous implémentez en utilisant la liaison de données a un équivalent en code (cela peut être plus long et plus de code à écrire), mais l'inverse n'est pas valable.

4. encore plus rapide que findViewById - comparer la vitesse entre ces deux-là, à mon avis est inutile, vous ne remarquerez jamais la différence, si vous voyez une différence, alors l'une des implémentations est mauvaise.

Classe générée automatiquement - il est vrai que cela augmente la taille de l'application, mais encore une fois, cela n'a d'importance que si vous en avez des tonnes. Il est vrai que sur le site web d'Android dev, ils déclarent qu'il est plutôt mauvais d'utiliser des bibliothèques qui créent du code autogénéré ou de la annotations qui générera du code supplémentaire.

6. difficile à déboguer - cela dépend, comme la lisibilité, de ce à quoi vous êtes habitué, mais le débogage est difficile dans tous les cas pour certains problèmes, et vous vous améliorerez en déboguant et non en utilisant une autre bibliothèque.

J'ai développé de nombreuses applications en utilisant différentes bibliothèques et différentes approches, et elles avaient toutes des avantages et des inconvénients, mais ce que j'ai appris : équilibrez tout, n'utilisez pas des tonnes de bibliothèques, ne perdez pas de temps à implémenter des choses qui sont déjà implémentées et qui fonctionnent bien, ne "découplez pas tout", ne "couplez pas" tout, n'utilisez pas uniquement du code, n'essayez pas de tout "générer".

Je pense que c'est une erreur, et que vous pouvez vous faire une idée fausse, si vous demandez le "pour et le contre" d'une bibliothèque ou d'une implémentation, parce qu'en général, ce ne sera pas impartial, vous obtiendrez beaucoup de "pour" de la part de quelqu'un qui a utilisé la bibliothèque d'une manière spécifique et qui a fonctionné, et d'autres vous donneront des "contre" parce qu'ils ont utilisé une autre bibliothèque et que cela n'a pas fonctionné.

En conclusion, je pense que vous devriez vérifier ce que la bibliothèque peut faire pour vous et ce qu'elle ne peut pas faire pour vous et décider si elle convient à votre situation. En d'autres termes, c'est à vous de décider si une bibliothèque est bonne pour vous, pas aux autres ;).

Mise à jour - 8 août 2018

Tout d'abord, je reste sur ma conclusion initiale, l'équilibre est la clé dans ce genre de situations, mais dans mon cas, le data-binding a accéléré un peu le processus de développement et l'a également amélioré. Voici quelques nouveaux points auxquels vous devriez tous réfléchir.

1. Tester l'interface utilisateur - avec la liaison de données, il est beaucoup plus facile de tester l'interface utilisateur, mais la liaison de données n'est pas suffisante pour cela, vous avez également besoin d'une bonne architecture et l'utilisation de l'architecture suggérée par Google montrera la puissance réelle de la liaison de données.

2. Les changements les plus visibles ont été apportés aux points 2 et 5 de ma réponse initiale. C'était en quelque sorte plus facile de lire le code après que nous ayons décidé d'utiliser la liaison de données, et la chose la plus importante ici est que nous avons décidé, en tant qu'équipe, d'utiliser la liaison de données et qu'après cela, nous nous attendions à avoir la plupart des configurations triviales et de base de l'interface utilisateur dans le fichier XML.

Pour la partie débogage, c'est un peu délicat, Android Studio a beaucoup à améliorer sur les erreurs et l'autocomplétion pour la liaison de données, mais les erreurs les plus courantes, vous les aurez après les 2-3 premières occurrences. J'ai aussi appris qu'une forme de "projet propre" de temps en temps, aide BEAUCOUP.

3. Un autre point que vous devrez prendre en considération est la configuration du projet pour utiliser la liaison de données, actuellement AS (3.1) supporte par défaut la liaison de données (il suffit de mettre un drapeau dans graddle) pour Java, mais j'ai eu quelques problèmes avec Kotlin, après un peu de recherche ici sur SO, j'ai réussi à tout régler.

Comme deuxième conclusion (de mon post original), si vous pouvez et si le délai/les exigences/etc du projet vous permettent d'essayer le data-binding, allez-y, ça vaudra le coup (à moins que vous ne fassiez des choses vraiment stupides :)) ).

Answer 2

Même si j'aime la réponse de danypata, j'aimerais ajouter/modifier certaines de ses déclarations concernant le databinding Android.

1. supprimer le code passe-partout - Comme indiqué dans la réponse de danypatas, il supprime du code et en ajoute d'autres ailleurs, par exemple dans les mises en page. Cela ne signifie pas que le boilercode n'est pas réduit, car il l'est généralement.

Par exemple, vous pouvez créer un adaptateur de liaison, qui gère plusieurs adaptateurs de tableau personnalisés pour votre spinner/recyclerview/listview/ mais ne nécessite qu'un seul adaptateur simple. Vous pouvez utiliser l'adaptateur dans votre mise en page en utilisant, par exemple, les éléments suivants

app:myCoolAdaptersData="@{model.mydata}"

Vous pouvez maintenant créer votre adaptateur générique et (ré)utiliser votre adaptateur de liaison dans toutes vos mises en page au lieu d'utiliser par exemple :

ListView lv = findViewById(...);
CoolGenericAdapter<MyModel> coolAdapter = new CoolGenericAdapter<>(...);
lv.setAdapter(coolAdapter);

Il ne s'agit que d'un exemple simple, mais le code est souvent utilisé dans des projets plus importants. Un autre exemple de récudement du code est que vous liez votre modèle à votre layout. La mise à jour des valeurs de champ de votre modèle met généralement à jour votre modèle également (si c'est au moins un BaseObservable/ObservableField).

Cela signifie que vous ne devez pas rechercher toutes vos vues, mettre à jour vos vues, mettre à jour vos modèles, ...

2. une meilleure lisibilité - Le temps supplémentaire passé à apprendre la liaison de données n'a pas vraiment d'importance. Puisque les mises en page ne sont pas vraiment différentes, sauf que vous les enveloppez dans une balise de mise en page et y placez vos espaces de noms, cela ne diffère pas vraiment des mises en page "ordinaires". L'utilisation des adaptateurs de liaison et l'accès au modèle dans la mise en page peuvent prendre un certain temps, mais vous pouvez généralement commencer par les bases qui sont faciles et belles à utiliser. Apprendre de nouvelles choses prend toujours du temps, mais vous pourrez facilement dépasser ce temps en utilisant le databinding après un certain temps.

3.Puissant - Oui, c'est très puissant. Il est plus facile de réutiliser le code existant, de réutiliser les adaptateurs de liaison existants et cela peut conduire à plus de code généré, mais ce n'est pas toujours vrai. Par exemple, vous pouvez créer plusieurs adaptateurs dans plusieurs classes au lieu de créer un adaptateur de liaison, il peut être difficile de l'"optimiser" plus tard. Optimiser le Bindingadapter signifie qu'il est mis à jour partout. L'optimisation peut diminuer le nombre de "lignes de code" puisque le lieu de la chaudière est réduit de toute façon.

Je suis d'accord avec les points 4 et 5.

6. Difficile à déboguer Comme AS 3.0+ fournit des indications utiles sur les problèmes de syntaxe dans votre mise en page (numéro de ligne et fichier), il est facile de déboguer le code généré par la liaison de données. Si vous avez des problèmes pour trouver le problème, vous pouvez également vouloir vérifier les erreurs dans le code généré. Certaines bibliothèques comme dagger 2 ou Android architecture library peuvent vous dérouter car les lignes d'erreur ne correspondent pas à la véritable "erreur". Ceci est dû au code généré par d'autres processeurs d'annotation. Si vous savez que ces processeurs d'annotation peuvent avoir des problèmes avec les sorties d'erreurs de liaison de données, vous pouvez facilement y remédier.

7. Les tests unitaires C'est possible comme si vous n'utilisiez pas de liaison de données en utilisant executePendingBindings.

8. Lisibilité La lisibilité peut être meilleure sans liaison de données. Comme vous placez une partie de la logique métier dans votre mise en page et une autre dans votre code réel, cela peut conduire à un code spaghetti. Un autre problème est que l'utilisation de lambdas dans votre layout peut être très confuse si le "layout-designer" ne sait pas quel paramètre peut être utilisé.

Un autre problème très important est que l'adaptateur de liaison peut se trouver partout. L'utilisation de l'annotation BindingAdapter génère le code. Cela signifie que l'utilisation de cette annotation dans votre mise en page peut entraîner des problèmes pour trouver le code approprié. Si vous voulez mettre à jour un bindingadapter, vous devez le "trouver".

Quand faut-il utiliser quoi ? Pour les projets plus importants, il est recommandé d'utiliser la liaison de données avec le modèle mvvm ou mvp. C'est une solution vraiment propre et très facile à étendre. Si vous voulez juste créer une petite application simple, vous pouvez utiliser le modèle MVC sans liaison de données. Si vous avez des adaptateurs de liaison génériques existants qui peuvent être utilisés dans d'autres projets, vous voudrez peut-être utiliser le databinding, car il est facile de réutiliser ce code.

Answer 3

Je travaille sur un énorme projet Android et l'équipe a décidé de supprimer progressivement la bibliothèque Data Binding. Pourquoi ? La raison principale est qu'elle augmente le temps de construction (10+ minutes), en générant beaucoup de classes dans le processus de construction.