2010-12-27 17 views

risposta

5

Un grande Pro di utilizzare questo approccio è che richiede pochissimo sforzo da parte tua e che la tua app sopravviverà alle modifiche di configurazione senza ricorrere agli arresti anomali.

Lo svantaggio è che l'utilizzo di risorse specifiche di configurazione (per orientamento orizzontale o verticale) non viene applicato automaticamente.

Nella mia (forse piccola) esperienza, penso che non valga veramente la pena di fare tutto l'impianto idraulico.

La "corretta" gestione di queste modifiche di configurazione richiede un sacco di impianti idraulici da parte vostra e le cose diventano ancora più drammatiche se dovete supportare le finestre di dialogo di avanzamento durante le modifiche all'orientamento dello schermo.

Anche se molte persone optano per la correzione rapida cambiando il manifest e configurando la loro attività con Android: configChanges = "keyboardHidden | orientation", penso che sia importante rendersi conto che ci sono alternative a questo.

Richiede più codice, ma fornisce informazioni più dettagliate su come funziona il sistema generale.

6

E 'strano che Google in realtà non chiacchierare il ragionamento dietro di esso, ma ci sono in realtà tre principali motivi che mi vengono in mente per evitare di utilizzare questo approccio:

  • Nella mia esperienza, alcuni tipi di vista (in particolare WebViews e MapViews su Android 2.1 o precedenti) possono comportarsi in modo piuttosto strano dopo il cambio di orientamento se non sono stati ricreati (ad esempio, i pulsanti dello zoom sono errati).
  • Impedisce l'utilizzo di layout specifici dell'orientamento (vedere la vista orizzontale della nuova app di Market, ad esempio).
  • Può impedirti di scoprire comportamenti buggy dalla tua applicazione relativi ad altri tipi di motivi per cui l'attività potrebbe essere distrutta e ricreata (ad esempio memoria insufficiente o altre uccisioni normali durante lo sfondo). Cioè, se la tua attività può gestire con garbo un riavvio a causa della rotazione, probabilmente può gestire un riavvio a causa dell'abbattimento dello sfondo. Se si ignora la gestione della rotazione, tuttavia, non si può verificare un riavvio a causa dell'abbattimento dello sfondo durante i normali test fino a quando un utente con un vecchio telefono con memoria insufficiente scrive con una segnalazione di errore.

L'ultimo motivo è il grande; specialmente con i vecchi telefoni a bassa RAM e con i comportamenti di autokilling presumibilmente più aggressivi in ​​Gingerbread, le tue attività devono sapere come essere ricreate rapidamente dopo una distruzione, salvando il loro stato, indipendentemente dalla gestione dell'orientamento. E una volta che le tue attività sono in grado di gestire questo tipo di distruzione/ricreazione, probabilmente sei pronto a far sì che il cambio di rotazione uccida comunque. Puoi guadagnare un po 'di velocità assorbendo l'evento di rotazione (dato che non devi tornare indietro con l'inflazione del layout e tutto il resto) ma a quel punto è tutto.

Se si decide di ingoiare rotazioni mi raccomando sempre utilizzando un emulatore o un dispositivo con l'opzione 's 'distruggere immediatamente le attività' del Development.apk controllato, e poi fare in modo che il passaggio app o il backup tramite il vostro stack compito ancora funziona correttamente.

Nella mia esperienza l'assorbimento delle rotazioni può essere una buona scelta per un'esperienza utente migliorata, in particolare su attività con layout complessi che potrebbero richiedere alcuni minuti per essere ricreati, ma è davvero necessario testare attentamente ed efficacemente assicurarsi che la propria attività funziona ancora anche senza ignorare la rotazione.

+0

Informazioni su WebView, è problematico perché se si cambia orientamento mentre viene caricato, si riavvia il caricamento. Come ho letto, non è possibile ripristinare il suo stato (ed è anche scritto nei documenti) –

Problemi correlati