Ist das Beenden einer Bewerbung verpönt?

Bei meinem Versuch, Android zu lernen, habe ich nur Folgendes gelesen :

Frage: Hat der Benutzer die Wahl, die Anwendung zu beenden, es sei denn, wir fügen eine Menüoption hinzu, um sie zu beenden? Wie beendet der Benutzer die Anwendung, wenn keine solche Option vorhanden ist?

Antwort: (Romain Guy): Der Benutzer tut dies nicht, das System behandelt dies automatisch. Dafür ist der Aktivitätslebenszyklus (insbesondere onPause / onStop / onDestroy) gedacht. Egal was Sie tun, setzen Sie keine "Beenden" - oder "Beenden" -Anwendungsschaltfläche. Es ist mit dem Anwendungsmodell von Android nutzlos. 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 sehr gut 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" fungiert - dass der Benutzer die App beenden kann, wenn er sich dazu entscheidet. Darauf sollte sich das Betriebssystem nicht verlassen.

Die Anwendung, die ich erstellen möchte, ist keine Anwendung für den Android Market. Es handelt sich nicht um eine Anwendung für die "breite Nutzung" durch die breite Öffentlichkeit, sondern um eine Geschäftsanwendung, die in einem sehr engen Geschäftsfeld eingesetzt werden soll.

Ich freute mich wirklich darauf, für die Android-Plattform zu entwickeln, da sie viele Probleme behebt, die in Windows Mobile und .NET auftreten. Allerdings war die letzte Woche für mich eine Art Abkehr ... Ich hoffe, ich muss Android nicht aufgeben, aber es sieht momentan nicht sehr gut aus = (

Gibt es eine Möglichkeit für mich, die Anwendung wirklich zu beenden?

Dies wird irgendwann zu Ihrer Frage führen, aber ich möchte zunächst eine Reihe von Fragen ansprechen, die Sie in Ihren verschiedenen Kommentaren zu den verschiedenen Antworten ansprechen, die zum Zeitpunkt dieses Schreibens bereits gegeben wurden. Ich habe nicht die Absicht, Ihre Meinung zu ändern - vielmehr sind diese für andere da, die diesen Beitrag in Zukunft lesen möchten.

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

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 daran, eine Webseite zu "beenden" oder einen Thermostat zu "beenden".

iPhone-Benutzer sind ähnlich, da das Drücken der iPhone-Taste nicht unbedingt das Gefühl hat, dass die App beendet wurde, da viele iPhone-Apps dort weitermachen, wo der Benutzer aufgehört hat, selbst wenn die App wirklich heruntergefahren wurde (nur seit dem iPhone) erlaubt derzeit jeweils eine Drittanbieter-App).

Wie oben erwähnt, ist in meiner App eine Menge los (Daten werden auf das Gerät übertragen, Listen mit Aufgaben, die immer vorhanden sein sollten usw.).

Ich weiß nicht, was "Listen mit Aufgaben, die immer vorhanden sein sollten" bedeutet, aber die "Daten, die auf das Gerät übertragen werden" sind eine angenehme Fiktion und sollten auf keinen Fall von einer Aktivität ausgeführt werden. Verwenden Sie eine geplante Aufgabe (via AlarmManager), um Ihre Daten für maximale Zuverlässigkeit zu aktualisieren.

Unsere Benutzer melden sich an und können dies nicht jedes Mal tun, wenn sie einen Anruf erhalten und Android beschließt, die App zu beenden.

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

Beispielsweise möchten wir Aktualisierungen beim Beenden der Anwendung überprüfen

Das ist ein Fehler auf jedem Betriebssystem. Nach allem, was Sie wissen, wird Ihre Anwendung "beendet", weil das Betriebssystem heruntergefahren wird und Ihr Aktualisierungsprozess dann während des Streams fehlschlägt. Im Allgemeinen ist das keine gute Sache. Überprüfen Sie entweder die Aktualisierungen beim Start oder die Aktualisierungen vollständig asynchron (z. B. über eine geplante Aufgabe), niemals beim Beenden.

Einige Kommentare deuten darauf hin, dass das Drücken der Zurück-Taste die App überhaupt nicht beendet (siehe Link in meiner Frage oben).

Durch Drücken der BACK-Taste wird die App nicht "beendet". Damit ist die Aktivität beendet, die auf dem Bildschirm angezeigt wurde, als der Benutzer die Taste ZURÜCK drückte.

Es sollte nur beendet werden, wenn die Benutzer es beenden möchten - niemals auf andere Weise. Wenn Sie in Android keine Apps schreiben können, die sich so verhalten, kann Android meiner Meinung nach nicht zum Schreiben von echten Apps verwendet werden = (

Dann können Webanwendungen auch nicht. Oder WebOS , wenn ich das Modell richtig verstehe (ich hatte noch keine Chance, mit einem zu spielen). In all diesen Fällen "beenden" Benutzer nichts - sie gehen einfach. Das iPhone ist insofern etwas anders, als es derzeit nur eine Sache gleichzeitig laufen lässt (mit wenigen Ausnahmen), und das Verlassen des Apps impliziert daher eine ziemlich sofortige Beendigung der App.

Gibt es eine Möglichkeit für mich, die Anwendung wirklich zu beenden?

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

Per Definition sind keine zwei Anwendungsumgebungen gleich. 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 im Allgemeinen nicht dazu, an Dateien zu denken. Und so weiter.

In ähnlicher Weise gibt es eine wachsende Bewegung, um zu versuchen, den Gedanken des "Beenden" einer App zu beseitigen. Die meisten Webanwendungen zwingen den Benutzer nicht zum Abmelden, sondern zum impliziten Abmelden des Benutzers nach einer gewissen Zeit der Inaktivität. Gleiches gilt für Android und in geringerem Maße für das iPhone (und möglicherweise für WebOS).

Dies erfordert eine stärkere Betonung des Anwendungsdesigns, die Konzentration auf Geschäftsziele und die Nichteinhaltung eines Implementierungsmodells, das an eine frühere Anwendungsumgebung gebunden ist. Entwickler, denen die Zeit oder die Neigung dazu fehlt, werden von neueren Umgebungen frustriert sein, die ihr bestehendes mentales Modell brechen. Dies ist nicht die Schuld einer der beiden Umgebungen, ebenso wenig wie die Schuld eines Berges für Stürme, die um ihn herum und nicht durch ihn fließen.

In einigen Entwicklungsumgebungen wie Hypercard und Smalltalk wurden beispielsweise die Anwendung und die Entwicklungstools in einem Setup zusammengeführt. Außer bei Spracherweiterungen für Apps (z. B. VBA in Excel , Lisp in AutoCAD ) hat sich dieses Konzept nicht durchgesetzt . Entwickler, die mentale Modelle entwickelten, die die Existenz von Entwicklungstools in der App selbst voraussetzten, mussten daher entweder ihr Modell ändern oder sich auf Umgebungen beschränken, in denen ihr Modell zutreffen würde.

Also, wenn Sie schreiben:

Zusammen mit anderen chaotischen Dingen, die ich entdeckt habe, denke ich, dass die Entwicklung unserer App für Android nicht passieren wird.

Das scheint für Sie im Moment das Beste zu sein. Ebenso würde ich Ihnen davon abraten, Ihre Anwendung auf das Web zu portieren, da einige der Probleme, die Sie mit Android gemeldet haben, auch in Webanwendungen auftreten (z. B. keine "Kündigung"). Oder umgekehrt, ein Tag , wenn Sie tun Port Ihre App im Web, können Sie feststellen , dass die Fluss der Webanwendung eine bessere Übereinstimmung für Android sein kann, und Sie können ein Android - Port zu diesem Zeitpunkt überdenken.

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 lange Zeit entgangen, deshalb möchte ich sicherstellen, dass keiner von Ihnen die gleichen Fehler macht:

System.exit()beendet Ihre App nicht, wenn Sie mehr als eine Aktivität auf dem Stapel haben. Was tatsächlich passiert, ist, dass der Prozess abgebrochen und sofort mit einer Aktivität weniger auf dem Stapel neu gestartet wird . Dies ist auch der Fall, wenn Ihre App im Dialogfeld "Schließen erzwingen" beendet wird oder wenn Sie versuchen, den Prozess über DDMS abzubrechen. Dies ist meines Wissens eine Tatsache, die völlig undokumentiert ist.

Die kurze Antwort lautet: Wenn Sie Ihre Anwendung beenden möchten, müssen Sie alle Aktivitäten in Ihrem Stapel und finish()ALLE verfolgen , wenn der Benutzer das Programm beenden möchte (und nein, es gibt keine Möglichkeit, den Aktivitätsstapel zu durchlaufen , also müssen Sie das alles selbst verwalten). Selbst dies beendet nicht den Prozess oder irgendwelche baumelnden Referenzen, die Sie möglicherweise haben. Es beendet einfach die Aktivitäten. Ich bin mir auch nicht sicher, ob es Process.killProcess(Process.myPid())besser funktioniert. Ich habe es nicht getestet.

Wenn es andererseits in Ordnung ist, dass noch Aktivitäten in Ihrem Stapel verbleiben, gibt es eine andere Methode, die Ihnen Activity.moveTaskToBack(true)die Arbeit sehr einfach macht: Sie können Ihren Prozess einfach als Hintergrund anzeigen und den Startbildschirm anzeigen.

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 steht. Wenn es sich im Hintergrund befindet, wird der Prozess einwandfrei beendet. Wenn es jedoch im Vordergrund steht, geht das Betriebssystem davon aus, dass der Benutzer weiterhin das tun möchte, was er getan hat. (Wenn Sie versuchen, den Prozess über DDMS zu beenden, sollten Sie zuerst die Home-Taste drücken und ihn dann beenden.)
2. Es wird auch davon ausgegangen, dass jede Aktivität unabhängig von allen anderen Aktivitäten ist. Dies trifft häufig zu, beispielsweise wenn Ihre App die Browser-Aktivität startet, die völlig separat ist und nicht von Ihnen geschrieben wurde. Die Browseraktivität kann abhängig von ihren Manifestattributen für dieselbe Aufgabe erstellt werden oder nicht.
3. Es wird davon ausgegangen, dass jede Ihrer Aktivitäten völlig eigenständig ist und in kürzester Zeit getötet / wiederhergestellt werden kann. (Ich mag diese spezielle Annahme eher nicht, da meine App viele Aktivitäten hat, die auf einer großen Menge zwischengespeicherter Daten beruhen, die zu groß sind, um effizient serialisiert zu werden onSaveInstanceState, aber was soll ich tun?) Für die meisten gut geschriebenen Android-Apps sollte dies zutreffen. da Sie nie wissen, wann Ihre App im Hintergrund beendet wird.
4. Der letzte Faktor ist nicht so sehr eine Annahme, sondern eine Einschränkung des Betriebssystems: Das explizite Beenden der App ist dasselbe wie das Abstürzen der App und auch das Beenden der App durch Android, um Speicher zurückzugewinnen. Dies gipfelt in unserem Gnadenstoß: Da Android nicht erkennen kann, ob die App beendet oder abgestürzt ist oder im Hintergrund getötet wurde, wird davon ausgegangen, dass der Benutzer dorthin zurückkehren möchte, wo er aufgehört hat, und der ActivityManager startet den Vorgang neu.

Wenn Sie darüber nachdenken, ist dies für die Plattform angemessen. Erstens ist dies genau das, was passiert, wenn der Prozess im Hintergrund beendet wird und der Benutzer darauf zurückkommt. Daher muss er dort neu gestartet werden, wo er aufgehört hat. Zweitens passiert dies, wenn die App abstürzt und das gefürchtete Dialogfeld "Schließen erzwingen" angezeigt wird.

Angenommen, ich möchte, dass meine Benutzer ein Bild aufnehmen und hochladen können. Ich starte die Kameraaktivität von meiner Aktivität aus und fordere sie auf, ein Bild zurückzugeben. Die Kamera wird oben auf meine aktuelle Aufgabe geschoben (anstatt in einer eigenen Aufgabe erstellt zu werden). Wenn die Kamera einen Fehler aufweist und abstürzt, sollte dies dazu führen, dass die gesamte App abstürzt? Aus Sicht des Benutzers ist nur die Kamera ausgefallen, und sie sollten zu ihrer vorherigen Aktivität zurückkehren. Es wird also nur der Prozess mit denselben Aktivitäten im Stapel neu gestartet, abzüglich der Kamera. Da Ihre Aktivitäten so gestaltet sein sollten , dass sie im Handumdrehen getötet und wiederhergestellt werden können, sollte dies kein Problem sein. Leider können nicht alle Anwendungen , die so gestaltet sein, so dass es istEin Problem für viele von uns, egal was Romain Guy oder sonst jemand Ihnen sagt. Wir müssen also Problemumgehungen verwenden.

Also, mein abschließender Rat:

• Versuchen Sie nicht, den Prozess zu beenden. Rufen Sie entweder finish()alle Aktivitäten auf oder rufen Sie an moveTaskToBack(true).
• Wenn Ihr Prozess abstürzt oder abgebrochen wird und Sie wie ich die Daten im Speicher benötigen, die jetzt verloren gehen, müssen Sie zur Stammaktivität zurückkehren. Dazu sollten Sie startActivity()mit einer Absicht aufrufen , die das Intent.FLAG_ACTIVITY_CLEAR_TOPFlag enthält .
• Wenn Sie Ihre App aus der Eclipse DDMS-Perspektive beenden möchten, sollte sie besser nicht im Vordergrund stehen, da sie sich sonst neu startet. Sie sollten zuerst die Home-Taste drücken und dann den Vorgang abbrechen.

Alle meine Anwendungen haben Schaltflächen zum Beenden ... und ich bekomme deshalb häufig positive Kommentare von Benutzern. Es ist mir egal, ob die Plattform so gestaltet wurde, dass Anwendungen sie nicht benötigen sollten. Zu sagen, "bring sie nicht dorthin" ist irgendwie lächerlich. Wenn der Benutzer beenden möchte ... biete ich ihm den Zugriff, um genau das zu tun. Ich denke nicht, dass es die Funktionsweise von Android einschränkt und eine gute Praxis zu sein scheint. Ich verstehe den Lebenszyklus ... und meine Beobachtung war, dass Android keine gute Arbeit darin leistet ... und das ist eine grundlegende Tatsache.

Stellen Sie sich Ihre Anwendung nicht mehr als monolithische Anwendung vor. Es handelt sich um eine Reihe von UI-Bildschirmen, auf denen der Benutzer mit Ihrer "Anwendung" und den über Android-Diensten bereitgestellten "Funktionen" interagieren kann.

Nicht zu wissen, was Ihre mysteriöse App "tut", ist nicht wirklich wichtig. Nehmen wir an, es wird in ein supersicheres Unternehmensintranet getunnelt, führt eine Überwachung oder Interaktion durch und bleibt angemeldet, bis der Benutzer "die Anwendung beendet". Da Ihre IT-Abteilung dies befiehlt, müssen Benutzer sehr bewusst sein, wann sie sich im Intranet befinden oder nicht. Daher ist es für Sie wichtig, dass Benutzer "beenden".

Das ist einfach. Erstellen Sie einen Dienst, der eine fortlaufende Benachrichtigung in die Benachrichtigungsleiste mit der Meldung "Ich bin im Intranet oder werde ausgeführt" einfügt. Lassen Sie diesen Dienst alle Funktionen ausführen, die Sie für Ihre Anwendung benötigen. Haben Sie Aktivitäten, die an diesen Dienst gebunden sind, damit Ihre Benutzer auf die Teile der Benutzeroberfläche zugreifen können, die sie für die Interaktion mit Ihrer "Anwendung" benötigen. Und haben eine Android-Menü -> Schaltfläche Beenden (oder Abmelden oder was auch immer), die den Dienst anweist, zu beenden, und dann die Aktivität selbst schließt.

Dies ist in jeder Hinsicht genau das, was Sie sagen, dass Sie wollen. Fertig auf Android-Art. Schauen Sie sich Google Talk oder Google Maps Navigation an, um Beispiele für diese "Exit" -Mentalität zu finden. Der einzige Unterschied besteht darin, dass durch Drücken der Zurück-Taste aus Ihrer Aktivität Ihr UNIX-Prozess möglicherweise auf der Lauer liegt, falls der Benutzer Ihre Anwendung wiederbeleben möchte. Dies ist wirklich nichts anderes als ein modernes Betriebssystem, das kürzlich aufgerufene Dateien im Speicher zwischenspeichert. Nachdem Sie Ihr Windows-Programm beendet haben, befinden sich die wahrscheinlich benötigten Ressourcen noch im Speicher und warten darauf, durch andere Ressourcen ersetzt zu werden, da sie jetzt geladen werden, da sie nicht mehr benötigt werden. Android ist das gleiche.

Ich sehe dein Problem wirklich nicht.

Dies ist eine interessante und aufschlussreiche Diskussion, an der so viele Experten beteiligt sind. Ich bin der Meinung, dass dieser Beitrag von der Hauptwebsite der Android-Entwicklung zurückgeschleift werden sollte, da er sich um eines der Kerndesigns des Android-Betriebssystems dreht.

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

Bisher war ich beeindruckt von der Art und Weise, wie Android mit Lebenszyklusereignissen umgeht und das Konzept einer webähnlichen Erfahrung in native Apps einbringt.

Trotzdem glaube ich immer noch, dass es einen QuitKnopf geben sollte . Warum? ... nicht für mich oder Ted oder einen der Tech-Gurus hier, sondern nur, um die Anforderungen der Endbenutzer zu erfüllen.

Obwohl ich kein großer Fan von Windows bin, haben sie vor langer Zeit ein Konzept eingeführt, an das die meisten Endbenutzer gewöhnt sind (eine X-Schaltfläche) ... "Ich möchte das Ausführen eines Widgets beenden, wenn ich möchte".

Das bedeutet nicht, dass sich jemand (Betriebssystem, Entwickler?) Nach eigenem Ermessen darum kümmert. Es bedeutet einfach, "wo ist meine rote X-Taste, an die 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" usw. sein. Es ist eine Wahrnehmung. Es ist per se eine Befriedigung, dass mein Handeln tatsächlich seinen Zweck erreicht.

Auch wenn ein Entwickler dieses Verhalten anhand der hier gegebenen Vorschläge fälschen kann, bleibt die Wahrnehmung bestehen, dh eine Anwendung sollte (jetzt) ​​von einer unabhängigen, vertrauenswürdigen und neutralen Quelle (OS) auf Anfrage des Endbenutzers vollständig nicht mehr funktionieren.

Sie können beenden, indem Sie entweder die BackTaste drücken oder finish()Ihre Activity. Rufen Sie einfach finish()von a an, MenuItemwenn Sie es explizit beenden möchten.

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

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

Ted hat darauf hingewiesen, dass eine der am häufigsten heruntergeladenen Apps auf dem Markt der "App Killer" ist. Menschen erhalten ein bisschen mehr Serotonin, wenn sie Anwendungen beenden. Sie sind daran mit einem Desktop / Laptop gewöhnt. Es hält die Dinge schnell in Bewegung. Es hält den Prozessor kühl und den Lüfter nicht einzuschalten. Es verbraucht weniger Strom.

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

Ich glaube jedoch auch, dass Sie den Benutzer nicht frustrieren sollten, selbst wenn diese Frustration aus eigener Unwissenheit resultiert. Aus diesem Grund komme ich zu dem Schluss, dass die Option "Beenden" ein gutes Design ist, auch wenn es sich meistens um eine Placebo-Schaltfläche handelt, die lediglich eine Ansicht schließt.

Ted, was du erreichen willst, kann getan werden, vielleicht einfach nicht so, wie du es dir gerade vorstellst.

Ich schlage vor, Sie informieren sich über Aktivitäten und Dienstleistungen. Verwenden Sie den Begriff "App" nicht mehr und beziehen Sie sich auf die Komponenten, dh Aktivität, Service. Ich denke, Sie müssen nur mehr über die Android-Plattform erfahren. Es ist eine Änderung der Denkweise gegenüber einer Standard-PC-App. Die Tatsache, dass keiner Ihrer Beiträge das Wort "Aktivität" (kurz vor einem FAQ-Zitat, dh nicht Ihren Worten) enthält, sagt mir, dass Sie noch etwas lesen müssen.

Blog-Beitrag Wann eine Exit-Schaltfläche in Android-Apps aufgenommen werden soll (Hinweis: Nie), erklärt dies weitaus besser als ich. Ich wünschte, jeder Android-Entwickler hätte es bereits gelesen.

Auszüge:

Nach meiner Erfahrung wollen [die Benutzer] wirklich: Eine eindeutige Möglichkeit, um sicherzustellen, dass eine App keine Ressourcen mehr verbraucht (Batterie, CPU-Zyklen, Datenübertragung usw.).

Viele Benutzer erkennen, dass eine Exit-Schaltfläche diese Anforderung implementiert, und fordern das Hinzufügen dieser Schaltfläche an. Entwickler, die ihren Benutzern gefallen möchten, fügen verbindlich einen hinzu. Kurz darauf scheitern beide.

• In den meisten Fällen ruft die Exit-Taste einfach auf Activity.finish(). Dies entspricht genau dem Drücken der Zurück-Taste. Genau. Die Dienste werden weiterhin ausgeführt und es werden weiterhin Abfragen durchgeführt. Benutzer denken möglicherweise, dass sie die App getötet haben, aber sie haben es nicht getan, und bald werden sie noch mehr verärgert sein.
• Das Exit-Verhalten ist jetzt nicht mehr eindeutig. Sollte Ihre Exit-Schaltfläche nur die Aktivität schließen oder alle zugehörigen Dienste, Empfänger und Alarme stoppen? Was soll Backich tun? Was passiert, wenn sie Homestattdessen treffen ? Was passiert, wenn Ihre App ein Widget hat? Sollte die Exit-Taste verhindern, dass auch diese aktualisiert wird?

Die Lösung besteht darin, die Schaltfläche "Zurück" so zu verhalten, wie Sie es von der Schaltfläche "Beenden" erwarten würden. Besser noch, hören Sie einfach auf, Ressourcen zu verbrauchen, wenn die App nicht sichtbar ist.

Lesen Sie den vollständigen Artikel.

Antwort: (Romain Guy): Der Benutzer tut dies nicht, das System behandelt dies automatisch. Dafür ist der Aktivitätslebenszyklus (insbesondere onPause / onStop / onDestroy) gedacht. Egal was Sie tun, setzen Sie keine "Beenden" - oder "Beenden" -Anwendungsschaltfläche. Es ist mit dem Anwendungsmodell von Android nutzlos. Dies steht auch im Widerspruch zur Funktionsweise von Kernanwendungen.

1: Das vollständige Beenden einer Anwendung kann im Allgemeinen nicht zwingend sein, ist jedoch nicht nutzlos. Was wäre, wenn Windows keine Exit-Option hätte? Das System wäre sehr langsam, da der Speicher voll war und das Betriebssystem raten musste, mit welchen Programmen Sie fertig waren. Es ist mir egal, was Romain Guy oder sogar Larry Page und Sergey Brin sagen - das sind unbestreitbare Fakten: Systeme laufen langsamer, wenn sie Aufgaben beenden müssen, um ihren Speicher zu erhalten, bevor eine neue App gestartet werden kann. Du kannst mir einfach nicht sagen, dass es keine Zeit braucht, eine App zu töten! Sogar das Licht entfernter Sterne braucht Zeit ... Es ist sinnvoll, dem Benutzer das vollständige Schließen von Apps zu ermöglichen.

2: Im Gegensatz zur Funktionsweise von Kernanwendungen? Was soll das heißen? Wenn ich mit dem Ausführen einer App fertig bin, macht sie keine Arbeit mehr ... Sie wartet nur darauf, vom Betriebssystem getötet zu werden, wenn ihr Speicher benötigt wird.

Zusammenfassend gibt es einen deutlichen Unterschied zwischen Minimieren und Verlassen, und keine Prise trifft gut für die andere. Lassen wir in jeder Schraube einen Schraubendreher? Oder ein Schlüssel in jeder Tür? Lassen wir alle unsere Geräte hoch, bis der Unterbrecher durchbrennt und wir ein anderes Gerät einschalten müssen? Lassen wir die Spülmaschine voll mit Geschirr und nehmen jedes Mal nur genug heraus, um Platz für neue schmutzige zu schaffen? Lassen wir alle Autos in der Einfahrt laufen, bis - oh, egal.

Wenn der Benutzer eine App minimieren möchte, ist es am besten, sie zu minimieren. Wenn ein Benutzer eine App beenden möchte, ist es auf jeden Fall am besten, sie zu beenden.

Ist es verpönt? Das ist die Ansicht von Android - sie runzeln die Stirn. Und viele, viele unabhängige Rookie-Android-Entwickler sehen das nicht gern.

Aber wenn es darauf ankommt, gibt es gute und schlechte Codierung. Es gibt gute Programmflussmodelle und schlechte Programmflussmodelle.

Programme im Speicher zu belassen, wenn der Benutzer weiß, dass sie damit fertig sind, ist einfach kein guter Programmfluss. Es hat absolut keinen Zweck und verlangsamt die Arbeit beim Starten neuer Apps oder beim Ausführen von Apps, die mehr Speicher zuweisen.

Es ist wie bei Ihrem Auto: Es gibt Zeiten, in denen Sie es laufen lassen, z. B. an einer Ampel anhalten oder vielleicht durch die Fast-Food-Straße fahren oder am Geldautomaten anhalten. Es gibt aber auch andere Situationen, in denen Sie das Gerät ausschalten möchten - beispielsweise, wenn Sie zur Arbeit, zum Lebensmittelgeschäft oder sogar zu Hause gehen.

Ebenso, wenn Sie ein Spiel spielen und das Telefon klingelt, ja. Unterbrechen Sie das Spiel und lassen Sie es laufen. Aber wenn der Benutzer eine Weile mit dem Spiel fertig ist, lassen Sie ihn auf jeden Fall beenden.

Die Schaltfläche zum Beenden sollte bei einigen Anwendungen weiter vorne liegen als bei anderen. Spiele zum Beispiel oder Programme, bei denen der Benutzer wahrscheinlich vollständig beenden möchte, sollten offensichtlich beendet werden. Andere Programme, wie z. B. E-Mail-Programme, bei denen das Beenden unwahrscheinlich ist (damit weiterhin nach E-Mails gesucht werden kann) - diese Programme sollten keinen Platz auf dem Eingabebildschirm der Hauptsteuerung mit einer Exit-Option verschwenden, sondern für einen guten Programmfluss sollte eine Exit-Option haben. Was ist, wenn jemand entscheidet, dass sein E-Mail-Programm nicht versucht, E-Mails zu lesen, wenn er sich in einem Gebiet mit schlechter Abdeckung befindet, oder vielleicht bei einem Skype-Anruf oder was auch immer? Lassen Sie sie das E-Mail-Programm beenden, wenn sie wollen!

Anhalten und Verlassen sind zwei wichtige Aufgaben und beide erfüllen nicht die Rolle des anderen.

Ich denke, der Punkt ist, dass es nicht notwendig ist, die App zu beenden, es sei denn, Sie haben fehlerhafte Software. Android beendet die App, wenn der Benutzer sie nicht verwendet und das Gerät mehr Speicher benötigt. Wenn Sie eine App haben, die einen Dienst im Hintergrund ausführen muss, möchten Sie wahrscheinlich eine Möglichkeit, den Dienst zu deaktivieren.

Beispielsweise spielt Google Listen weiterhin Podcasts ab, wenn die App nicht sichtbar ist. Es gibt jedoch immer die Pause-Taste, um den Podcast auszuschalten, wenn der Benutzer damit fertig ist. Wenn ich mich richtig erinnere, fügt Listen sogar eine Verknüpfung in die Benachrichtigungsleiste ein, damit Sie immer schnell zur Pause-Schaltfläche gelangen. Ein anderes Beispiel ist eine App wie beispielsweise eine Twitter-App, die ständig einen Dienst im Internet abfragt. Diese Arten von Apps sollten es dem Benutzer wirklich ermöglichen, zu entscheiden, wie oft der Server abgefragt werden soll oder ob sogar in einem Hintergrundthread abgefragt werden soll.

Wenn Sie Code benötigen, der beim Beenden ausgeführt wird, können Sie onPause (), onStop () oder onDestroy () entsprechend überschreiben. http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

Wenn Sie nicht verstehen können, wie Sie Ihre Daten / Verbindungen (und damit Ihre "Anwendung") dauerhaft machen können, können Sie mit Android nicht das tun, was Sie "brauchen".

Diejenigen, die diese niedlichen kleinen App Killers herunterladen, stellen normalerweise fest, dass sie die Akkulaufzeit oder die Speichernutzung nicht verbessern, aber das Betriebssystem daran hindern, den Speicher effizient zu verwalten ...

http://android-developers.blogspot.com/2010/04/multitasking-android-way.html

Ich würde in Betracht ziehen, "Android Wireless Application Development" von Addison-Wesley zu lesen . Ich beende es gerade und es ist SEHR gründlich.

Es scheint, dass Sie einige grundlegende Missverständnisse der Android-Plattform haben. Auch ich war anfangs ein wenig frustriert über den Anwendungslebenszyklus von Android-Apps, aber nachdem ich zu einem besseren Verständnis gekommen bin, habe ich diesen Ansatz wirklich genossen. Dieses Buch beantwortet alle Ihre Fragen und vieles mehr. Es ist wirklich die beste Ressource, die ich für neue Android-Entwickler gefunden habe.

Ich denke auch, dass Sie einen Line-for-Line-Port der vorhandenen App loslassen müssen. Um Ihre Anwendung auf die Android-Plattform zu portieren, wird sich ein Teil des Anwendungsdesigns ändern. Der verwendete Anwendungslebenszyklus ist erforderlich, da mobile Geräte im Vergleich zu Desktop-Systemen nur über sehr begrenzte Ressourcen verfügen und Android-Geräte mehrere Anwendungen ordnungsgemäß und ressourcenbewusst ausführen können. Wenn Sie sich eingehender mit der Plattform befassen, werden Sie feststellen, dass das, was Sie tun möchten, durchaus machbar ist. Viel Glück.

Übrigens bin ich in keiner Weise mit Addison-Wesley oder einer Person oder Organisation verbunden, die mit diesem Buch verbunden ist. Nachdem ich meinen Beitrag noch einmal gelesen habe, habe ich das Gefühl, dass ich ein bisschen fanboyisch geworden bin. Ich habe es einfach sehr genossen und fand es sehr hilfreich. :) :)

In fast 99% der Fälle ist es nicht erforderlich, dass eine Android-Anwendung ihren eigenen Lebenszyklus übernimmt. Meistens kommt es auf eine bessere Planung oder ein intelligenteres Design der Anwendung an. Erstellen Sie beispielsweise lieber einen internen Dienst (nicht exportiert), um Downloads usw. zu verarbeiten, oder entwerfen Sie Aktionen und Aufgaben rund um den Benutzerworkflow.

Aber wo es einen Willen gibt, gibt es einen Weg. Android bietet über die android.os.Process-Klasse eine viel bessere API als Java, um den zugrunde liegenden Prozess zu steuern. Und im Gegensatz zu Java behandelt es den Entwickler nicht wie einen Idioten, indem es alles hinter einem einfachen Aufruf von java.lang.System.exit () versteckt.

Wie fordern Sie Ihre Anwendung auf, in Android Selbstmord zu begehen? Nun, der Trick ist einfach:

Erstellen Sie Ihre eigene Android-Anwendungsklasse, indem Sie von der Standardklasse android.app.Application erben (denken Sie daran, sie in der Datei AndroidManifest.xml zu deklarieren).

Überschreiben Sie die onCreate () -Methode und speichern Sie die Prozess-ID, mit der Ihre Anwendung gestartet wurde:

this.pid = android.os.Process.myPid(); // Save for later use.

Geben Sie nun eine kill () -Methode an, um Ihre Anwendung zu beenden:

android.os.Process.sendSignal(pid, android.os.Process.SIGNAL_KILL);

Wenn Sie Ihre App zum Selbstmord benötigen, geben Sie einfach cast den Anwendungskontext ein und rufen Sie Ihre Kill-Methode auf!

((MySuicidalApp) context.getApplicationContext()).kill()

Denken Sie daran, dass Android aufgrund der Prozessverwaltungsrichtlinien in Android, die sich speziell auf Dienste beziehen, möglicherweise nur den Dienst neu startet (siehe Sie sollten unter Android keine Task-Killer verwenden ).

Wenn ich eine Anwendung in Android konzipiere, sehe ich das so:

• Sie arbeiten mit Ihrer Anwendung
• Das Telefon klingelte
• Sie nehmen den Anruf entgegen
• Am Ende des Anrufs kehren Sie an der Stelle zu Ihrer Bewerbung zurück, an der Sie sich befanden

Dazu benötigen Sie nur die BackTaste oder die HomeTaste Ihres Telefons (entweder durch kurzes oder langes Drücken) und die Benachrichtigungsleiste.

Wenn ich meine Anwendung beende, benutze ich die BackSchaltfläche nur, bis ich nicht mehr in der Anwendung bin Home.

So sind die meisten Anwendungen konzipiert, denke ich. Wenn ich jedoch eine Sitzung oder Verbindung benötige, habe ich dies dem Benutzer mit einer Anmelde- / Abmeldeschaltfläche und einer Benachrichtigung (Titelleiste oder etwas anderem) klar gemacht. Dies ist ein etwas anderer Stil als die reine "Exit" -Stilanwendung.

Auf PCs haben Sie einen Multi-GUI-Desktop und auf Android haben Sie offensichtlich mehrere Aufgaben, aber Sie zeigen jeweils nur eine App an (Widgets werden hier nicht berücksichtigt ^^). Und auf einem Mobiltelefon können Sie jederzeit eine Benachrichtigung für etwas Wichtigeres als das, was Sie tun, erhalten.

Das gesamte Konzept einer Anwendung basiert also auf etwas anderem, das "Anwendung eingeben - Arbeit - Anwendung beenden".

Hmmmm ...

Ich denke, dass Sie die Android-App einfach nicht richtig sehen. Sie können so etwas wie das, was Sie wollen, ganz einfach tun:

• Speichern / Wiederherstellen des Status der App-Aktivitäten, wie in der Entwickler-Livecycle-Dokumentation empfohlen.

• Wenn in der Wiederherstellungsphase eine Anmeldung erforderlich ist (keine Anmelde- / Sitzungsinformationen verfügbar), führen Sie diese aus.

• Fügen Sie schließlich eine Schaltfläche / ein Menü / eine Zeitüberschreitung hinzu. In diesem Fall führen Sie eine aus, finish()ohne das Login und andere Sitzungsinformationen zu speichern, was implizit das Ende der App-Sitzung bedeutet. Wenn die App also erneut gestartet / nach vorne gebracht wird, wird eine neue Sitzung gestartet.

Auf diese Weise ist es Ihnen egal, ob die App wirklich aus dem Speicher entfernt wird oder nicht.

Wenn Sie es wirklich aus dem Speicher entfernen möchten (dies wird nicht empfohlen, und zu welchem ​​Zweck?), Können Sie es am Ende von onDestroy()mit java.lang.System.exit(0)(oder vielleicht restartPackage(..)?) Bedingt beenden . Natürlich nur in dem Fall, in dem Sie "die App wirklich beenden" möchten, da dies onDestroy()Teil des normalen Lebenszyklus von Aktivitäten ist und überhaupt kein App-Ende.

Da eine Anwendung in einem Android-Kontext nur eine Reihe von vage verwandten Aktivitäten ist, ist das Beenden einer Anwendung nicht wirklich sinnvoll. Sie können eine Aktivität beenden (), und die Ansicht der vorherigen Aktivität im Aktivitätsstapel wird gezeichnet.

Ich stimme Ted zu. Ich verstehe, dass das Beenden der Anwendung nicht der "Android-Weg" ist, aber es scheint nicht so, als ob dies ausgeschlossen werden sollte. Hier sind drei Gründe, warum Sie die Anwendung möglicherweise wirklich beenden möchten (nicht nur die Aktivität):

1. Der Benutzer möchte möglicherweise eine gewisse Kontrolle darüber, welche App bei geringem Arbeitsspeicher beendet wird. Wenn wichtige App A im Hintergrund ausgeführt wird, möchten Sie möglicherweise App B beenden, wenn Sie damit fertig sind, damit App A nicht vom Betriebssystem beendet wird.

2. Wenn in Ihrer Anwendung vertrauliche Daten im Speicher zwischengespeichert sind, möchten Sie die App möglicherweise beenden, damit eine Virus- / Wurm- / Schurken-App nicht darauf zugreifen kann. Ich weiß, dass das Sicherheitsmodell das verhindern soll, aber nur für den Fall ...

3. Wenn Ihre Anwendung Ressourcen (wie Netzwerk, CPU, Sensoren usw.) verwendet, die sich nachteilig auf das Telefon auswirken können, können Sie sicherstellen, dass diese Ressourcen freigegeben werden, indem Sie die Anwendung beenden. Ich verstehe, dass gut erzogene Apps Ressourcen freisetzen sollten, wenn sie nicht benötigt werden. Aber auch hier scheint das Beenden der Anwendung ein vernünftiger Weg zu sein, um dies sicherzustellen.

Der Linux-Kernel verfügt über eine Funktion namens Out-of-Memory-Killer (wie oben erwähnt, sind die Richtlinien auf Benutzerbereichsebene konfigurierbar, und der Kernel ist nicht optimal, aber keinesfalls unnötig).

Und es wird stark von Android verwendet:

• OOM Killer ist nicht für den Benutzerbereich

• Android Notes (OOM Killer Info - hier können Sie die OOM-Funktion unter Android konfigurieren)

• Android-Portierung auf echtes Ziel

Einige Userspace-Apps unterstützen diese Kill-Apps, zum Beispiel:

• Autokiller / Konfigurieren des internen Task-Killers von Android

Sie haben anscheinend die gewünschte Antwort im Befehl finish () gefunden. Dadurch wird Ihre App nicht aus dem Speicher entfernt, Android jedoch immer dann, wenn Ressourcen benötigt werden. Es macht also keinen Unterschied, dass Sie dies nicht explizit tun.

Ich möchte nur hinzufügen, dass Sie, um die volle Wirkung zu erzielen, die ein Anwendungsexit normalerweise haben würde, den Status der App auf den Status zurücksetzen möchten, der normalerweise zum Zeitpunkt der ersten Ausführung nach einem Start des Geräts unmittelbar zuvor vorliegt um bei all Ihren Aktivitäten finish () aufzurufen. Wenn der Benutzer Ihre App erneut auswählt, scheint sie auf diese Weise "frisch" ausgeführt worden zu sein, ohne dass ein Status von dem Punkt vor dem simulierten "Beenden" übrig geblieben ist.

Wenn es einige spezielle Aktionen gibt, die nur beim "Beenden" ausgeführt werden sollten, z. B. das Speichern der Arbeit des Benutzers oder was auch immer, können Sie diese auch vor dem Neuinitialisierungsteil der obigen Routine ausführen.

Mit diesem Ansatz können Sie Ihr Ziel erreichen, einen "exit" -Befehl zu erhalten, ohne die Philosophie von Android zu verletzen, die Verwaltung von Betriebssystemressourcen, einschließlich des Schließens von Apps, in den Händen des Betriebssystems zu lassen.

Persönlich würde ich diesen Ansatz nicht verwenden, da Android-Benutzer erwarten, dass eine App ihre Kontinuität beibehält, wenn sie sie erneut besuchen, und sie daher nicht an die Modalität des "Beenden" einer App gewöhnt sind. Ich würde stattdessen eine "Lösch" -Funktion unterstützen, die ein Benutzer aufrufen kann, um die App auf einen Standard-Ausgangszustand zurückzusetzen, ohne dass sie dabei "belassen" werden muss.

Die einzige Ausnahme wäre, wenn der Benutzer die Zurück-Taste so oft gedrückt hat, dass die App geschlossen wird. In dieser Situation gibt es keine Erwartung seitens des Benutzers, dass der Status gespeichert wurde (und wenn die App einen nicht gespeicherten Status enthält, sollten Sie als Entwickler über Code verfügen, der die Schaltfläche "Zurück" verarbeitet, mit der diese nicht gespeicherten Daten erkannt werden, und fordert den Benutzer auf, es in SharedPreferences oder in einer Datei oder auf einem anderen nichtflüchtigen Medium zu speichern.

In Bezug auf system.exit (0):

Wenn Sie sich entscheiden, system.exit (0) zu verwenden, um Ihre App mit unhöflicher Endgültigkeit zu schließen (z. B. als Ergebnis eines letzten Zurück-Knopfdrucks), würde ich Sie warnen, obwohl dies für mich "funktioniert" und in einigen Fällen Fälle waren die einzige Möglichkeit, eine App zu schließen, ohne dass eine Spur davon übrig blieb. Bei Verwendung dieses Ansatzes tritt in Jelly Bean ein kleiner Fehler auf.

Insbesondere wenn Sie die Liste der zuletzt verwendeten Apps verwenden, um Ihre App zu öffnen, und dann die Schaltfläche Zurück verwenden, um die App zu schließen (wobei dieser Abschluss über system.exit (0) implementiert wurde), wird die Liste der zuletzt verwendeten Apps sofort wieder angezeigt noch nie geschlossen worden. Wenn Sie dann auf den Eintrag Ihrer App in dieser Liste tippen, um sie ein zweites Mal in derselben, bereits geöffneten Liste der zuletzt verwendeten Apps auszuführen , erfolgt keine Antwort.

Ich vermute, dass die Ursache dafür darin liegt, dass die Liste der zuletzt verwendeten Apps einen Verweis auf Ihre App enthält, der aufgrund des Schließens der App mit system.exit (0) nicht mehr funktionsfähig ist. Ein zivilisierteres Schließen Ihrer App mit finish () hätte das Betriebssystem möglicherweise auf eine Weise informiert, die es ihm ermöglicht hätte, die Liste der zuletzt verwendeten Apps zu aktualisieren, aber system.exit (0) tut dies anscheinend nicht.

Dies ist an und für sich kein großes Problem, da nur sehr wenige Benutzer eine App über die zuletzt verwendeten Apps öffnen, sie dann beenden und sie sofort über dieselbe geöffnete Liste der zuletzt verwendeten Apps wieder öffnen. Wenn sie auf die Home-Schaltfläche tippen und dann die Liste der zuletzt verwendeten Apps erneut öffnen , ist der Eintrag Ihrer App dort und voll funktionsfähig. Aber ich denke , dass es zeigt , dass die Verwendung von System.exit (0) mit der richtigen Kommunikation zwischen Ihrer Anwendung beeinträchtigen können und die OS, und dies deutet darauf hin , dass es andere sein kann, ernster, möglicherweise subtil, Folgen dieses Ansatzes.

Ich hoffe, dass sich die Dinge im Laufe der Zeit ändern werden. Der Benutzer sollte in der Lage sein, eine App oder einen Prozess zu beenden, wenn der App-Prozess vom Betriebssystem korrekt in einer Sandbox gespeichert wird. Es gibt eine Vorstellung, dass Apps perfekt geschrieben sein sollten, oder der Benutzer verwendet nur die Apps, die allen SDK-Empfehlungen folgen. Ich denke, das ist eine große Aufgabe.

Es gibt ein (relativ) einfaches Design, mit dem Sie das Rätsel um den "Ausgang" umgehen können. Stellen Sie sicher, dass Ihre App einen "Basis" -Status (Aktivität) hat, der nur ein leerer Bildschirm ist. Beim ersten onCreate der Aktivität können Sie eine andere Aktivität starten, in der sich die Hauptfunktionalität Ihrer App befindet. Das "Beenden" kann dann erreicht werden, indem Sie diese zweite Aktivität beenden () und zur Basis eines leeren Bildschirms zurückkehren. Das Betriebssystem kann diesen leeren Bildschirm so lange im Speicher behalten, wie es möchte ...

Im Wesentlichen verwandeln Sie sich einfach in ein selbst erstelltes Nichts, da Sie das Betriebssystem nicht verlassen können.

Ohne eine Exit-Funktion für den Anwendungsentwickler, um seine eigene Anwendung zu beenden, ist das Design sehr schlecht.

Meine Anwendung muss es dem Benutzer ermöglichen, Daten zur Laufzeit dynamisch dynamisch zu ändern, und der Benutzer muss meine Anwendung neu starten, um den Änderungseffekt zu erzielen. Android hat jedoch nicht zugelassen, dass meine Anwendung selbst neu gestartet wird. Android OS hat einen sehr schlechten Lebenszyklus für Designanwendungen.

Um eine App zu einem beliebigen Zeitpunkt zu schließen, verwenden Sie das FLAG_ACTIVITY_CLEAR_TOPFlag in Absicht und dannsystem.exit();

Oder es gibt einen ähnlichen Weg, aber ohne, system.exit()wann Sie beenden möchten, rufen Sie diese Methode auf:

public void exit() {
    startActivity(new Intent(this, HomeActivity.class).
    setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | IntentCompat.FLAG_ACTIVITY_CLEAR_TASK).putExtra(EXIT_FLAG, true));
}

Fügen HomeActivity.onCreate()Sie in Ihrem Code den folgenden Code hinzu

protected void onCreate(Bundle savedInstanceState) {
    if (getIntent().getBooleanExtra(EXIT_FLAG, false)) {
        if ((getIntent().getFlags() & Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY) == 0) {
            finish();
        }
    }
......................

Dies funktioniert, ohne den Android-Lebenszyklus zu unterbrechen.

Verwenden Sie niemals niemals System.exit (0). Es ist, als würde man eine Person schlafen lassen und sie auf den Kopf schlagen!

Zweitens: Ich stehe vor diesem Problem. Bevor ich meine Lösung teile, möchte ich meine Gedanken teilen.

Ich finde einen "Exit Button" dumm. Wirklich wirklich sehr, sehr dumm. Und ich denke, dass Benutzer (Verbraucher), die nach einer Schaltfläche zum Beenden Ihrer Anwendung fragen, auch dumm sind. Sie verstehen nicht, wie das Betriebssystem funktioniert und wie Ressourcen verwaltet werden (und es macht einen großartigen Job).

Ich denke, wenn Sie einen guten Code schreiben, der die richtigen Dinge (Aktualisierungen, Speichern und Pushs) zum richtigen Zeitpunkt und unter den richtigen Bedingungen ausführt und die richtigen Dinge (Service und Empfänger) verwendet, funktioniert dies ziemlich gut und niemand wird sich beschweren .

Aber um das zu tun, muss man lernen, wie die Dinge auf Android funktionieren. Auf jeden Fall ist dies meine Lösung, um Benutzern einen "Exit Button" bereitzustellen.

Ich habe ein Optionsmenü erstellt, das in jeder Aktivität immer sichtbar ist (ich habe eine super Aktivität, die das macht).

Wenn der Benutzer auf diese Schaltfläche klickt, geschieht Folgendes:

Intent intent = new Intent(this, DashBoardActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

SharedPreferences settings = getSharedPreferences(getString(PREF_ID), Context.MODE_PRIVATE);
SharedPreferences.Editor editor = settings.edit();
editor.putBoolean(FORCE_EXIT_APPLICATION, true);

  // Commit the edits!
editor.commit();
startActivity(intent);
finish();

Ich speichere also in SharedPreferences, dass ich meine App beenden möchte, und starte eine Absicht. Bitte schauen Sie sich diese Flaggen an. Dadurch wird mein gesamter Backstack gelöscht, indem meine DashBoard-Aktivität aufgerufen wird, die meine "Heim" -Aktivität ist.

In meiner Dashboard-Aktivität führe ich diese Methode in onResume aus:

private void checkIfForceKill() {

    // CHECK IF I NEED TO KILL THE APP

    // Restore preferences
    SharedPreferences settings = getSharedPreferences(
            getString(MXMSettingHolder.PREF_ID), Context.MODE_PRIVATE);
    boolean forceKill = settings.getBoolean(
            MusicSinglePaneActivity.FORCE_EXIT_APPLICATION, false);

    if (forceKill) {

        //CLEAR THE FORCE_EXIT SETTINGS
        SharedPreferences.Editor editor = settings.edit();
        editor.putBoolean(FORCE_EXIT_APPLICATION, false);

        // Commit the edits!
        editor.commit();

        //HERE STOP ALL YOUR SERVICES
        finish();
    }
}

Und es wird ziemlich gut funktionieren.

Das einzige, was ich nicht verstehe, warum es passiert, ist, dass sich die Anwendung nach dem letzten Abschluss (und ich habe überprüft: es folgt dem korrekten Ablauf von onPause → onStop → onDestroy) immer noch in der letzten Aktivität befindet (aber es ist leer).

Es scheint, dass die neueste Absicht (die DashboardActivity gestartet hat) noch im System vorhanden ist.

Ich muss mehr graben, um es auch zu entfernen.

Der Lebenszyklus von Android-Anwendungen ist für Mobiltelefonbenutzer und nicht für Computerbenutzer konzipiert.

Der App-Lebenszyklus ist das brutal vereinfachte Paradigma, das erforderlich ist, um einen Linux-Server in eine Consumer-Appliance zu verwandeln.

Android ist Java über Linux, ein echtes plattformübergreifendes Server-Betriebssystem. So verbreitete es sich so schnell. Der App-Lebenszyklus kapselt die zugrunde liegende Realität des Betriebssystems.

Für mobile Benutzer werden Apps nur installiert oder nicht installiert. Es gibt kein Konzept zum Laufen oder Beenden. Tatsächlich sollen App-Prozesse ausgeführt werden, bis das Betriebssystem sie für ihre gehaltenen Ressourcen freigibt.

Da es sich um einen Stapelüberlauf handelt, ist jeder, der dies liest, ein Computerbenutzer und muss 90% seines Wissens deaktivieren, um den Lebenszyklus der mobilen App zu verstehen.

Ich habe länger gebraucht, um diese Fragen und Antworten zu lesen, als tatsächlich einen halbwegs richtigen Android-Anwendungslebenszyklus zu implementieren.

Es ist eine GPS-App, die nach Punkten fragt und den aktuellen Standort alle paar Sekunden mithilfe eines Threads an einen Webservice sendet. Dies könnte in Teds Fall alle 5 Minuten nach einem Update abfragen, dann kann onStop einfach die Update-Aktivität starten, die Ted soo war besorgt darüber, ob einer gefunden wurde (asynchroner Ted, codiere nicht wie ein Windows-Programmierer oder deine Programme werden wie Windows-Programme ausgeführt ... eww, es ist nicht so schwer).

Ich habe in onCreate einen ersten Code erstellt, um Dinge für die Lebensdauer der Aktivität einzurichten, darunter checkUpdate.start();:

...

@Override
public void onStart() {
    super.onStart();
    isRemote = true;
    checkUpdate.resume();

    locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 2000, 0, luh);
}

@Override
public void onPause() {
    isRemote = false;
    checkUpdate.suspend();
    locationManager.removeUpdates(luh);
    super.onStop();
}

Dieser Code ist möglicherweise völlig falsch, funktioniert aber. Dies ist eine meiner ersten Android-Anwendungen.

Voilà, eine Anwendung, die im Hintergrund keine CPU verbraucht, aber sofort wieder geöffnet werden kann, da sie sich im RAM befindet (obwohl sie nicht wie im Android-Lebenszyklus RAM enthält) ... eine App ist immer bereit, es ist ein Telefon Jungs / Mädels. Wenn eine App den gesamten Arbeitsspeicher verbrauchen soll und vom Betriebssystem nicht heruntergefahren werden kann, hört das Ding möglicherweise auf zu klingeln = P Deshalb muss das Betriebssystem in der Lage sein, Ihre App zu schließen, wenn sie sich im Hintergrund befindet (wenn Ihre Anwendung nicht vorhanden ist) Es ist kein Ressourcenfresser, es wird übrigens nicht geschlossen. Schreiben wir also einfach bessere Anwendungen.

Verwenden Sie jedes Mal, wenn Sie absichtlich zur nächsten Seite wechseln, Folgendes:

`YourActivityname.this.finish()`;

Beispiel:

Intent intent = new Intent(getApplicationContext(), SMS.class);

startActivity(intent);
MainActivity.this.finish();

So dass keine Aktivität auf Hintergrund ausgeführt werden , und wenn Sie möchten , verlassen Sie Ihre App, zu verwenden:

MainActivity.this.finish();
android.os.Process.killProcess(android.os.Process.myPid());
System.exit(0);
getParent().finish();

Dieses Aufregen hat für mich wie ein Zauber gewirkt :)

In jedem Fall können Sie jederzeit anrufen, wenn Sie Ihre Anwendung beenden möchten System.exit(0);.

Wenn 10,20 .. mehrere Aktivitäten ausgeführt werden und Sie alle beenden und das System verlassen möchten.

Erstellen Sie ein statisches Array in application classoderconstants class.

Konstanten

public class Constants {

public static ArrayList<Activity> activities = new ArrayList<Activity>();

}

MainActivity Fügt die aktuelle Aktivitätsreferenz in dieses Array ein

activity = MainActivity.this; Constants.activities.add(activity);

public class MainActivity extends Activity {

    private ImageView imageButton;
    private Activity activity;


    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        activity = MainActivity.this;
        Constants.activities.add(activity);

        imageButton = (ImageView) findViewById(R.id.camera);
        imageButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // existing app.
                if (Constants.activities != null) {
                    for (int i = 0; i < Constants.activities.size(); i++) {
                        Activity s = Constants.activities.get(i);
                        s.finish();
                    }
                }
                //super.finish();
                finish();
                android.os.Process.killProcess(android.os.Process.myPid());
                System.exit(1);
            }
        });
    }
}