This question already has answers here:
Android - What happens to Threads when a Activity finishes?
(2 answers)
Closed 6 years ago.
If we start a handler thread / thread in an activity and then the activity is destroyed when we press back button, What happens to the handler thread?
Is it still in running state?
If Yes When the thread execution will stop?
Simply , your Thread is in running state.
It is actually bad practice to keep a thread running after onPause. The reason is that after onPause your application may drop out of memory at any time without your being able to know, therefore you will not be able to clean up after yourself.
The proper way to do it is stopping the thread onPause and recreating it onResume. If you need state you can use Android's built in saveState methods or settings or whichever to keep that.
Your related thread is here and here
The thread won't be destroyed until its job is finished. So make sure all its job is finished before closing an activity. Because the thread may contain any reference of views and it may try to access it after the job is done. HandlerThread can be stopped by calling
thread.quitSafely();
this ensures that all pending messages are processed before the thread stops.
Related
How can I run background operations correctly without creating memory leaks or blocking other threads? I first used asynctask, but it uses a thread pool which blocks after 5 tasks in background, and passing weak references don't fix the problem of memory leaks. So I need to transfer data between client and server. I think I should use a class that implements Runnable, and in the activity I start the runnable with ExecutorService (singleThreadExecutor). Then I call submit. I need to get the "Future" from the ExecutorService to be able, to cancel the Thread if the activity call onStop(). If someone has a better solution for this, please help me. The requirements are that it should block other threads, and I should be cancel able if the activity is destroyed.
AsyncTask are for my point of view the best way to deal with Threads.
I don't know what kind of operations you want to do, but check the intent service
Runnable are running on the main thread, so if your activity die, it dies too, or you can wipe the stack handler.removeCallbacksAndMessages(null);.
Play with Thread can be tricky, be aware of what you do :)
In this case, you need to set up a loop that check for interrupted exception :)
Good Luck !
This question already has answers here:
Interrupting or stopping a sleeping thread [duplicate]
(5 answers)
Closed 7 years ago.
Is there a way in stopping thread.sleep on button click?
like for example? i clicked the 1st button for sleep and then the second button is for stopping the thread while on sleep? i have tried thread.stop() and thread.interrupt and it's not working.
Thread.interrupt() will cause a sleeping thread to unblock ... assuming you interrupt the right thread.
Thread.stop() is deprecated, and SHOULD NOT BE USED.
However ...
Is there a way in stopping thread.sleep on button click?
This does not make a lot of sense to me. Unless you have done something really strange (and wrong), a thread does not "sleep on a button click". And you certainly should NEVER write an input event listener (for example an "on click" listener) that calls sleep(...). Since input event listeners get called by the event handler thread, if you sleep you are going to lock up the UI.
Call the interrupt() method on your thread. This will cause the sleep to be cancelled and an InterruptedException will be thrown.
Sorry but, I'm quite a bit confused after reading this.
If let say, I have a single Activity and inside it,
I tried to make an inner Class implementing Thread that has looper and handler.
My question is;
If I finish() my activity. Is that close any Looper / Handler i just created last time?
I'm afraid the Thread is still running background altough the Activity is already closed -> ended.
After finish, you don't have to care about Handlers attached to the Main Thread, because it's Looper (and the Thread itself) is managed by the system, and it will quit when it is necessary.
However if the Handler is attached to a separate Looper that is not managed by the system (for example a Thread with a Looper started by you), it will be there in case you have not stopped the relevant Thread (that has the Looper). This true in general for all Threads, the fact that the Thread has a Looper does not change the situation.
So the important think here is to stop every Thread that you started manually.
As an addition:
You can always check your running Threads in Eclipse. Just attach the
debugger and go to the Debug view. All Threads will be listed there.
Take a look at HandlerThread.
I wrote an app on android in which a thread is created through the main activity(UI thread), the new thread saves the activity instance and then calls a method in it while running.
I got an error "Can't create handler inside thread that has not called Looper.prepare()" and found out in this post:
Can't create handler inside thread that has not called Looper.prepare()
and in many more questions that i can't call a method of another thread directly, i should use runOnUIThread or doInBackGround and so on...
my question is WHY?
what's wrong with that design?
thanks in advance :)
You seem a bit confused - the question does not make much sense, so it's quite hard to answer.
Bits and pieces:
creating a thread in UI thread that "saves the activity instance" is wrong in itself: lifecycle of activity is complicated and you should not refer to it by instance.
you cannot "call a method of another thread" (unless you mean the java.lang.Thread object itself, and from the context it seems that you don't), because objects do not belong to any thread. All objects in Java live on heap and can be accessed by any thread.
BUT since each thread is an object, you can have a Map that holds objects indexed by thread instances. This is basically what ThreadLocal is.
Android introduces concept of "Loopers" - you can build one in any thread and call it; if you do, you can say that the thread "has a looper". A thread that has a looper is stuck in a loop, doing any work that handlers pass to it, and - after finishing each task - waiting for another to come by. This is what the main thread does all the time. If you build a handler instance, the handler can be called from any thread, but is connected to the looper of the thread that called the constructor.
Since handlers work by passing work to loopers, they can only be built in threads that have loopers.
I am not sure what you want to achieve, but the bottom line is:
your idea of holding a reference to Activity is wrong - just let it go (and use Loader API or a Service)
you try to build a Handler instance on some custom thread that has no Lopper (probably adding the looper is NOT what you want, instead you want to build the Handler in your main thread)
you imagine objects as being owned by threads - try to get rid of this idea, it skews your way of thinking.
This what i am trying to do in my application.
The activity has 2 button
1 - for starting thread (start)
2 - for stopping the thread (stop)
I press a button to start a thread and i don't want to kill my thread when press back
everything okay for now.
The problem is when i come back to that activity there is a button to stop that thread
but the thread been lost so i can't stop it and if i press start a second thread run and i got 2 thread running.
My question is can we save that thread in a bundle? If possible how i don't see a method to put a object. If not any good solution that i can do to avoid losing my thread.
Thank you.
You can't save a thread in a Bundle. In general if you need a task to run after you exit the app you should be using a Service.