Tracking down modifications to adapter data not on UI thread

Question

I have just inherited a very large code base of probably around 100 activities. It seems the past developers didn't understand how to only update adapter data on the UI thread and remember to notify that the data set changed. In bugsense I have many stack traces such as this pointing out that it is causing a crash.

The problem is the stacktrace is all OS level and doesn't actually point to what caused the issue. Is there any systematic way to go about finding these issues that anyone knows about? I know I can fix them by manually inspecting all adapter usage in the entire code base but that is not really an effective use of time and I want to get this fixed.

java.lang.IllegalStateException: The content of the adapter has changed but ListView did not receive a notification. Make sure the content of your adapter is not modified from a background thread, but only from the UI thread. [in ListView(16908298, class android.widget.ListView) with Adapter(class android.widget.HeaderViewListAdapter)]

In C, I'd set a memory breakpoint- tell the debugger to notify me if the memory where the object was stored changed. There has to be something similar for Java, I just don't know where. — Gabe Sechan, May 24 '13 at 14:38

score 1 · Answer 1 · answered May 24 '13 at 14:03

1

What IDE are you using? You could load your code into an IDE like eclipse bundled with ADT. There you can find references (shortcut depends on your OS) for a specific class. Do this for all adapters or any other relative code. This also works on compiled class files.

enter image description here

answered May 24 '13 at 14:03

hcpl

17,382
7
72
73

Thanks for the comment. Yeah I am aware of that tool. The problem is there is a massive amount of code and I am looking for a few needles in a haystack of over a hundred activities. It would not be an effective use of time to manually inspect every usage of adapters. I am wondering if there are any clever ways to maybe wrapper things to get the errors to call themselves out. – w.donahue May 24 '13 at 14:25

score 1 · Answer 2 · answered May 24 '13 at 16:43

1

Here's an idea:

Obtain a reference to the application's main thread with:

Thread mainThread = Looper.getMainLooper().getThread();

Before each method call you make to the adapter in your code, check that you are currently executing on the application's main thread (by testing for equality, for example):
```
if (!mainThread.equals(Thread.currentThread())) {
    // Then throw a runtime exception or log an error to indicate
    // that the code is not thread safe.
}
```

answered May 24 '13 at 16:43

Alex Lockwood

83,063
39
206
250

Thank you for the response. I am aware of that technique, but that would not be able to answer the question of where in the code these issues are without me going through the entire baseline and adding these checks to everywhere where an adapter or its backing data store is changed. – w.donahue Jun 03 '13 at 14:23

Tracking down modifications to adapter data not on UI thread

2 Answers2