I’ve been working on building a nice graphical clock selector. Unfortunately, this selector is causing me lots of frustration due to a race condition that keeps deadlocking the application’s UI thread. Parsing and rendering the various SVG layers that make up each clock is a relatively expensive operation. Locking up the user interface while doing these operations is bad design and leads the user to believe that the application may not working correctly. What I’m attempting to do seems pretty simple on the surface. The following screen capture shows the (partially working) goal:
[image: Clock Skin Selector]<http://www.setera.org/wp-content/uploads/2011/12/clocks.png> The selector consists of two columns, an image of the clock on the left and the name of the clock on the right. Using the standard ListActivity support, the goal is to show an indeterminate progress image in the left column until the layers have been loaded and rendered. At that point, the animated progress image is hidden and the clock image is displayed. The implementation is simple in concept. The list adapter subclasses the standard BaseAdapter implementation to provide an implementation of the * getView* method. The *getView* method delegates loading of the clock’s image to an asynchronous executor service, keeping the user interface alive. When the asynchronous task completes, it posts a runnable to the UI thread to hide the progress indicator and show the image view. There is logic related to properly handling recycled item views as well. While this is mostly working, I’m hitting a random deadlock condition that locks up the UI thread, usually resulting in an “Application Not Responding” (ANR) error message to the user. All of my attempts to diagnose and resolve this issue have ended with nothing but frustration. So far, I’ve tried all of the “standard” approaches to diagnose this: - Analyzed the traces.txt file generated by the ANR. Unfortunately, the process never shows up in the log file. - Force-generated a traces.txt file using *kill SIGQUIT pid* while the application was still running. Again, the process doesn’t seem to show up. Instead, I see “W/dalvikvm(19144): threadid=4: spin on suspend #1 threadid=9 (pcf=0)” whenever attempting this. - Enabled the kernel-level deadlock prediction stuff, but it never showed anything - Attempted to use the standard Eclipse debugger to suspend the UI thread once it is locked up. No big surprise that it did not work. - Added lots of Log output trying to pinpoint the hang. At least from that logging, it doesn’t *appear* to be a hang anywhere directly in my code. - I even tried to use method tracing to see if I could figure anything out. At this point, I’ve run out of good ideas on how to track down and fix this problem on my own. There is a part of me that is wondering if there is some kind of deadlock "underneath" my code (in particular in android.graphics.Picture" handling), but a stack trace would definitely be helpful. -- 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
