Creación de una serie de aplicaciones de podcasting: 2. Estado del jugador
Luego de configurar la panorama, es muy importante tener un maniquí que maneje la IU, podemos observar y renderizar la IU de acuerdo a su estado. Es mejor usar algún tipo de escucha para reaccionar a los cambios del maniquí, y sería magnífico si no tuviéramos que suscribirnos / suprimir la suscripción manualmente al maniquí. A Dios gracias, Android tiene una clase ViewModel creada para este propósito.
Ver maniquí
El modo de visualización es una invención relativamente nueva. Antiguamente de la aparición de ViewModels, representar todo el AAC (Componentes de la bloque de Android) de ViewModels de una forma limpia y segura era particularmente complicado. Las actividades o fragmentos de Android pueden estar en varios estados, y la conexión / desconexión correcta de actividades o fragmentos específicos puede ejecutar aproximadamente de onCreate / onDestrory, onResume / onPause y otros métodos del ciclo de vida. Transmitido que nuestra panorama del reproductor en la aplicación es visible en todas las pantallas, necesitamos un titular de estado accesible conjuntamente para el reproductor. A Dios gracias, necesitamos ViewModel para compartir de forma segura el estado del reproductor entre diferentes clips. Transmitido que estamos usando un modo de actividad único, ViewModels se vinculará automáticamente a la actividad y se puede compartir entre fragmentos. Esto significa que podemos decirle fácilmente a otras vistas el estado de nuestro reproductor en la aplicación simplemente compartiendo un ViewModel entre múltiples fragmentos. Ah, y por cierto, ViewModels puede permanecer los cambios de configuración, por lo que igualmente debe prestar atención a esto.
Entonces, ¿cómo creamos un nuevo maniquí de panorama?Simplemente podemos escribir cualquier fragmento
private val playerViewModel by sharedViewModel<PlayerViewModel>()
La idea básica aquí es que a ViewModels no le importa quién esté usando su LiveData, puede ser un solo fragmento o un liga, no importa. Los ViewModels no deben hacer narración a ningún Fragmento o Actividad, solo exponen datos para que View los observe.
Si tiene curiosidad sobre el código de PlayerViewModel, consulte este enlace
Datos en tiempo efectivo
Una vez que tengamos un titular de estado compartido para los jugadores, necesitamos una forma segura de refrescar nuestras vistas. Aquí es donde entra LiveData. Es un contenedor seguro para cualquier tipo de datos. La mejor parte de LiveData es que puede memorizar automáticamente si nuestro segmento o actividad está activo y puede percibir actualizaciones, ¡así que no tenemos que bregar con esta método nosotros mismos! Esto significa que no hay más excepciones de puntero torpe con excepciones de estado ilegal. Somos libres de informar nuevos datos en LiveData y asegurarnos de que no se bloqueen correcto a esto.
¿Cómo creamos y actualizamos datos en tiempo efectivo?
private val _currentlyPlaying = MutableLiveData<Episode>()
currentlyPlaying.value = currentEpisode
Modo repositorio
La parte final del rompecabezas estatal es determinar de dónde provienen nuestros datos. En recopilación: ¡desde el repositorio de Podcast! El modo de repositorio es un modo tan simple y muy útil. Podemos hacer que nuestro repositorio haga muchas cosas interesantes. Podemos juntar datos en distinción en una pulvínulo de datos circunscrito, podemos afectar datos, podemos obtener poco de Internet y todas las cosas relacionadas con los datos se recuperan ocultas detrás de nuestra clase Repository.
¿Cómo se ve un repositorio simple?
class PodcastRepository
fun getPodcasts(): List<Podcast> =
listOf(Podcast("The Joe Rogan experience"))
Configuración básica para cada pantalla
En recopilación, cada pantalla de nuestra aplicación hará narración a ViewModels y se suscribirá a LiveData. ViewModels obtendrá los datos del repositorio y actualizará LiveData, tenemos una configuración reactiva para cada pantalla en la aplicación. El manejo de errores se realiza de la misma forma, solo tenemos LiveData de mensajes de error, donde podemos empujar errores y observarlos en Fragmentos.
Explore el código completo en este enlace. Estén atentos para el próximo artículo de esta serie, exploraremos exoPlyaer, que es el cerebro detrás de cualquier aplicación de podcasting.
