studio example descargar compiler codelabs android kotlin

android - example - kotlin ios



Kotlin: const val vs val (3)

Entiendo que en Kotlin const val se usa para declarar constantes y val es para propiedades de solo lectura. Sin embargo, me pregunto en el siguiente caso, cuál es el más adecuado para usar.

Supongamos que tengo un fragmento que necesita una clave para usar para saveInstanceState y restoreInstanceState . Me pregunto cuál de las siguientes 2 opciones es mejor:

Opción 1:

class MyFragment { private val MY_KEY = "my_key" ... }

Opcion 2:

private const val MY_KEY = "my_key" // declared in the same file. class MyFragment { ... }

Prefiero la #opción 2, ya que deja claro que MY_KEY es una constante y el valor se determina en tiempo de compilación. Sin embargo, como se declara en el nivel superior, cuesta una clase, es decir, MyFragmentKt (suponiendo que el nombre del archivo es MyFragment.kt ) que se creará en el código java compilado. En #option 1, no se genera ninguna clase adicional y aunque el valor de MY_KEY se asignará en tiempo de ejecución y no es constante, eso no hace ninguna diferencia en cómo se usa en este caso específico.

Entonces, aunque personalmente prefiero #option 2, mi análisis me hace pensar que #option 1 no es peor, si no mejor. Me pregunto cómo piensan otros desarrolladores sobre esto y si hay otros beneficios de #option 2 que no haya pensado. Gracias.


Cada vez que escribe una expresión lambda (no en línea), ha creado otra clase. Comparado con eso, crear una clase única para mantener declaraciones de nivel superior parece ser algo secundario.

Además, si todo lo que tiene en el nivel superior es una declaración constante, se incluirá en cada sitio de uso (por especificación), por lo que la clase propietaria quedará sin referencia y, por lo tanto, será minimizada por ProGuard. Lo más probable es que no aparezca en tu APK de producción.


Creo que la Opción # 2 es la manera correcta.


No hay solo una diferencia semántica entre las dos opciones.

La opción 1 ( val dentro de la clase) es un campo de instancia.

La opción 2 ( const val nivel superior) es un miembro "estático" de nivel superior (aproximadamente, ya que la static no existe en Kotlin).

Por esta razón, tiene MyFragmentKt una clase MyFragmentKt : los miembros de nivel superior se compilan en una clase del nombre [Filename]Kt .

Consideraría una tercera opción:

class MyFragment { companion object { private const val MY_KEY = "my_key" } }

De esta manera, MY_KEY es (desde Java) un miembro static de la clase MyFragment , ya que JvmStatic se infiere para las variables const . Se generará una clase Companion (pero estará vacía).

Dado que su enfoque original era un campo dentro de la clase, creo que es preferible el companion object / constante static .

Más sobre companion object static contra la static de Java.