pendingTransition() funktioniert auch außerhalb ui thread

Jaiel

Jaiel

Dauergast
235
Hey ich starte aus einem anonymen thread aus eine andere activity finishe die aktuelle ebenso daraus und füge ein pendingTransition () danach ein

Ist der thread nicht außerhalb des ui threads?
Wieso funktioniert pendingTransition () dann?
 
Hi
du musst dich überlesen haben ich Poster heute mal den Code

ich meine pendingtransition die eine Animation zwischen einen activity Wechsel ausführt damit alles ganz softe ineinander übergehen kann
 
@markus.tullius:
- Er redet von pendingTransitions, nicht pendingIntents.
- Thread != Prozess
Es gibt einen UIThread, richtig, und einen Hauptprozess jeder App. Auch richtig. In diesem Prozess kann ich aber Threads starten wie ich will und die sind keine UIThreads.

startActivity (und ich nehme an auch finish) wird in jedem Fall im UIThread ausgeführt. Das overridePendingTransition sagt ja dem Framework nur, wie es die Transistion zwischen den Activities animieren soll. Da das Activity starten in jedem Fall im UIThread ausgeführt wird, wird auch die Animation im UIThread ausgeführt.
 
Ich posted mal meinen Code ist auch nur paar Zeilen lang weil ich nur ein splashscreen Anzeige und danach sofort in die main activity starte

Ich frag mich nur ob jetzt der extra thread den ich created habe um ihn für eine gewisse Zeit schlafen legen und ein Bild vorher auf den Bildschirm malen

Ob er im UI thread läuft
meiner Meinung nicht aber wieso kann ich dann da einfach finish () schreiben und halt die transition und er führt diese richtig aus obwohl es aus einem anderen thread gerufen wird ohne Referenz auf die activity

Ich dachte vllt hat es was mit meiner Implementierung zu tun ich Poste den Code so gegen 16 uhr bis dann
 
@deek

danke für die für den Hinweis. Hatte gerade meine Augen geöffnet.

Die beiden Links zu den Threads und Prozess stimmen trotzdem (Zufall ;) ).

Im Endeffekt kannst alles was mit Layout und Use-Case zwischen Activity / Fragmenten nur im UIThread ändern. Einfache Thread's sind dafür tabu. (War nicht immer so.)

Der Grund ergibt sich aus dem Lifecycle.

Der ursprüngliche Beitrag von 14:16 Uhr wurde um 15:15 Uhr ergänzt:

@deek
Noch ein Nachtrag: Eine App kann mehrere Prozesse habe. Nur ein Prozess kann ein UIThread beinhalten. Die App kann auch ohne den Prozess mit den UIThread laufen! Mann braucht nur ein Observer zum System. ;)
 
also hier mein code der auch funzt:

PHP:
public class SplashScreenActivity extends Activity {
	
	@Override
	protected void onCreate(Bundle savedInstanceState)
	{
		super.onCreate(savedInstanceState);
		
		requestWindowFeature(Window.FEATURE_NO_TITLE);
        getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
        					 WindowManager.LayoutParams.FLAG_FULLSCREEN);
        setContentView(new SplashScreenView(this));
	}
	
	@Override 
	protected void onStart()
	{
		super.onStart();
		new SplashScreenThread().start();
		
	}
	
	@Override
	public void onBackPressed()
	{}
	
	
	private class SplashScreenThread extends Thread
	{
		public void run()
		{
			try {
				  sleep(1000);
				} catch (Exception e) {}
				finish();
				startActivity(new Intent(getApplicationContext(),MainActivity.class));
				overridePendingTransition(android.R.anim.fade_in, android.R.anim.fade_out);	
		}
	}

}


versteh ich das irgendwie falsch odder läuft mein Splashscreenthread auf dem UI?

Der ursprüngliche Beitrag von 15:21 Uhr wurde um 15:34 Uhr ergänzt:

und ja es klappt wirklich die activity wird gefinished und die transition ist auch smooth ohne blackscreen...wenn ich in der main auf back drücke gelange ich auch direkt raus aus der apopp also ist die activity aus dem backstack gefinished......aber why? warum funktioniert etweas was cih geschrieben habe von dem ich mir sicher bin dass es nciht funktionieren sollte!!!(mal was anderes oder?)
 
Ist doch sonnenklar :D

Dein Splashscreenthread läuft natürlich nicht im UIThread.

Da du ihn als eine innere Klasse definierst, die eine Instanz der umschließenden Klasse benötigt (kein static an der Definition der Thread Klasse) kannst du aus dieser inneren Klasse auch Methoden auf der äußeren aufrufen. Dabei wird die Instanz an das "this" gebunden zum Zeitpunkt der Instanziierung. Also alle Methoden die auf der Activity aufgerufen werden, werden auf der Instanz ausgeführt, die das hier gesagt hat:
new SplashScreenThread().start();

Du kannst aus dem SplashScreenThread auch etwas expliziter auf diese Methoden zugreifen mit z.B. SplashScreenActivity.this.startActivity(). Damit wird es etwas klarer. Ohne diesen Prefix ist nur syntaktischer Zucker vom Compiler.

Was gibt es hier zu beachten:
normale Objekte die so instanziiert werden, leben solange wie die umgebende Instanz lebt. Das ist bei Threads etwas anders, da diese nicht Garbage collected werden. D.h. im schlimmsten Fall könnte dein SplashScreenActivity.this null sein.
Weiteres interessantes Phänomen hier:
Wenn du den back button nicht abgeklemmt hättest könnte man während der Splashscreen zu sehen ist mit back zurück gehen und da der Thread noch läuft wird trotzdem noch die eigentliche Activity gestartet. (aus User Sicht aus heiterem Himmel) Da würde ich in onPause oder so den Thread stoppen.

PS: wenn du die Thread Klasse static deklarierst, sollte er bei startactivity und finish meckern. So kannst du meine Aussage oben überprüfen.
 
OK ja klar hab ich wohl nicht beachtet dass es eine innere klasse ist.
Noch ne blöde Frage ich gehe eigentlich davon aus das der gc den thread killt weil das Objekt ja mit der activity verbunden ist oder sehe ich das falsch obwohl er ja eh sterben sollte nach dem er die mainactivity aufruft
 
Ein Thread ist im Sinne des Garbage Collectors ein root Objekt. Normalerweise werden Threads nicht Garbage collected. Wenn er fertig ist (nach dem Durchlauf der run-Methode) ist er aber definitiv tot und wird abgeräumt.
Jetzt hast du natürlich einen guten Einwand gebracht. Ich kann dir ehrlich gesagt nicht sagen ob der Thread nicht vielleicht doch beendet wird, wenn die Activity abgeräumt wird, weil es ja eine innere Klasse ist... Soo tief bin ich dann leider doch nicht in den Java/Android Interna drin.

Btw: Normalerweise implementiert man für sowas Runnable statt Thread zu extenden. Dann macht man new Thread(deinRunnable).start().
Du willst ja nicht die Thread Klasse erweitern im Sinne von mehr Funktionalität, sondern du willst einem Thread nur was zum Arbeiten geben. Genau dafür ist Runnable da.
 
  • Danke
Reaktionen: Jaiel
ja das mit thread ist gewöhnungssache bei mir in diesem fall erweitere ich wirklich ncihts sonst hab ich mehr oder wenige viele objekt mit denen ich arbeite in einem thread(timer positions objects etc pp)

dein einwand ist natürlich gerechtfertigt und landläufig wird das auch so vertreten
 
Der Thread wird nicht weggeräumt, da der Thread kein Observer auf den Lifecycle der App hat. Das Teil kann also abstürzen.
In den Sinne sind Threads Rootobjekte. Sie werden erst vom GC weggeräumt, wenn er beendet wurde. Und hier liegt die Crux. Man sollte alle Threads beenden, bevor die Activity beendet wird.

Langlaufende Threads sollte man in einen Service auslagern. Ein Service lebt wesentlich länger!

Am besten, man beendet den Thread selber, wenn die Activity nicht mehr im Vordergrund ist. Dafür gibt es Interrupts.
Interrupts (The Java™ Tutorials > Essential Classes > Concurrency)

Ob du Runnable oder Threads benutzt ist Geschmacksache. Runnable kann man mit weniger Aufwand implementieren. Ich benutze meist beides, je nach Fall.
 
ich finde erst ein objekt runnable erzeugen und dann noch ein thread objekt um damit den thread zu starten irgendwie umständlicher als einfach

new Thread(){...}.start();

zu schreiben
auch wenn man
das interface in eine schon vorhandene klasse reinimplementieren kann vertstößt dass für mich die unabhängigkeit und selbstständigkeit von objekten...

Der ursprüngliche Beitrag von 14:26 Uhr wurde um 14:28 Uhr ergänzt:

und der thread geht ja eh zu ende nachdem er die neue activity aufgerufen hat von daher ist alles ok so weit

und wenn etwas schief läuft im thread bleibt der user dann höchstens die ganze zeit in der splashscreenactivity
 

Ähnliche Themen

SaniMatthias
Antworten
19
Aufrufe
871
swa00
swa00
O
Antworten
15
Aufrufe
2.871
ORHUX
O
W
  • waltsoft
Antworten
3
Aufrufe
713
waltsoft
W
Zurück
Oben Unten