Improvement/navigation architecture#73
Conversation
…on viewmodel implemented
…into improvement/navigation-architecture # Conflicts: # app/src/main/java/com/architectcoders/equipocinco/ui/fragment/master/child/FavouriteMoviesFragment.kt # app/src/main/res/layout/activity_main.xml # presentation/src/main/java/com/architectcoders/presentation/viewmodels/MovieViewModel.kt
| bundleOf(DetailMovieFragment.MOVIE_ID_KEY to it.id) | ||
| ) | ||
| } | ||
| adapter = MovieAdapter(items.toMutableList(), viewModel::onSelectedMovie) |
There was a problem hiding this comment.
aqui es donde me referia que no rastreabamos la accion del onClick en una peli. Ahora si que le pasamos al viewModel la accion(onSelectedMovie) y de esta manera ya podemos testear este logica-flow
|
|
||
| fun onSelectedMovie(movie: Movie) { | ||
| _modelNavigation.value = Event( | ||
| NavigationModel(movie) |
There was a problem hiding this comment.
he añadido Event aqui, de otro modo cuando vuelva atras a Movies desde Details Screen, ya se ha consumido y no vuelva de nuevo a Details instantaneamente
| R.anim.slide_in_from_left, | ||
| R.anim.slide_out_to_right | ||
| ).build() | ||
| fragmentHideStrategy = FragNavController.DETACH_ON_NAVIGATE_HIDE_ON_SWITCH |
There was a problem hiding this comment.
Aqui puedes personalizar la estrategia del stack de fragments, ahora tenemos DETACH_ON_NAVIGATE_HIDE_ON_SWITCH que basicamente significa q en nuestro caso siempre tendria 3 vistas en memorias a la vez, no importa en que nivel de profundidad estes. Por ejemplo: si estas en detailMovie del TAB de popularMovies, tendrías en memoria estas 3, DetailScreen(de popularMovie), TopRatedScreen y FavouriteScreen , y si le das hacia atras desde DetailScreen, tendrias ahora estas vistas PopularMovie, TopRatedScreen y FavouriteScreen en memoria
There was a problem hiding this comment.
cuando vas en niveles dentro de un mismo TAB, por ej. desde PopularMovies a detail, se hace un detach del fragment de modo que se destruye la View del fragment de PopularMocies pero queda la instancia del objeto en memoria, y en consecuencia el ViewModel sobrevive tambien conteniendo en sus LiveDatas los ultimos valores. Por eso tuve que hacer un wrapper del object Navigation en un Event en el onSelectedMovie y preguntar si ya se habia consumido anteriormente, de otro modo me volveria de nuevo al detailscreen y no me dejaria ir nunca hacia atras
There was a problem hiding this comment.
Brutal! Gracias por la explicación!
| class FavouriteMoviesFragment : MoviesFragment(){ | ||
| class FavouriteMoviesFragment : MoviesFragment() { | ||
|
|
||
| companion object; |
There was a problem hiding this comment.
¿Esto para qué se usa? Por cierto, no sabía que se podía declarar así, en vez de llaves, concerrando con punto y coma. He visto que si no se pusiera, da un error de compilación.
There was a problem hiding this comment.
Perdona Gabi por la tardanza, es simplemente para indicar que tenemos una extension del companion object en otro archivo. Si te das cuenta tenemos un newInstance para crear el objeto moviesFragment en uno de los extension files. Kotlin te obliga a q pingas companion object para dejar saber q hay una parte estatica inplementada en otro lado
There was a problem hiding this comment.
En resumen lo puse para no poner el newInstance en el fragment y dejarlo mas limpio y legible
There was a problem hiding this comment.
Perfect! No tenía ni idea. Muchas gracias por la explicación! 😊
There was a problem hiding this comment.
Yo tampoco tenía ni idea! =O Gracias por la explicación caballero!
Nombre del branch:
navigation-architecture
Descripcion
-pass the button click action to the ViewModel in order to make it testable
-remove navigation bar
-add fragnav library https://github.com/ncapdevi/FragNav
Pull request checklist: