| 31d9acbf0623872f9d4a2b3210b5970854b654c7 |
|
12-Feb-2011 |
Marc Blank <mblank@google.com> |
Email split, part huit: Refactor constants, clean emailcommon
* There are three pieces to this CL (sorry):
1) Move and/or rename some constants into emailcommon
2) Move Utility to emailcommon, moving the few UI
related utilities back into Email (FolderProperties
and UiUtilities)
3) Remove all references to resources from emailcommon
* The three pieces relate in that, between them, they allow
the emailcommon static library to compile cleanly
Bug: 3442973
Change-Id: Ic5e3abaa2a1b36999e0b6653c6c2134ea1bd544f
/packages/apps/Email/src/com/android/email/data/ThrottlingCursorLoader.java
|
| 31e25767918193217c884db72aaa98e50a4957d3 |
|
17-Jan-2011 |
Dianne Hackborn <hackbod@google.com> |
Follow API changes.
Change-Id: I1ca0fe365b953fa98a462912309a1c9647277ba7
/packages/apps/Email/src/com/android/email/data/ThrottlingCursorLoader.java
|
| e447bea49b9a50ef76c35f6dc0f794a3fd147e79 |
|
04-Jan-2011 |
Makoto Onuki <omakoto@google.com> |
Attempt to fix StaleDataException
I'm not yet 100% sure what's going on, but the old code, not stopping
the scheduled forceLoad() in onReset() is apparently wrong.
onReset() is a new callback introduced in the recent loader change, so
this can explain why it started after the change.
Also, call super.onContentChanged() instead of directly calling forceLoad(),
as Loader.onContentChanged() now does more than just calling forceLoad.
Bug 3308465
Change-Id: Ica46bf994b571a26dd532734307a5c7ec6df0268
/packages/apps/Email/src/com/android/email/data/ThrottlingCursorLoader.java
|
| 8b9f2a7284337bfb23d5e2f8de9f1c70cb9532a1 |
|
21-Dec-2010 |
Dianne Hackborn <hackbod@google.com> |
Update to use new Loader callbacks.
Change-Id: Ib478c2f2314bbae4a380539e22892d85dd9a34b5
/packages/apps/Email/src/com/android/email/data/ThrottlingCursorLoader.java
|
| 085f7eb1219f270faa8317a5c6069a562213cb83 |
|
02-Oct-2010 |
Makoto Onuki <omakoto@google.com> |
Extract the throttling part from ThrottlingCursorLoader
Extracted into the Throttle class as I'll need this logic elsewhere.
Bonus: Now it has tests.
Change-Id: Ie9a5933f8e5015dda6985ba76814f1f945266178
/packages/apps/Email/src/com/android/email/data/ThrottlingCursorLoader.java
|
| 4209ea36b0602d4f1dca0e9057e6a6b58d7d907d |
|
22-Sep-2010 |
Makoto Onuki <omakoto@google.com> |
Make ThrottlingCursorLoader smarter
Now the class initially uses smaller timeout, and expand it when detecting
multiple changes in a short period.
This CL makes the UI look more responsive especially on the message list +
message view mode. e.g. Starring on the message view will quickly be
reflected to the message list.
Bug 3024799
Bug 3027832
Change-Id: Ie2d44c3769d43e3fd0f54ee526556eb3bad5e288
/packages/apps/Email/src/com/android/email/data/ThrottlingCursorLoader.java
|
| 630e31ef788d4aa0dc259bc3412f7e98bca201e8 |
|
02-Aug-2010 |
Makoto Onuki <omakoto@google.com> |
Introducing ThrottlingCursorLoader.
This is a {@link CursorLoader} variant that takes {@code timeoutSecond}
in the constructor.
When it detects changes in the underlying data, it'll wait until the timeout
before doing a requery.
We use this to throttle # of queries. We don't want to issue a query every
time something changes in the DB while we're syncing.
Change-Id: I098366bce923c3242c42964bc166493610ee0f6f
/packages/apps/Email/src/com/android/email/data/ThrottlingCursorLoader.java
|