Frage Ist das Beenden einer Anwendung verpönt?


In meinem Versuch, Android zu lernen, gehe ich einfach weiter Lese das folgende:

Frage: Hat der Benutzer die Wahl, die Anwendung zu beenden?   es sei denn, wir setzen eine Menüoption, um es zu töten? Wenn keine solche Option existiert,   Wie beendet der Benutzer die Anwendung?

Antwort: (Romain Guy): Der Benutzer erledigt das nicht automatisch. Dies ist der Aktivitätslebenszyklus (insbesondere onPause / onStop / onDestroy). Egal, was Sie tun, setzen Sie keine "Beenden" oder "Beenden" -Anwendung Schaltfläche. Es ist nutzlos mit Androids Anwendungsmodell. Dies steht auch im Widerspruch zur Funktionsweise von Kernanwendungen.

Hehe, bei jedem Schritt in der Android-Welt stoße ich auf ein Problem = (

Anscheinend können Sie eine Anwendung in Android nicht beenden (aber das Android-System kann Ihre App völlig zerstören, wann immer es sich anfühlt). Was ist damit? Ich fange an zu denken, dass es unmöglich ist, eine App zu schreiben, die als "normale App" funktioniert - dass der Nutzer die App beenden kann, wenn er sich dazu entschließt. Das sollte nicht auf das Betriebssystem angewiesen sein.

Die Anwendung, die ich erstellen möchte, ist keine Anwendung für den Android Market. Es ist keine Anwendung für "breite Nutzung" durch die breite Öffentlichkeit, es ist eine Business-App, die in einem sehr engen Geschäftsfeld eingesetzt wird.

Ich habe mich wirklich sehr darauf gefreut, für die Android-Plattform zu entwickeln, da es viele Probleme behebt, die in Windows Mobile und .NET existieren. Aber die letzte Woche war für mich eine kleine Ablenkung ... Ich hoffe, ich muss Android nicht aufgeben, aber es sieht jetzt nicht sehr gut aus = (

Gibt es einen Weg für mich? Ja wirklich die Anwendung beenden?


1037


Ursprung


Antworten:


Dies wird schließlich zu Ihrer Frage kommen, aber ich möchte zuerst eine Reihe von Fragen ansprechen, die Sie in Ihren verschiedenen Kommentaren zu den verschiedenen Antworten, die zum Zeitpunkt des Schreibens bereits gegeben wurden, aufwerfen. Ich habe nicht die Absicht, Ihre Meinung zu ändern - vielmehr sind diese hier für andere, die kommen, um diesen Beitrag in der Zukunft zu lesen.

Der Punkt ist, dass ich nicht zulassen kann   Android um festzustellen, wann meine App ist   wird beendet. das muss sein   die Wahl des Benutzers.

Millionen von Menschen sind vollkommen zufrieden mit dem Modell, bei dem die Umgebung die Anwendung nach Bedarf schließt. Diese Benutzer denken einfach nicht daran, die Android-App zu "beenden", genauso wenig wie sie über das "Beenden" einer Webseite oder das "Beenden" eines Thermostats nachdenken.

iPhone-Nutzer sind in etwa so, als dass das Drücken der iPhone-Taste nicht unbedingt so "gefühlt" wie die App abgebrochen wurde, da viele iPhone-Apps dort aufgehört haben, wo der Nutzer aufgehört hat (auch seit iPhone) ermöglicht zurzeit jeweils eine Drittanbieter-App).

Wie ich oben sagte, gibt es eine Menge   Dinge, die in meiner App passieren (Daten werden   PUSHed zum Gerät, Listen mit Aufgaben   das sollte immer da sein, usw.).

Ich weiß nicht, was "Listen mit Aufgaben, die immer da sein sollten" bedeutet, aber die "Daten, die an das Gerät PUSHed sind" ist eine angenehme Fiktion und sollte in keinem Fall durch eine Aktivität erledigt werden. Verwenden Sie eine geplante Aufgabe (über AlarmManager) um Ihre Daten für maximale Zuverlässigkeit zu aktualisieren.

Unsere Benutzer melden sich an und können nicht handeln   das jedes Mal, wenn sie einen Anruf bekommen   und Android beschließt, die App zu töten.

Es gibt viele iPhone- und Android-Anwendungen, die damit umgehen. In der Regel liegt dies daran, dass sie Anmeldeinformationen speichern, anstatt Benutzer zu zwingen, sich jedes Mal manuell anzumelden.

Zum Beispiel möchten wir Updates überprüfen   beim Beenden der Anwendung

Das ist ein Fehler auf jedem Betriebssystem. Der Grund dafür, dass Ihre Anwendung "beendet" ist, besteht darin, dass das Betriebssystem heruntergefahren wird und der Aktualisierungsprozess dann im Midstream fehlschlägt. Im Allgemeinen ist das keine gute Sache. Entweder Updates beim Start prüfen oder Updates vollständig asynchron (z. B. über eine geplante Aufgabe) prüfen, niemals beim Beenden.

Einige Kommentare deuten darauf hin, dass die   Zurück-Taste tötet die App nicht bei   alle (siehe Link in meiner Frage oben).

Durch Drücken der BACK-Taste wird die App nicht beendet. Es beendet die Aktivität, die auf dem Bildschirm angezeigt wurde, wenn der Benutzer die Schaltfläche ZURÜCK gedrückt hat.

Es sollte nur beendet werden, wenn der   Benutzer möchten es beenden - nie   auf jede andere Weise. Wenn du nicht schreiben kannst   Apps, die sich in Android so verhalten,   dann denke ich, dass Android nicht verwendet werden kann   um echte Apps zu schreiben = (

Dann können auch keine Web-Anwendungen. Oder WebOSwenn ich ihr Modell richtig verstehe (hatte noch keine Chance mit einem zu spielen). In all diesen Fällen "kündigen" die Benutzer nichts - sie verlassen einfach. Das iPhone ist ein bisschen anders, da es momentan nur eine Sache zu einer Zeit laufen lässt (mit ein paar Ausnahmen), und so bedeutet das Verlassen der App eine ziemlich sofortige Beendigung der App.

Gibt es eine Möglichkeit für mich, wirklich aufzuhören?   die Anwendung?

Wie alle anderen Ihnen gesagt haben, Benutzer (über BACK) oder Ihren Code (über finish()) können Ihre aktuell laufenden Aktivitäten schließen. Benutzer benötigen im Allgemeinen für ordnungsgemäß geschriebene Anwendungen nichts anderes, als sie eine "Beenden" -Option für die Verwendung von Webanwendungen benötigen.


Keine zwei Anwendungsumgebungen sind per Definition identisch. Dies bedeutet, dass Sie Trends in Umgebungen sehen können, wenn neue entstehen und andere begraben werden.

Zum Beispiel gibt es eine wachsende Bewegung, um zu versuchen, den Begriff der "Datei" zu beseitigen. Die meisten Webanwendungen zwingen Benutzer nicht dazu, an Dateien zu denken. iPhone-Apps zwingen Benutzer normalerweise nicht dazu, an Dateien zu denken. Android-Apps zwingen Benutzer normalerweise nicht dazu, an Dateien zu denken. Und so weiter.

In ähnlicher Weise gibt es eine wachsende Bewegung, um den Begriff "Beenden" einer App zu eliminieren. Die meisten Webanwendungen zwingen den Benutzer nicht dazu, sich abzumelden, sondern protokollieren den Benutzer implizit nach einem Zeitraum der Inaktivität. Das Gleiche gilt für Android und in geringerem Maße für das iPhone (und möglicherweise WebOS).

Dies erfordert eine stärkere Betonung des Anwendungsdesigns, die Fokussierung auf Geschäftsziele und nicht die Einhaltung eines Implementierungsmodells, das an eine frühere Anwendungsumgebung gebunden ist. Entwickler, denen die Zeit oder die Neigung fehlt, dies zu tun, werden frustriert mit neueren Umgebungen, die ihr bestehendes mentales Modell durchbrechen. Das ist nicht die Schuld der einen oder anderen Umgebung, ebenso wenig wie die Schuld eines Berges für Stürme, die ihn umströmen und nicht durch ihn.

Zum Beispiel, einige Entwicklungsumgebungen, wie Hyperkarte und Smalltalk, hatten die Anwendung und die Entwicklungstools in einem Setup zusammengemischt. Dieses Konzept hat sich außerhalb von Spracherweiterungen für Apps (z. B. VBA im Excel, Lisp in AutoCAD). Entwickler, die mentale Modelle entwickelten, die die Existenz von Entwicklungswerkzeugen in der App selbst vermuteten, mussten daher entweder ihr Modell ändern oder sich auf Umgebungen beschränken, in denen ihr Modell gelten würde.

Also, wenn du schreibst:

Zusammen mit anderen unordentlichen Dingen   entdeckt, ich denke, dass sich das entwickelt   unsere App für Android wird nicht gehen   geschehen.

Das scheint für Sie das Beste zu sein, für jetzt. Ebenso würde ich Sie davon abraten, Ihre Anwendung ins Web zu portieren, da einige der gleichen Probleme, die Sie bei Android gemeldet haben, auch in Webanwendungen zu finden sind (z. B. keine "Kündigung"). Oder, umgekehrt, eines Tages, wenn Sie machen Wenn Sie Ihre App auf das Web portieren, stellen Sie möglicherweise fest, dass der Fluss der Webanwendung möglicherweise besser zu Android passt, und Sie können zu diesem Zeitpunkt einen Android-Port erneut aufrufen.


1216



Ich möchte hier nur eine Korrektur für die zukünftigen Leser dieses Threads hinzufügen. Diese besondere Nuance ist meinem Verständnis für eine lange Zeit entgangen, deshalb möchte ich sicherstellen, dass keiner von euch die gleichen Fehler macht:

System.exit() tötet Ihre App nicht, wenn Sie mehr als eine Aktivität auf dem Stapel haben.  Was tatsächlich passiert ist das Der Prozess wird beendet und sofort neu gestartet mit einer Aktivität weniger auf dem Stapel. Dies ist auch der Fall, wenn Ihre App durch das Dialogfeld Schließen erzwungen wird oder wenn Sie versuchen, den Prozess von DDMS zu beenden. Dies ist eine Tatsache, die meines Wissens völlig undokumentiert ist.

Die kurze Antwort ist, wenn Sie Ihre Anwendung beenden möchten, müssen Sie alle Aktivitäten in Ihrem Stack und verfolgen finish() Alle von ihnen, wenn der Benutzer beenden möchte (und nein, es gibt keine Möglichkeit, den Aktivitätsstapel zu durchlaufen, so dass Sie all dies selbst verwalten müssen). Auch dies tötet nicht den Prozess oder irgendwelche dangling Referenzen, die Sie haben können. Es beendet einfach die Aktivitäten. Außerdem bin ich mir nicht sicher ob Process.killProcess(Process.myPid()) funktioniert besser; Ich habe es nicht getestet.

Wenn es andererseits für Sie in Ordnung ist, Aktivitäten in Ihrem Stack zu haben, gibt es eine andere Methode, die Ihnen die Dinge sehr leicht macht: Activity.moveTaskToBack(true) wird einfach Ihren Prozess Hintergrund und zeigen Sie den Startbildschirm.

Die lange Antwort beinhaltet die Erklärung der Philosophie hinter diesem Verhalten. Die Philosophie basiert auf einer Reihe von Annahmen:

  1. Dies geschieht zunächst nur, wenn Ihre App im Vordergrund ist. Wenn es im Hintergrund ist, wird der Prozess gut beendet. Wenn es jedoch im Vordergrund ist, nimmt das Betriebssystem an, dass der Benutzer weiter machen möchte, was auch immer er gerade macht. (Wenn Sie versuchen, den Prozess von DDMS zu beenden, sollten Sie zuerst die Home-Taste drücken und dann die Option beenden)
  2. Es geht auch davon aus, dass jede Aktivität unabhängig von allen anderen Aktivitäten ist. Dies ist häufig der Fall, wenn Ihre App beispielsweise die Browser-Aktivität startet, die völlig separat ist und nicht von Ihnen geschrieben wurde. Abhängig von den Manifestattributen kann die Browseraktivität für dieselbe Aufgabe erstellt werden oder auch nicht.
  3. Es geht davon aus, dass jede Ihrer Aktivitäten vollständig selbständig ist und in kürzester Zeit getötet / wiederhergestellt werden kann. (Ich mag diese bestimmte Annahme eher nicht, da meine App viele Aktivitäten hat, die auf einer großen Menge von zwischengespeicherten Daten beruhen, die zu groß sind, um während dieser Zeit effizient serialisiert zu werden onSaveInstanceState, aber was soll ich machen?) Für die meisten gut geschriebenen Android-Apps sollte das stimmen, da man nie weiß, wann die App im Hintergrund gelöscht wird.
  4. Der letzte Faktor ist nicht so sehr eine Annahme, sondern eine Einschränkung des Betriebssystems: Das explizite Ausschalten der App ist mit dem Absturz der App identisch und das gleiche wie Android, das die App zum Wiederherstellen des Speichers beendet.  Dies gipfelt in unserem Gnadenstoß: Da Android nicht feststellen kann, ob die App beendet wurde oder abgestürzt ist oder im Hintergrund getötet wurde, geht sie davon aus, dass der Benutzer dorthin zurückkehren möchte, wo er aufgehört hat, und der ActivityManager startet den Prozess neu.

Wenn Sie darüber nachdenken, ist dies für die Plattform geeignet. Erstens passiert genau das, wenn der Prozess im Hintergrund beendet wird und der Benutzer zu ihm zurückkehrt, so dass er dort neu gestartet werden muss, wo er aufgehört hat. Zweitens passiert dies, wenn die App abstürzt und den gefürchteten Force Close-Dialog anzeigt.

Angenommen, ich möchte, dass meine Nutzer ein Bild aufnehmen und hochladen können. Ich starte die Kameraaktivität aus meiner Aktivität und fordere sie auf, ein Bild zurückzugeben. Die Kamera wird an die Spitze meiner aktuellen Aufgabe geschoben (anstatt in einer eigenen Aufgabe erstellt zu werden). Wenn die Kamera einen Fehler hat und abstürzt, sollte dies zum Absturz der gesamten App führen? Aus Sicht des Benutzers ist nur die Kamera ausgefallen und sie sollten zu ihrer vorherigen Aktivität zurückkehren. Es startet also den Prozess mit den gleichen Aktivitäten im Stapel, abzüglich der Kamera. Seit deinen Aktivitäten sollte so konzipiert sein, dass sie im Handumdrehen getötet und restauriert werden können, sollte dies kein Problem sein. Leider können nicht alle Apps so gestaltet werden ist ein Problem für viele von uns, egal was Romain Guy oder jemand anderes Ihnen erzählt. Also müssen wir Workarounds verwenden.

Also, mein abschließender Ratschlag:

  • Versuche nicht, den Prozess zu beenden. Entweder anrufen finish() auf alle Aktivitäten oder rufen Sie an moveTaskToBack(true).
  • Wenn Ihr Prozess abstürzt oder getötet wird, und wenn, wie ich, können Sie die Daten benötigen, die in Erinnerung war, die jetzt verloren ist, werden Sie auf die Wurzelaktivität zurückkommen müssen. Um dies zu tun, sollten Sie anrufen startActivity() mit einer Absicht, die die enthält Intent.FLAG_ACTIVITY_CLEAR_TOP Flagge.
  • Wenn Sie Ihre App aus der DDMS-Perspektive von Eclipse beenden möchten, ist sie besser nicht im Vordergrund oder wird neu gestartet. Sie sollten zuerst die Home-Taste drücken und dann Töte den Prozess.

280



Alle meine Anwendungen haben Schaltflächen zum Beenden ... und ich bekomme deswegen häufig positive Kommentare von Benutzern. Es ist mir egal, ob die Plattform so entworfen wurde, dass Anwendungen sie nicht benötigen. Zu sagen "bring sie nicht hin" ist irgendwie lächerlich. Wenn der Benutzer beenden möchte, biete ich ihnen den Zugang, genau das zu tun. Ich glaube nicht, dass es die Funktionsweise von Android reduziert und wie eine gute Praxis aussieht. Ich verstehe den Lebenszyklus ... und meine Beobachtung war, dass Android keine gute Arbeit damit macht ... und das ist eine grundlegende Tatsache.


168



Hören Sie auf, Ihre Anwendung als eine monolithische Anwendung zu betrachten. Es ist eine Reihe von UI-Bildschirmen, die der Benutzer mit Ihrer "Anwendung" und "Funktionen" über Android-Dienste interagieren kann.

Nicht zu wissen, was deine mysteriöse App "tut" ist nicht wirklich wichtig. Nehmen wir an, dass es sich in ein super sicheres Unternehmens-Intranet eintunnelt, eine Überwachung oder Interaktion durchführt und solange angemeldet bleibt, bis der Benutzer die Anwendung "beendet". Da Ihre IT-Abteilung es anweist, müssen sich Benutzer sehr bewusst sein, wann sie sich im Intranet befinden oder nicht. Daher ist es Ihre Einstellung, dass es für Benutzer wichtig ist, "aufzuhören".

Das ist einfach. Stellen Sie einen Dienst bereit, der eine fortlaufende Benachrichtigung in der Benachrichtigungsleiste mit der Meldung "Ich bin im Intranet, oder ich lebe" sendet. Lassen Sie diesen Dienst alle Funktionen ausführen, die Sie für Ihre Anwendung benötigen. Verfügen Sie über Aktivitäten, die an diesen Dienst gebunden sind, damit Ihre Benutzer auf die UI-Elemente zugreifen können, die sie für die Interaktion mit Ihrer "Anwendung" benötigen. Und haben Sie ein Android-Menü -> Beenden (oder Abmelden, oder was auch immer) -Taste, die dem Dienst sagt, um zu beenden, schließt dann die Aktivität selbst.

Dies ist für alle Absichten und Zwecke genau das, was Sie sagen, dass Sie wollen. Fertig für Android. Sehen Sie sich Google Talk oder Google Maps Navigation für Beispiele dieser "Exit" ist möglich Mentalität. Der einzige Unterschied besteht darin, dass das Zurückdrücken Ihrer Aktivität Ihren UNIX-Prozess in Gefahr bringt, falls der Benutzer Ihre Anwendung wiederbeleben möchte. Dies ist wirklich nicht anders als ein modernes Betriebssystem, das kürzlich zugegriffene Dateien im Speicher zwischenspeichert. Nachdem Sie Ihr Windows-Programm beenden, höchstwahrscheinliche Ressourcen, die es sind noch im Speicher benötigt, warten darauf, von anderen Ressourcen ersetzt zu werden, da sie nun geladen sind, dass sie nicht mehr benötigt werden. Android ist das Gleiche.

Ich sehe dein Problem wirklich nicht.


134



Dies ist eine interessante und aufschlussreiche Diskussion mit so vielen Experten. Ich denke, dass dieser Beitrag von der Android-Hauptwebsite zurückgeschleift werden sollte, da er sich um eines der Kerndesigns des Android-Betriebssystems dreht.

Ich möchte auch meine zwei Cent hier hinzufügen.

Bisher war ich beeindruckt von der Art und Weise, wie Android Lifecycle-Ereignisse behandelt, und bringt das Konzept eines webähnlichen Erlebnisses in native Apps.

Nachdem ich gesagt habe, dass ich immer noch glaube, dass es eine geben sollte Verlassen Taste. Warum? ... nicht für mich oder Ted oder irgendeinen der Technologie-Gurus hier, sondern ausschließlich für die Erfüllung einer Endnutzer-Nachfrage.

Obwohl ich kein großer Fan von Windows bin, aber lange zurück, haben sie ein Konzept eingeführt, an das die meisten Endbenutzer gewöhnt sind (eine X-Taste) ... "Ich möchte ein Widget beenden, wenn ich es möchte".

Das heißt nicht, dass jemand (OS, Entwickler?) Das nach seinem eigenen Ermessen erledigen wird ... es bedeutet einfach "Wo ist mein Red X Button, an den ich gewöhnt bin". Meine Aktion sollte analog zu "Beenden eines Anrufs beim Drücken einer Taste", "Ausschalten des Geräts durch Drücken einer Taste" und so weiter und so weiter sein ... es ist eine Wahrnehmung. Es bringt per se eine Befriedigung, dass mein Handeln tatsächlich seinen Zweck erfüllt.

Obwohl ein Entwickler dieses Verhalten unter Verwendung der hier gegebenen Vorschläge vortäuschen kann, bleibt die Wahrnehmung bestehen, d. H. Eine Anwendung sollte (jetzt) ​​vollständig aufhören, durch eine unabhängige, vertrauenswürdige und neutrale Quelle (OS) auf Anforderung vom Endbenutzer.


68



Sie kann quittieren, entweder durch Drücken der Taste Zurück Knopf oder durch anruf finish() in deinem Activity. Ruf einfach an finish() von einem MenuItem wenn du es explizit ausschalten willst.

Romain sagt nicht, dass es nicht machbar ist, nur dass es sinnlos ist - Benutzer müssen sich nicht darum kümmern, ihre Arbeit zu kündigen oder zu speichern, denn die Art und Weise, wie der Anwendungslebenszyklus funktioniert, ermutigt Sie, intelligente Software zu schreiben, die automatisch speichert und speichert stellt seinen Zustand wieder her, egal was passiert.


35



Diese Debatte läuft auf die uralte Frage hinaus, ob die Entwickler am besten wissen oder ob der Benutzer am besten Bescheid weiß. Professionelle Designer in allen Bereichen menschlicher Faktoren kämpfen damit jeden Tag.

Ted hat darauf hingewiesen, dass eine der am häufigsten heruntergeladenen Apps auf dem Markt der "App Killer" ist. Die Leute bekommen ein bisschen extra Serotonin, wenn sie Anwendungen beenden. Sie sind daran gewöhnt mit einem Desktop / Laptop. Es hält Dinge in Bewegung. Es hält den Prozessor kühl und der Lüfter schaltet sich ein. Es verbraucht weniger Energie.

Wenn Sie bedenken, dass ein mobiles Gerät ein viel kleineres Schiff ist, dann können Sie besonders ihren Anreiz schätzen, "über Bord zu werfen, was Sie nicht mehr brauchen". Jetzt haben die Entwickler von Android argumentiert, dass das Betriebssystem am besten weiß und dass das Beenden einer App antik ist. Ich unterstütze das von ganzem Herzen.

Ich glaube jedoch auch, dass Sie den Benutzer nicht frustrieren sollten, auch wenn diese Frustration aus ihrer eigenen Ignoranz resultiert. Aus diesem Grund komme ich zu dem Schluss, dass die Option "Beenden" ein gutes Design ist, auch wenn es sich meistens um einen Placebo-Button handelt, der lediglich eine Ansicht schließt.


31



Ted, was du erreichen willst, kann gemacht werden, vielleicht gerade nicht, wie du gerade jetzt darüber nachdenkst.

Ich schlage vor, dass Sie sich über Aktivitäten und Services informieren. Hören Sie auf, den Begriff "App" zu verwenden und beginnen Sie, auf die Komponenten, d. H. Aktivität, Dienst, zu verweisen. Ich denke, Sie müssen nur mehr über die Android-Plattform lernen; Es ist eine Änderung in der Denkweise von einer Standard-PC-App. Die Tatsache, dass in keinem Ihrer Beiträge das Wort "Aktivität" (kurz vor einem FAQ-Zitat, d. H. Nicht Ihre Wörter) enthalten ist, sagt mir, dass Sie etwas mehr lesen müssen.


28



Blogeintrag Wann sollte eine Beenden-Schaltfläche in Android-Apps enthalten sein (Hinweis: Nie) erklärt es weit, weit besser als ich kann. Ich wünschte, jeder Android-Entwickler hätte es schon gelesen.

Auszüge:

Nach meiner Erfahrung, was [die Benutzer] wirklich wollen, ist:    Ein eindeutiger Weg, um sicherzustellen, dass eine App keine Ressourcen mehr verbraucht (Batterie, CPU-Zyklen, Datenübertragung usw.).

Viele Benutzer nehmen an, dass eine Exit-Schaltfläche diese Anforderung implementiert   und bitten darum, dass es hinzugefügt wird. Entwickler, die ihre Nutzer zufriedenstellen möchten,   gefällig hinzufügen. Kurz darauf versagen sie beide.

  • In den meisten Fällen ruft der Exit-Button einfach auf Activity.finish(). Das ist genau entspricht dem Drücken der Zurück-Taste.    Genau.    Dienstleistungen laufen weiter und die Abstimmung läuft weiter. Benutzer denken vielleicht, dass sie die App getötet haben, aber sie haben es nicht getan, und bald   Sie werden noch ärgerlicher sein.
  • Das Austrittsverhalten ist jetzt mehrdeutig. Sollte Ihre Exit-Schaltfläche nur die Aktivität schließen, oder sollte sie auch alle zugehörigen Dienste, Empfänger und Alarme stoppen? Was sollte Zurück machen? Was passiert, wenn sie treffen? Zuhause stattdessen? Was passiert, wenn deine App ein Widget hat? Sollte der Exit-Button das auch stoppen?

Die Lösung besteht darin, dass sich der Zurück-Button wie erwartet verhält   Exit-Taste nach. Besser noch, hören Sie einfach auf, Ressourcen zu verbrauchen, wann auch immer   Die App ist nicht sichtbar.

Gehen Sie voran und lesen Sie den kompletten Artikel.


23