running code immediately after activity is displayed

by Peter Jeffe » Wed, 22 Jul 2009 09:51:34 GMT

Sponsored Links
 I want to run some init code immediately after my activity becomes
visible to the user, so that the main view can come up as soon as
possible and then the data can get filled in afterward.  So all I want
to do is schedule something to run on the UI thread immediately after
the activity is actually made visible.

Of course I can send a message to a Handler with a long enough delay
to wait out the activity creation code, but I don't want a delay, I
want it to run asap.  If I make a reasonably small delay then it still
ends up being run before the activity creation code is done and
blocking the display of the activity until it's done.  I tried running
it from onPostResume() but same problem.

This is such a common use case I have to believe it's doable--does
anyone know how?  Thanks.

-- Peter


running code immediately after activity is displayed

by skink » Wed, 22 Jul 2009 14:30:13 GMT


use MessageQueue.addIdleHandler()


Sponsored Links

running code immediately after activity is displayed

by Peter Jeffe » Wed, 22 Jul 2009 22:10:28 GMT


Very cool, thanks!  So I guess this works since it only gets back to
the (now empty) message queue when it's completely done starting the

-- Peter


running code immediately after activity is displayed

by Micah » Wed, 22 Jul 2009 22:25:04 GMT

 If the code you are running takes long enough to noticeably block the
UI (ie: more than 200ms) then you should do it in another thread.
Allowing the user to see the UI but not interact with it (because your
app is doing some heavy lifting in the main thread) is just as bad of
a user experience as having to wait a long time for the app to load.
The only exception is if you put up a loading screen that says
something along the lines of "please wait" but that's still not nearly
as user friendly as doing the heavy lifting in another thread.


running code immediately after activity is displayed

by Peter Jeffe » Thu, 23 Jul 2009 00:59:21 GMT


Well, there are a couple of different issues here.  Clearly you
shouldn't block the UI thread too long for obvious reasons.  "Too
long" is something you have to decide for yourself, but the ANR
timeout is certainly an upper bound on it.

So if you have expensive stuff you need to do at activity init time
there aren't too many options.  All other things being equal, you
should push whatever you can to a background thread so that you don't
block whatever UI activity is happening (even if it's just updating a
progress spinner).

That's all a given.  What I was asking about was how to
deterministically run a chunk of code immediately after the activity
becomes visible, and that's what pskink answered.  In my particular
case my init code needs to first run on the UI thread, and then I
background an expensive process and call back to the UI thread when
it's done, but that's beside the point.

I'm not sure I understand your dichotomy between either putting up a
"please wait" notice *or* doing stuff in a background thread.  If you
aren't ready for user interaction until the background stuff is done
then you need to do both.  If you can let the user do something useful
while the background stuff is going on then all the better (but that's
not my case at the moment).

So I think we mostly agree but are having two different
conversations. :-)

-- Peter


running code immediately after activity is displayed

by skink » Thu, 23 Jul 2009 01:44:14 GMT


yes, this is how it works

-- Peter

Other Threads

1. return a List in aidl?

Can I return a List in aidl? When I try to do so, I get an error in
the interface file that is automatically generated from my aidl file.
Any other return type seems to work.

The error is in reply.writeBinderList(_result); it says The method
writeBinderList(List<IBinder>) in the type Parcel is not applicable
for the arguments (List<IStatus>)


2. running 2.6.29 on HTC Dream

Greetings!  I'm responsible for getting my company's Bluetooth application
up and running on the Android platform, and the HTC Dream in particular.
One of our requirements was support for Bluetooth L2CAP enhanced
retransmission and streaming modes.  I've implemented the necessary changes
to the L2CAP core on a Debian system running 2.6.29 and 2.6.30-rc* kernels.
(The patchset has been submitted to the linux-bluetooth mailing list, a GSOC
student is currently integrating and extending it's functionality.)

I'm now faced with the prospect of getting it running on the HTC Dream,
running Android 1.5, which uses kernel 2.6.27.  I've successfully compiled
the android-msm-2.6.29 kernel from the Android kernel tree with the L2CAP
patches applied.  Unfortunately, when running this kernel, the prebuilt TI
wireless module will not load, due to it being compiled against a different
kernel version.

# insmod wlan.ko

Getting both Bluetooth eL2CAP and Wireless/WiFi working concurrently is
critical to our application.  Previous messages on this list imply 2.6.29
will be the next supported Android kernel.  Does this mean that the TI
module has been compiled against this kernel version?  If so, is it

If not, would my only recourse be backporting the changes to 2.6.27?  But if
I do so, won't backporting to 2.6.27 and applying my patches still result in
a different git commit hash in the version magic string?  Or does it only
check the kernel version numbers?



3. How can I listen for WebView for a page load complete event?

4. Trying to retrieve codec output from Audio Record


6. How can I install my app to Dev G1 phone?

7. how to add space between column in TableLayout