| 944ef3b09d15d28f13cf63e3410850e246b1d54f |
17-Jul-2014 |
Greg Bullock <gregbullock@google.com> |
Extract AccountLoadCallbacks so that it can be re-used.
Change-Id: I24a50abf78b1a44269914126a86813c3e8b97d4e
bjectCursor.java
|
| a6e715636fa6243e088f1263ea7e191ad317acf8 |
24-Aug-2013 |
Scott Kennedy <skennedy@google.com> |
Make getUri()/setUri() public
Bug: 10429030
Change-Id: I29412c132dc87fb8e9e17f07acf1f750384bc876
bjectCursorLoader.java
|
| d521baf3a51c9fc1306bd55e027ce57d0a1d18aa |
22-May-2013 |
Andy Huang <ath@google.com> |
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
hreadSafeCursorWrapper.java
|
| 7f39bbd358f7003a72ae2b480dfe38a84e830e5f |
21-May-2013 |
Andy Huang <ath@google.com> |
use Cursor.respond() instead of blobs
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
hreadSafeCursorWrapper.java
|
| 8908b265acaf04a1c062721388968875d19ad1e4 |
17-May-2013 |
Yu Ping Hu <yph@google.com> |
Don't create an ObjectCursor if underlying cursor is null.
Bug: 9019274
Change-Id: I1d225c855127038ae00ebcfdc8daf425fdce332a
bjectCursorLoader.java
|
| 6de11b098c86f45a3c21dd59b548da91cb736892 |
11-May-2013 |
Paul Westbrook <pwestbro@google.com> |
Allow ConversationCursor to be populated in background
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
hreadSafeCursorWrapper.java
|
| c42ad5ea3a49e6045a79d1fde3d858033176e67b |
10-May-2013 |
Paul Westbrook <pwestbro@google.com> |
Use an ObjectCursorLoader for Messages
Bug: 8763530
Change-Id: I0a70c92dd52eff5d10c067fdb78b371bfd8178ac
bjectCursorLoader.java
|
| e6459424b3e46d768865c908af1caa932f783095 |
02-Apr-2013 |
Andy Huang <ath@google.com> |
fix blank conversation view on tablet when launching from intent
If a 2-pane layout pass finished before the FIRST_FOLDER loader returned
results, the layout pass triggered an early showConversation() operation
before mConversationToShow is set by the FIRST_FOLDER loader.
The later showConversation() in the FIRST_FOLDER onLoadFinished did not
re-run the operation, because it assumed a transition would run that
showConversation had to wait for. The transition does not actually run
because TwoPaneLayout debounces consecutive requests to change the view
mode.
So...
* don't switch modes on FIRST_FOLDER load unnecessarily
* FIRST_FOLDER load was triggering a mode change to LIST, so move that
into loadAccountInbox
* don't have 2-pane ask ViewMode to see if the mode changed, have it
ask TPL instead
Add some helpful optional logging, and a facility to ObjectCursorLoader
to slow down race conditions for debugging purposes.
Bug: 8408885
Change-Id: If4672c0f6c4426f810de33f65694119d678bacfb
bjectCursorLoader.java
|
| 738731d641c80b08e710dd4a6a78eb063d282bcc |
13-Mar-2013 |
Scott Kennedy <skennedy@google.com> |
Remove a method
It was only being called in one location, and the parameter was being
ignored.
Matches Ia853dd8d3898ac3e4c4b2fb3a51d103844b57ca1 in frameworks/base
Change-Id: Id963e1950fb0139ad88ca6c7aa425b3b1c497256
bjectCursorLoader.java
|
| 8e746b81712bb616d4811eeebf078654c1a8f4e5 |
14-Mar-2013 |
Andy Huang <ath@google.com> |
Fix settings changes so they propagate to account listeners
CursorLoader.onCanceled was accidentally copied as cancelLoad, which is
quite different. onCanceled is CursorLoader's handling of canceled async
tasks, while cancelLoad is a Loader signal that typically happens when
loading is stopped (e.g. Activity is stopped).
Bug: 8384213
Change-Id: I49bfde800f02d9ebd0d8a108e05686a71565eb8a
bjectCursorLoader.java
|
| 60593354f1126b9687d09c3b11a852a3459f7118 |
13-Mar-2013 |
Scott Kennedy <skennedy@google.com> |
Fix a NPE when the up button is pressed
The up button in ComposeActivity was using createViewInboxIntent, but
not passing in the required folderUri parameter, which was being used
later. This change just checks if that parameter is there, and if
not, uses the account's inbox URI.
Bug: 8373309
Change-Id: Ie1bc88d0480c531ab02a4950f404013879784b28
bjectCursorLoader.java
|
| 177097fad8fc26b8a215f9f1af6dd5fd2c8eb06c |
08-Mar-2013 |
Vikram Aggarwal <viki@google.com> |
Loaders that create objects in the background
Create Folder objects in the background. This frees the UI thread
after onLoadFinished is called, since the object has already been
created.
Bug: 8315641 optimize AbstractActivityController's loaders
Change-Id: I1f4b2f679cf99a9193d88cb6b9a5aa77b33d6ea9
ursorCreator.java
bjectCursor.java
bjectCursorLoader.java
|