"Gewalt" über Activities bekommen / Threads / Timer

[ui_3k1]

Hallo,

ich habe eine Frage, die mir schon länger durch den Kopf schwirrt. Habe schon ein paar kleinere Apps programmiert und mir ist aufgefallen, dass manche Activities irgendwie "unberechenbar" sind, scheinbar im Zusammenhang mit Threads.

Beispielsweise bei einem Splash-Screen (Begrüßung): Dort wird mittels Thread ein Timer gestartet, bis es dann in die nächste Activity geht. Und genau hier habe ich das Gefühl nicht mehr Herr über den Code zu sein. Denn wenn man während des Wartens die Home- bzw. Zurück-Taste drückt, schließt sich die Anwendung, um dann nach einer kurzen Zeit doch wieder die vorher angeforderte neue Activity anzuzeigen.
Lässt sich solch ein Timer noch anders darstellen? Bzw. gibt es eine Möglichkeit eine Activity "gewaltsam" zu beenden?

Wie entsteht dieser Fehler und wie lässt sich sowas beheben? Eine Möglichkeit wäre wahrscheinlich die Tasten in diesen Activities zu deaktivieren, aber ist das eine saubere Implementierung, oder kommt doch einer oder obigen Punkte in Frage? Bis dato habe ich zum Thema "Threads" noch nichts gefunden, was auf besagte Fragestellung eingeht. Auch die Anleitungen / Beispiele , die ich bis jetzt zum Thema "Lebenszyklus von Activities" und "Intents" durchgearbeitet habe, geben mir auf diese Fragestellung keine Antwort.

Ein Codebeispiel habe ich derzeit nicht, da die Frage eher allgemein gestellt ist.

NACHTRAG: Die Tasten zu deaktivieren wäre eher unvorteilhaft. Beispielsweise wenn ein Countdown läuft und die Eingabe einer Antwort erwartet wird (wie bei Quizduell). Bei Eingabe der Antwort muss folglich auch die eine neue Activity angesteuert werden können und der Timer der alten Activity "vergessen", gelöscht, oder ignoriert werden.

Ich hoffe ihr wisst was ich meine

 

[swordi]

bei deinem splash screen beispiel:

ich nehme einen handler. schicke eine leere nachricht delayed in der on resume

wenn der user wartet - passt

wenn nicht, lösche ich die leere message aus dem handler in der onpause methode.

somit kann er home drücken und es wird halt der timer abgebrochen.

tasten deaktivieren wäre ein blödsinn

 

[JustinTime]

Generell finde ich splashscreens schlecht. Man sollte sich eher darum kümmern dem User eine gute onboarding experience zu geben auch wenn noch nicht alle Daten geladen sind. Spiele sind da eine Ausnahme.

 

[swordi]

ja das sowieso. vor allem splash screens wo dahinter nichts geladen wird sind noch schrecklicher.

den user einfach mal so 2-3 sek warten zu lassen ist nicht nett. aber alle kunden wollen es immer so machen wie apple

 

[kleinerkathe]

Generell finde ich splashscreens schlecht. Man sollte sich eher darum kümmern dem User eine gute onboarding experience zu geben auch wenn noch nicht alle Daten geladen sind. Spiele sind da eine Ausnahme.

Absolut richtig, ...
Splash Screens are Evil, Don't Use Them! - Cyril Mottier

Ich hatte noch irgendwo eine Analyse von "erfolgreichen" Apps, die alle(!) keinen Splashscreen verwenden (bzw. nicht mehr), warum sie das tun und so weiter ... find ihn aber leider gerade nicht mehr.

 

[amfa]

"If your application has a time-consuming initial setup phase, consider showing a splash screen"
Keeping Your App Responsive | Android Developers

Empfehlung von Google
Allerdings wirklich nur wenn es unbedingt sein muss, besser ist ein Loading Indicator in der App selber.
Meine App z.B. geht sofort auf, muss allerdings noch ein paar wenige Daten aus dem Internet laden.
Aber statt einem Splashscreen dreht sich da eine progressBar, das ist mir die eindeutig bessere Variante, weil die App sich einfach schneller anfühlt, sie tut halt was und der User sieht das auch, bei einem Splashscreen kann der User nur hoffen das sich was tut