not all respond() calls require locking

The UI thread uses respond() to signal user-visibility on each list
item, so we definitely don't want to block the UI thread on those kinds
of respond() calls. Add an options bitfield whose inaugural value is a
bit that hints that the cursor position must be safely moved prior to
respond().

This fixes some big hiccups that result when syncing + scrolling with
the respond CLs yesterday.

Bug: 9032162
Change-Id: I1c927453b9f474c89861a7295de1e318279e3a49

1 files changed, 8 insertions, 2 deletions

diff --git a/src/com/android/mail/content/ThreadSafeCursorWrapper.java b/src/com/android/mail/content/ThreadSafeCursorWrapper.java
index 35ec10370..ed2b3f93a 100644
--- a/src/com/android/mail/content/ThreadSafeCursorWrapper.java
+++ b/src/com/android/mail/content/ThreadSafeCursorWrapper.java
@@ -20,6 +20,7 @@ import android.database.Cursor;
 import android.database.CursorWrapper;
 import android.os.Bundle;
 
+import com.android.mail.providers.UIProvider;
 import com.android.mail.utils.LogTag;
 import com.android.mail.utils.LogUtils;
 
@@ -98,8 +99,13 @@ public class ThreadSafeCursorWrapper extends CursorWrapper {
 
     @Override
     public Bundle respond(Bundle extras) {
-        synchronized (mLock) {
-            moveToCurrent();
+        final int opts = extras.getInt(UIProvider.ConversationCursorCommand.COMMAND_KEY_OPTIONS);
+        if ((opts & UIProvider.ConversationCursorCommand.OPTION_MOVE_POSITION) != 0) {
+            synchronized (mLock) {
+                moveToCurrent();
+                return super.respond(extras);
+            }
+        } else {
             return super.respond(extras);
         }
     }