Apps korrekt beenden - das warum und wie ..

  • Antworten:52
  • OffenNicht stickyNicht beantwortet
Gelöschter Account
  • Forum-Beiträge: 87

28.06.2009, 00:11:26 via Website

Die Idee von Android ist ja, dass der Lifecylce nicht vom Anwender, sondern vom Betriebssystem geregelt wird. Daher machen das die meisten apps auch nicht., da es wie schon gesagt die Experience stört wenn jede App sich selbst beenden würde.

Antworten
  • Forum-Beiträge: 1.614

28.06.2009, 17:54:08 via Website

Markus Gursch
hehe naja überleg mal

das betriebssystem kommt hauptsächlich von google ( auch wenn da andere dabei sind. google ist da sicher die stärkste macht )

die programme kommen von google

also ich würd sagen eher machen die es richtig, als irgendein lustiger kleiner programmierer vom berg

Und wenn du noch deinen Gedanken weiterführst, wirst du feststellen, dass Google genauso begonnen hat zu existieren. Es waren damals auch nur 2 kleine Entwickler vom Berg. Deine Behauptung an sich, dass ein großes Unternehmen mehr Know-How hat als ein einziger Entwickler, finde ich ein wenig oberflächlich.

Zum Glück hat jeder seine eigene Meinung ;-)

Neu bei Android, AndroidPIT oder dem App Center? Hier erfährst Du alles Wichtige: http://bit.ly/ccFQvI

Antworten
  • Forum-Beiträge: 2.644

28.06.2009, 22:17:29 via Website

nana

musst schon genau lesen.

ich hab net gesagt, dass eine große firma mehr know how hat als eine kleine

ich hab gesagt, dass google, als entwickler des betriebssystems, eher weiß, wie man dafür optimal entwickelt, als irgendwer anderes

na mal ganz ehrlich, wenn google net weiß, wie man richtig für ihr eigenes betriebssystem programmiert, dann sollten sie ganz schnell die branche wechseln

swordiApps Blog - Website

Antworten
Gelöschter Account
  • Forum-Beiträge: 5.136

28.06.2009, 23:51:19 via Website

Die tun sich aber auch leichter es "anders" zu machen Markus.

Da gibt es genügend Beispiele.

Der HomeButton ist als einziger HardwareButton offiziell nicht abzufangen,
an gewisse Phone Funktionen, wie bspw. das Auflegen kommt man nicht heran,

Wie ich in den letzten Tagen feststellen konnte, werden sehr wohl einige Applikationen von Google
korrekt beendet, ohne dabei jedoch einen offiziellen Quit Button anzubieten.

Die Applikationen wie bspw. Google Maps dümpeln nach dem drücken auf den Homebutton noch kurz als IDLE auf der Applications-Liste umeinander nachdem sie vorher ForeGround oder BackGround Status hatten.

Das passiert in dieser Geschwindigkeit nur dann wenn der GarbageCollector (der zu dieser Zeit keine Speicher freischaufeln muss weil genügend da ist) die Objekte finalisieren kann.

Das bedeutet aber, dass automatisch bei bestimmten Stati der App. an bestimmten Stellen oder Laufzeitpunkten einfach ein finish eingebaut wurde.

Ich für meinen Teil finde es allerdings eher ungut, weil damit die Kontrolle über diese Dinge dem Anwender entzogen wird. Wehtun würde es bei den meisten Apps jedenfalls nicht.

Alles nur dem GC zu überlassen der "IRGENDWANN" aufräumt .. (selbst wenn man Ihn explizit aufruft) ist keine best Practice .. gerade wenn man bedenkt das darunter unter Umständen andere Applikationen und auch die Akkulebenszeit leiden muss.

Jeder der sich mal längere Zeit mit Profiling von Applikationen in Multiuser/Multitaskingumgebungen befasst hat, wird das bestätigen können.

Das mit dem "besser oder richtig machen" sehe ich in sofern nicht unbedingt als ein valides Argument an.
Die Googelianer haben einfach andere Möglichkeiten, oder sagen wir einfachere Möglichkeiten an gewisse Dinge heranzukommen. Wenn ein Programmierer oder ein Team etwas macht, muss es nicht heißen das man es nicht anders auch machen könnte. Vielleicht sogar besser ;)

Vielleicht hab ich letzteres aber auch schon einfach zu oft erlebt ..

lg
Voss

lg Voss

Antworten
  • Forum-Beiträge: 1.614

29.06.2009, 09:59:01 via Website

Markus Gursch
nana

musst schon genau lesen.

ich hab net gesagt, dass eine große firma mehr know how hat als eine kleine

ich hab gesagt, dass google, als entwickler des betriebssystems, eher weiß, wie man dafür optimal entwickelt, als irgendwer anderes

na mal ganz ehrlich, wenn google net weiß, wie man richtig für ihr eigenes betriebssystem programmiert, dann sollten sie ganz schnell die branche wechseln

Aus dem Wortlaut heraus, hört es sich aber so an ;-)

Google wußte bis vor kurzem anscheinend auch noch nicht, dass es ein Feld für Geburtstage bei den Kontakten vorhanden sein sollte. Von daher ist deine Aussage auch nicht ganz richtig.

Es kann sich ja jeder sein eigenes Bild davon machen.

Neu bei Android, AndroidPIT oder dem App Center? Hier erfährst Du alles Wichtige: http://bit.ly/ccFQvI

Antworten
  • Forum-Beiträge: 48

02.07.2009, 21:44:48 via Website

Auch wenn der Thread schon einpaar Tage alt ist, will ich doch mal meine Gedanken zu dieser Diskussion schreiben.

Der Ansatz von Android den Activity* Lifecycle dem Betriebssystem zu überlassen ist schon etwas gewöhnungsbedürftig, sowohl für den Nutzer als auch für den Programmierer. Am Anfang war ich immer leicht irritiert, weil ich die Anwendungen schließen wollte, um Batterie und Arbeitsspeicher zu sparen. Nach einer weile Benutzung von Android und der Beschäftigung mit dem Livecycle finde ich es recht clever, wie Android das gelöst hat. Die Philosophie dahinter ist, dass das Laden und Beenden einer App mehr CPU (Strom + Zeit) kostet, als wenn die zuletzt benutzten Anwendungen einfach im Speicher bleiben. Wird der Speicher knapp, werden die Apps mit der niedrigsten Prio zuerst beendet. Welche Prio einer App zugeordnet ist, ist abhängig von deren Lifecycle Status. Das Besondere daran ist, dass nur die sichtbare Activity und deren Threads wirklich aktiv sind, alle nicht sichtbaren sind mindestens im Status onPause und verbrauchen keine CPU, das gilt auch für alle Backround-Threads dieser Activities, diese laufen nicht einfach weiter. Einzig Services bleiben aktiv (CPU), auch wenn die dazugehörige Activity nicht sichtbar ist.

Das Ganze soll jetzt für die Programmierer kein Freibrief sein, um verschwenderisch mit dem Speicher umzugehen, da gebe ich Jörg schon recht. Allerdings bin ich der Meinung, dass das aktive Beenden einer Anwendung durch den Nutzer oder Programmierer im Android-Framework eher das Gegenteil bewirkt. Ich gebe Speicher frei den ich nicht sofort wieder brauche, dafür aktiviere ich den Grabe Collector, welcher CPU verbraucht. Ich irritiere evtl. den Nutzer, der erwartet mit dem Backbutton zurück zu der eben benutzten Anwendung zu gelangen und diese jetzt evtl wieder neu startet und wieder CPU verbraucht.

Hier mein Verständnis zu den vorgeschlagenen Methoden:

Activity.finished();
Die Docu schreibt dazu:
„Call this when your activity is done and should be closed. The ActivityResult is propagated back to whoever launched you via onActivityResult(). “

Dieser Aufruf ist sinnvoll, wenn meine Activity eine Subactivity ist und ich die von mir verlangten Daten an die aufrufende Activity übergeben habe. Meine Activity wird nun nicht mehr gebraucht und ist auch nicht per Backbutton erreichbar. Meine Activity bekommt die niedrigste Prio und wird beim nächsten Bedarf aus dem Speicher entfernt.

finished()
Hat keine Auswirkungen auf eine Main-Activity also auf die erste steuernde Activity meines Programmes.

System.exit(0)
Würde ich nicht verwenden, denn damit umgehe ich das Android-Framework und halte mich nicht an den Lifecycle und riskiere Inkonsistenz im Lifecycle (kein Aufruf von onStop bzw. onDestroy)

Um dennoch schonend mit dem Speicher / Performance umzugehen, gibt es gute Tipps auf der Android Developer Seite:

http://developer.android.com/guide/practices/design/performance.html

Diese beinhaltet folgendes:
# Avoid Creating Objects
# Use Native Methods
# Prefer Virtual Over Interface
# Prefer Static Over Virtual
# Avoid Internal Getters/Setters
# Cache Field Lookups
# Declare Constants Final
# Use Enhanced For Loop Syntax With Caution
# Avoid Enums
# Use Package Scope with Inner Classes
# Avoid Float

* Ein Android Programm besteht aus einer oder mehreren Activities.

Antworten
Gelöschter Account
  • Forum-Beiträge: 281

21.05.2011, 19:53:45 via Website

Also zu System.exit(0) sag ich jetzt mal gar nichts, das ist einfach d...

Ansonsten würde ich mich um das "Beenden" meiner Apps nicht aktiv kümmern, dazu gibt es die entsprechenden Life-Cycle-Callbacks (onPause, onDestroy, usw...). Und dort gilt einfach nur - behave nicely, also Status ordentlich sichern, alles, was man irgendwo an Listenern registriert hat, deregistrieren, Services un-binden und stoppen und so weiter. Und in den entsprechenden gegenteiligen Callbacks (onResume) einfach umgekehrt.

Kurzum - sorgt doch einfach dafür, dass das Betriebssystem die App beenden oder pausieren kann, wann und wie es das für richtig hält.

Antworten
  • Forum-Beiträge: 20

11.09.2012, 09:04:59 via Website

Hallo,

sauber beenden mit Beenden-Button und Menüpunkt "beenden" ist schön und gut.

Wenn der User aber nicht wie vorgesehen beendet,
sondern einfach auf die Hardware-Taste mit dem Häusle tippt,
dann läuft die Anwendung im Hintergrund weiter.

Ist es möglich den Code so zu gestalten, dass die gesamte App beim Häusle-Button beendet wird?

PS: Bis jetzt habe ich in den Stopp-Button (Menüpunkt) und in onDestroy() (Listener-Beerdigung)
jeweils finish(); und System.exit(0); reingepackt.

mit vorauseilenden Dank
der Frank

Antworten
  • Forum-Beiträge: 284

11.09.2012, 09:56:13 via Website

So viel ich weiß, kann man den Home Button nicht überschreiben.

Es stellt sich auch nach wie vor die Frage, warum die App unbedingt geschlossen werden muss und man gegen das Android Framework arbeiten muss.

Antworten
  • Forum-Beiträge: 2.241

11.09.2012, 10:42:03 via Website

Frank Mehlhop
PS: Bis jetzt habe ich in den Stopp-Button (Menüpunkt) und in onDestroy() (Listener-Beerdigung)
jeweils finish(); und System.exit(0); reingepackt.
Lies dir mal die Doku zum Thema Activity Lifecycle durch.
Beim Minimieren der App wird die onPause() Methode aufgerufen.
Bevor die App aus dem Speicher fliegt, wird noch onSaveInstanceState() aufgerufen.
Das ist das einzige was das Framework garantiert.
onStop(), onDestroy() usw. kann aufgerufen werden, muss aber nicht, wenn z.B. dringend Speicher freigeräumt werden muss.

— geändert am 11.09.2012, 10:42:26

Antworten
  • Forum-Beiträge: 20

11.09.2012, 12:14:26 via Website

Rafael K.
Beim Minimieren der App wird die onPause() Methode aufgerufen.
Gibt es die Möglichkeit dem Betriebssystem mitzuteilen, dass mein einem onPause() meiner App finish() ausgeführt werden soll?

Antworten
  • Forum-Beiträge: 284

11.09.2012, 12:32:01 via Website

Kannst du uns mal erklären, warum du die App unbedingt beenden möchtest? Das muss ja einen Grund haben.

Antworten
Gelöschter Account
  • Forum-Beiträge: 694

11.09.2012, 13:54:53 via Website

Ich häng mich auch mal ran:

Eigentlich sollte es für einen Entwickler selbstverständlich sein das er alles aufräumt was er zuvor erschaffen hat. Wenn ich mir aber so manchen Code in den Schulungen so anschaue dann bekomme ich das kalte Grausen. Nach dem Motto "Irgendeiner wird schon hinter mir aufräumen" verlässt man sich auf viele Automatismen - vergisst aber allzu leicht das es Dinge gibt die werden eben nicht sofort aufgeräumt (z.B. ein laufender Task mit Netzwerkverbindungen, etc.).

Eben diese Nicht-Aufräumer fallen bei Android auf die Nase da Android noch einen Schritt weiter geht - die App wird nämlich nur dann wirklich geschlossen wenn das System das für nötig erachtet - nicht der Benutzer, nicht der Entwickler. Während die Activity schon längst beendet ist läuft ein Task, gestartet in der selben Activity, lustig weiter - denn der Prozess läuft ggfs. noch

Beendet wird jede Activity mit der folgenden Befehlsfolge - damit ist gewährleistet das aufrufende Activities oder Systembestandteile sauber mit dieser Activity umgehen:

1setResult(<z.B. RESULT_OK>);
2finish();

Das ist hier alles schon aufgeführt worden. Ich möchte mit ein paar Zitaten das Verhältnis - den "Vertrag" - zwischen Entwickler und dem Android System vielleicht etwas klarer machen:

* "[...] onPause() is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed [...]". Gefunden hier.

* "You should really think about not exiting the application. This is not how Android apps usually work.". Diese Aussage stammt von Romain Guy dem Android Mitentwickler, gefunden hier.

* "We did not want to require that users close applications when "done" with them. Such a usage pattern does not work well in a mobile environment, where usage tends to involve repeated brief contact with a wide variety of applications throughout the day.". Diese Aussage stammt von Frau Hackborn der Android Framework Entwicklerin, gefunden hier.

Eine App mit einem Exit Button hat etwas zu verbergen. Entweder ist es eine App die von einer anderen Plattform, in Unkenntnis des Android Zielsystems, 1:1 übertragen wurde oder sie ist nicht sauber programmiert und lässt im exit() aufräumen, nämlich all das was der Entwickler selbst nicht aufräumen will oder all das von dem er nicht wusste wie es richtig geht.

— geändert am 11.09.2012, 14:02:52

Manumaticx

Antworten
  • Forum-Beiträge: 77

11.09.2012, 14:51:17 via Website

Wenn man ordentlich aufräumt, gibt es keinen Gund seine Activity selbst zu beenden, wenn man nicht gerade eine Anwendung hat, die irgendwann mit dem was sie tut "fertig" ist, oder man sie "gegen den Willen des Nutzers" beenden will, z.B. nach einer Fehlermeldung.

Als grobe Definition, was in einer normalen Activity "ordentlich aufräumen" bedeutet, würde ich persönlich folgendes sehen:

* Nachdem onStop() aufgerufen wurde, läuft kein Thread der Anwendung mehr und sie hat keine aktiven BroadcastReceiver.

Wenn man das befolgt, verbraucht die Activity keine CPU ( = Batterie) wenn sie nicht sichtbar ist, und stört damit auch nicht. Sollte das System zu wenig Speicher haben, wird es die Activity selbst beenden. Der Vorteil, wenn man seine Activity dabei nicht selbst beendet, ist dass ein erneutes Wechseln des Benutzers zu der Activity sehr schnell geht, da der Zustand und die Daten in der Anwendung noch komplett vorhanden sind und nicht neu geladen werden müssen.

Antworten
  • Forum-Beiträge: 20

11.09.2012, 14:51:52 via Website

Florian B.
Kannst du uns mal erklären, warum du die App unbedingt beenden möchtest?
Die App produziert Töne zu gegebenen Anlässen.
Wenn der User die App wegklappt (mit dem Häusle) und es piept weiter, dann denkt der doch, was'n das für'n Mist.

wenn onPause(); nicht void wäre, sondern vielleicht ein boolean für Pause Ja ode Nein geben würde, könnte ich ich die Tonausgabe in diese Abfrage packen. Ist aber nicht.

Darum suche ich weiter,
wie kann entweder die App mit dem Häusle ganz beendet werden
oder wie kann ich in der App abfragen ob die App auf onPause() steht?

— geändert am 11.09.2012, 15:00:06

Antworten
  • Forum-Beiträge: 77

11.09.2012, 14:54:28 via Website

Frank Mehlhop
Florian B.
Kannst du uns mal erklären, warum du die App unbedingt beenden möchtest?
Die App produziert Töne zu gegebenen Anlässen.
Wenn der User die App wegklappt (mit dem Häusle) und es piept weiter, dann denkt der doch, was'n das für'n Mist.

Das ist kein Grund die App zu beenden, sondern sie besser zu implementieren. Einfache Idee: ein Flag isRunning welches in onStart() auf true gesetzt wird, in onStop() auf false, und die Töne werden nur abgespielt wenn das Flag auf true gesetzt ist.

Als ernsthafter Vorschlag: die "gegeben Anlässe" sind vermutlich Events die per BroadcastReceiver empfangen werden? Die solltest du eh in onStop() deaktivieren.

— geändert am 11.09.2012, 14:55:48

Antworten
  • Forum-Beiträge: 20

11.09.2012, 15:03:00 via Website

André
die "gegeben Anlässe" sind vermutlich Events die per BroadcastReceiver empfangen werden? Die solltest du eh in onStop() deaktivieren.

Ne, es sind Sensordaten, die akustisch ausgewertet werden.

Antworten
  • Forum-Beiträge: 20

11.09.2012, 15:05:39 via Website

André
ein Flag isRunning welches in onStart() auf true gesetzt wird, in onStop() auf false, und die Töne werden nur abgespielt wenn das Flag auf true gesetzt ist.

Ich habe noch nie mit Flag's gearbeitet.
Ich vermute, das ginge auch mit onPause() statt mit onStop()?!?
Weil wenn onStop() greift, dann habe ich das Problem ja schon gar nicht mehr.

Antworten

Empfohlene Artikel