Los usuarios esperan disfrutar de una experiencia fluida con tu app. Las fallas pueden producir un incremento en las opiniones negativas y las desinstalaciones e incluso dañar la percepción sobre tu producto. A partir del diálogo con la comunidad, sabemos que una de las razones principales para adoptar Kotlin es obtener un código más seguro. En esta publicación, compartiremos algunas de las maneras en que Kotlin mejoró la estabilidad de algunos de los códigos de nuestros socios y también observaremos los resultados de algunas de las estadísticas de Google Play Store y veremos si existe una correlación entre el uso de Kotlin y la cantidad de fallas (spoiler: ¡las hay!).
Calidad de la app
La calidad de tu app no solo influye en la experiencia del usuario. Hay varios otros elementos que se verán afectados por una gran cantidad de fallas:
- Visibilidad de la app: las recomendaciones de Google Play Store constan de una combinación de tratamiento humano y cálculos algorítmicos, de los cuales la calidad es una de las principales consideraciones.
- Producto: el rendimiento de tu producto puede afectar las calificaciones y opiniones que recibas, lo que puede tener un impacto sobre la percepción de este.
- Números más altos de usuarios (interesados): la mejora del tráfico orgánico y la percepción de la marca pueden generar una mejor captación y retención de usuarios, lo que también puede tener un impacto sobre la participación y las métricas de la parte inferior del embudo.
Las apps integradas con Kotlin tienen un 20 % menos de probabilidades de sufrir fallas.
¿Qué función desempeña Kotlin en esto? Analizamos las 1000 apps principales de Google Play y observamos que las que usan Kotlin tienen un 20 % menos de fallas por usuario que las que no lo hacen.
Un ejemplo de esto se puede hallar en el equipo de ingeniería de Swiggy, de cuyo código el 74 % está compilado en Kotlin; este equipo observó una reducción del 50 % en las fallas desde que el nuevo desarrollo de características pasó a Kotlin.
Cómo evitar NullPointerExceptions
La principal causa de fallas en Google Play son NullPointerExceptions. En 2018, el equipo de Google Home comenzó a escribir todas las nuevas características en Kotlin y observó una disminución del 33 % en las fallas de puntero nulo durante el plazo de un año.
Google Home observó una disminución del 33 % en las NullPointerExceptions
Para evitar NullPointerExceptions, debes asegurarte de que las referencias del objeto con el que estás trabajando sean no nulas antes de llamar a métodos para ellas o de intentar acceder a sus miembros. En Kotlin, la nulabilidad es parte del sistema de tipo. Por ejemplo, se debe declarar una variable como anulable o no anulable antes de comenzar. A la hora de convertir la parte de nulabilidad del sistema de tipo, no es necesario que recurras a lo que recuerdes o conozcas sobre la base de código ni a las advertencias de tiempo de compilación (si comentas tus campos y parámetros con @Nullable). Se aplica, más bien, la nulabilidad para que obtengas errores de tiempo de compilación y no solo advertencias. Para consultar maneras en las que puedes controlar la nulabilidad, visita esta página.
Cómo evitar problemas comunes
Los desarrolladores ingresan muchos problemas sin darse cuenta, y muchos de ellos pueden ser bastante sutiles y difíciles de investigar. Aquí hay algunos ejemplos de esta clase de problemas que se evitan cuando se usa Kotlin.
hashCode() y equals()
Si dos objetos son iguales, su hashcode debe ser el mismo; sin embargo, olvidarse de implementar uno de estos métodos o actualizarlos cuando se agregan nuevas propiedades a la clase es algo normal. Al trabajar con estas clases cuyas funciones son solo las de contener datos, usa las clases de datos de Kotlin. Con las clases de datos el compilador genera hashCode() y equals(), y estos se actualizan de forma automática cuando cambias las propiedades de las clases.
Comparación de igualdad estructural e igualdad referencial
¿Dos objetos son iguales a nivel estructural (tienen contenido equivalente) o iguales de forma referencial (sus punteros son los mismos)? En el lenguaje de programación Java, para los primitivos siempre debes usar ==; por lo tanto, un error común es también llamar == (igualdad referencial) a objetos, cuando lo que en verdad quieres es controlar si son iguales a nivel estructural (verificados al llamarlos equals()). Primero, Kotlin no tiene tipos primitivos, sino que usa clases como Int o String; esto significa que ya no es necesario que realices esta diferenciación entre objetos y tipos primitivos, puesto que todo es un objeto. Segundo, Kotlin definido == para igualdad estructural y === para igualdad referencial a fin de que no controles la igualdad referencial cuando no deberías.
Cuando «if else if else if else» no es suficiente
Cuando se trabaja con enums, con frecuencia necesitarás asegurarte de que estás cubriendo todos los casos posibles. Esto conduce a usar un interruptor o una cadena de varios «if else». Cuando modificas tu enum para agregar un nuevo valor, deberás controlar manualmente cada fragmento de código donde estés usando el enum y asegurarte de estar manejando el caso nuevo. Pero esto es propenso a errores. En Kotlin, puedes confiar que el compilador haga esto si estás usando el parámetro «when» como expresión: si no estás cubriendo todas las ramificaciones posibles, aparecerá un error del compilador.
Conclusión
La estabilidad de tu app es importante para tus usuarios y tu marca. Comienza a utilizar Kotlin para reducir las tasas de fallas, mantener a tus usuarios contentos y estar al tanto de tu retención y adquisición manteniendo una alta calificación de la app.
Obtén más información sobre Cómo compilar mejores apps con Kotlin y observa cómo se han beneficiado los desarrolladores de Kotlin a través de la lectura de nuestros casos de éxito. Para comenzar con Kotlin, uno de los lenguajes más populares en el mundo, visita nuestra página Primeros pasos.
Source: Google Dev