Una actualización: ahora lifecycleScope.launchWhenX está obsoleto, en su lugar deben usar lifecycle.launch{ repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.spinner.collect {} } } ¿Por qué? Porque lifecycleScope sigue recolectando los valores del flow aún cuando la activity está en background (estado Stopped), lo que puede inundar tu memoria. Sin embargo, con lifecycle & repeatOnLifecycle son seguras de llamar porque tienen en cuenta el ciclo de vida de la activity.
@devexpert_io Жыл бұрын
Así es, muchísimas gracias por el comentario.
@Palettha232 жыл бұрын
Woah! Hace años (2016) 🥺 aprendí a programar contigo en tu curso de Udemy, gracias por compartir tanto y por seguir compartiendo a esta comunidad. Te reconocí por la voz y ahora que me fui a tu git recordé tu nombre 🙌🏼 (woah si me da nostalgia 🥲)
@devexpert_io2 жыл бұрын
Gracias! Aunque nunca publiqué ninguno de mis cursos en Udemy 😁
@Palettha232 жыл бұрын
@@devexpert_io haha sí cierto! Ya vi y fue con Javier Villena pero entonces algo aprendí contigo en el camino porque tu nombre me suena mucho. Igual muchas gracias porque el uso de flow me enreda! Gracias por tu tiempo.
@devexpert_io2 жыл бұрын
@@Palettha23 Muchas gracias, un placer poder ayudaros en lo que pueda! 😀
@devexpert_io4 жыл бұрын
🎁 Si aún no te decides sobre si Kotlin es el lenguaje que deberías aprender, te animo a que te apuntes a mi masterclass gratuita 👉 bit.ly/3nmCbBm
@albertmartorellgarcia85284 жыл бұрын
Hola Antonio. Cómo gestionamos el caso en que, por ejemplo, al entrar el usuario en una pantalla se carga una lista de elementos y se produce un error y mostramos un mensaje? Este mensaje solo se tiene que enseñar una vez, o sea que si después del error rotamos la pantalla dicho mensaje no se tiene que volver a mostrar. Con LiveData lo solucionamos con un wrapper que determina si ese evento ya se ha consumido o no, para mostrar o no dicho mensaje. Gracias!
@devexpert_io4 жыл бұрын
Pues la verdad que aún no me lo he planteado. Quizá serviría el SharedFlow para eso pero me lo tengo que estudiar
@nonofce4 жыл бұрын
Quizas sea porque al crearse nuevamente la Activity al rotar la pantalla se crea un nuevo subscriptor al StateFlow, y como este siempre emite el ultimo valor obtienes el mismo mensaje en el collector. MutableSharedFlow tiene un metodo "resetReplayCache" que quizas sirva. kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-mutable-shared-flow/reset-replay-cache.html
@alvarogarnett3 жыл бұрын
Es una cuestión muy interesante y que espero que Antonio trate más adelante, yo he encontrado la solución utilizando SharedFlow en vez de StateFlow. Ya que está pensado para emitir eventos una única vez, por lo que el problema se soluciona (aunque también se puede configurar a tu gusto con el parámetro replay). Pero no me convence del todo porque cada vez que se quiera realizar un emit() se debe realizar dentro de una coroutine obligatoriamente y habrá casos en los que no se requiera el uso de ellas. Antonio si encuentras alguna manera de realizar con StateFlow el comportamiento de un SingleLiveEvent sería un gran acierto! O a lo mejor el planteamiento es erróneo y no está pensado para ello StateFlow
@devexpert_io3 жыл бұрын
Se me había olvidado esto! Le echo un ojo
@nonofce4 жыл бұрын
Excelente Antonio, gracias. He visto que StateFlow tiene un hermano mayor, SharedFlow, ¿algun criterio de cuando usar uno u otro? ¿Que aporta StateFlow sobre SharedFlow?
@devexpert_io4 жыл бұрын
SharedFlow me lo tengo que estudiar todavía. Pero es lo más parecido a un bus de eventos, cualquiera se puede conectar en cualquier momento y recibe los valores que se emitan a partir de ese momento. Se puede también definir el buffer de valores antiguos que almacena. Se diferencia de un Flow normal en que cuando te conectas a un Flow recibes todos los valores desde el principio de la cadena, no solo los nuevos que recibas.
@nonofce4 жыл бұрын
@@devexpert_io Perfecto Antonio, muchas gracias.
@monkycheaky46803 жыл бұрын
Excelente video.. solo tengo una duda, livedata conoce el ciclo de vida, pero y stateflow?
@devexpert_io3 жыл бұрын
StateFlow no, tiene que conocerlo el contexto de corrutina en el que se ejecuta. Por eso hay que hacer el "launchWhenStarted", e incluso con esto hay algún pequeño caso que se escapa. De esto haré otro vídeo pronto.
@johnalejandrogarciaarias97563 жыл бұрын
Hola Antonio! Como siempre aportando excelente contenido. Te quería preguntar ¿tienes algún video en donde expliques por qué usar flow - stateFlow en vez de liveData?. Saludos! 🤗
@devexpert_io3 жыл бұрын
Sobre el porqué no tengo ninguno. Pero te diría que si no usas corrutinas ni flows en tus proyectos, tires por LiveData, en caso contrario ya StateFlow. Mira, aquí hablan más sobre el tema, aunque aún no he tenido mucho tiempo de verlo: medium.com/androiddevelopers/migrating-from-livedata-to-kotlins-flow-379292f419fb
@johnalejandrogarciaarias97563 жыл бұрын
@@devexpert_io Mil gracias!
@i12capea4 жыл бұрын
Buen vídeo, ya lo estoy aplicando en mi proyecto personal. ¿Es necesario hacer algo en onStopped o similar para cancelar el flujo? LiveData se supone que lo hace por estar vinculado al ciclo de vida, pero StateFlow no ¿verdad? Un saludo!
@devexpert_io4 жыл бұрын
Se supone que lo hace si días launchWhenStarted. Tengo alguna duda porque en la documentación de Google pone como 2 warnings de que hay que tener cuidado con eso. Pero en particular StateFlow creo que funciona sin problema y que con los que puede haber algún problema es con los Flows normales
@johnfriend2010 Жыл бұрын
no encuentro ese video donde dice q dava problemas con livedata
@devexpert_io Жыл бұрын
A qué te refieres?
@samuelcandelaperal35152 жыл бұрын
Hola, en el caso del collect, si yo el valor por defecto lo tengo en un ViewModel y luego en otro Fragment, instancio el viewmodel y observo el MutablestateFlow, el cual he cambiado su valor al hacer un .launch en el viewmodel, emitiendo asi, su nuevo valor. El problema es que me colecta el valor por defecto, y no el cambiado. Cual seria la forma correcta de hacer esto bien entonces.
@devexpert_io2 жыл бұрын
Ahí suena a que hay algo raro, debería coger siempre el último valor almacenado. Puede que pase por el anterior según lo que ocurra primero, pero siempre debiría emitir el último si lo estás observando correctamente
@samuelcandelaperal35152 жыл бұрын
@@devexpert_io cuando hago el launch, dentro, es donde cambio el valor de esta variable
@mauridom3 жыл бұрын
Pregunta fuera de contexto, ¿qué tema usas para Android Studio? Gracias!
@devexpert_io3 жыл бұрын
Buenas! Uso Darcula, el oscuro que viene por defecto en el IDE
@eduartml22663 жыл бұрын
Y yo apenas aprendí livedata 😱😱😱😱😱😱😱😱😱😱😱
@devexpert_io3 жыл бұрын
Jejeje esto evoluciona tan rápido...
@andresandreoli6772 жыл бұрын
Muy buen video, me re sirvió este video, pero tengo una consulta, dijiste que la diferencia entre liveData y stateFlow es que esta ultima no esta atado al framework de Android, de tal forma que lo podes implementar en donde quieras, a que te referis con el framework de Android? Saludoss y gracias por estos videos
@devexpert_io2 жыл бұрын
El framework de Android es un conjunto de clases que te permiten crear Apps que luego se compilan para crear un ejecutable que se puede reproducir en dispositivos Android. Imagina que hay una parte de ese código que lo quieres usar por ejemplo para escritorio en un proyecto multiplataforma. Si utilizas LiveData, ese código no se va a poder usar para Desktop porque no estás creando una App Android. Con StateFlow no tienes esa limitación.
@felipefranco74444 жыл бұрын
Hola Antonio creo que se te ha caido la app haciendo scroll.
@devexpert_io4 жыл бұрын
A qué te refieres?
@devexpert_io4 жыл бұрын
Ah creo que ya sé lo que dices. Es porque venía una película sin carátula, y no tengo ese caso controlado en el código