Runnable is posted successfully but not run
Solution 1
If you look at the docs for View.post
there's some relevant info:
This method can be invoked from outside of the UI thread only when this View is attached to a window.
Since you're doing this in onCreate
, it is likely that sometimes your View
will not be attached to the window yet. You can verify this by overriding onAttachedToWindow
and putting something in the logs and also logging when you post. You'll see that when the post fails, the post call happens before onAttachedToWindow
.
As the others have mentioned, you can use Activity.runOnUiThread
or provide your own handler. However, if you want to do it directly from the View
itself, you can simply get the View
's handler:
view.getHandler().post(...);
This is especially useful if you have a custom view that includes some sort of background loading. There's also the added bonus of not having to create a new separate handler.
Solution 2
I think the problem is you are updating the UI (ImageView) with a separate thread, which is not the UI Thread. The UI can only be updated by the UI Thread.
You can solve this by using Handler:
Handler uiHandler;
public void onCreate(){
...
uiHandler = new Handler(); // This makes the handler attached to UI Thread
...
}
Then replace your:
if ( !img.post(new Runnable() {
with
uiHandler.post(new Runnable() {
to make sure the imageview is updated in the UI Thread.
Handler is a quite confusing concept, I also took hours of research to really understand about this ;)
Solution 3
I extended ImageView
class to solve this problem. I collect runnables passed to post while view not attached to window and in onAttachedToWindow
post collected runnable.
public class ImageView extends android.widget.ImageView
{
List<Runnable> postQueue = new ArrayList<Runnable>();
boolean attached;
public ImageView(Context context)
{
super(context);
}
public ImageView(Context context, AttributeSet attrs)
{
super(context, attrs);
}
public ImageView(Context context, AttributeSet attrs, int defStyle)
{
super(context, attrs, defStyle);
}
@Override
protected void onAttachedToWindow()
{
super.onAttachedToWindow();
attached = true;
for (Iterator<Runnable> posts = postQueue.iterator(); posts.hasNext();)
{
super.post(posts.next());
posts.remove();
}
}
@Override
protected void onDetachedFromWindow()
{
attached = false;
super.onDetachedFromWindow();
}
@Override
public boolean post(Runnable action)
{
if (attached) return super.post(action);
else postQueue.add(action);
return true;
}
}
Solution 4
I don't see anything obviously wrong with what you have there; calling View.post() should cause it to run on the UI thread. If your Activity went away (perhaps through a screen rotation), then your ImageView wouldn't be updated, but I would still expect a log entry to say "setting bitmap ...", even if you couldn't see it.
I suggest trying the following and see if it makes a difference:
1) Use Log.d (the standard Android logger) rather that System.out
2) Pass your Runnable to Activity.runOnUiThread() rather than View.post()
Solution 5
Use the following code, can post your code to MainThread anytime anywhere, but not depends any Context
or Activity
. That can prevent view.getHandler()
failure or tedious onAttachedToWindow()
stuffs etc.
new Handler(Looper.getMainLooper()).post(new Runnable() {
@Override
public void run() {
//TODO
}
});
Related videos on Youtube
mvds
Updated on December 01, 2020Comments
-
mvds over 3 years
In an existing Android project I've encountered the following piece of code (where I inserted the debugging litter)
ImageView img = null; public void onCreate(...) { img = (ImageView)findViewById(R.id.image); new Thread() { public void run() { final Bitmap bmp = BitmapFactory.decodeFile("/sdcard/someImage.jpg"); System.out.println("bitmap: "+bmp.toString()+" img: "+img.toString()); if ( !img.post(new Runnable() { public void run() { System.out.println("setting bitmap..."); img.setImageBitmap(bmp); System.out.println("bitmap set."); } }) ) System.out.println("Runnable won't run!"); System.out.println("runnable posted"); } }.start();
New to Android development, and having googled around, I understand that this is the way to do stuff without blocking the main (UI) thread, while still setting the image on the UI thread after decoding. (at least according to android-developers) (which I have verified by logging
Thread.currentThread().getName()
at various places)Now sometimes the image just doesn't show up, and stdout only says
I/System.out( 8066): bitmap: android.graphics.Bitmap@432f3ee8 img: android.widget.ImageView@4339d698 I/System.out( 8066): runnable posted
with not a trace of the messages from the Runnable. So appearantly the Runnable doesn't
run()
, althoughimg.post()
returnstrue
. Pulling the ImageView inonCreate()
and declaring itfinal
doesn't help.I'm clueless. Simply setting the bitmap directly, while blocking the UI thread, does fix things, but I want to get things right. Does anybody understand what's going on here?
(ps. this was all observed on an Android 1.6 phone and android-3 sdk)
-
Richard Le Mesurier almost 12 years
-
-
mvds over 13 yearsI don't understand why, but this seems to work! In one out of ten tries, I got a segmentation fault (apparently in libc), but I can't believe this is related.
-
mvds over 13 yearsI don't understand why, but this seems to work as well! So anything is more reliable than
View.post()
. Thanks! -
xandy over 13 yearsGood call @Shawn. I never noticed runOnUiThread() function. Interesting enough, I checked the source code and runOnUiThread is using Handler to implement. So @mvds, both works is not coincidence, they are using same method under the hood.
-
Shawn Lauzon over 13 yearsWhat's still not clear to me is why @mdvs's solution doesn't work. The Google article at developer.android.com/resources/articles/… references View.post(Runnable), which is what he used, and the Javadoc says "Causes the Runnable to be added to the message queue. The runnable will be run on the user interface thread."
-
hungson175 about 12 yearsI have the exactly same problem as mvds. And yeah, it also works like one out of 3 - but when I added some more Log.i(...) - it works better, like 1 out of 7 , and I took out thoses Log.i() , it works again in 1 out of 3 .... So I just don't understand why - but it seems that when the code get "slower" just a little bit then the View.post() works ! Is that a bug in SDK ?
-
hungson175 about 12 yearsUpdated: I just pass in a Handler, and use handler.post() - it works flawlessly ! And one more thing: be careful when pass Activity to the thread - it could be a memory-leak (in my case, I use the thread to load images from web, and the thread should be Singleton - static & pointer to Activity: dangerous as in developer.android.com/resources/articles/…
-
ThomasW over 11 yearsI've only investigated this briefly, but it appears that when the view is not attached to a window it also doesn't have a handler.
-
kabuko over 11 years@ThomasW My solution worked in my scenario but YMMV for sure. As far as I know, the docs don't specify when
getHandler()
is going to be valid, but on examination of the code it looks like my solution only works when the view is at least about to be attached. If you never even try to attach it to a window then you're correct, there will be no handler available. -
dcow over 10 years@kabuko this should be edited now that the functionality has changed. The docs no longer have the clause you reference. I would assume this is because, according to the source, the functionality seems to have changed:
// Execute enqueued actions on every traversal in case a detached view enqueued an action \n getRunQueue().executeActions(attachInfo.mHandler);
This means that posting to a View should work provided the View has been attached once (where it gets the initial reference to the ViewRootImpl's Handler). But, you cannot still post to a view before it's been initially attached. -
dcow over 10 years@kabuko View.post() now also returns a boolean to signal whether the action was successful. I think it would now be advisable to check that value to determine whether the post was successful (since any successfully posted runnable should now be executed regardless of whether the View is attached or not).
-
kabuko over 10 years@DavidCowden Thanks for pointing this out. I haven't had the time to take a close look to see what the current behavior is exactly, but it definitely seems that the documentation has changed. The boolean return value was always there. I didn't point it out because it simply wasn't useful in this situation (it was successfully posted, but not executed). Hopefully at some point I'll take some time and figure out exactly what happens now and update this answer for newer versions of Android. For the record, I think this functionality changed around 4.3, though it'd be good to find out for sure.
-
dcow over 10 years@kabuko yeah it was definitely in the last 2 API levels at least.
-
Stefan Haustein almost 10 yearsFTR: This seems to still be an issue with 4.4: There are situations where the handler is null, post() returns true and the Runnable is never invoked...
-
njzk2 over 9 years@StefanHaustein: +1. On 4.1 and 4.2 too. Using
post
in a thread created in a fragment onCreateView, thepost
returnstrue
, but therun
may or may not be called, without any notification -
Charlesjean over 9 yearsI can not see this comment
This method can be invoked from outside of the UI thread only when this View is attached to a window.
any more in android 5.0 doc, but It seems this problem is still there -
dimsuz almost 9 years@StefanHaustein +1 And I also found out that at least on 4.4 calling view.getHanlder().post() outside an ui thread just hangs. I tried to put some logging after this call - never got executed...
-
Alex Cohn almost 8 yearsActiually, this has never been true, but at some point the JavaDoc for View.java did wrongly state that "View.post only works from another thread when the View is attached to a window". This was fixed on Oct. 15, 2012, but took a while to penetrate the minds of Android developers. The caveat probably is that if the view is not attached to a window in the future, the posted Runnable will never be executed.
-
Mustafa R.Mahdi almost 7 yearsbetter is : new Handler( Looper.getMainLooper() ).post( Runnable );
-
sud007 over 6 yearsSurprising yet again! This works. Thanks! But I wonder
View.post
andpostDelayed
are so unpredictable! They work flawlessly in some Android devices and fail miserably in some. Duh! -
sud007 over 6 years
View.post
andpostDelayed
are so unpredictable! They work flawlessly in some Android devices and fail miserably in some. Duh! -
Bos over 6 yearsRunnable from View.post in onCreate is stored in a RunQueue rather than add it to message queue directly. This Runnable will execute after next performTraversals. Before Android 7.0, Runnable will not execute if you View.post it in a thread in onCreate. Yes, this issue was fixed in 7.0.