2012-02-15 10 views
8

So che ci sono state alcune domande su questo argomento, tuttavia, sto ancora cercando di capire quale ruolo deve svolgere la classe Activity quando si implementa il modello di progettazione modello Model-View-Controller su Android?Qual è il ruolo della classe di attività in MVC?

Il mio istinto è che dovrebbe essere il controller, tuttavia ciò significa una relazione uno-a-uno tra schermate dell'interfaccia utente (poiché è necessario disporre di uno Activity per schermo) e controller, che sconfigge il punto di accoppiamento libero di MVC tra i diversi componenti.

+0

[Spero che avresti già visto questo:)] (http://stackoverflow.com/q/2925054/593709) –

+0

Sì, ho :) Sembra che ci sia solo un commento su una risposta che è rilevante però: http://stackoverflow.com/a/2925368/824903 e in pratica dice "Android non funziona MVC". Speravo in una maggiore chiarezza in merito alla questione. – donturner

risposta

7

Hai ragione. Le interfacce xml possono essere definite come View e l'altra classe che lavora con dati come Modello.

L'attività riceve tutti gli eventi e gli input utente dalla vista, quindi possiamo facilmente dire che è il Controller.

Ma cerchiamo di essere chiari, non è un perfetto (è veramente esiste?) MVC

Date un'occhiata a this question, e più specificamente, il primo commento della risposta accettata, può essere utile

+0

Quindi, in pratica, Android non esegue MVC "out of the box"? – donturner

+0

In una mano, Android SDK ti consente di separare i diversi livelli della tua app. ma d'altra parte puoi costruire una vista direttamente con il codice nell'attività. Quindi sì, Android ti consente di implementare MVC, ma NO non è un'applicazione rigorosa del modello. Non sono un esperto di design pattern quindi forse qualcun altro può chiarirlo meglio di me :) – grunk

1

Le attività possono rendere i controller competenti e, con i frammenti, è possibile implementare anche MVC gerarchico. La maggior parte del lavoro di MVC è compito del programmatore, perché anche nei framework più rigidi è ancora possibile trovare modi per do crazy things.

-1

Android non ha una buona architettura e non segue il modello di progettazione MVC.

Il modo migliore per concettualizzare attività in MVC è come una visualizzazione (con qualche Logic Controller) perché viene distrutto ogni volta che un cambiamento configurazione avviene, ad esempio una rotazione schermo o cambiamento locale, perdendo il suo stato.

Il controller in questo caso sarebbe l'oggetto Application, poiché è il bridge ad accedere alla vista (Activity e alle sue componenti GUI) dal codice al di fuori del contesto di attività. Devi usare i singleton in modo che ci sia un solo oggetto Application in un dato momento, altrimenti ci sarà un oggetto Application per processo. L'oggetto applicazione non è un buon posto in cui archiviare il modello poiché il suo ciclo di vita è scollegato da quello delle attività. Può essere distrutto e ricreato in qualsiasi punto del ciclo di vita di un'attività (mentre l'applicazione è in background) senza farla riavviare, e quindi tutte le sue variabili e riferimenti non assegnati all'interno del suo metodo onCreate() diventeranno nulli.

Il modello deve quindi essere memorizzato su un frammento senza testa senza GUI con setRetainInstance (true), che è collegato a un'attività e deve essere nuovamente collegato ad esso ogni volta che l'attività viene ricreata. Devi usare un gestore di frammenti per assicurarti di recuperare il frammento trattenuto e non crearlo di nuovo. Questo è anche il posto migliore per eseguire attività in background, sebbene sia possibile eseguirle anche nell'oggetto Application. Non eseguire mai attività su un'attività in quanto verranno distrutte durante le modifiche alla configurazione.

0

Penso che la confusione potrebbe venire con la definizione di una vista come XML e quindi l'attività è errata per essere la vista. Non è. Passa la vista (il tuo layout XML) all'attività che poi gonfierà le viste contenute nel layout XML. La tua attività passa anche i dati (modelli) nelle tue visualizzazioni (EditText, TextView, versione estesa delle viste di base, ecc.).

Se si desidera realmente MVC, è possibile ottenere ciò semplicemente impostando la vista in un layout XML, creare un oggetto vista che si estende dalla vista radice (se si estende da RelativeLayout). Da lì aggiungi i tuoi metodi di accesso e le diverse logiche necessarie per quella vista e puoi quindi aggiungere test delle unità in merito.

Nella attività non sarà più passare l'ID del layout e sarà invece fare qualcosa del genere:

CustomView customView = new CustomView(...); 
setContentView(customView); 
... 

Naturalmente quasi tutte le applicazioni non fare questo e davvero non hanno bisogno per fare questo. Chiamare findViewById è sufficiente per collegarsi a quell'oggetto vista e chiamare i metodi che ha. Quale nella mia mente, è MVC.

Problemi correlati