Nueva herramienta de encuadernación de vistas: guía del usuario de ViewBinding

Prefacio

En el proceso de desarrollo de Android, siempre necesitamos obtener el ViewId en el diseño XML para poder asignarle un valor para su visualización. En los primeros días, solo podíamos usar la API findViewById, lo que hacía que apareciera una gran cantidad de código de plantilla. Alrededor de 2013, el dios del mundo de Android, Jake Wharton, abrió el marco Butter Knife, que facilita a los desarrolladores obtener ViewId a través del método Bind ("viewid"). Debido al soporte de Google para Kotlin en los últimos dos años, hemos comenzado a usar extensiones de Android Kotlin. Importe el archivo de diseño en el archivo y haga referencia directamente al viewId. No es necesario realizar otras operaciones adicionales, las más convenientes.

Actualmente, Google ha agregado una nueva herramienta de vinculación de vistas ViewBinding en Android Studio 3.6 Canary 11 y superior.

Echemos un vistazo al uso específico.


Usar ViewBinding

Ahora estamos desarrollando muchos proyectos que utilizan la modularidad para desarrollarse. ViewBinding también es muy inteligente y se puede habilitar según el módulo. Si desea habilitar ViewBinding en un módulo, debe agregar la siguiente configuración en build.gradle del módulo:

android {
    
    ...
    
    viewBinding {
        enabled = true
    }

}

Si el desarrollador no desea generar una clase de enlace para un determinado archivo de diseño durante el uso, puede usar los siguientes atributos para agregarlo a la vista raíz del diseño:

<LinearLayout
        ...
        tools:viewBindingIgnore="true" >
        
    ...
    
</LinearLayout>

Cuando el módulo abre la función de vinculación de vista, el sistema generará la clase de vinculación correspondiente para cada archivo XML en el módulo. Cada clase de enlace contiene una referencia a la vista siguiente y todas las vistas con ID definidos.

La regla de generación de nombres de la clase de vinculación es finalizar el nombre del archivo XML de acuerdo con la regla de denominación de casos camel más la vinculación.


Por ejemplo, nuestro archivo activity_main.xml.

<LinearLayout ... >
    <TextView android:id="@+id/name" />
    <ImageView android:cropToPadding="true" />
    <Button android:id="@+id/button"
        android:background="@drawable/rounded_button" />
</LinearLayout>

Entonces, el nombre de la clase de enlace producido es ActivityMainBinding. Esta clase tiene dos campos: uno es un nombre con nombre TextView y el otro es un botón con nombre Button. El ImageView en este diseño no tiene ID, por lo que no hay referencia a él en la clase de enlace.

Cada clase de enlace también contiene un método getRoot (), que proporciona una referencia directa a la vista raíz del archivo de diseño. En este ejemplo, el método getRoot () de la clase ActivityMainBinding devuelve la vista raíz LinearLayout.


La clase de enlace generada automáticamente no es complicada, principalmente dos métodos de sobrecarga de inflado y un método de enlace. La referencia a viewId que obtenemos se realiza en el método bind, y la vista interna se obtiene realmente a través de findViewById.

Por lo general, configuramos el archivo de diseño a través de setContentView ("layoutId"), pero después de usar ViewBinding, necesitamos configurar el diseño de la siguiente manera:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding.root)

         //获取name进行赋值
        binding.name.text = "viewBinding"
    }
}

Esto se puede utilizar directamente. Es muy simple?


Pero debe tenerse en cuenta que si nuestro archivo de diseño se divide en layout y layout-land, es posible que tengamos un viewId diferente cuando definamos el diseño. Si usamos findViewById o Butter Knife, entonces debe ser anormal.

Cuando usamos ViewBinding, la clase de enlace hizo juicios relevantes íntimamente para nosotros. Utilice las dos anotaciones @Nullable y @NonNull para indicar a los desarrolladores qué vistas pueden estar vacías. Y se agregaron instrucciones de mirada relacionadas en la vista que pueden estar vacías.

  /**
   * This binding is not available in all configurations.
   * <p>
   * Present:
   * <ul>
   *   <li>layout/</li>
   * </ul>
   *
   * Absent:
   * <ul>
   *   <li>layout-land/</li>
   * </ul>
   */
  @Nullable
  public final TextView mAppTv;

Recuerde a los desarrolladores que presten atención al manejo de excepciones al usar.


para resumir

Actualmente, la función de ViewBinding no es perfecta, por ejemplo, cuando se usa la etiqueta inClude en XML, no se puede hacer referencia a la vista. Pero en general es bastante bueno. En comparación con findViewById y Butter Knife, es mucho más conveniente. Y no hay conversión de tipo ni excepción de puntero nulo en el proceso de uso de ViewBinding. Porque todos se han definido en la clase de enlace. Los desarrolladores pueden usarlo directamente. En comparación con las extensiones de Android Kotlin, creo que son similares. No puedo decir quién es mejor. En comparación con el enlace de datos, la biblioteca de enlace de datos solo se ocupa de los diseños de enlace de datos creados mediante código. Tiene limitaciones.


Actualmente, Jake Wharton también agregó la siguiente oración a la biblioteca de código abierto de Butter Knife:

Atención: el desarrollo de esta herramienta se está agotando. Considere cambiar para ver la vinculación en los próximos meses.

Es de suponer que el estado y la función de ViewBinding en el futuro serán evidentes.


Original: https://segmentfault.com/a/1190000021280566?utm_source=tag-newest

Supongo que te gusta

Origin blog.csdn.net/yechaoa/article/details/104615490
Recomendado
Clasificación