Exit Button

  • 18 Antworten
  • Letztes Antwortdatum
weely

weely

Neues Mitglied
4
Hallo,
ich bräuchte einmal Hilfe. Ich würde gerne in meiner App einen "Beenden Knopf" in der Action Bar programmieren. Leider kann ich keinen Code dafür finden. Könntet ihr mir da weiterhelfen?

weely
 
Einfach in der Activity finish(); aufrufen. Oder System.exit(0), wenn es die Brechstange sein soll. Ich würde dir aber zu ersterem raten.
 
finish();

Das sollte ausreichen die App zu beenden.
Oder brauchst du den Code für die ActionBar?

Und warum willst du überhaupt deine App beenden?
Das ist in den meisten Fällen überflüssig.
 
Ich mache es mit System.exit(1);
 
Entweder ein Scherz oder du erkärst mir einen guten Grund dafür.
System.exit(0) is ja eigentlich meistens schon schlimm genug.
aber mit 1 ?
 
amfa schrieb:
Entweder ein Scherz ... schlimm genug
Zum Vergrößern anklicken....
Sollte kein Scherz sein, den Vorschlag habe ich aus einem Internet-Beispiel.
Jetzt bin ich da kein Profi, bislang hatte ich aber nie Probleme.
Warum "schlimm genug".
Aber wenn finish() besser sein soll, werde ich das übernehmen.
Ein danke gibt es aber erst, wenn Du mich aufklärst :)
 
Was macht System.exit() den ?
 
amfa schrieb:
Entweder ein Scherz oder du erkärst mir einen guten Grund dafür.
System.exit(0) is ja eigentlich meistens schon schlimm genug.
aber mit 1 ?
Zum Vergrößern anklicken....

Solange die Zahl 0 ist, ist der Exit erwünscht. Ungleich null ist dann dafür, wenn irgendwas schief gelaufen ist.
Also zum erwünschten Beenden 0 nehmen.

Am allerbesten ist aber trotzdem finish()
 
Kommt darauf an:

Wenn man sich in der MainActivity befindet und die App mittels der überschriebenen onBackPressed() beenden möchte ist exit(0) schon gut. Oder eben erst finish() und dann exit(0).

Wenn man nur finish() aufruft kann es sein, dass im Hintergrund noch eine andere Activity existiert, die nicht richtig beendet wurde und dann wird eben diese aufgerufen, anstatt die App zu beenden.

Mit exit(0) ist jedenfalls sicher gestellt, dass die App auf jeden Fall beendet wird.
 
Zuletzt bearbeitet:
Das Problem mit exit ist, dass damit die komplette VM beendet wird.
Unter Android ist das zugegebener maßen nicht sooo schlimm, da jede App ihre eigene VM bekommt.
Aber sowas darf man z.B. niemals auf einem Application Server oder ähnlichem machen.

Warum System.exit(1) besonders "schlimm" ist, nunja, prinzipiell macht es das gleiche wie mit der 0.
Nur gibt das ans System zurück, dass wie schon geschrieben ein Fehler aufgetaucht ist. Ich bin mir nicht sicher ob Android das irgendwo auswertet.
Ich halte es aber für keine gute Idee das so zu machen.
Die Rückgabe werte braucht man eigentlich auch nur, wenn man sein Java Programm von einem Script aufrufen lassen möchte, dass diesen Rückgabewert dann weiterverarbeitet.

Ich bin aber grundsätzlich der Meinung, dass man Android App nicht beenden sollte.
Dafür mag es zwar bei bestimmten Apps auch gute Gründe für geben, die allermeisten Apps werden das aber nicht brauchen.
Und wenn es keinen Grund gibt die App zu beenden warum sollte man dann Android in die App-Verwaltung fuschen?

Deswegen ist es meiner Meinung nach am besten die App einfach nicht zu beenden.

finish() kann sinn machen wenn man beispielsweise eine Acitivity hat wo man Einstellungen der eigenen App speichert, die kann dann beim click auf "Speichern" oder ähnliches beendet werden.
Die App als solche braucht man aber im normalfall nicht beenden.
 
amfa schrieb:
...
Ich bin aber grundsätzlich der Meinung, dass man Android App nicht beenden sollte.
...
Zum Vergrößern anklicken....
Aber eine Begründung für diese Meinung sehe ich jetzt nicht.

Was macht eine App die nicht beendet ist?
Vermutlich Strom verbrauchen, das will ich aber nicht.

Wenn das System einen Befehl exit() zur Verfügung stellt,
warum soll es dann schlimm sein, ihn zu benutzen?
Was exit(1) konkret im Hintergrund macht, weiss ich nicht.
Aber ich kann mir durchaus vorstellen, dass das System sagt
"Vorsicht, da ist ein Fehler aufgetreten, ich bereinige den Bereich,
den die App benutzt sehr sorgfältig, vor allem schliesse ich *alle*
activities dieser App".
Das kann mir doch nur recht sein.

Mit Gruß
E.S.
 
note3 schrieb:
Was exit(1) konkret im Hintergrund macht, weiss ich nicht.
Zum Vergrößern anklicken....

Und du weist auch nicht was Android in der nächsten Version damit macht ;-)
Evtl. bekommt der Nutzer den die "Achtung, schwerer unerwarteter Fehler in..."

Wenn es Vereinbarungen gibt sollte man sich dann halten. Und exit > 0 meint Fehler, es sei denn einige Rückgabecodes sind extra definiert.

Und Theorien wie "dann räumt er evtl. gleich richtig auf und ich brauch mich nicht dumm zu kümmern von nen Dev"... sowas macht mir Angst ;-)

cu
 
Naja die Begründung ist: Android ist so designed worden, dass man die App nicht schließen muss.
Damit untergräbt man ja den gesamten Activity Lifecycle.
Und die App verbraucht keinen Strom wenn sie im Hintergrund noch aktiv ist, wenn man die Lifecycle Methoden richtig implementiert.

Das ganze wurde ja extra so entwickelt damit mal eine Art Multitasking hat, der Vorteil davon ist, dass das Telefon schneller reagiert, da die besagten Acitivites weiter im Speicher gehalten werden.
Das ist kein Nachteil solange keine andere App den Speicher benötigt, denn leerer Speicher ist verschwendeter Speicher ;)
Und sobald eine App mehr Speicher braucht als nötig killt Android sie automatisch.
Wenn man die App komplett beendet, dauert es etwas länger bis sie wieder geöffnet wird.
Siehe hier:
Activity | Android Developers
Je nachdem wie viel die App in ihrer OnCreate Methode macht und wie groß und kompliziert das Layout der App ist (das ja normalerweise in der OnCreate Methode gesetzt wird) kann das schon mal etwas dauern.
Das mag zwar absolut gesehen nur eine sehr geringe Zeit sein, wenn ich aber 5 verschiedene Apps nutze die sich alle beenden und komplett neustarten und dabei jedesmal kurz hängen ist das ganz schlecht für die User Experience, da sich das Telefon ingesamt ein träge anfühlt.

Wenn ich meine eigene App komplett beende (Einstellungen - Apps - Beenden erzwingen) und sie dann aufrufe sehe ich für einen kurzen Moment nur einen komplett weißen Bildschirm und dann erst die Icons die geladen wurden.

Öffne ich sie danach ein weiteres mal sind die Icons sofort da.

Wie gesagt das sind nur Zehntelsekunden, führen aber ingesamt zu einem sich schneller anfühlendem Handy.
Und glaubt mir wenn ich sage, dass das UI und die gefühlte Responsezeit mit das wichtigste sind bei jeder Anwendung. Denn das ist das, was der Benutzer immer als erstes sieht.
Um noch ein Beispiel dafür zu bennen:
Habe ich einen "Daten Laden" Button und dauert das laden der Daten auch nur 1 Sekunde, sollte man trotzdem eine Animation für das Laden einsetzen, die sofort nach dem Klick auf den Button angezeigt wird, das fühlt sich eindeutig besser an, als wenn die App 1 Sekunde nichts macht.

Das ganze wird je extremer, desto mehr in der OnCreate Methode erledigt wird.
Baue ich z.B. ein Image ein, dass nicht lokal gespeichert ist sondern irgendwo online dürfte man das richtig merken je nach Verbindungsgeschwindkeit.
Beende ich die App nicht sondern lasse Android die Verwaltung übernehmen habe ich gute Chancen, dass wenn der User die App wieder öffnet, das Bild sofort da ist weil es nicht neu geladen werden muss.
Und deswegen sollte es mir eigentlich recht sein, dass meine Activities halt NICHT beendet werden, sondern so lange wie möglich im Speicher bleiben.
(Natürlich unter der Prämisse, dass ich die Lifecycle methoden richtig implementiert habe und die Activity nach der onPause Methode auch nichts mehr tut, siehe Api Doku)

Und was den System.exit befehl angeht, der hat schon seine Berechtigung und bei einer Android App macht er normalerweise auch nichts schlimmes (Da jede App ihre eigene VM hat).
Nur es gibt Leute die sowas dann, wenn sie mal dran arbeiten auch in ihre WebbApp auf einem Application Server einbauen, und dann wird der gesamte AppServer runtergefahren.
Eine weitere (theoretische) Gefahr ist, wenn man die Methode aufruft, werden sogenannte Shutdown Hooks aufgerufen (Methode bzw Threads die noch aufräumen sollen, muss man selber festlegen) und alle nocht nicht aufgerufenen finalize() Methoden werden aufgerufen (wenn finalize-on-exit aktiviert ist, weiß ich nicht genau für die Android-VM) Wenn man in dieser Zeit beispielsweise in einem anderen Thread ebenfalls shutdown.exit(0) aufruft, dann blockiert diese Methode "unendlich" und das Programm wird niemals beendet.
Siehe:
Runtime (Java Platform SE 7 )

Dies bringt mich zu der Meinung, dass System.exit() generell selten gebraucht wird und in Android Apps noch weniger genutzt werden sollte.


PS: Was mir noch gerade in den Sinn kommt, wenn ich einen Service in meiner App starte und dieser läuft dann in der gleichen VM (ich bin mir nicht sicher ob das so ist, denke aber schon), dann wird dieser Service auch mitbeendet. Und man fängt dann an nach dem Fehler zu suchen.

Ich hoffe das war einigermaßen verständlich und geht als Begründung durch ;)
 
  • Danke
Reaktionen: note3
Hi,
Schonmal danke für die ganzen Antworten. Ich Programmiere eine Witze App die auch nicht im Hientergrund laufen muss. Nachdem ich mich in anderen Activitys (Also den Unteractivities die mit Intents verlinkt sind) aufgehalten habe, und zur "MainActivity" zurückkehre und dann auf den Zurück knopf drücke beendet sich aber die App nicht, sondern geht zur vorherigen Activity. Ich dachte es wäre ganz schön, dann einen Exit Button zu haben. Der sollte in der Action Bar eingefügt werden. Desweiteren bin ich totaler Anfänger im Programmieren und wüsste gar nicht wo ich diesen "finish()" Befehl einbauen sollte. Ich Programmiere mit Eclipse.

weely
 
Den finish() Befehl baust du einfach an der Stelle ein, an der du die App (bzw. Activity) beenden willst. Wenn das mit dem Backpress im Hauptmenü nicht funktioniert, dann wahrscheinlich deshalb, weil du zuvor noch andere Activities aufgerufen hast, die noch nicht beendet wurden.

Je nach App bietet es sich deshalb an, mit Fragments zu arbeiten!
 
Hi,
Wie schon gesagt ich bin totaler Anfänger. Meine App hat bisher nur ein paar Activities die mit Buttons und der onClick()-Methode verlinkt sind. Ich bräuchte jetzt eine Anleitung wie ich den Button in die Action-Bar bekomme und schaffe, dass er tut was er soll: Die App beenden.

weely
 
im Detail kann ich dir gerade auch nicht helfen müsste selbst in die ActionBar Doku gucken.
Aber per Design ist die Backtaste genau dafür gedacht zur letzten Activity zurück zu kehren, beispielsweise rufe ich aus meiner App den Browser auf, drücke back und komme zu meiner Activity zurück.

Wenn der Browser das jetzt überschreibt und sich einfach nur beendet, bin ich hinterher wieder auf meinem Startbildschirm und meine eigene App taucht nicht wieder auf. Das mag bei vielen Apps kein großen Unterschied machen, da diese nicht von fremden programm aufgerufen werden.

Zum beenden hat der User die "Home" taste, drückt er darauf verschwindet deine App und erkann machen was er möchte. Theoretisch wenn deine App gut gemacht ist, kommt er wenn er deine App wieder öffnet genau zur gleiche Stelle zurück wo er vorher war (beispielsweise zum gleichen Witz).

Ich bin halt weiterhin ein großer Freund davon sich daran zu halten was Google sich ausgedacht hat.
(Zugegeben in meiner App tu ich das auch nicht überall und hab leider moment viel zu wenig zeit die App anständig umzubauen)
 
weely schrieb:
Hi,
Wie schon gesagt ich bin totaler Anfänger. Meine App hat bisher nur ein paar Activities die mit Buttons und der onClick()-Methode verlinkt sind. Ich bräuchte jetzt eine Anleitung wie ich den Button in die Action-Bar bekomme und schaffe, dass er tut was er soll: Die App beenden.

weely
Zum Vergrößern anklicken....

In Kurzform:

1. lege eine xml für dein Actionbar-Menü in Order res/menu an

Code: 
<?xml version="1.0" encoding="utf-8"?>
<menu xmlns:android="http://schemas.android.com/apk/res/android">

    <item 
        android:id="@+id/menu_exit"
        android:icon="@drawable/ic_exit"
        android:showAsAction="always"
        />
    
</menu>

2. erzeuge das Menu in der Activity mit onCreateOptionsMenu()

Code: 
    @Override
    public boolean onCreateOptionsMenu(final Menu menu) {
        getMenuInflater().inflate(R.menu.my_menu, menu);
        return super.onCreateOptionsMenu(menu);
    }

3. rufe in der Funktion onOptionsItemSelected() beim Click auf das entsprechende Icon finish() auf.

Code: 
@Override
	public boolean onOptionsItemSelected(final MenuItem item) {
		switch (item.getItemId()) {
		case R.id.menu_exit:
			finish();
		default:
			return super.onOptionsItemSelected(item);
		}
	}
 
  • Danke
Reaktionen: weely
Super! Das hat mir jetzt echt weitergeholfen! :thumbsup::thumbsup::thumbsup:

Danke euch allen.
weely
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten