Tinder usa componentes de la arquitectura de Android a fin de solucionar errores en su app para citas

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Tinder es la app de citas más popular del mundo. Es famosa porque cambió la manera en que las personas se conocen y tienen citas, y porque les permite a los usuarios conectarse con otras personas y chatear con solo deslizar el dedo hacia la derecha. En Tinder, se producen más de 26 millones de coincidencias al día, y, desde su lanzamiento en 2012, el total alcanza los 20,000 millones.

Debido a la demanda de los usuarios, la empresa tuvo que ampliar la app con rapidez. Sin embargo, la implementación de la base de datos era la misma desde sus inicios, de manera que cada vez se hacía más complicado expandirla. También tenían una arquitectura pesada en cuanto a visualizaciones a fin de reducir las complejidades del ciclo de vida, pero necesitaban saber qué eventos eran específicos de una actividad. La empresa no contaba con un marco de trabajo coherente para manejar ciertas tareas, como la agrupación de elementos Cursor en objetos de dominio, las migraciones de bases de datos o la formulación de consultas de rendimiento de manera constante.

Qué hizo la empresa

Imagen de un perfil

Figura 1: Foto de una fotógrafa en Tinder

Tinder acudió a los componentes de la arquitectura de Android para obtener soluciones que le permitieran actualizar su código. Se usó Lifecycle para permitir que View observara el ciclo de vida de su actividad de host y se empleó LifecycleObserver a fin de facilitar una arquitectura de complementos descentralizada y evitar la sobrecarga en los objetos Presenter, Activity y View. La biblioteca de persistencias de Room ofreció un método predeterminado para definir y administrar su base de datos local, además de realizar consultas.

El equipo de desarrollo de Tinder pudo implementar LifecycleObserver y la arquitectura de complementos en solo dos semanas, mientras que la implementación de Room para su SDK de anuncios internos solo llevó dos días.

"Ya no teníamos que dedicar mucho tiempo para administrar el ciclo de vida de Activity dentro de complementos o vistas", comenta Andy Lawton, jefe de Android en Tinder. "El diseño de Room está bien pensado y facilita la implementación de nuestra capa de persistencia. El uso de Room para el SDK de anuncios internos quizás nos permitió ahorrar una semana de tiempo en el desarrollo anticipado".

Resultados

En Tinder quedaron tan satisfechos con los resultados del SDK de anuncios que están migrando toda la capa de base de datos a Room. La etapa de pruebas fue sencilla y la protección de Room frente a los olvidos de registro redujo las fugas de memoria. Además, los componentes de la arquitectura de Android también ayudaron a reducir la huella de memoria.

"Los componentes de la arquitectura de Android fueron la receta perfecta para solucionar muchas de las dificultades que los desarrolladores tienen que enfrentar en distintas escalas", explica Lawton. "Mediante el uso de componentes optimizados para el ciclo de vida, Tinder consiguió mejorar la modularidad, la capacidad de prueba y la productividad del desarrollador, y, al mismo tiempo, optimizar la arquitectura para las visualizaciones. Room elimina la necesidad de recurrir a otras soluciones para administrar SQLite y convierte las consultas y la administración de la base de datos en un ejercicio de configuración".

Métrica

Se quitaron más de 500 líneas de código de MainActivity mediante la arquitectura de complemento de LifecycleObserver

Comenzar

Todos los desarrolladores pueden acceder a los componentes de la arquitectura de Android como parte de Android Jetpack. Comienza a usar los componentes de la arquitectura de Android.