50 votes

Bibliothèque de liaison des données Android vs Extensions Kotlin Android

Je suis en train de lire sur le fonctionnement de l'architecture MVVM et sur comment utiliser Library Data Binding d'Android.

D'une manière générale, je comprends que Data Binding d'Android crée un lien entre la couche UI et le modèle de données sous-jacent qui contient les informations à afficher.

Les extensions Android Kotlin sont un autre plugin Kotlin qui vous permettra de récupérer des vues à partir des Activités, Fragments et Views. Le plugin générera un code supplémentaire qui vous permettra d'accéder aux vues dans la mise en page XML, comme s'il s'agissait de propriétés avec le nom de l'identifiant que vous avez utilisé dans la définition de mise en page.

Quelle est la différence entre l'utilisation de Library Data Binding d'Android et des extensions Kotlin Android? Ont-elles des objectifs différents? Se complètent-elles, de quelle manière?

Merci pour vos réponses.

0 votes

Vraiment bon article à ce sujet : medium.com/google-developer-experts/…

31voto

Supriya Points 939

À la fois, les extensions Android de Kotlin et la bibliothèque Android Data Binding aident à éliminer l'utilisation de findViewById.

Mais il y a aussi plus de choses que ces deux éléments peuvent faire, qui peuvent se compléter mutuellement. Pour élaborer, avec la bibliothèque Android Data Binding, vous pouvez 'définir' des modèles dans vos fichiers xml, qui peuvent ensuite être directement utilisés pour définir des valeurs pour les vues dans la mise en page. Voir comment une balise peut être utilisée avec la bibliothèque de liaison de données.

Les extensions Android de Kotlin ne fournissent pas cela. En même temps, les extensions Android de Kotlin offrent des fonctionnalités étonnantes comme l'annotation @parcelize pour rendre les classes parcelables avec presque aucun code redondant, etc.

En conclusion, bien qu'ils éliminent tous deux l'utilisation de findViewById, ils ont aussi leurs propres fonctionnalités qui peuvent bien se compléter mutuellement.

5 votes

Laquelle préférez-vous en cas de code généré ou de construction?

0 votes

Aussi, je viens de réaliser et j'aimerais ajouter que KTX ne semble pas fournir des classes de liaison de mise en page concrètes qui peuvent être utilisées dans le code. Il fournit uniquement des références aux IDs spécifiés dans les classes de mise en page en tant que variables de champ qui peuvent être utilisées dans le code mais pas l'ensemble de la mise en page elle-même.

31voto

Oya Canlı Points 276

Les Extensions Kotlin pour Android ne se limitent pas uniquement à la liaison de vues. Elles contiennent également d'autres fonctionnalités. Mais je suppose que vous parlez des fonctionnalités de liaison/mise en cache des vues des Extensions Kotlin pour Android et vous vous demandez si nous avons toujours besoin de la liaison de données, puisque nous nous sommes déjà débarrassés des appels à findViewById avec les propriétés synthétiques de Kotlin. C'était la question que je me suis posée et ma conclusion est que oui, la liaison de données vaut toujours la peine d'être utilisée.

À partir de la documentation officielle:

La bibliothèque de liaison de données crée un champ immuable dans la classe de liaison pour chaque vue ayant un ID dans la mise en page... La bibliothèque extrait les vues incluant les IDs de la hiérarchie des vues en une seule passe. Ce mécanisme peut être plus rapide que d'appeler la méthode findViewById() pour chaque vue dans la mise en page.

Ainsi, la liaison de données ne fait pas appel à findViewById sur les vues une par une. Les classes synthétiques de Kotlin, d'autre part, appellent toujours findViewById sur les vues en interne, mais ne le font qu'une seule fois pour chaque vue et mettent en cache la référence de la vue pour les appels suivants. (Voici un article à ce sujet)

En outre, la liaison de données offre bien plus que simplement la mise en cache des vues. Vous pouvez utiliser des balises de données pour transmettre des données à la mise en œuvre de liaison et les déclarer dans votre XML, au lieu de les définir de manière programmatique. De cette manière, vous pouvez vous débarrasser du code redondant que vous utilisez pour peupler les données, comme les "setText", "setImageResource", etc. Vous pouvez définir des écouteurs d'événements depuis le XML en utilisant la liaison de données. Vous pouvez également créer vos propres attributs en utilisant des adaptateurs de liaison personnalisés. Lorsqu'elle est utilisée à sa pleine puissance, elle peut réduire significativement votre code Java/Kotlin.

Édition: Il semble que l'équipe Google Android déconseille l'utilisation des propriétés synthétiques de Kotlin. Cet article résume la discussion autour de ce problème. Et vous pouvez voir dans le nouveau cours Udacity préparé par Google qu'ils utilisent la liaison de données comme pratique recommandée.

Édition2: Si vous n'aimez pas l'idée de "mettre la logique métier dans votre XML", si vous n'êtes pas intéressé par le paramétrage ou la récupération de données à partir du XML, si vous souhaitez simplement éviter l'utilisation de findViewById de manière sûre et efficace, alors vous pouvez utiliser la bibliothèque ViewDataBinding à la place. C'est une version simplifiée de la bibliothèque de liaison de données. Elle ne vous permet pas de définir des données à partir de votre XML, mais lie vos vues de manière sûre et efficace.

1voto

Manzur Alahi Points 424

Je suis en désaccord avec les points mentionnés ci-dessus. Peut-être parce que je déteste écrire de la logique en XML. donc les deux commentaires mentionnent l'utilisation des balises non trouvées dans les Extensions Kotlin Android (KTX). avec kotlin et KTX, vous pouvez faire mieux que les balises data.

disons que nous avons

data class Person(val name:String, 
                   val phone:String,
                   val isMale:Boolean,
                   val isMarried:Boolean)

dans l'activité ou le fragment, nous pouvons faire

fun updateView(data:Person){
    with(data){

     nameTextField.text = if(isMale){
                            "M." + name 
                          } else {
                             if(isMarried){
                              "Mme. " + name
                             }else{
                              "Mlle. " + name
                             }
                          }
     phoneTextField.text = phone
    }
 }

dans la liaison de données, vous devez faire

android:text='@{person.isMale ? "M."+user.name: ((user.isMarried ? "Mme. " : "Mlle. ") + user.name)}'

Le code KTX est bien plus propre que ce que vous avez à faire avec la liaison de données pour obtenir le même résultat. lorsque vous avez besoin de conditions pour définir des valeurs pour la vue, la liaison de données devient laide. donc pour moi, les Extensions Android Kotlin fonctionnent mieux. J'aime mon code propre. vous pouvez toujours utiliser les deux, la décision vous appartient.

5 votes

Vous n'avez pas à le faire comme ça avec la liaison de données. En fait, vous ne devriez pas le faire ainsi. L'utilisation d'opérateurs ternaires compliqués dans le XML n'est pas recommandée, à la fois pour la lisibilité, comme vous l'avez mentionné, et aussi parce que les codes XML ne sont pas testables. Donc ce que vous pouvez faire avec la liaison de données, c'est d'utiliser une méthode d'aide qui acceptera une personne comme argument et renverra le texte dont vous avez besoin.

0 votes

Puisque je peux faire cela si facilement avec ktx et kotlin, pourquoi me donner la peine d'utiliser la liaison de données + la classe d'aide !?

2 votes

Je voulais juste clarifier que vous n'avez pas besoin d'utiliser des opérateurs ternaires "moins beaux" ou illisibles dans la liaison de données. Vous n'avez pas à vous embêter, bien sûr, si cela semble être une "corvée". Je suppose que cela dépend de ce à quoi quelqu'un est habitué. Pour moi, la liaison de données signifie significativement moins de code dans mes activités et mes fragments.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X