2010-05-06 15 views
21

Sto avviando Android facendo un'applicazione per la ricerca di ristoranti, e alcune indicazioni sarebbero benvenute! Nella prima schermata mi piacerebbe avere un campo di ricerca con un pulsante di invio (ottengo i dati da un servizio web) e sotto un elenco con i risultati della ricerca. Quando si fa clic su uno degli elementi dell'elenco, viene visualizzata una schermata con i dettagli del ristorante e una mappa che mostra la sua posizione. Le mie domande sono:Quante attività dovrei usare?

  • Posso fare tutto in una singola attività o devo fare un'attività di ricerca, uno per la lista dei risultati, uno per la descrizione ristorante, e un altro per la mappa?
  • Fare una sola attività renderà l'applicazione più reattiva?
  • Come è possibile utilizzare un elenco e una mappa in un'attività normale (senza ListActivity e MapActivity)?
+0

Ciao Jul, potresti provare a rendere più descrittivo il titolo della domanda? – Casebash

+0

Ho aggiunto "quante attività dovrei usare?". – jul

risposta

25

Posso fare tutto in un'unica attività o devo svolgere un'attività per la ricerca, una per la lista dei risultati, una per la descrizione del ristorante e un'altra per la mappa?

La risposta a questo dipende davvero dal flusso dell'applicazione. Penso che la cosa più importante da tenere presente qui è come l'utente controllerà la tua app con il pulsante "indietro". Quando crei una nuova attività, questa viene messa in pila e l'utente può sempre premere "indietro" per estrarlo dallo stack.

Un estremo è mettere tutti questi passaggi in attività diverse. Quindi l'utente ha il controllo definitivo usando il pulsante "indietro", ma potrebbe essere infastidito saltando attorno alle attività. Mettere tutto in una sola attività è l'altro estremo e consiglio vivamente di non farlo; gli utenti si aspettano che i nuovi schermi siano un'attività diversa, da cui possono "tornare indietro", e quindi se metti tutte le uova in una sola attività dovrai iniziare a gestire "indietro" te stesso.

Penso che ci sia una buona via di mezzo che la tua app potrebbe prendere, anche se ovviamente la progettazione dell'interfaccia utente potrebbe essere diversa da quella che propongo. Direi che potresti farlo in due Attività; nella prima, hai un campo di ricerca in alto (con un pulsante di invio accanto ad esso), e sotto quel campo di ricerca c'è un ListView che viene popolato con i risultati. Nel secondo, si utilizza TabActivity, in cui una scheda è per la descrizione e l'altra è per la mappa. Penso che questo sia vantaggioso per due motivi: nella prima attività, l'utente vede i risultati della loro ricerca sulla stessa pagina della ricerca e può modificare rapidamente i parametri di ricerca, se necessario. E nella seconda attività, il tasto indietro incapsula il ritorno da un ristorante.

Fare una singola attività renderebbe l'applicazione più reattiva?

Non proprio. Le attività richiedono tempo per creare/abbattere, ma non che molto tempo. È meglio segmentare l'applicazione in modo logico (per l'esperienza dell'utente).

Come è possibile utilizzare un elenco e una mappa all'interno di un'attività normale (senza ListActivity e MapActivity)?

Si può ottenere via con un controllo ListView all'interno di una normale attività senza ListActivity; includi semplicemente una ListView nel contenuto della tua attività, quindi nel codice prendi il ListView e imposta il suo adattatore manualmente. Tutto ciò che ListActivity fa è aggiungere alcune pratiche funzioni wrapper per un ListView primario, ma non è affatto necessario.

Le mappe sono una questione diversa. Dovrai utilizzare MapActivity per visualizzare le mappe, poiché MapActivity ha un codice di installazione e di rimozione speciale che deve essere eseguito. Scusate.

+1

Grazie mille Daniel. – jul

+0

@DanielLew è ancora vero che devi usare MapActivity per visualizzare una mappa? Sto appena iniziando con Android (usando Mono) e spero di usare una visualizzazione mappa come parte di un'altra attività più completa. (Mi piacerebbe che l'utente passasse tra le viste della mappa o dell'elenco) –

+0

Sì, è ancora così. L'unica soluzione è che l'intera attività sia un MapActivity o che si usi un gruppo di attività in cui uno dei bambini è un MapActivity. (A questo punto raccomando il primo, poiché funzionerà meglio con Fragments.) –

1

Avrei un'attività con sia la ricerca che l'elenco, quindi un altro che mostra i dettagli del ristorante.

Non penso che funzionerebbe bene con una sola attività.

Le attività possono contenere più viste: una singola attività può contenere una mappa e un elenco, se necessario.

+0

Grazie, proverò con 2 attività. – jul

1

Vorrei aggiungere una guida alla risposta eccellente di Daniel.

Gli utenti non possono dire la differenza tra un'attività con una vista che cambiano e le molteplici attività ciascuno con la propria visione - fino a quando non premere il tasto back. Quindi è abbastanza importante che il pulsante back abbia uno scopo naturale e logico in relazione a ciò che appare sullo schermo quando viene premuto. L'utente non dovrebbe mai essere sorpreso da ciò che accade quando lo usa.

Così, per ogni attività che hai, chiedetevi se il comportamento del pulsante Indietro è logico l'utente finale in qualsiasi momento. Se trovi uno scenario in cui non lo è, dovresti considerare il refactoring delle tue attività - che potrebbe implicare la combinazione di due o più attività in una, spostando alcune responsabilità da un'attività all'altra (ma conservandole entrambe), o anche suddividendo un'attività in Due.

Creare un'interfaccia utente che si comporti in modo logico mentre l'utente naviga attorno ad esso è importante, e più l'applicazione fa (e più c'è la navigazione) più diventa importante. Un comportamento di navigazione imprevedibile impedisce alle persone di imparare come ottenere il meglio dalla propria applicazione nel momento in cui è più probabile che la disinstallino - nelle prime ore dopo averlo scaricato.

0

Se stai cercando di scrivere codice modulare, riutilizzabile e portatile, un'attività è la strada da percorrere. L'attività è un concetto solo per Android. Il flusso principale e la logica aziendale di qualsiasi applicazione ben progettata dovrebbero essere indipendenti dalla piattaforma. Coinvolgere attività nel tuo codice di livello superiore lega il tuo progetto ad Android, che va contro l'indipendenza dalla piattaforma, un principio fondamentale sia in Java che nella programmazione di qualità in generale.

+0

Si consiglia davvero una separazione della struttura dell'interfaccia utente dalla logica di business sottostante, che è un eccellente consiglio. Tuttavia, questo non significa che devi essere limitato a una sola attività, ma semplicemente ridurre l'accoppiamento tra questi livelli. –

+0

Una classe di wrapper attorno ad ogni attività viene in mente come soluzione. Ma poi di nuovo, le attività vengono riavviate secondo il capriccio del sistema operativo, quindi è necessario assicurarsi che tutti i dati necessari siano precaricati (gli oggetti SharedPreferences e InstanceBundle, ma ancora, quelli specifici di Android). –

+0

Questo è un cattivo consiglio per l'interfaccia utente, gli utenti Android si aspettano che più finestre si trovino più o meno in attività diverse. Questo consiglio è come dire a qualcuno di usare un JFame per evitare la dipendenza da Swing ... –