We were sort of using observers to maintain the new message notifications.
However, other parts of the code would poke into the notification controller
to set things such as a list of newly added message IDs. Now, we rely
exclusively on db observers to manage notifications.
As a side effect of this, we now set the notification text correctly to be
the most recently _added_ message. This may be different than the most recently
sent message [since there may be a non-negligable delta between when the
message was sent and when it was received].
NOTE this still suffers from an outstanding bug where we continue to get
notifications when the Eamil UX is visible. That and monitoring changes to the
account table will be addressed in future CLs.
Change-Id: I4c68273716cc685574a1ca71e5d634f53fe0d882
The notifiaction table will be used by the updated notification controller.
The table stores the key and the associated last notified message key and
message count.
Change-Id: I037b5374ab51620f1cffc8b41391db858cfd3a2d
Added the base class for the UI controllers and the 1-pane implementaion,
which is almost empty at this point.
The old phone activities still exist and will be used on the phone by default.
To use the new activity (1-pane EmailActivity) on the phone, use the following
comamnd.
adb shell am start -a android.intent.action.MAIN \
-d '"content://ui.email.android.com/view/mailbox"' \
-e DEBUG_PANE_MODE 1
Change-Id: Id1fe85d4517778afc967d7d5e17e1299dd1bfefd
This introduces tab navigation on large screens with action bar (a
dropdown for the phone view is yet to be implemented, though the
internals are ready for it).
This requires the side effect that restoring a draft
reply/replyall/forward will attempt to also load the source message in
full for additional information. If that load fails for whatever reason,
the draft just remains a "compose" as it used to before.
Bug: 3117253
Change-Id: I9cff5ed4a5e9abd1338b6dbde28ceb3e4dc2b761
They're variants of getView() that will *not* crash even if the view
doesn't exist.
I didn't add them before as they would be exactly same as findViewbyId(),
but now that we make use of generics they'll be handy.
Change-Id: Ib649e591a987183064c7e98afe0e2414d9e62280
* Use EmailProvider to backup/restore into a backup database
* Remove all of the old AccountBackupRestore code
* Get rid of the legacy Account class and all of the Preferences
crap that referenced it
* Remove corresponding tests
Change-Id: I2de75aafdacc87246174303961e58547303f641e
Now attachments are actually stored in an explicit list, instead of
being inferred from the state of the UI. This makes it possible to
switch states and restore attachments, and test.
Change-Id: I8c5f80f17f8c9e78d880ac4a1ac6ae22c2ec0579
In order to provide a bit more granularity for content observers, we add the
operation (e.g. "insert", "remove" or "update") as well as the id of the row
that has changed (if it's known).
Change-Id: I214d3c030872f888cde1a2db9b6b46f1bb121b7a
...so that we can easily reuse it for the one pane UI controller.
The one pane controller should eventually have its own action bar
controller, but we can use it for the time beeing, until we get
more detailed UI spec.
Change-Id: I10c92963350dad9eb834fd7474c597aedad5eb80
If we receive new messages, we may display a notification to the user. If
those same messages are read elsewhere (i.e. via a web client), we will
remove the notification.
Change-Id: Iba09afe01942e0deaac8210fd6f9b315b1c8c93f
There is no invariant in the controller that the fragments it references
are non-null, so querying the fragment for state is not always valid.
Change-Id: I880053be4000260b03b54ed8741e646b01314e0d
from Mailbox/MessageListFragment.
This fixes some issues with screen rotation.
(We still reuse MessageViewFragement for the phone, but this should eventually
be cleaned up too.)
Also removed obsolete comments/TODOs.
Bug 4341517
Change-Id: Ib3e713ccab023151c1c47d7d7e4cd1c0de74039d
* Before the Email/Exchange split, EmailProvider was guaranteed not to return a null
cursor; this is no longer true
* We now throw a new RuntimeException (ProviderUnavailableException) when calling
commonly-used utility methods (e.g. restoreXWithId) and the cursor as returned from
EmailProvider is null (which implies that the provider isn't available).
Change-Id: I152d13bff0129c23586cd570d23c87d69cfce372
* Update sync window options to include "Automatic" and "All"
* Make the default (for new accounts) "Automatic"
Change-Id: Icbc696f55abcfad79e66079ebb414ca50778dcaa
This is a lot of code moves to make the asynchronous loading process
more explicit in nature:
- separate out code path for state restoration and intent resolving (no
need to over-write mAction now)
- separate out code path for draft loading and source message
loading
- fixes an issue where loading a message accidentally set the draft
message instead of the source message
- makes it possible to switch reply/replyall/forward since now
processing a source message doesn't do crazy things
Bug: 4375775
Change-Id: I5b3a7ac9ed031abe88f9358df9cd46408dd1e9f9
