GWT - Separazione del ruolo del relatore dall'attività

Question

Quali vantaggi si potrebbero trarre dalla dismissione del ruolo di relatore da un'attività?

Quali sono i ruoli/le preoccupazioni che potrebbero essere separati al fine di analizzare un'attività dall'essere un presentatore?

Perché dovresti separarli in due distinte preoccupazioni?

In quali circostanze avrebbe senso non unificarle?

Fornire esempi, vantaggi o svantaggi.

Answer 1

Vedo due motivi principali per separare i presentatori di attività: la riutilizzabilità e la verificabilità.

Caso di utilizzo reale per la riusabilità: abbiamo un'entità di illustrazione con proprietà come il fotografo, copyright e data di ripresa, che possono essere collegate ai documenti. La leggenda di è sulla relazione tra il documento e l'illustrazione. È possibile modificare sia l'illustrazione che la legenda sul proprio schermo, ma volevamo anche che l'immagine potesse essere modificata dalla schermata della legenda. Così abbiamo fatto un presentatore per la schermata di illustrazione. L'attività di illustrazione è un involucro molto sottile attorno al presentatore e l'attività della legenda è un po 'più complessa, ma riutilizza il presentatore e la vista. La responsabilità delle attività è quella di fornire i numeri RequestContext e fare il fire() (i pulsanti Salva/Annulla sono su un'altra attività, simile alle azioni su Google Gruppi).

casi d'uso ipotetici per riutilizzabilità:

• per i diversi fattori di forma, si vuole aggregare le cose sullo stesso schermo o separarli in proprio schermo (ad esempio, master/dettaglio), e quando aggregarli, avere due attività potrebbe non essere l'ideale. L'uso di attività sottili nel fattore di forma del telefono consente di riutilizzare i componenti (presentatore/vista) all'interno di una singola attività nei fattori di forma del tablet o del desktop.
• riutilizzando lo stesso presentatore su piattaforme diverse: è possibile utilizzare lo stesso presentatore su un'app Android e un'app Web (e forse anche un'app per iOS tramite java2objc), la visualizzazione sarebbe una visualizzazione Android nativa o basata su GWT vista, e la navigazione sarebbe gestita da attività e/o frammenti Android vs. attività e luoghi GWT.

Chi testability (questo è teorico), si potrebbe quindi verificare il vostro presentatore senza il fastidio del ciclo di vita di attività (beffardo la vista), e quindi verificare separatamente il ciclo di vita (se si inizializza e pulisce il modo corretto presentatore, recupera/memorizza nella cache i dati, ecc. prendendo in giro il presentatore).

Vedere anche il messaggio di commit dell'idea https://code.google.com/p/google-web-toolkit/source/detail?r=10185
di Ray era di fare MVP un dettaglio di implementazione di widget, come i widget cellulari utilizzano presentatori interne oggi. Dall'esterno sono solo widget che puoi comporre nel modo desiderato; al loro interno usano MVP in modo da poterli testare senza la necessità di un GWTTestCase.

Answer 2

Prima di tutto due Grazie per la domanda che mi spinge alla ricerca più lunga di sempre. :)

Secondo Thomos Broyer here.

L'attività non può parlare con i widget, cosa che il relatore può fare.

due principali aree di preoccupazione:

1- ottenere i dati nei widget: come può questo progetto potrebbe essere migliorato?

Server (RequestFactory) ---> Activity ---> WidgetPresenter ---> Widget 

qui, RequestFactory mani in dati a Activity, che poi dà a la Presenter che successivamente passa al widget.

2- ottenere i dati dal widgets alla server

widget ---> WidgetPresenter ---> Activity ---> Server(RequestFactory)