Warum nicht immer android:configChanges=”keyboardHidden|orientation” verwenden?

Lesezeit: 10 Minuten

Warum nicht immer androidconfigChangeskeyboardHiddenorientation verwenden
Mikooos

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?

  • 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

1646629999 439 Warum nicht immer androidconfigChangeskeyboardHiddenorientation verwenden
yydl

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.

  • Es ist erwähnenswert, dass Sie größere Probleme haben, wenn Sie Ihre Aktivität nicht neu starten, als wenn Sie weniger häufige Konfigurationsänderungen nicht handhaben. Der hier verwendete Aktivitätsneustart ist genau derselbe Mechanismus, mit dem Android Ihre Aktivität in ihren vorherigen Zustand zurückversetzt, wenn Ihre App im Hintergrund beendet wird. Wenn Sie dies also nicht richtig machen, werden Ihre Benutzer feststellen, dass Ihre App zufällig nicht korrekt zurückkommt, wenn sie aus dem Hintergrund zu ihr zurückkehren, je nachdem, ob der Prozess zufällig beendet wurde. Ein großer Vorteil also: Es stellt sicher, dass Ihre App korrekt neu gestartet wird.

    – Hackbod

    4. November 2011 um 6:46 Uhr

  • Verpassen Sie ab Android 3.x nicht, “screenSize” hinzuzufügen ———- android:configChanges=[“mcc”, “mnc”, “locale”, “touchscreen”, “keyboard”, “keyboardHidden”, “navigation”, “screenLayout”, “fontScale”, “uiMode”, “orientation”, “screenSize”, “smallestScreenSize”]

    – Michael Biermann

    10. Dezember 2012 um 21:26 Uhr


  • Mir ist aufgefallen, dass Ihre App bei Verwendung des Attributs configChanges auch die Orientierungssperre ignoriert. Wie können Sie das lösen? Wenn Sie die Antwort wissen, schreiben Sie sie bitte hier: stackoverflow.com/questions/24000361/…

    – Android-Entwickler

    2. Juni 2014 um 17:55 Uhr

  • Please don't do the default reset when the keyboard is pulled out Ich habe noch nie einen Aktivitätsneustart für gesehen Tastatur ausziehbar!

    – Muhammad Babar

    1. Dezember 2014 um 7:28 Uhr

  • Diese Antwort erwähnt leider nicht die Haupterklärung des Beamten Google-Dokumentation. Das Hauptproblem liegt in alternativen Ressourcensätzen, die bei Konfigurationsänderungen nicht automatisch für Sie angewendet werden, falls Sie dies manuell handhaben möchten. Und es betrifft nicht nur die betreffende Aktivität, sondern die gesamte Anwendung.

    – Coryffäus

    15. Januar 2016 um 11:46 Uhr

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.

  • Ja, wir haben uns in Version 1.0 unserer App dafür entschieden, passend zu unserer Apple-Version. Es wurde NUR im Hochformat präsentiert. Was auf meinem Droid X großartig aussah, wir haben das Popup-Tastaturverhalten der IOS-Version genau angepasst. Dann installierte der CFO die App auf seinem Droid, drehte ihn zur Seite und schob die Tastatur auf. Hoppla. Die Sache mit Android ist, dass es eine offene Plattform ist und Sie die Hardwarekonfiguration oder das, was der Benutzer damit machen möchte, wirklich nicht vorhersagen können, also sollten Sie wahrscheinlich beide (alle) Ausrichtungen unterstützen, nur für den Fall.

    – Tevo D

    1. November 2011 um 18:45 Uhr

  • Was übrigens unsere Nur-Hochformat-Einstellung außer Kraft setzte, da es im Grunde genommen in der Hardware lag, dass Querformat dann die normale, nicht alternative Ausrichtung war. Was unser Layout WIRKLICH durcheinander gebracht hat 🙁 und ziemlich peinlich war, da es innerhalb von Sekunden nach der Installation der App einen großen Fehler hatte

    – Tevo D

    1. November 2011 um 18:51 Uhr


  • Warum haben Sie versucht, es sich genau wie iOS verhalten zu lassen? 🙁

    – FunkTheMonk

    1. November 2011 um 20:53 Uhr

  • @FunkTheMonk Leider leben wir in einer Welt, in der Geschäftsleute technische Entscheidungen treffen. Selbst wenn Sie dagegen argumentieren, denken sie die Hälfte der Zeit, dass sie sowieso Recht haben. Und sie kontrollieren Ihren Gehaltsscheck.

    – Stapelüberlauf

    25. Juni 2012 um 2:11 Uhr

  • Die Verwendung nur eines Layouts bedeutet nicht, dass der Bildschirm beim Drehen gleich aussieht. Ein gut strukturiertes XML-Layout bewirkt, dass sich die Dinge automatisch verschieben, damit sie mit angemessenen Dimensionen gut funktionieren, und die Benutzer werden das zu schätzen wissen.

    – Melinda Grün

    9. November 2012 um 0:12 Uhr

Warum nicht immer androidconfigChangeskeyboardHiddenorientation verwenden
Renetik

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.

  • Hallo, kann jemand, der sich mit diesem Thema auskennt, bitte einen Blick auf meinen Thread werfen: stackoverflow.com/questions/35941585/… ? Brauche dringend Hilfe.

    – Lukas Allison

    14. März 2016 um 4:28 Uhr

  • Sie sollten das Speichern/Fortsetzen von Aktivitäten voll unterstützen … die Handhabung für die Rotation ist nicht anders … Sie sagen, Sie verlieren ein paar Schritte … wenn Sie es richtig machen, verlieren Sie keine Schritte und Sie stellen genau dort wieder her, wo der Benutzer aufgehört hat … auch nach Neustart des Gerätes.

    – GEHÄMMERT

    7. Dezember 2016 um 18:46 Uhr

  • gehämmert Ich weiß nicht, wovon Sie sprechen, aber ich sage, dass Anwendungen, wenn Sie es auf diese Weise tun, unter normalen Umständen gut funktionieren. 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…

    – Renetik

    8. Dezember 2016 um 1:56 Uhr


  • Das Ignorieren der Einhaltung des Aktivitätsvertrags (Speichern/Wiederherstellen des Zustands) ist eine schlechte Praxis, und dies ist insgesamt ein schrecklicher Rat. Versuchen Sie, den Prozesstod zu testen, und sehen Sie, wohin Ihre App Sie führt, und dieses Verhalten ist ein völlig normaler “normaler Umstand”, wenn Ihr Benutzer mindestens 2-3 Apps auf seinem Telefon verwendet und zwischen ihnen wechselt.

    – EpicPandaForce

    16. Januar 2018 um 12:49 Uhr

1646630001 487 Warum nicht immer androidconfigChangeskeyboardHiddenorientation verwenden
Raúl

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.

  1. Aktualisieren Sie das Manifest, um die Ausrichtung zu verarbeiten.

    android:configChanges="orientation|screenSize"
    
  2. diesen Code hinzufügen

    @Override
    public void onConfigurationChanged(Configuration newConfig) {
        // TODO Auto-generated method stub      
        super.onConfigurationChanged(newConfig);        
        setContentView(R.layout.activity_main);
    }
    
963060cookie-checkWarum nicht immer android:configChanges=”keyboardHidden|orientation” verwenden?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy