| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | not all respond() calls require locking | Andy Huang | 2013-05-21 | 1 | -2/+8 |
| | | | | | | | | | | | | | | | 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 | ||||
| * | use Cursor.respond() instead of blobs | Andy Huang | 2013-05-20 | 1 | -3/+16 |
| | | | | | | | | | | | | | | | | | | | | | | | | Using Cursor.getBlob() to pass complex objects from provider to UI requires us to serialize a perfectly usable Parcelable, then de- serialize that byte array. Let's cut out the middle man by shoving the Parcelables into a Bundle from Cursor.respond(). Since Gmail is single- process, this is nearly free, but even in multi-process situations, respond() should not be any more expensive than getBlob(). respond() must now be thread-safe in the wrapper, and it should trigger a position move like getBlob() does. I found that the async task that marks lists visible was sometimes running when the position is -1, so start ignoring this. I think this is a red herring, as AbstractCursor just doesn't like moving to -1. On Galaxy Nexus, this cuts Conversation construction 30% from 2.11ms to 1.46ms. It also avoids creating 4 large objects per row, which should make for less object churn and heap fragmentation. Bug: 8642220 Bug: 9032162 Change-Id: Ic4cea27e8e84d85b160e6cf8fe0d3cc6a836249f | ||||
| * | Allow ConversationCursor to be populated in background | Paul Westbrook | 2013-05-13 | 1 | -0/+179 |
| Added a "thread safe" cursor wrapper, which can allow a cursor to be used by multiple threads The constructor for UnderlyingCursorWrapper will load 100 conversations. If the there are more rows, an AsyncTask will be started to load the remainder Bug: 8642220 Change-Id: I665b7a57d3264b6347e5d8bc8588629e320d8382 | |||||
 |
index : packages_apps_UnifiedEmail.git | |
| packages_apps_UnifiedEmail |
| summaryrefslogtreecommitdiff |