Ich habe mich gefragt, warum nicht verwenden android:configChanges="keyboardHidden|orientation"
bei jeder (fast jeder ;)) Aktivität?
Waren:
- Sie müssen sich keine Sorgen darüber machen, dass Ihre Aktivität gedreht wurde
- es ist schneller
Nicht sehr nett:
- Sie müssen Ihre Layouts ändern, wenn sie von der Bildschirmgröße abhängen (z. B. Layouts mit zwei Spalten oder so).
Schlecht:
- keine flexible Möglichkeit, unterschiedliche Layouts mit unterschiedlicher Ausrichtung zu haben
- nicht so gut bei der Verwendung von Fragmenten
Aber wenn wir keine anderen Layouts verwenden, warum nicht?
Schneller Hintergrund
Standardmäßig startet Android bei bestimmten Änderungen der Schlüsselkonfiguration auf Android (ein häufiges Beispiel ist eine Ausrichtungsänderung) die laufende Aktivität vollständig neu, um die Anpassung an solche Änderungen zu erleichtern.
Wenn Sie definieren android:configChanges="keyboardHidden|orientation"
In Ihrem AndroidManifest sagen Sie Android: „Bitte führen Sie das Zurücksetzen auf die Standardeinstellungen nicht durch, wenn die Tastatur herausgezogen oder das Telefon gedreht wird. Ich möchte das selbst erledigen. Ja, ich weiß, was ich tue.“
Ist das eine gute Sache? Wir werden bald sehen…
Keine Sorgen?
Einer der Vorteile, mit denen Sie beginnen, ist, dass es Folgendes gibt:
Sie müssen sich keine Sorgen darüber machen, dass Ihre Aktivität gedreht wurde
In vielen Fällen glauben Menschen fälschlicherweise, dass sie einen Fehler, der durch eine Ausrichtungsänderung (“Rotation”) erzeugt wird, einfach durch Einfügen beheben können android:configChanges="keyboardHidden|orientation"
.
Android:configChanges=”keyboardHidden|orientation” ist jedoch nichts weiter als ein Pflaster. Tatsächlich gibt es viele Möglichkeiten, wie eine Konfigurationsänderung ausgelöst werden kann. Wenn der Benutzer beispielsweise eine neue Sprache auswählt (dh das Gebietsschema hat sich geändert), wird Ihre Aktivität auf die gleiche Weise neu gestartet wie bei einer Orientierungsänderung. Wenn Sie möchten, können Sie sehen eine Liste aller verschiedenen Arten von Konfigurationsänderungen.
Bearbeiten: Noch wichtiger ist jedoch, dass Ihre Aktivität, wie Hackbod in den Kommentaren betont, auch dann neu gestartet wird, wenn sich Ihre App im Hintergrund befindet und Android beschließt, etwas Speicher freizugeben, indem es sie tötet. Wenn der Benutzer zu Ihrer App zurückkehrt, versucht Android, die Aktivität auf die gleiche Weise neu zu starten wie bei einer anderen Konfigurationsänderung. Wenn Sie damit nicht umgehen können, wird der Benutzer nicht glücklich sein …
Mit anderen Worten, verwenden android:configChanges="keyboardHidden|orientation"
ist keine Lösung für Ihre “Sorgen”. Der richtige Weg besteht darin, Ihre Aktivitäten so zu codieren, dass sie mit jedem Neustart von Android zufrieden sind. Dies ist eine gute Übung, die Ihnen auf dem Weg helfen wird, also gewöhnen Sie sich daran.
Also wann sollte ich es verwenden?
Wie Sie bereits erwähnt haben, gibt es einen entscheidenden Vorteil. Das Überschreiben der Standardkonfigurationsänderung für eine Rotation, indem Sie sie selbst handhaben, wird die Dinge beschleunigen. Diese Geschwindigkeit hat jedoch einen Preis für die Bequemlichkeit.
Um es einfach auszudrücken, wenn Sie dasselbe Layout für Hoch- und Querformat verwenden, sind Sie mit dem Überschreiben in guter Verfassung. Anstelle eines vollständigen Neuladens der Aktivität werden die Ansichten einfach verschoben, um den verbleibenden Platz zu füllen.
aberwenn Sie aus irgendeinem Grund ein anderes Layout verwenden, wenn sich das Gerät im Querformat befindet, ist die Tatsache, dass Android Ihre Aktivität neu lädt, gut, da es dann das richtige Layout lädt. [If you use the override on such an Activity, and want to do some magical re-layout at runtime… well, good luck – it’s far from simple]
Kurze Zusammenfassung
Auf jeden Fall, wenn android:configChanges="keyboardHidden|orientation"
das Richtige für Sie ist, dann nutzen Sie es. Aber BITTE Stellen Sie sicher, dass Sie testen, was passiert, wenn sich etwas ändert, da eine Ausrichtungsänderung nicht die einzige Möglichkeit ist, einen vollständigen Aktivitätsneustart auszulösen.
Aus meiner Sicht: Wenn das Layout sowohl im Quer- als auch im Hochformat gleich ist, können Sie auch eines der beiden in Ihrer App deaktivieren.
Der Grund, warum ich das sage, ist, dass ich als Benutzer von der App einen gewissen Nutzen erwarte, wenn ich die Orientierung ändere. Wenn es egal ist, wie ich mein Telefon halte, dann brauche ich keine Wahl.
Nehmen Sie zum Beispiel eine App, in der Sie eine ListView haben, und wenn Sie auf ein ListItem klicken, möchten Sie eine detaillierte Ansicht für dieses Element angezeigt bekommen. Im Querformat würden Sie dies tun, indem Sie den Bildschirm in zwei Teile teilen, wobei die Listenansicht links und die Detailansicht rechts ist. Im Hochformat hätten Sie die Liste auf einem Bildschirm und wechseln dann den Bildschirm in die Detailansicht, wenn ein ListItem ausgewählt wird. In diesem Fall ist eine Änderung der Ausrichtung ebenso sinnvoll wie unterschiedliche Layouts.
Ich verstehe nicht, warum … gelegentliche Neustarts sind meiner Meinung nach in Ordnung … configChanges bewältigt die meisten Fälle für mich … nun, vielleicht kann dies bei einigen Arten von Anwendungen ein Problem sein, aber es hängt wirklich vom Typ der App und davon ab, wie Sie sie wiederherstellen Status beim Neustart der App … Wenn eine meiner Apps neu gestartet wird, wird der Benutzer zurückgemeldet und die letzte Aktivität wird von meinem Code geöffnet, und der Benutzer verliert nur einige Schritte, um dorthin zurückzukehren, wo er war, aber keine große Sache. In anderen Fällen wird ein bestimmter Status immer beibehalten und Beim Neustart wird immer ein bestimmter Zustand wiederhergestellt. Als die Aktivität neu gestartet wurde, musste es sein, dass die App nicht verwendet wurde oder so … also überhaupt kein Problem … Im Spiel zum Beispiel kann dies ein Problem sein oder in einer anderen Art von App, die ich nicht kenne …
Ich sage, wenn Sie es auf diese Weise tun, funktionieren Anwendungen unter normalen Umständen gut. Und der Code ist viel besser lesbar, ohne dass eine Menge Logik zum Speichern und Wiederherstellen benötigt wird, wo Sie nur neue Fehler machen und ihn die ganze Zeit warten müssen … sicher, wenn Android den Strom verliert und Ihr Anwendungsfenster beendet, verliert es den Kontext und startet wieder, aber das passiert nur in besonderen Situationen und bei neueren Geräten glaube ich, dass das immer seltener wird…
Also töte mich, aber ich benutze das ziemlich erfolgreich für alle Anwendungen … android:configChanges=”locale|keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize” Aber ich verstehe, dass es für einige spezielle Arten von Anwendungen möglicherweise nicht so ist Guter Weg, aber die meisten Apps können damit gut leben.
Ja, ich denke, das Pausieren wird es schneller machen, als den Player loszulassen. Habe aber trotzdem die Pause.
Habe jetzt eine Lösung gefunden, die das Lied nicht pausiert.
Geben Sie im Manifest an, dass Sie die Konfigurationsänderung für die Bildschirmausrichtung vornehmen werden, und verwenden Sie dann die onConfigurationChanged-Methode, um die Layoutdatei zu laden. Dadurch kann ich in logCat sehen, dass onPause, onCreate und onResume nicht aufgerufen werden und daher das Lied nicht angehalten wird.
-
Aktualisieren Sie das Manifest, um die Ausrichtung zu verarbeiten.
android:configChanges="orientation|screenSize"
-
diesen Code hinzufügen
@Override
public void onConfigurationChanged(Configuration newConfig) {
// TODO Auto-generated method stub
super.onConfigurationChanged(newConfig);
setContentView(R.layout.activity_main);
}
Sie sollten auch erklären, was Sie Überlegen keyboardHidden|orientation tut
– Blundell
19. Oktober 2011 um 8:50 Uhr
Es verhindert, dass die native Behandlung bestimmter Konfigurationsänderungen verwendet wird, und erlaubt der Anwendung, damit umzugehen, nicht wahr?
– Mikooos
19. Oktober 2011 um 10:39 Uhr
Deshalb gibt es diese Option, wenn Sie wissen, was Sie tun (keine Änderungen an Ressourcen), verwenden Sie sie.
– Zeiger Null
31. Oktober 2011 um 21:23 Uhr
Warum ist es schneller als mit ScreenSize?
– Emil
30. Mai 2017 um 13:59 Uhr