MVP de Android: qué capa debe almacenar la variable de contexto

Me encuentro donde necesito para reproducir un archivo de sonido cuando el usuario hace clic en un botón en una vista.

MediaPlayer requiere que se cree un contexto.

¿Cuál es la mejor manera de poner el código de inicialización de MediaPlayer?

¿Debo pasar un contexto a un método presentador y jugarlo allí?

O está bien para jugar en la vista.

3 Solutions collect form web for “MVP de Android: qué capa debe almacenar la variable de contexto”

Context es una parte de Android View Layer en MVP, por lo que Presenter no debe tener ninguna idea al respecto y no debe pasarlo al presenter .

Tienes que agregar métodos a tu interfaz de View e implementarlos dentro de tus componentes de vista de android (es decir, Activity o Fragment ) y usarlos para hacer una acción en la capa de View al reproducir un sonido.

Presenter debe solicitar el evento de la interfaz de usuario y View debe manejarlo!

Aquí hay una muestra de MVP que utiliza Dagger , RxJava y Retrofit , que podría ayudarle a obtener más información sobre MVP en Android:

https://github.com/mmirhoseini/marvel

A menudo pongo el código de la lógica de negocio en la capa del modelo (no confunda con el modelo en la base de datos). A menudo renombrar como XManager para evitar la confusión (como ProductManager , MediaManager …) para que la clase presentador sólo se utiliza para mantener el flujo de trabajo.

La regla de oro es no o al menos limitar el paquete de importación android en la clase presentador. Esta mejor práctica te ayuda más fácilmente a probar la clase de presentador porque ahora el presentador es una simple clase java, por lo que no necesitamos el framework android para probar esas cosas.

Por ejemplo, aquí está mi flujo de trabajo mvp.

Clase de vista : Este es un lugar donde almacena toda su vista como botón, textview … y establece todos los oyentes para esos componentes de vista en esta capa. También en esta Vista, define una clase de Listener para los implementos del presentador más adelante. Sus componentes de vista llamarán a métodos en esta clase de escucha.

 class ViewImpl implements View { Button playButton; ViewListener listener; public ViewImpl(ViewListener listener) { // find all view this.listener = listener; playButton.setOnClickListener(new View.OnClickListener() { listener.playSong(); }); } public interface ViewListener { playSong(); } } 

Presenter class: Aquí es donde almacena la vista y el modelo en el interior para llamar más tarde. También presentador clase implementará ViewListener interfaz se ha definido anteriormente. El punto principal del presentador es el flujo de trabajo de la lógica de control.

 class PresenterImpl extends Presenter implements ViewListener { private View view; private MediaManager mediaManager; public PresenterImpl(View, MediaManager manager) { this.view = view; this.manager = manager; } @Override public void playSong() { mediaManager.playMedia(); } } 

Clase del gestor: Aquí está el código de la lógica empresarial central. Tal vez un presentador tendrá muchos gerentes (dependerá de cómo complicar la vista es). A menudo conseguimos la clase Context través de algún marco de inyección como Dagger .

 Class MediaManagerImpl extends MediaManager { // using Dagger for injection context if you want @Inject private Context context; private MediaPlayer mediaPlayer; // dagger solution public MediaPlayerManagerImpl() { this.mediaPlayer = new MediaPlayer(context); } // no dagger solution public MediaPlayerManagerImpl(Context context) { this.context = context; this.mediaPlayer = new MediaPlayer(context); } public void playMedia() { mediaPlayer.play(); } public void stopMedia() { mediaPlayer.stop(); } } 

Finalmente: Ponga esas cosas juntas en Actividades, Fragmentos … Aquí es el lugar que inicializar vista, administrador y asignar todo al presentador.

 public class MyActivity extends Activity { Presenter presenter; @Override public void onCreate() { super.onCreate(); IView view = new ViewImpl(); MediaManager manager = new MediaManagerImpl(this.getApplicationContext()); // or this. if you use Dagger MediaManager manager = new MediaManagerImpl(); presenter = new PresenterImpl(view, manager); } @Override public void onStop() { super.onStop(); presenter.onStop(); } } 

Verá que cada presentador, modelo, vista está envuelto por una interfaz. Estos componentes serán llamados a través de la interfaz. Este diseño hará que su código sea más robusto y más fácil de modificar posteriormente.

Este es un post tan largo para responder a su pregunta. Pienso que esto es conveniente porque cada uno tiene su propia puesta en práctica del MVP (el flujo de la base es igual, pero las minorías son diferentes). Así que presento aquí un flujo de trabajo que a menudo uso en el trabajo. Esperando ver esto útil 🙂

Si necesita un Contexto genérico puede extender la Aplicación, declarar una variable de contexto estático y después de que pueda obtener este Contexto en su presentador.

  • Model View Presenter con un EventBus, ¿cómo recuperar los eventos en Presenter?
  • Problemas al definir el patrón MVP para las aplicaciones de Android
  • Explicación de Android MVP
  • ¿Cómo puedo seguir la arquitectura MVP con SDK de terceros?
  • Inyección de genéricos en Dagger
  • Realización de Interactors con Android MVP Clean Architecture
  • Android MVP - ¿Debería evitar el uso de referencias R.string en el presentador?
  • ¿En MVP está onClick la responsabilidad de View o Presenter?
  • Dificultades para implementar Model-View-Presenter en Android
  • El papel de los adaptadores en Mvp patrón?
  • Model View Presenter - misma vista, diferentes presentadores
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.