Android Timer

[Xyz1]

Ich habe mal eine Frage, man sollte es so nicht machen, aber wenn man einen periodischen Timer verwenden möchte, sollte dieser nur in der onResume()-Funktion stehen? Ein Beispiel wäre super.

 

[Xyz1]

Puschel, Ich bitte nochmal darum, diese Frage zu beantworten. Ernsthaftes anliegen.

 

[mihe7]

Ich würde ja gerne, wenn ich könnte Ich verstehe aber den Zusammenhang schon nicht. Gegenfrage: was soll die Begründung dafür sein, einen Timer in onResume starten zu müssen?

 

[Xyz1]

Momentan ist es so, dass die App nach einer Aktualisierung nach 5 Sekunden beendet wird, egal was ich probier. Könnte an der falschen Verwendung des Timer liegen, dem API Level, der Lifecycle, der Activity, dem Handler oder wtf.
Deswegen also meine Nachfrage, welches der "proper" Weg wäre.

 

[mihe7]

Momentan ist es so, dass die App nach einer Aktualisierung nach 5 Sekunden beendet wird, egal was ich probier

Was sagt logcat?

 

[Xyz1]

Was sagt logcat?

Das frage ich mich auch. Momentan schmeiße ich im Falle eines Fehlers einfach ein Toast (das nicht erscheint), denn ich hab keinen Emulator und keine Bridge.

 

[Nicco27]

Ich weiß nicht ob es hilfreich für dich ist, aber dieses Beispiel könnte deine Frage beantworten.

 

[Robat]

Im allgemeinen würde ich nicht sagen, dass es *immer* im onResume() stehen sollte. Gerade wenn der Timer (du machst es sicherlich über einen Handler denke/hoffe ich?) zB die View updatet, sollte es nicht im onResume stehen, da dort nicht unbedingt gesichert ist, dass die View schon sichtbar ist für den Nutzer.

 

[Xyz1]

Ich weiß nicht ob es hilfreich für dich ist, aber dieses Beispiel könnte deine Frage beantworten.

Danke, da fehlte glatt ein Attribut.

 

[Xyz1]

@mihe7, hast du noch eine Idee, wie man "richtigerweise" periodisch erfolgende Aktualisierungen programmiert? (Best way, best practices, key traits ...)

 

[mihe7]

Da müsste ich erst die Hintergründe verstehen, warum das über einen stinknormalen Thread nicht funktionieren sollte. Klar: UI-Aktualisierungen müssen im "EDT" ablaufen

 

[Xyz1]

Danke, mihe7. Diese SO-Seite hat ein paar wichtige Hinweise: https://stackoverflow.com/q/15317600 . Es gibt mehrere weg, um die UI zu aktualisieren.

 

[mihe7]

Letztlich muss immer eine Message in die MessageQueue des Loopers, der im UI-Thread für die Weiterreichung der Messages an den Handler sorgt (gleichzeitig dient der Handler zum Hinzufügen einer Message in die Queue); soweit ich das verstanden habe.

Insofern sehe ich da keinen großen Unterschied zu Swing. Und insofern verstehe ich auch nicht, wo das beim Problem beim Thread (java.util.Timer) liegen soll - außer, dass die Thread-Erzeugung nicht ganz billig ist und man ggf. zu viele davon erstellt.

Und weil ich gerade Swing erwähnt habe: ich habe seinerzeit auch den Wirbel um den SwingWorker nicht verstanden. Was bitte ist so schwer daran, invokeLater aufzurufen?!?

 

[Xyz1]

So, ich muss das beenden. Ich hab das jetzt "klassisch" mit einem Thread + runOnUiThread() gelöst. Möglich wäre auch ein Timer + UI Thread oder ein Handler minus UI Thread explizit. Allerdings verlangt sowohl Timer + UI Thread als auch Handler minus UI Thread ein höheres API Level , als ich zurzeit eingestellt hab. Bei einem niedrigerem API Level können nicht mehr 100 % aller Geräte erreicht werden.

mihe7 , ich danke dir für deine ausführliche Beschreibung sowie Erfahrungsangabe.