DataBinding est un cadre officiellement publié par Google. Le cadre mvvm qui est directement lié en fonction des données de la page était initialement incroyable lorsqu'il a été contacté. Il peut directement lier des données dans des fichiers xml et obtenir des contrôles d'identification directement via la classe Binding. La surveillance des données peut modifier directement les données pour changer les données de la page, même si la page est utilisée à plusieurs endroits. Mais j'ai maintenant décidé de l'abandonner. Les raisons sont énumérées ci-dessous.
1. Délai de compilation
La compilation de DataBinging n'est pas opportune. Après avoir écrit la disposition du fichier xml, nous ne pouvons pas trouver directement la classe Binding correspondant au fichier xml, mais nous ne pouvons trouver la classe Binding qu'après le projet de reconstruction. Après avoir ajouté l'id d'un contrôle dans le fichier xml, Vous ne pouvez pas référencer directement ce contrôle, mais aussi Reconstruire le projet . En fait, toute modification du fichier xml doit être Reconstruire le projet , la liaison de données associée prendra effet, contrairement au fichier R, nous n'avons pas besoin d'effectuer des opérations supplémentaires après la modification, le fichier R Va changer. Et cela affectera la vitesse d'encodage.
2. De nombreuses fonctions inutiles
DataBinding peut lier directement l'événement click dans le fichier xml et l'événement de liaison peut être déclenché lorsque la propriété est modifiée (la méthode de DataBinding change). Cependant, ces fonctions apparemment magnifiques n'ont jamais été utilisées par moi par essence.
3. Fichier de mise en page complexe
Nous pouvons écrire le code suivant:
<data>
<variable
name="bean"
type="***.ConsignmentDetailBean"/>
</data>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="#f4f4f4"
android:orientation="vertical">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_marginRight="15dp"
android:text="@{bean.createTime}"
android:textColor="@color/colorTextWhite"
android:textSize="15sp"
tools:text="2018/08/12 12:20:20" />
</LinearLayout>Après avoir obtenu la classe d'entité de données via la demande de réseau, utilisez-la mBinding.setBean(bean);pour définir les données. Cependant, lorsque nous voulons effectuer des réglages de format pour l'heure obtenue, nous devons d'abord écrire une classe de conversion d'heure, puis l'appeler comme suit:
<import type="com.saiot.steward.baseLib.util.TimeUtil"/>
android:text="@{TimeUtil.formatTime(bean.createTime)}"Bien sûr, vous pouvez également le faire dans la méthode get de la classe d'entité, mais la gestion de DataBinding est en effet plus gênante. Parce que les fonctions directement prises en charge par DataBinding sont limitées.
Si vous n'utilisez pas DataBinding, nous avons juste besoin de faire le traitement du format à l'heure définie.
Il y a une autre situation, par exemple, l'interface doit être affichée comme suit: "Aujourd'hui doit être fait (10)", puis l'interface renvoie 10 à notre interface, alors nous devons le faire sur DataBinding:
android:test="{@string/a+bean.value+@string/b}"Parmi eux, a et b sont définis dans le fichier de ressources "à faire aujourd'hui (" et ")", et ne peuvent pas être directement épissés dans le fichier XML.
4. Développement multi-module
Si les problèmes ci-dessus sont de petits problèmes qui ne me conviennent pas, alors le problème du développement multi-module est la principale raison pour laquelle j'ai abandonné.
Lorsque DataBinding est développé en plusieurs modules, il existe un tel mécanisme:
-Si le sous-module utilise DataBinding, le module principal doit également être ajouté à la configuration gradle, sinon une erreur sera signalée; -Si le
module principal et le sous-module sont ajoutés Configuration DataBinding Ensuite, au moment de la compilation, la classe Binding générée par le fichier XML du sous-module aura une copie sous le module principal en plus de sa propre build.
Ensuite, si le module principal et le sous-module ont tous deux un activity_main.xml dans le répertoire racine de la mise en page, le ActivityMainBinding généré par le module principal sera généré en fonction du fichier du sous-module! Dans ce cas, nous pouvons également utiliser des noms différents pour le module principal et les sous-modules, le problème suivant sera alors mortel:
Si un fichier xml du sous-module utilise des contrôles tiers, le module principal génère également la classe Binding de ce fichier et contient des références à des contrôles tiers. À ce stade, car le module principal n'introduit pas ces contrôles, alors Une erreur sera signalée, et la solution consiste à utiliser la méthode API lorsque le contrôle tiers est appliqué au sous-module, de sorte que le module principal se réfère fermement à ces contrôles tiers, ce qui viole le principe de découplage.
