Estensioni Android di ViewBinding vs Kotlin con viste sintetiche

Come si confronta il nuovo ViewBinding con le estensioni Android di Kotlin con i collegamenti delle visualizzazioni sintetiche?

Oltre a NullSafety e TypeSafety forniti dai nuovi ViewBindings, perché dovremmo considerare di abbandonare il modo Kotlin di utilizzare i binding sintetici su Views.

Il nuovo ViewBinding è più performante in quanto genera prima la classe Binding?

Rivediamo i due.

Configurazione

Estensioni Android di Kotlin

1. Importa estensioni sintetiche di layout appropriate: import kotlinx.android.synthetic.main.<layout>.*
2. Riferimento viste in codice tramite i loro ID: textView.text = "Hello, world!". Queste estensioni lavorano su: Activities, Fragmentse Views.

Visualizza rilegatura

1. Crea riferimento vincolante all'interno della tua classe: private lateinit var binding YourClassBinding
2. Gonfiare il legame binding = YourClassBinding.inflate(layoutInflater)dentro Activity's onCreatee la chiamata setContentView(binding.root), o gonfiare in Fragment' s onCreateViewpoi tornare:return binding.root
3. Visualizzazioni di riferimento nel codice tramite associazione utilizzando i loro ID binding.textView.text = "Hello, world!"

Digitare sicurezza

Kotlin Android Extensions e ViewBinding sono sicuri per definizione, poiché le viste referenziate sono già espresse in tipi appropriati.

Sicurezza nulla

Le estensioni Android e ViewBinding di Kotlin sono entrambe sicure per nulla. ViewBinding non ha alcun vantaggio qui . Nel caso di KAE , se la vista è presente solo in alcune configurazioni di layout, IDE lo segnalerà per te:

Quindi lo tratti come qualsiasi altro tipo nullable in Kotlin e l'errore scompare:

Applicazione di modifiche al layout

Nel caso delle estensioni Android di Kotlin , le modifiche al layout si traducono istantaneamente nella generazione di estensioni sintetiche, in modo da poterle utilizzare immediatamente. Nel caso di ViewBinding , devi creare il tuo progetto

Utilizzo errato del layout

Nel caso di estensioni Android di Kotlin , è possibile importare estensioni sintetiche di layout errate, causando così NullPointerException. Lo stesso vale per ViewBinding , poiché possiamo importare una Bindingclasse errata . Tuttavia, è più probabile trascurare l'importazione errata rispetto al nome di classe errato, soprattutto se il file di layout ha un nome corretto dopo Activity/ Fragment/ View, quindi ViewBinding ha il sopravvento qui.

Riepilogo di KAE vs ViewBinding

• Digitare sicurezza - Disegna.
• Sicurezza nulla - Disegna.
• Codice della caldaia - KAE vince. Dalla documentazione relativa alle estensioni Android di Kotlin :

Il plug-in Estensioni Android di Kotlin ci consente di ottenere la stessa esperienza che abbiamo con alcune di queste librerie, senza dover aggiungere alcun codice aggiuntivo.

• Applicazione delle modifiche al layout : vince KAE . Le modifiche sono istantanee rispetto a ViewBinding .
• Utilizzo errato del layout : vince ViewBinding

Penso che ci sia un grosso malinteso sul fatto che ViewBinding venga sostituito da KAE . Le persone ascoltano le parole chiave grandi e le ripetono senza verificarle in anticipo. Certo, ViewBinding è la migliore opzione per lo sviluppo Java in questo momento (sostituzione per ButterKnife ), ma non ci sono o pochi vantaggi rispetto a KAE in Kotlin (vedere la sezione Uso errato del layout ).

Nota a margine : sono sicuro che alle persone di DataBinding piacerà ViewBinding :)

ViewBindingrisolto il problema più grande di kotlinx.android.synthetic. In syntheticassociazione se si imposta la visualizzazione del contenuto su un layout, quindi si digita un ID che esiste solo in un layout diverso, l'IDE consente di completare automaticamente e aggiungere la nuova istruzione di importazione. A meno che lo sviluppatore non controlli specificamente per assicurarsi che le loro dichiarazioni di importazione importino solo le viste corrette, non esiste un modo sicuro per verificare che ciò non causi un problema di runtime. Ma in ViewBindingte dovresti usare il tuo layoutoggetto vincolante per accedere alle sue viste in modo da non invocare mai una vista in un layout diverso e se vuoi farlo otterrai un errore di compilazione non un errore di runtime. Ecco un esempio

Creiamo due layout chiamati activity_maine activity_othercosì:

activity_main.xml

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
                android:layout_width="match_parent"
                android:layout_height="match_parent">

    <TextView
        android:id="@+id/message_main"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        />

</RelativeLayout>

activity_other.xml

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
                xmlns:tools="http://schemas.android.com/tools"
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                >

    <TextView
        android:id="@+id/message_other"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        />

</RelativeLayout>

Ora se scrivi la tua attività in questo modo:

import android.os.Bundle
import android.support.v7.app.AppCompatActivity
import kotlinx.android.synthetic.main.activity_other.*

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        //Application will crash because "message_other" doesn't exist in "activity_main"
        message_other.text = "Hello!"
    }
}

il codice verrà compilato senza errori ma l'applicazione si arresterà in modo anomalo in fase di esecuzione. Perché la vista con message_otherID non esiste activity_maine il compilatore non ha verificato questo. Ma se lo usi in questo ViewBindingmodo:

class MainActivity : AppCompatActivity() {
    private lateinit var binding: ActivityMainBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)
        //This code will never compile and the IDE shows you an error
        binding.message_other.text = "Hello!"
    }
}

il tuo codice non verrà mai compilato e Android Studioti mostrerà un errore nell'ultima riga.

kotlinx.android.synthetic non è più una pratica raccomandata, ha detto google in un messaggio di commit "uno del thread Reddit

https://android-review.googlesource.com/c/platform/frameworks/support/+/882241 "

Synthetics non è sviluppato da Google, fa parte dell'estensione Android di kotlin creata da JetBrains e gradualmente gli sviluppatori Android di Google hanno iniziato a sostituire i Synthetics con i ViewBindin nelle loro demo e codici sorgente.

"Ora arriva la domanda, quale dobbiamo prendere in considerazione."

Secondo Google (Visualizza rilegatura, ButterKnife, sintetici Kotlin) queste librerie sono utilizzate con successo da molte app e risolvono lo stesso problema.

Ma per la maggior parte delle app google consiglia di provare la rilegatura della vista invece di queste librerie, poiché la rilegatura della vista offre una ricerca della vista più sicura e concisa.

Immagine di riferimento allegata per cancellare rapidamente le cose.

Tuttavia, se si desidera andare in profondità, è possibile seguire il link indicato di seguito. https://medium.com/androiddevelopers/use-view-binding-to-replace-findviewbyid-c83942471fc