Callbacks de Android convertidos en Flows

Curso de Android: Integración de APIs nativas

Contenido del curso

Introducción a la Integración Nativa en Android

Google Maps SDK

Servicios de Localización

Integración Maps con Localización

Manejo de permisos

Integración cámara

Servicios en Android

Transmisiones en Android (Broadcast)

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0014:50

Callbacks de Android convertidos en Flows

Curso de Android: Integración de APIs nativas

Clase 10 de 33

Clase 10 / 33

Recursos

Obtener la ubicación de un usuario en Android no es solo pedirle al GPS que entregue coordenadas. Implica mapear modelos, validar permisos, vigilar el hardware y traducir callbacks del sistema operativo a flows de corrutinas. Aquí verás cómo construir esa capa de datos con una arquitectura limpia, lista para sobrevivir cambios futuros.

Por qué necesitas un mapper entre Location de Android y tu modelo de dominio

Android trae su propia clase Location cargada de propiedades que tu aplicación probablemente no necesita. Por eso el primer paso es crear una carpeta data con un LocationMapper que traduzca esa clase nativa a la tuya, definida en domain [00:14].

La solución es una extension function sobre android.location.Location llamada toLocation(), que devuelve tu modelo propio asignando latitud y longitud:

kotlin fun android.location.Location.toLocation(): Location { return Location( lat = latitude, long = longitude ) }

¿Para qué sirve un mapper en arquitectura limpia? Aísla tu dominio de las clases del framework. Si mañana migras de plataforma, solo cambias el mapper, no toda tu lógica de negocio.

Cómo definir un contrato con la interfaz LocationObserver

Dentro de domain/location agregas una interfaz llamada LocationObserver con una función observeLocation() que devuelva un Flow de tu modelo Location [01:05]. Esa interfaz es un contrato: cualquier clase que la implemente promete entregar ubicaciones siguiendo tu propio formato.

La ventaja es que tu capa de datos queda desacoplada. Si necesitas cambiar de proveedor de localización, escribes una nueva implementación y listo. El resto de la aplicación no se entera.

kotlin interface LocationObserver { fun observeLocation(interval: Long): Flow<Location> }

Revisa que importes tu propio Location y los Flow de corrutinas, no los de Java o Android.

Cómo implementar AndroidLocationObserver con callbackFlow

En la carpeta data creas la clase AndroidLocationObserver que implementa la interfaz [01:55]. Por inyección de dependencias recibes el Context de Android y construyes el cliente de Google Play Services:

kotlin class AndroidLocationObserver @Inject constructor( private val context: Context ) : LocationObserver { private val client = LocationServices.getFusedLocationProviderClient(context) }

Para devolver un Flow desde un sistema basado en callbacks, usas callbackFlow, un tipo de flow especial diseñado para traducir esos callbacks tradicionales de Android al mundo de las corrutinas [02:35].

Qué tres tareas debe resolver el observer

Dentro de callbackFlow cubres tres frentes:

Verificar que el GPS y la red estén activos en el dispositivo.
Validar que el usuario haya otorgado los permisos correctos.
Mapear el Location de Android al modelo del dominio.

Cómo verificar si el GPS y la red están activos

Obtienes el LocationManager desde el context y declaras dos banderas, isGpsEnabled e isNetworkEnabled, ambas en false. Luego entras a un loop que las actualiza en cada iteración consultando locationManager.isProviderEnabled para GPS_PROVIDER y NETWORK_PROVIDER [03:20].

Si ninguno está habilitado, el flow espera con un delay de tres segundos antes de volver a verificar. Tres segundos es razonable: el usuario no va a activar permisos en milisegundos, así que no tiene sentido saturar el bucle.

Cómo validar permisos de localización en Android

Android distingue entre dos permisos clave para ubicación:

ACCESS_FINE_LOCATION para localización exacta (GPS).
ACCESS_COARSE_LOCATION para localización aproximada (red).

Usas ActivityCompat.checkSelfPermission(context, ...) y comparas el resultado con PackageManager.PERMISSION_GRANTED. Si alguno falla, simplemente no emites valores, evitando una SecurityException del sistema operativo [05:00].

¿Por qué necesito declarar permisos en el manifiesto si ya los pido en código? Android exige que los permisos estén listados en el AndroidManifest.xml antes de compilar. El chequeo dinámico solo confirma si el usuario los aceptó en tiempo de ejecución.

En el manifiesto, antes de la etiqueta <application>, agregas:

xml <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

En cuanto los declaras, el error de compilación que pedía permisos requeridos desaparece.

Cómo emitir ubicaciones con trySend y LocationCallback

Con los permisos validados, pides la última ubicación al cliente con lastLocation.addOnSuccessListener. Si el resultado no es nulo, usas el operador let y llamas a trySend(location.toLocation()). Esa función trySend es la pieza clave que convierte un callback en una emisión del flow [06:30].

Pero lastLocation solo entrega un valor inicial. Para recibir actualizaciones continuas necesitas un LocationRequest y un LocationCallback:

kotlin val request = LocationRequest.Builder(interval) .setPriority(Priority.PRIORITY_HIGH_ACCURACY) .build()

val locationCallback = object : LocationCallback() { override fun onLocationResult(result: LocationResult) { result.locations.lastOrNull()?.let { location -> trySend(location.toLocation()) } } }

client.requestLocationUpdates(request, locationCallback, Looper.getMainLooper())

La prioridad PRIORITY_HIGH_ACCURACY indica al sistema que quieres precisión máxima, y el interval define cada cuánto pedir actualizaciones [07:50].

Por qué cerrar recursos con awaitClose

Cuando el consumidor del flow deja de observar, necesitas detener las actualizaciones para no consumir batería en vano. Lo haces con awaitClose, donde llamas a client.removeLocationUpdates(locationCallback) [09:10]. Sin este cierre, el cliente seguiría emitiendo aunque nadie escuche.

Usar sensores del sistema operativo es complejo: pedir permisos, vigilar hardware y traducir callbacks a flows requiere disciplina. ¿Ya tienes tu AndroidLocationObserver corriendo? Cuéntame en los comentarios si te apareció alguna SecurityException y cómo la resolviste.

Resumen

Por qué necesitas un mapper entre Location de Android y tu modelo de dominio

La solución es una extension function sobre android.location.Location llamada toLocation(), que devuelve tu modelo propio asignando latitud y longitud:

kotlin fun android.location.Location.toLocation(): Location { return Location( lat = latitude, long = longitude ) }

¿Para qué sirve un mapper en arquitectura limpia? Aísla tu dominio de las clases del framework. Si mañana migras de plataforma, solo cambias el mapper, no toda tu lógica de negocio.

Cómo definir un contrato con la interfaz LocationObserver

La ventaja es que tu capa de datos queda desacoplada. Si necesitas cambiar de proveedor de localización, escribes una nueva implementación y listo. El resto de la aplicación no se entera.

kotlin interface LocationObserver { fun observeLocation(interval: Long): Flow<Location> }

Revisa que importes tu propio Location y los Flow de corrutinas, no los de Java o Android.

Cómo implementar AndroidLocationObserver con callbackFlow

kotlin class AndroidLocationObserver @Inject constructor( private val context: Context ) : LocationObserver { private val client = LocationServices.getFusedLocationProviderClient(context) }

Qué tres tareas debe resolver el observer

Dentro de callbackFlow cubres tres frentes:

Verificar que el GPS y la red estén activos en el dispositivo.
Validar que el usuario haya otorgado los permisos correctos.
Mapear el Location de Android al modelo del dominio.

Cómo verificar si el GPS y la red están activos

Cómo validar permisos de localización en Android

Android distingue entre dos permisos clave para ubicación:

ACCESS_FINE_LOCATION para localización exacta (GPS).
ACCESS_COARSE_LOCATION para localización aproximada (red).

¿Por qué necesito declarar permisos en el manifiesto si ya los pido en código? Android exige que los permisos estén listados en el AndroidManifest.xml antes de compilar. El chequeo dinámico solo confirma si el usuario los aceptó en tiempo de ejecución.

En el manifiesto, antes de la etiqueta <application>, agregas:

xml <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

En cuanto los declaras, el error de compilación que pedía permisos requeridos desaparece.

Cómo emitir ubicaciones con trySend y LocationCallback

Pero lastLocation solo entrega un valor inicial. Para recibir actualizaciones continuas necesitas un LocationRequest y un LocationCallback:

kotlin val request = LocationRequest.Builder(interval) .setPriority(Priority.PRIORITY_HIGH_ACCURACY) .build()

val locationCallback = object : LocationCallback() { override fun onLocationResult(result: LocationResult) { result.locations.lastOrNull()?.let { location -> trySend(location.toLocation()) } } }

client.requestLocationUpdates(request, locationCallback, Looper.getMainLooper())

La prioridad PRIORITY_HIGH_ACCURACY indica al sistema que quieres precisión máxima, y el interval define cada cuánto pedir actualizaciones [07:50].

Por qué cerrar recursos con awaitClose

Introducción a la Integración Nativa en Android

API nativas de Android con Kotlin y Compose

Configuración inicial de proyecto Android con Kotlin DSL y Hilt

Google Maps SDK

Configuración de API key de Google Maps para Android

Creación de marcadores personalizados en Google Maps con Compose

Cómo dibujar polilíneas en mapas con Jetpack Compose

Centrado automático de mapas con Camera Update Factory

Servicios de Localización

Kotlin Flows para medir tiempo en Android

Simulación de ubicación GPS en emulador y dispositivo Android

Modelos de localización propios con Clean Architecture

Callbacks de Android convertidos en Flows

Inyección de dependencias para observar localización en Android

LocationTracker con StateFlow para rastreo en Android

State Flows para controlar localización y tiempo en Kotlin

Configuración y pruebas de Location Tracker en Android

Integración Maps con Localización

Integración de ubicación actual en mapas interactivos

Creación de polilíneas con datos reales en mapas de Android

Integración de intents y estados en pantalla mapa con Compose

TrackingMapViewModel con Hilt y StateFlow

Manejo de permisos

Permisos de Android en tiempo de ejecución

Creación de diálogos de permisos reutilizables en Android

Gestión de permisos de localización y notificaciones en Android

Implementación de solicitud de permisos con LaunchedEffect en Compose

Integración cámara

Cómo guardar fotos en Android con PhotoHandler

Conversión de Bitmaps a Byte Arrays con Extension Functions

CameraViewModel con Hilt y StateFlow

Configuración de métodos del ViewModel para gestión de cámara

Integración de CameraX con Jetpack Compose en Android

Creación de pantalla de previsualización de fotos con Jetpack Compose

Galería de fotos en marcadores del mapa

Servicios en Android

Servicios en segundo plano en Android

Configuración de foreground services y notificaciones en Android

Transmisiones en Android (Broadcast)

Broadcast Receivers para escuchar eventos del sistema en Android

Prueba completa de aplicación Android con cámara y localización

Callbacks de Android convertidos en Flows