* No code was harmed, er, changed in the making of this CL
* All that's happened is that code that is needed by both Email and
Exchange have been moved into emailcommon
* This required import changes to many files, which explains the
length of the CL
Change-Id: I4e12455ba057a4a8054fdbd0b578c73afa411c8a
When downloading attachments in the background, do not display any errors
on the display.
NOTE: This is a partial fix for general background attachment downloading issues
bug 3373982
Change-Id: I874ed902bde293303e10308f38b992b2bb15b6aa
- Added accountId to loadAttachmentCallback/loadMessageForViewCallback
- Cleaned up LegacyListener/MessagingListener.
Removed the constructors which take messageId and attachmentId, which
are used to bridge loadAttachmentProgress, which the callsite doesn't know
these IDs. The inconsistency (only loadAttachmentProgress() uses the member
messageId) doesn't look too good, so extracted this into a separate class,
MessageRetrievalListenerBridge.
Change-Id: I46303e50df2b0e1fe8616e7c9cef632ac14f23aa
The basic failure mode is to delete an account while it is being
synced or some other background activity. The fixes in this CL will
harden against this, but it will not be a perfect solution; That
will require shutting down all sync, which is difficult in the current
too-many-threads implementation.
Primary bug# 2112564
This happens in two primary cases:
1. When a very large POP message was skipped during initial sync
2. When any message was interrupted during initial sync, e.g. by
a dropped connection.
Changes:
* Added loadMessageForView and callbacks to Controller (and touched all
files with Controller listeners)
* Rewrote loadMessageForView in legacy MessagingController to work with
provider.
* Update flow in MessageView to use loadMessageForView when needed.
* Restored the use of "loading.html" and "empty.html" assets (although
I think we should replace them with simple layouts & views.)
* Some random cleanup in MessageView
Satisfies bug # 2065563
* Finish IMAP/POP sections of Controller.sendMessage
* Rewrite MessagingController.sendPendingMessagesSynchronous
* Add deleteAllAttachmentFiles to AttachmentProvider, and unit test
* Rework sendMessage callbacks and integrate into MessageList UI
* Send pending from UI
TODO:
* Find other places from which to call deleteAllAttachmentFiles
* Handle messages >25k
* When structure is available (e.g. IMAP) pull in the entire body
and the list of attachments
* When structure is not available (e.g. POP) pull in a large chunk of
the body to try and capture the message body at least.
* Implement loadAttachment for IMAP/POP to demand download large items
* Tested with IMAP & POP messages
INCOMPLETE (file bugs):
* implement logic for the old loadMessageForView calls that comes from
MessageView (when you open a message that's partially-loaded)
* Resolve handling of mimetype when attachment info is read (currently
we're assuming base64 in a couple of places)
* delete account => delete attachments
* delete attachment => delete file
* create account => clear existing attachments for acct id
* Rewrite service logic to select and update one account at a time
* Add checkmail API to Controller, and much rework/cleanup of existing
callback API's
* Rewrite notification posting code
* Rewire connection to MessageList to be opened by notifications, to
cancel notifications, and to reset the "new message" count whenever
an account is viewed.
* Boilerplate cleanup to a lot of activities because they share the
callbacks that have had minor changes.
* Remove old push controls from Store API
In progress:
* To provide notification mechanism for EAS pushed mail
The exception was caused by removing from the HashSet (in Controller.java)
while iterating over it. The locking offered no protection in that case.
Extracted the notification of listeners (MessagingListener) in separate class
to simplify reimplementation.
Got rid of a couple of generic catch(Exception) that were hiding surprises.
Marc Blank