Hmm..I tried that but it seems the runnable is executed too fast, the flag is always true by the time next the message is posted (which indicates it's ok to post a new runnable), even when there is a large influx of data. I decided to try another approach and calculate the time difference between the new and previous message and post a new runnable if the time difference is quite large and this seems to work quite well.
But it also seems I was checking the wrong trace file (>.<), the new trace file shows the ANR happens when I try to scroll and it tries to retrieve the spans for the previous text: (from the traces file): DALVIK THREADS: "main" prio=5 tid=3 RUNNABLE | group="main" sCount=1 dsCount=0 s=1 obj=0x400113a8 | sysTid=966 nice=0 sched=0/0 handle=-1092436836 at android.text.SpannableStringBuilder.getSpans (SpannableStringBuilder.java:~744) at android.text.Layout.getParagraphAlignment(Layout.java:1238) at android.text.Layout.getLineLeft(Layout.java:554) at android.text.method.Touch.scrollTo(Touch.java:46) at android.text.method.Touch.onTouchEvent(Touch.java:117) at android.text.method.ScrollingMovementMethod.onTouchEvent (ScrollingMovementMethod.java:176) at android.text.method.LinkMovementMethod.onTouchEvent (LinkMovementMethod.java:229) at android.widget.TextView.onTouchEvent(TextView.java:4424) at android.view.View.dispatchTouchEvent(View.java:3178) at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:857) at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:857) at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:857) at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:857) at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:857) at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:857) at android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:857) at com.android.internal.policy.impl.PhoneWindow $DecorView.superDispatchTouchEvent(PhoneWindow.java:1561) at com.android.internal.policy.impl.PhoneWindow.superDispatchTouchEvent (PhoneWindow.java:1085) at android.app.Activity.dispatchTouchEvent(Activity.java:1873) at com.android.internal.policy.impl.PhoneWindow $DecorView.dispatchTouchEvent(PhoneWindow.java:1545) at android.view.ViewRoot.handleMessage(ViewRoot.java:1140) at android.os.Handler.dispatchMessage(Handler.java:88) at android.os.Looper.loop(Looper.java:123) at android.app.ActivityThread.main(ActivityThread.java:3742) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:515) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run (ZygoteInit.java:739) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:497) at dalvik.system.NativeStart.main(Native Method) I'm using a fair amount of spanned text to add colour and the like to distinguish between certain types of messages (quit messages vs join messages, etc). It seems I need to remove the spans for text which was added a while ago. On Jan 13, 4:16 pm, Michael MacDonald <[email protected]> wrote: > I wouldn't count on ever being called when your app is as busy as it is. > Instead, I would make sure that there was only one instance of your > specific Runnable on the queue. Set a flag when you create and queue the > Runnable and have the Runnable clear the flag when it completes, > and don't create the Runnable again if the flag is set. > Al wrote:Michael, I had a look > athttp://code.google.com/android/reference/android/os/MessageQueue.IdleHandler.html, > which is supposed to be called when the message queue is empty, but I never > received a call on it. I'm implementing it like this: myHandler = new > Handler() { MessageQueue.IdleHandler foo = new MessageQueue.IdleHandler() { > public boolean queueIdle() { //Do something return true; } }; public void > handleMessage(Message m) { //Handle the message } }; Am I implementing it > right? @RomainGuy, just using post didn't help, but I think using post() > would be better to use if I was able to check the status of the message queue > (empty or not). On Jan 13, 2:59 am, Michael > MacDonald<[email protected]>wrote:Try not posting a runnable on the > receiving thread if one is already queued? Al wrote:Hi all, in my irc app, > I'm trying to improve the responsiveness when it has to deal with a lot of > data at a single time.At the moment, once the data is append()-ed to the > textview, I post a delayed runnable (100ms delay) back to the UI thread to > make it scroll right down to the bottom. Unfortunately, without the runnable > being posted, it doesn't seem to be possible to correctly calculate the > amount the ScrollView should scroll and often scrolls halfway only.This works > fine for normal situations and the program is fully responsive. But when, > there is a lot of channel activity, the queue of Runnables start to strain > the UI thread and it has trouble appending the data as it arrives and > occasionally causes an ANR.My question is, how would I get around this? > Without the Runnable, it doesn't scroll correctly but with it, it causes > problems. A possible solution could be to detect when there is an influx of > data and post the Runnable less often, but I'm not sure how I would detect > this.Any ideas welcomed. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
