Wie verhindere ich die mehrfach Initialisierung von onCreate ?

Vacutainer schrieb:

onPause() ruft nicht onCreate() auf. Das wäre ja auch völlig sinnlos, da die Activity beim Aufruf von onPause() eben pausiert wird. Warum sollte sie dann neu initialisiert werden?

Zum Vergrößern anklicken....

Es ist einer der Möglichkeiten, die im Lifecycle vorgesehen ist. Gerade bei Device, die einen chronischen Speichermangel haben, passiert das schon mal. (Siehe auch dein Schaubild.)

Wenn man wirklich die Activity im Orginalzustand braucht, soll man sie nicht beenden. Dann reicht onResume() und onPause.
Wenn man eine Activity beendet, sollte man sich schon überlegen, ob man die Daten nicht doch komplett neu initialisiert.

Aber eigentlich braucht man nur ein Activity, für was gibt es den sonst Fragmente. Genau um solch ein Irrsinn zu vermeiden!

Und wenn du Daten schnell brauchst, gibt es auch das Application Objekt. Dieses Objekt ist ein Singleton, und dort kann man ohne Probleme Daten zwischenspeichern. Dann braucht man nicht den umständlichen Weg über ein Bundel gehen.

Ich bin der Meinung onSaveInstanceState() sollte man den System vorbehalten.

@markus.tullius
Aber onCreate() wird niemals direkt nach oder gar von onPause() aufgerufen. Wenn das System aufgrund von Speichermangel den Prozess und damit die aktuell im Hintergrund gespeicherte Activity killt, wird onCreate() auch erst aufgerufen, wenn der User wieder zu dieser Activity navigiert.
Mit welchem Fall wäre es zu erklären, dass in onPause(), also während die Activity in den Hintergrund verschwindet, wieder onCreate() aufgerufen wird, sodass die Activity direkt wieder im Vordergrund landet?

Eine Activity beenden oder nicht sollte man dem System überlassen, aber entsprechend sichergehen, dass keine Daten verloren gehen.

Vacutainer schrieb:

? Bei ersterem reicht onSaveInstanceState(). Bei letzterem sind SharedPreferences sinnvoll.

Zum Vergrößern anklicken....

Das Image wird bei mir nicht angezeigt, ich kann deine Bemerkungen daher nicht interpretieren?


Aber hier ist zu sehen das onPause() sehr wohl onCreate() anstoßen kann.

Du missverstehst die Grafik. Im Fall, der auf der linken Seite dargestellt ist, wird onCreate() nach onPause() erst aufgerufen, nachdem der User wieder zu der Activity navigiert. Zwischen den Aufrufen kann eine beliebige Zeitspanne liegen. Das onCreate() wird also nicht als direkte Folge von onPause() aufgerufen.
Das System ruft in dem Fall wieder onCreate() auf, weil die vorherige Instanz der Activity aufgrund von knappen Speicher beendet wurde.

Von onPause() geht ein Pfeil weg, und dort steht "Apps with higher priority need memory".
onStop() und onDestroy sind killable!

Und das macht schon Sinn, wenn das System dringend RAM braucht, und deshalb den UIThread aufräumen möchte.
Beispiel: Du möchtest ein Notruf absetzen, und das geht nicht, weil deine App den ganzen Speicher belegt.

onSaveInstanceState() wird zwar noch aufgerufen, aber danach ist Ende. Vor Android 3.0 wird die Methode onSaveInstanceState() nicht aufgerufen.
Activity | Android Developers

Wenn du die Docu selber weiter liest, empfehlt Google selber alle persistenten Daten mit SharedPreference oder SQLite abzuspeichern. Und der dafür vorgesehene Ort ist onPause().

---
Nachtrag:
Nicht er, sondern du missverstehst die Grafik.
[doublepost=1487500627,1487499798][/doublepost]@Vacutainer Schön Dich mal wieder hier im Entwickler-Forum zu sehen.

znieh99 schrieb:

Aber hier ist zu sehen das onPause() sehr wohl onCreate() anstoßen kann.

Zum Vergrößern anklicken....

Hierum geht es. Ich habe doch nie angezweifelt, dass das System die App nicht killt. Aber es ist nunmal falsch, dass zwangsläufig onCreate() von onPause() aufgerufen wird. Wenn der User nachdem die App vom System gekillt wurde die entsprechende Activity nicht wieder aufruft wird onCreate() auch nicht wieder aufgerufen. Nicht mehr und nicht weniger versuche ich hier klar zu machen.

Das persistente Daten mit SharedPreferences oder in einer Datenbank gespeichert werden sollten habe ich exakt so einige Beiträge weiter vorne geschrieben. Da aber im Startpost nicht erläutert wurde was für Daten gespeichert werden sollten und sogar spezifisch nach onSaveInstanceState() gesucht wurde gehe ich natürlich davon aus, dass nicht persistente Daten zwischengespeichert werden sollen. Und dafür ist ohne Zweifel onSaveInstanceState vorgesehen.

Aber onSaveInstanceState () speichert auch persistente Daten .

Macht Dir nicht daraus. Ist alles okay. Vielleicht sollte hier jemand mal zusammen fassen, welche Möglichkeiten es gibt, persistente Daten zwischen zu speichern.

Aber noch mal was Grundsätzliches. Keiner der Wege ist "falsch". Jeder Entwickler hat seine Vorlieben, und viele Wege führen nach Rom. Ich fand die Beiträge interessant. Ist schon lange her, das ich mit mal onSaveInstanceState() beschäftigt habe.

markus.tullius schrieb:

Vielleicht sollte hier jemand mal zusammen fassen, welche Möglichkeiten es gibt, persistente Daten zwischen zu speichern.

Zum Vergrößern anklicken....

Ich mochte Dich nicht darin hindern .........

(Den haste dir selbst eingebrockt

Meinst du, dass das Bundle von onSaveInstanceState() persistent gespeichert wird? Wenn ja würde ich dem aufgrund der folgenden Links (teilweise) widersprechen: "persistent state" vs. "current state"
Weiterführend: What is holding my activity's state once my application process has been killed?
Es kann scheinbar sein, dass die Daten persistent gespeichert werden, aber du kannst sie nicht ohne weiteres abrufen, ohne restoreInstanceState. Es wäre also nicht gerade sinnvoll bspw Einstellungen so zu sichern.

Richtig, es gibt eine Vielzahl von Wegen solche Sachen anzugehen, ich persönlich versuche mich iA an die Android Guides zu halten. Da man auch am einfachsten Informationen zu diesen Methoden findet ist es für Anfänger wohl auch am sinnvollsten diese Methoden auszuschöpfen.

markus.tullius schrieb:

Ich benutze dann lieber schon mal protected void onNewIntent(Intent intent).

Zum Vergrößern anklicken....

Wie kann mir onNewIntent(Intent intent) helfen. Wird dies nur beim ersten Aufruf von onCreate() aufgerufen?
lg heinz
[doublepost=1487510337,1487508016][/doublepost]Ok, ich habe mich für "onSaveInstanceState" entschieden und das funktioniert nun auch so.

Ich möchte mich hier noch bei allen Beteiligten bedanken,
lg heinz

Ich habe mal gerade in den Quellcode von Android geschaut. Das ganze entspricht meiner Lösung, die mit der Klasse Application. Das Bundle wird einfach dort in einer ArrayList abgelegt. Das ganze benutzt das Observerpattern.

Fazit: Das Bundle wird nicht persistent gespeichert, sondern in einem Singleton vorgehalten. Ich hoffe, jetzt sind alle Unklarheiten beseitigt.

Die einfachere Lösung wäre natürlich, dass die Daten nicht in ein Bundle zu parsen, sondern die Daten als Objekt direkt im Singleton (Application) abzulegen. Ist auch schneller.

Speichern im Application Singleton sollte aber auch nur für kurzfristiges Speichern genutzt werden, ähnlich zur Bundle-Methode: Don't Store Data in the Application Object
Nur noch als kleiner Hinweis für etwaige Leser.

PS: Gewonnen
Nein Spaß, freut mich, dass es jetzt klappt! War auch eine sehr interessante Diskussion.

Vacutainer schrieb:

Meinst du, dass das Bundle von onSaveInstanceState() persistent gespeichert wird? Wenn ja würde ich dem aufgrund der folgenden Links (teilweise) widersprechen: "persistent state" vs. "current state"
Weiterführend: What is holding my activity's state once my application process has been killed?

Zum Vergrößern anklicken....

Nein widerspricht dem nicht. Das von dem Autor geschilderten Problem kann man einfach mit einer simplen if - Abfrage umgehen. Ist der Wert null, instantiiere das Objekt neu.

Hast du den falschen Beitrag zitiert? Ich denke du beziehst dich auf Don't Store Data in the Application Object oder?

Da wäre eine if-Abfrage aber auch nicht hilfreich, wenn ein von User gegebener Wert gespeichert werden soll. Wenn ich den sonst nirgendwo gespeichert habe, was das Speichern im Application Objekt auch hinfällig werden ließe, kann ich den schlecht erraten und müsste den User wieder eine Activity zurück schicken.
Habe ich so ähnlich schon erlebt und ist immer etwas irritierend.

Genau den meinte ich.
Ich mache es immer so, und hatte noch nie ein Problem mit einem NullpointerException. Das ist Basis - Wissen. Man überprüft Objekte, wenn man nicht weiß, ob sie Null sind, mit einer if-Abfrage auf Null. Das Application-Objekt existiert immer, ohne Application - Objekt keine App.

Das habe ich wo in Frage gestellt?
Wenn du aber vom User eingegebene Werte nur im Application Objekt speicherst und das System bei Speichermangel die App im Hintergrund killt ist der Wert weg. Auch wenn du es mit if abfängst. Dann muss der User es trotzdem nochmal eingeben.
Deswegen sagte ich, dass diese Art Daten zu Speichern auch nur für kurzfristiges Zwischenspeichern genutzt werden soll. Nicht mehr und nicht weniger.

Ich meine auch nicht, die Tatsache, das die Daten vorhanden sind, bis die App beendet wurde. Ich meine den Inhalt des Artikel. Die Argumentation darin ist sinnlos, weil man das thematisierte Problem mit einer einfachen if-Abfrage umgehen kann. Liegt vielleicht auch am seltsame Verständnis des Autor über den Lifecyle einer App.

Okay, der beschriebene Crash lässt sich damit verhindern, aber eben der Verlust der Daten nicht. Darauf wollte ich nur hinweisen. Aufgrund dessen wäre es wiederum von Vorteil solche vom User erfragte Werte in einem Bundle zu übergeben. Das sollte trotz eines Background kills der Application bestehen bleiben.

Nee, ex und ob. Gleiches Problem, das Bundel wird in einer ArrayList im Application-Objekt gehalten. Wenn das Application-Objekt weg ist, sind auch alle Referenzen weg. Da ist der Garbage Collector gnadenlos.

Da ist nichts mit persistent.

Nope. Der ActivityManager übernimmt das Bundle und übergibt es, sobald die Activity wieder gestartet wird: Will 'Bundle savedInstanceState' be alive after Application is being killed?