Best practice per il pattern MVP su Android

Question

Best practice per il pattern MVP su Android

#1 da (1 voti)

4

il mio team ha avuto un grande successo introducendo MVP e i test unitari associati con il presentatore. Ci chiediamo in che modo granulare dovremmo fare l'interazione tra la vista e il presentatore.

Ad esempio, abbiamo una schermata che mostra un'icona di caricamento e quindi effettua una richiesta per alcuni dati. Quando la chiamata ritorna, rimuoviamo l'icona di caricamento e visualizziamo i dati.

In questo scenario potremmo rendere la visualizzazione davvero stupida e delegare al presentatore all'avvio e chiedere di visualizzare l'icona di caricamento. Quindi il relatore farebbe la richiesta e quando ritorna, dire alla vista di rimuovere l'icona di caricamento e quindi effettuare un'altra chiamata di visualizzazione con i dati da visualizzare.

Un altro modo per farlo è far visualizzare all'attività l'icona di caricamento, quindi chiamare il relatore. Il presentatore effettua la chiamata, riceve una richiamata quando ritorna e quindi chiama la vista con i risultati. Sta fino all'attività sapere di rimuovere l'icona di caricamento e quindi visualizzare i dati.

In prima istanza la vista viene esplicitamente informata di tutto ciò che deve fare e la seconda solo delega la "logica aziendale" al presentatore.

Che cosa pensa la gente è l'approccio migliore?

mvp android

posta FinalFive 04.03.2015 - 00:12

fonte

1 risposta

Leggi altre domande sui tag mvp android

Mappatura di più tassonomie diverse tra loro Design Pattern per analizzare array di oggetti

score 1 · Answer 1

Ecco un esempio di cosa potrebbe essere l'interfaccia tra View e Presenter, da questo articolo

interface MessageView {
  // View methods should be directives, as the View is just executing orders from the 
  // Presenter.

  // Methods for updating the view
  void setMessageBody(String body);
  void setAuthorName(String name);
  void showTranslationButton(boolean shouldShow);

  // Navigation methods
  void goToUserProfile(User user);
}

interface MessagePresenter {
  // Presenter methods should mostly be callbacks, as the View is reporting events for the
  // Presenter to evaluate

  // Lifecycle events methods
  void onStart();

  // Input events methods
  void onAuthorClicked();
  void onThreeFingersSwipe();
}

Qui ci sono un paio di punti interessanti da notare su questa interfaccia:

I metodi per aggiornare la vista dovrebbero essere semplici e mirati su un singolo elemento. È meglio che avere un singolo metodo setMessage(Message message) che aggiornerà tutto, poiché la formattazione di ciò che dovrebbe essere visualizzato dovrebbe essere responsabilità del Presenter. Ad esempio, potresti voler visualizzare "Tu" anziché il nome utente se l'utente corrente è l'autore del messaggio e questo fa parte della tua logica aziendale.
I metodi degli eventi del ciclo di vita sul Presenter sono semplici e non è necessario mappare quelli (eccessivamente complicati) del ciclo di vita di Android. Non è necessario implementare nessuno di essi, ma è possibile implementarne il numero desiderato se il Presenter deve intraprendere azioni specifiche.
I metodi degli eventi di input sul Presenter sono mantenuti ad un livello elevato. Se, per esempio, stai cercando di rilevare un gesto complesso, come nell'esempio di scorrimento con 3 dita, tutta la rilevazione dei gesti dovrebbe essere eseguita nella vista. Puoi vedere che ci sono metodi MessagePresenter.onAuthorClicked() e MessageView.goToAuthorProfile() . L'implementazione della vista avrà probabilmente un listener di clic che chiama questo metodo Presenter che chiamerà goToAuthorProfile() . Dovresti saltare tutto questo e andare direttamente al profilo dell'autore dal listener dei clic? No! La decisione di accedere a quel profilo quando viene fatto clic sul nome dell'autore fa parte della tua logica aziendale e appartiene al Presenter.