16 consejos de desarrollo para Android en Kotlin. Parte 2

Hola a todos En previsión del inicio del curso básico sobre desarrollo de Android , continuamos compartiendo material útil.



Antes de leer estos consejos, debe leer la documentación de Kotlin y aprender el idioma usted mismo en try.kotlinlang.org . Dado que estos consejos están destinados específicamente a usar Kotlin en el contexto del desarrollo de Android, también debe tener experiencia con el SDK de Android. También es recomendable familiarizarse con el complemento Kotlin y el uso de Kotlin con Android Studio de JetBrains (creadores de Kotlin)



Lee la primera parte

Descripción de objetos.


Las descripciones de objetos permiten solo singleton, que no puede confundirse con una clase con la capacidad de crear instancias. Por lo tanto, no necesita almacenar singletes como variables de una clase estática o en la clase Aplicación.

Por ejemplo, si tengo una clase de utilidad con métodos estáticos asociados con subprocesos y quiero acceder a toda la aplicación, puede hacer esto:

 package com.myapps.example.util import android.os.Handler import android.os.Looper // ,   ,    object ThreadUtil { fun onMainThread(runnable: Runnable) { val mainHandler = Handler(Looper.getMainLooper()) mainHandler.post(runnable) } } 

ThreadUtil se puede llamar más tarde de la misma manera que cuando se llama a un método de clase estática:

 ThreadUtil.onMainThread(runnable) 

Esto significa que ya no necesita simular el comportamiento de una clase estática utilizando un constructor privado y no necesita averiguar dónde está almacenada la instancia. Los objetos, de hecho, son los elementos originales del lenguaje. Por el mismo principio, creamos objetos en lugar de clases internas:

 iewPager.addOnPageChangeListener(object : ViewPager.OnPageChangeListener { override fun onPageScrollStateChanged(state: Int) {} override fun onPageScrolled(position: Int, positionOffset: Float, positionOffsetPixels: Int) {} override fun onPageSelected(position: Int) { bindUser(position) } }); 

Ambos esencialmente hacen lo mismo: crean una instancia de la clase como un objeto declarado.

Objetos de apoyo


A primera vista, Kotlin no tiene variables y métodos estáticos. No existen tales conceptos en este lenguaje, pero hay un concepto de objetos auxiliares. Son objetos únicos en una clase que contienen métodos y variables a los que puede acceder de forma estática. Un objeto complementario permite ciertas constantes y métodos, similares a las clases estáticas en Java. Con él, puede seguir el nuevo patrón de fragmento de entrada.

Eche un vistazo al objeto complementario en su forma más simple:

 class User { companion object { const val DEFAULT_USER_AGE = 30 } } //      : user.age = User.DEFAULT_USER_AGE 


En Android, usualmente usamos métodos y variables estáticas para crear fábricas estáticas para fragmentos. Por ejemplo:

 class ViewUserActivity : AppCompatActivity() { companion object { const val KEY_USER = "user" fun intent(context: Context, user: User): Intent { val intent = Intent(context, ViewUserActivity::class.java) intent.putExtra(KEY_USER, user) return intent } } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_cooking) val user = intent.getParcelableExtra<User>(KEY_USER) //... } } 

Crear una intención es similar a una acción similar en Java:

 val intent = ViewUserActivity.intent(context, user) startActivity(intent) 

Este patrón es bueno porque reduce la probabilidad de que Intent o Fragment no tenga los datos necesarios para mostrar contenido definido por el usuario o cualquier otro contenido. Los objetos complementarios son una forma de preservar el formulario de acceso estático en Kotlin, y deben usarse para compensar la falta de clases.

Constantes globales


Kotlin le permite definir constantes que son visibles en un lugar de la aplicación (si corresponde). Pero el alcance de las constantes debe minimizarse tanto como sea posible. Y en situaciones en las que desea que una región sea global, Kotlin tiene una excelente manera de hacerlo sin tener que usar una clase constante. Algo como:

 package com.myapps.example import android.support.annotation.StringDef //   ,  ! const val PRESENTATION_MODE_PRESENTING = "presenting" const val PRESENTATION_MODE_EDITING = "editing" 

Luego se pueden usar como constantes en cualquier parte del proyecto:

 import com.savvyapps.example.PRESENTATION_MODE_EDITING val currentPresentationMode = PRESENTATION_MODE_EDITING 

Las constantes en el proyecto deben ser lo más pequeñas posible para reducir su complejidad. Si tiene un valor que se aplica solo a una clase personalizada, es mejor ponerlo en un objeto auxiliar.

Extensiones


Las extensiones son útiles porque le permiten agregar funcionalidad de clase sin heredarla. Por ejemplo, ¿cómo agregar algún método a la hideKeyboard() como hideKeyboard() ? Usando extensiones, puede hacer esto fácilmente:

 fun Activity.hideKeyboard(): Boolean { val view = currentFocus view?.let { val inputMethodManager = getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager return inputMethodManager.hideSoftInputFromWindow(view.windowToken, InputMethodManager.HIDE_NOT_ALWAYS) } return false } 

Las extensiones son útiles porque:

  • Ayuda a mejorar la legibilidad del código
  • Eliminar la necesidad de crear clases y métodos de utilidad.

Puede ir más allá y mejorar la arquitectura del código. Imagine que tiene un modelo básico, por ejemplo, Artículo , que se considera como una clase de datos extraídos de una fuente por API:

 class Article(val title: String, val numberOfViews: Int, val topic: String) 

Es necesario determinar la relevancia del artículo para el usuario con base en alguna fórmula. ¿Deberías ponerlo directamente en la clase Artículo? Y si el modelo debe contener solo datos de la API, nada más, las extensiones se pueden usar nuevamente:

 fun Article.isArticleRelevant(user: User): Boolean { return user.favoriteTopics.contains(topic) } 

Esta es actualmente una manera fácil de verificar la presencia de un tema de artículo en su lista de temas favoritos.

Esta lógica puede variar según dónde desee probar estos y otros atributos del comportamiento del usuario. Dado que esta lógica es compatible hasta cierto punto, independientemente del modelo del artículo , puede cambiarla según el propósito, el método y su capacidad de cambio.

Source: https://habr.com/ru/post/480534/


All Articles