Bienvenido a nuestra página, ahora vas a encontrar la resolución que estás buscando.
Solución:
Como puedes ver en De Google muestras (https://github.com/googlesamples/android-architecture), Activities crear Presenters. También Views adjuntar a Activity y Presenters obtener vistasFragments) como parámetro.
Después Fragment transacción comprometida o Fragment (ver) estado restaurado Presenters ser creado y tomar Fragments (vistas) como parámetro que llamar
view.setPresenter(T presenter);
métodos de vistas y Presenters regístrese para ver.
Creo que creando Presenter en Fragment no es una buena práctica. Primero que nada son capas separadas. Esto es ilegal para Separación de intereses. Y segundo, si crea un presentador en Fragment, vincula la vida de su Presentador a la vista LifeCycle y cuando Fragment se destruye y se vuelve a crear, creas un nuevo presentador pero son capas diferentes.
El modelo es una interfaz que define los datos que se mostrarán o sobre los que se actuará en la interfaz de usuario.
El presentador actúa sobre el modelo y la vista. Recupera datos de repositorios (el modelo) y los formatea para mostrarlos en la vista.
La vista es una interfaz pasiva que muestra datos (el modelo) y enruta los comandos del usuario (eventos) al presentador para actuar sobre esos datos.
Entonces Activity puede actuar como un overall controller que crea el Presenters y Views y conectarlos.
Si hablamos de tu pregunta, sí puedes registrar presentador en fragmento. Pero debe evitar crear presentadores en fragmentos que utilice como vista.
Pero hay muchos enfoques diferentes sobre el patrón MVP en la comunidad de Android, como a continuación. https://plus.google.com/communities/114285790907815804707
¿Por qué las actividades no son elementos de la interfaz de usuario? http://www.techyourchance.com/activities-android/
Si está utilizando una sola Actividad para alojar varios Fragmentos y también está utilizando Dagger 2 para inyectar el presentador que necesita, puede inyectar cada presentador a cada Fragmento directamente.
Mi caso de uso
Estoy haciendo un proyecto con arquitectura desde hace algunos meses desde que me enteré del componente de navegación jetpack de Android, comencé a migrar todas las vistas de mi aplicación a este patrón.
Entonces, me encontré con mucha refactorización al hacer el proceso y estaba en esta situación de no sé qué hacer con esta situación.
Como utilicé Dagger 2 desde el punto de inicio para inyectar a mis presentadores en mis Actividades, esto no cambiará mucho haciendo lo mismo pero con Fragmentos.
Me encontré con el mismo repositorio para verificar cómo se suponía que debía seguir la arquitectura con Fragments, que de hecho es una buena manera de crear una instancia del presentador dentro de la Actividad del host si solo tiene 1 Fragmento cuando era niño.
El caso es que si necesito tener varios Fragmentos dentro de una Actividad de host, debería hacer una instancia de cada presentador y pasarla a través de mi FragmentManager dentro de cada Fragmento y creo que no es lo que estaba viendo, ya que agrega múltiples instancias del presentador de la Actividad del anfitrión.
Esto lleva a un caso, tener varias instancias dentro de mi actividad de host para todos los presentadores, y también algunas interfaces para manejar la separación de trabajos / vistas si es necesario.
Una forma sencilla de hacerlo con varios fragmentos es simplemente no pensar en la actividad del anfitrión e inyectar a los presentadores dentro de cada fragmento.
Desde que hizo esto con Dagger, hace que la inyección sea más limpia.
Eche un vistazo a un ejemplo sencillo
class MainMenuActivity : BaseActivity()
override fun onCreate(savedInstanceState: Bundle?)
super.onCreate(savedInstanceState)
inflateMainFragment(savedInstanceState)
override fun getLayout(): Int
return R.layout.activity_main_menu
fun inflateMainFragment(savedInstanceState: Bundle?)
if (savedInstanceState == null)
val fragment = MainMenuFragment()
supportFragmentManager
.beginTransaction()
.add(R.id.nav_host_fragment, fragment)
.commit()
Como puede ver, aquí no tengo ninguna instanciación de los presentadores que toda mi navegación debería necesitar. En cambio, solo inyecto cada presentador que necesito dentro de cada Fragmento
class MapsFragment: BaseMapFragment(), MapContract.MapView
private lateinit var mMap: GoogleMap
@Inject
lateinit var presenter: MapsPresenter
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View?
return inflater.inflate(R.layout.fragment_paseo,container,false)
override fun onViewCreated(view: View, savedInstanceState: Bundle?)
super.onViewCreated(view, savedInstanceState)
(requireActivity().application as YawpApplication).getAppComponent()?.inject(this)
presenter.attachView(this)
setupToolbar()
setupMap()
Y haciendo uso del ciclo de vida de Fragmentos, puede separar todas sus vistas de Fragmentos en onDestroyView() y también ahorra algo de espacio en la memoria cuando se ejecuta el recolector de basura.
override fun onDestroyView()
super.onDestroyView()
presenter.detachView()
presenter.detachJob()
En el repositorio oficial de Google encontré una pregunta que me ayudó a entenderlo mejor.
Puede comprobar aquí
Al final de todo puedes encontrar las crónicas de otros sys admins, tú de igual forma tienes la habilidad dejar el tuyo si lo crees conveniente.