Thanks for your quick reply.
On Aug 31, 12:28 pm, Dianne Hackborn <hack...@android.com> wrote:
> On Wed, Aug 31, 2011 at 9:16 AM, Dmitry Golubovsky <golubov...@gmail.com>wrote:
> > Q1: Is post(action) equivalent to postDelayed(action, 0)?
OK, may I suggest that this be reflected in the reference?
> > what combinations of N and T ranges (including T = 0) are acceptable
> > to make sure the view remains responsive to touch and other user-
> > generated events, and "force close/wait" dialog does not appear?
> It will remain responsive because older messages are processes before newer
> messages, so you can't starve other messages from the queue by re-posting a
> message when you handle it, even with no delay.
OK, so there are no specific priorities on user-generated vs. posted
> the user is in your app, if using a delay of 20ms means you are keeping the
> CPU running at near 100%, are going to much more quickly drain the battery
> (and the user will see this in the battery use report).
I posted much simplified code. This is the same Smalltalk VM port that
I mentioned several times in the NDK group.
The VM has an interval timer (which is N in my example), and when it
expires inside the native code, the VM saves its state and returns to
the Java UI code. Or otherwise it may return if there is nothing to
process (no input events). If return happened by timer, the VM will be
reentered ASAP (that is, after T in my example). Otherwise it may not
be reentered until another user event is registered. That is, zero-or-
near-delays between entering native code do not happen 100% of the
All I am concerned about is not to have the "non-responding" dialog
and buffer pending events within the application.
Your explanation is very helpful.
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at
Post a Comment