I have a strange problem with the order of execution methods.
A progress bar.setVisibility(View.VISIBLE)appears only after the operation geocoder.getFromLocation is end.
summarizing:
first is 60 sec geocoder.getFromLocation
after the download I see progressWheel.setVisibility
my expectations:
Firstly, I want to see progress , later start time-consuming operations
void doSomethingTimeConsuming()
{
progressWheel.setVisibility(View.VISIBLE);
for(int i=0;i<100;++i)
{
List<Address> addresses = geocoder.getFromLocation(latitude, longitude, 1);
progressWheel.setProgress(i);
{
}
program must be running on the main thread without thread
Yes, of course I know that I should not do so in the main thread, I ask because I'm curious about why there was such a strange situation, I would like to understand better to avoid such of situations in the future.
program must be running on the main thread without thread
Well that's the problem. You're performing an expensive operation (getFromLocation) on the UI thread. Don't do that, basically. You're stopping the UI from being updated because the UI thread is busy calling getFromLocation.
You should use another thread for this operation - marshalling back to the UI thread where appropriate to update the UI.
Your UI thread is blocked on this line:
geocoder.getFromLocation
You should perform it on a different thread(consider execute it using handler).
Related
I read a lot about threads but don't understand yet :( let me explain to you what I have learned about threads. all we are working on such as codes any thing worked on UI thread or Main thread right? After that what happens if we call runOnUiThread? and my other question how do we know it's Time to use a new thread? I mean how do we understand we are working on another thread or replace or code in the new thread?
I know this is an unclear question but I don't understand as well. Please help me Thanks, john.
Let me try to answer. Actually Android has Main Thread (also called as UI Thread) and other thread.
Main Thread is basically for showing UI and other thread is for processing other big processes such as connecting to the server, etc.
runOnUiThread is called when you want to move from other thread to main thread. It is needed since only main thread can show/display result on UI. So when you have done some process on other thread, and you want to display the result on the apps, you need to show it on main thread by calling runOnUiThread.
We working on other thread only if it is a big or lengthy process like taking data from the server, load data, etc. And we move from other thread to main thread whenever we want to show some UI result.
Easiest way is to use AsyncTask<> class. You'll need to override three functions.
doInBackGround(...) : The codes that gets executed in background thread.
onPreExecute(..) : code that gets executed before background thread
completes executing like displaying progress bars, etc.
onPostExecute(...): Code that gets executed after background thread
has completed running. Perform task like updating UI in here
One general rule of thumb is: Don't use multithreading if you don't need to. Multithreading is always error-prone, and in many situations there's no benefit. Basically, you start a new thread whenever you execute a lengthy operation (i.e. some extensive computation like image processing) that would block the main thread for some time, so the application would become unresponsive.
I have written a foreground service which in the onCreate method does this:
public void onCreate(){
//........
startForeground(id,notification);
Task1=new Task(this);
task1.execute();
Task2=new Task(this);
Log.d("T2","Created");
task2.execute();
Log.d("T2","Executed");
}
Now what is happening is that above code is causing task1 to execute(which has a while(true) with sleep of 60 sec after each loop), but never lets task2 start its doInBackground().
I am not sure whats wrong.As per the logcat, its clearly showing that the task2.execute() does get invoked.But why is the doInBackground() of second task is not getting started?
I was initially planning to have two foreground services, but after reading a few SO posts, decided to have only one Service in foreground and let it have two different Asynctasks to do some continuous processing in background. Please help me in making this work!
The default executor for AsyncTask, starting from Honeycomb, is AsyncTask.SERIAL_EXECUTOR, which means that only one task is executing at a given time.
If you need parallelism, just use AsyncTask.THREAD_POOL_EXECUTOR, i.e.
task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
instead of just
task.execute(params);
See the Order of Execution section in the documentation for AsyncTask.
It`s simply because since from Android 3.0 AsyncTask-s work in a single background thread:
Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.
http://developer.android.com/reference/android/os/AsyncTask.html
So Task2 never run because you run it before a completion of Task1.
I recently looked through SO to find the answer to the same question here, but there was not an answer directed at the question in regards to the risk of doing so. But basically I want to run another AsyncTask inside the doInBackground() method of another AsyncTask. Is this a bad approach and/or does it leave any potential side effects?
I know that running it in the onPostExecute() works and so far from past experiences I have not had any issues due to the fact that onPostExecute() runs back on the main thread which started a AsyncTask to begin with.
From the API docs:
•The task instance must be created on the UI thread.
doInBackground() runs on the background thread. So you cannot create and run another asynctask from doInBackground().
http://developer.android.com/reference/android/os/AsyncTask. Have a look at the topic under threading rules.
When an asynchronous task is executed, the task goes through 4 steps: (Straight from the doc)
1.onPreExecute(), invoked on the UI thread before the task is executed. This step is normally used to setup the task, for instance by showing a progress bar in the user interface.
2.doInBackground(Params...), invoked on the background thread immediately after onPreExecute() finishes executing. This step is used to perform background computation that can take a long time. The parameters of the asynchronous task are passed to this step. The result of the computation must be returned by this step and will be passed back to the last step. This step can also use publishProgress(Progress...) to publish one or more units of progress. These values are published on the UI thread, in the onProgressUpdate(Progress...) step.
3.onProgressUpdate(Progress...), invoked on the UI thread after a call to publishProgress(Progress...). The timing of the execution is undefined. This method is used to display any form of progress in the user interface while the background computation is still executing. For instance, it can be used to animate a progress bar or show logs in a text field.
4.onPostExecute(Result), invoked on the UI thread after the background computation finishes. The result of the background computation is passed to this step as a parameter.
When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.
If you truly want parallel execution, you can invoke executeOnExecutor(java.util.concurrent.Executor, Object[]) with THREAD_POOL_EXECUTOR.
Also you can consider using an alternative RoboSpice.https://github.com/octo-online/robospice.
Can make multiple spice request. Notitifes on the ui thread when task is complete. Worth having a look at robospice.
AsyncTask(), with the exception of the Honeycomb releases, execute serially. So, no, you cannot execute another AsyncTask() from within doInBackground() -- I guess I should say that I've never tried it, but it's highly unlikely you're going to achieve the desired affect.
I asked about AsyncTask() execution during one of the Google Office Hours. Straight from their mouths when asked, "Why did it change from serial to parallel and back to serial execution?"; "Because it broke a lot of stuff."
I have an application which uses a separate thread to execute a calculation performed in code from a separate library. I would like the user to able to cancel this operation as, depending on the parameters, it can take a long time.
I cannot use a stopping variable or check for interrupts as the calculation from the applications point of view is a single line
public void run() {
result = library.performCalculation(params);
}
I would like to be able to use thread.stop() but as far as I'm aware this is not posible on android.
Is there anyway I can cause the thread to stop running?
You're correct, Thread.stop() is not available on Android (and even on systems where it is still supported, its problems outweight its usefulness).
What you can do is two-fold. First, call thread.interrupt() to set an interrupted flag on the thread running your library. Second, modify your library at appropriate point(s) to call isInterrupted() to determine if it is interrupted and, if so, it should voluntarily clean up and leave.
An AsyncTask can be Cancelled. Put that into an AsyncTask and call
AsyncTask.cancel(true);
I'm trying to implement a sort of interrupt process into my java program so that if an operation takes longer than 5 minutes, i can kill it.
Is there any sort of generic way I can do this? I'm using an external API to carry out very processor intensive calculations and it already multithreads the process so can I still use the executor class to do this?
-edit-
Ended up solving it by using a bash script wrapper function. It kills the PID after a timeout.
It's considered unsafe to kill or forcefully stop a Thread because it may leave the program in an undetermined state, which will later cause a crash or other more serious problem. Instead, you should design your worker thread to periodically check the interrupt flag via Thread#isInterrupted or Thread#interrupted and exit if it is set. Then, using another thread, you can signal to the worker thread that it should stop by calling interrupt() on the worker thread, which will result in the worker thread detecting the interrupt or possibly receiving an InterruptedException if it is blocking inside your code or the third party code.
Depending on how your thread is coded (ie. whether it would properly terminate when interrupted), you could use the provided Thread.join(millis) or Thread.join(mills, nanos) method calls.
Something like this:
Thread myThread
// ... start myThread
myThread.join(300000); // 5mins in millis
if (myThread.isAlive()) {
myThread.interrupt();
}
Inside the thread itself, you would want to ensure that you .yield() at relevant points and properly handle an InterruptedException to allow this kind of logic to work.
Of course this is an "ideal" kinda situation - if the thread is blocked due to some outside process, and cannot handle the .interrupt(), then it will not work very well.
HTH