This activity already supports phone and tablet mode.
Only renames in this change - no other change.
Change-Id: Ieca17137af45e3860812091f69cd4d9b55ddf3ec
Since the notification controller now operates exclusively using database
observers, there's no reason for the exchange service to call the
notifyNewMessages() service API.
Change-Id: Iaa7e2f5eae786162eab23b02b03ce6d1e8a738e9
If there is only one unread&unseen message in the notification, clicking the
notification will automatically open the message view fragment. Otherwise,
the message list fragment will be opened.
Change-Id: I22778258836a36f289d71b99a6214ec82778f385
We will suspend notifications whenever we display the message list for an
account (including "combined inbox"). As soon as the message list is paused,
notifications will be resumed.
Change-Id: I481a0f59ce68f89c32210d862d0267f3f334063b
* This is a serious bug dating back to the first Honeycomb release
* It was possible that a newly created Message could not yet be
committed to the database when the AttachmentDownloadService
tries to download one of that message's attachments.
* ADS, when it sees that the message (apparently) doesn't
exist, deletes the Attachment (it appears to be orphaned)
* The effect is that the user never sees one of the attachments
in a message.
* This bug has been reported externally
* The fix is simply to check for the message's existence before
deciding to delete it (this check will always work properly)
Bug: 4409692
Change-Id: I106ed2fe88d2435ad7a462fced5cb307c2559fd6
The notification controller now observes changes to the account database and
adds or removes message observers as appropriate.
Change-Id: I1670fcfd6ce744030199b86708a6ada55b239a84
The primary purpose of this CL is to remove phone activities, so the
one pane implementation is very much temporary and primitive, but it
should offer minimal operations.
Change-Id: If57f81db7c605c95664d49044a5cc082beda59c0
We can remove the preferences stuff 'cuz the service "should be" longer
living. And, even if the service is terminated (either by the user or by
the system) we'll receive a new notification when the service comes back.
This is probably desired behaviour anyway.
Change-Id: I4850a9473401536e8fb20385b780d4736ce80a8e
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
