Need to do a transition from one activity to an other. Need startActivity(intent); executed on main thread on it can be a worker thread? I would choose main thread concept, because there are GUI related operations. What do you think?
Yes, it should, but as others stated is not required to do so.
Basically, "where", in the sense of Context, your new Activity should be placed in its stack or under/above others.
From documentation:
Launch a new activity. You will not receive any information about when the activity exits.
Note that if this method is being called from outside of an Activity Context, then the Intent must include the FLAG_ACTIVITY_NEW_TASK launch flag. This is because, without being started from an existing Activity, there is no existing task in which to place the new activity and thus it needs to be placed in its own separate task.
Previous answers have revealed that the startActivity method itself ensures the relevant operations are run on the main thread, so it doesn't actually matter where you call it: Is it safe to launch and activity from a non-ui thread?
If i'm not wrong... startActivity() internally executes in the UI thread so there's no discussion :)
Related
I am new to android and I have a question, it looks silly but i need to know.
I was looking in a source code of an open project that was uploaded in git the app starts with an authentication activity
user enters his/her username password, and if it didn't exists in database, it will show a snack bar, but if it was exist in database the app will do this:
RunOnUiThread(() => { TransitToServiceListActivity();});
and in TransitToServiceListActivity() method, the code defines a new intent and starts navigate to the activity related to that intent.
So my question is, why in the first place we didn't start to navigate to other Activities.
why we need to do first:
RunOnUiThread(() => { TransitToServiceListActivity();});
and then star to navigate between activities?
Why not create an intent from that activity we are going to transit to, and call that activity
what problem this RunOnUiThread(() => { TransitToServiceListActivity();}); solves that we are using it?
The purpose of RunOnUiThread is to ensure that a given Runnable is executed in the UI thread.
So, the method RunOnUiThread is meant to be called when running in a different thread other than the main one, and it is required that some specific code gets executed in the main thread. Although is also perfectly valid to be called in an ambiguous code block, which could be called in both the UI thread or a background thread, for which scenario RunOnUiThread will resolve if the runnable must be executed immediately or passed to the main thread.
I am guessing that probably the code you are looking at, is performing the authentication in a background thread. If it doesn't and there is no chance that the authentication is never executed in a background thread, then there is no point to use RunOnUiThread.
To avoid OnDestory() and OnCreate() beeing called all the time when navigating between my main activity and some sub activities, I have set the singleTop option in my manifest. Unfortunatly this causes that the UI in my main activity is gone when returning from a sub activity. Do I really need to redraw my UI manually?
I am still wondering how to handle these basic navigation features. Is it unusual to perform application initialization tasks (e.g. start services) in OnCreate() of the main activity?
I must be missing something from your explanation I guess because the very basic point that you provided is not correct. When you launch another (sub) activity from your activity then your starting activity is not destroyed but it is stopped. So your onStart is called when you navigate back.
So maybe you can explain a little bit more the background of your requirements.
Use android:launchMode="singleTask" for your main activity so the system will not re-create it if you call it via Intent. You can also clear the stack and go back to your main activity by using
Intent intent = new Intent(SubActivity.this, MainActivity.class);
intentHome.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intentHome.addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);
startActivity(intentHome);
I'm a bit confused really. When it says that
Activities with singleInstance launchmode uses the singleton pattern, and that instance will be the root activity of a new task
When it says new task, does it mean that the launching activity will get executed in a new thread??? Or the android system just uses flags to control activities navigation internally with datastructures within the Main Thread
Activities with singleInstance launchmode uses the singleton pattern
This is misleading. Activities, whatever the launchmode, should never be considered singletons. True, there is only one instance of the Activity when using singleInstance, but the normal Activity lifecycle still occurs and it is not safe to keep a static reference to any Activity.
When it says new task, does it mean that the launching activity will get executed in a new thread???
No, all Activities live in the main thread and you should only interact with them there. The confusion comes from the usage of the word task, which does not refer to threading in this case. It refers to a group of Activities. There's a useful reference concerning this subject in the official docs.
does it mean that the launching activity will get executed in a new thread???
No it does not.
All app's activities (and services and receiver) are executed on a single thread called the main thread.
You can find a good read on the Android threading model here.
If an Asynchronous thread is a thread that operates separately to the main thread and doesn't interfere with the main thread...
Does a new Activity not occupy the main thread after it has been started through startActivity(intent)?
The majority of what I have read on this says these are both asynchronous, however there are a fair few conflicting answers and the people that say this don't really give convincing arguments.
So if anyone who has this clear in their head and could explain why they are synchronous/asynchronous, I would be a very grateful man!
Cheers
EDIT: So the answer I have derived from these two good folk and some stuff online...
Bringing Activities into the mix of synchronous/asynchronous can cause a load of horse to come about. But it is still referring to the principles of...
Synchronous methods/commands must be completed before the call stack can continue.
Asynchronous methods/commands (commonly done in a thread/AsyncTask) continue in parallel allowing the main thread of execution to continue. (It can return in its own time)
The startActivity(intent) and startActivityForResult(intent) methods are Asynchronous as they are non-blocking and allow the thread of execution to continue whilst performing their corresponding task as well.
startActivity(intent) and startActivityForResult(intent) are asynchronous in the sense that these methods return immediately without starting an Activity. Actually, they schedule an Activity to start only after the lifecycle events of the current Activity is finished.
The takeaway is, if you have something, that takes some time to finish, in the onPause() method of the first activity , the new Activity will be slow to start.
When you startActivityForResult you still perform an asynchronous call. Your caller activity gets suspended and the new is started in another process (if it runs under a different user).
But when the called activity terminates setting a result, your activity is resumed and you get onActivityResult called as a callback containing the result.
I am writing an Android app (ICS) for a tablet. The user moves from Activity A to Activity B to Activity C with the touch of a button. I want to return from Activity C to Activity A after 10 seconds. Is there some way to count to 10 without locking up Activity C?
I've succeeded with an asyncTask but if I startActivity(A) in the onPostExecute() it feels like I'm violating the guideline that an asyncTask should not mess with the UI. I've tried get() but that does lock up Activity C while it's waiting for the 10 seconds to pass.
Thanks in advance!
Assuming you have any View instance in your activity, you can use View.postDelayed() to post runnable with a given delay. In this runnable you can call Activity.finish(). You should also use View.removeCallbacks() to remove your callback in onDestroy(), to avoid your callback being called after user already navigated back from your activity.
Using AsyncTask just to count some time is just an overkill (unless you want to use AsyncTask to actually do some useful, background work). The Looper and Handler classes provide everything you need to execute any code on UI thread after a given delay. The View methods mentioned above are just convenience methods exposing the Handler functionality.
Using AsyncTask works fine as you describe. From Android Documentation:
onPostExecute(Result), invoked on the UI thread after the background computation finishes.
Since it is invoked on UI thread you should be fine.
Documentation
You can use a alarm manager for that. Set it to send a broadcast 10 seconds starting from activity a and implement a base activity for activity a b and c to receive the broadcast, after receiving the broadcast just end the current activity and start activity a with a new flag. If the current instance is activity a then ignore if not start activity a. Something like that.
As for the idle part you can update the alarm manager on every action, upon entering activity etc.
The advantage of this implementation is that you dont have to go through the hassle of having to worry about context leaks, persisting timers across activities and such. and can make use of what is already there. You can also consider using a service though.
If not you can just use the shared preference store the time to time out and check or update against it for the actions.. A simpler implementation.
Good luck.