- Don't show the progress icon unless loading from network
- Don't show the content until LoadAttachmentsTask finishes
- Disable the fade-in animation. It causes some weird positioning issue
with the GL accelerated webview.
- Use WebView.clearView() to clear its content.
- Use the "normal" layout mode, otherwise WebView won't use its entire
width
- Don't hide the vertical scrollbar
Bug 3287729
Bug 3225068
Bug 3295761
Bug 3304396
Change-Id: Ic4b8baac99b71dc0da58021849ff7c1dbd6dbe55
This should fix the "attempt to re-open an already-closed object" exception
from SQLite.
(destroy()s don't have @Override becuase the base method is now depricated
and will be removed someday.)
Bug 3288666
Change-Id: I4780f6c8d89c7204b266608462c0833ad5af4e5f
Sorry it is a bit ugly, it is to allow this change to be
checked in prior to the first stage of the framework change
without breaking the build.
Change-Id: I1828579019ac0325d19c070a4c62cd79549e7d51
* Copies the icon from contacts
* Used whenever the sender doesn't have a local photo
* Used in notifications and in messageview
Bug: 3282187 (notification)
Bug: 3285156 (memory leak from the placeholder graphic)
Change-Id: I528cae20355aa8cce7be37b26f32aa90e092708b
- 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
- Fix the XL layout: Don't refer to "GONE" views in RelativeLayout.
- Don't always (re-)load message on onResume().
This will make it lose all state (e.g. webview's zoom level) when coming
back from other activities.
- Change the default visibility of some views so that it'll look okay
while loading the message.
- Remove the use of obsolete fragment APIs.
- And some other minor cleanups...
Bug 3221066
Change-Id: I475bc229f4ea9e0e480f528389f5180e1d63fcd6
Call clearContent() in onDestroy(), instead of cancelAllTasks().
(This is what I thought I was doing.)
Calling clearContent() tells the BG thread that the activity has already
been destroyed, and prevents them from loading a message.
Also as a precaution, don't load a message if getActivity() returns null,
which means the activity has already been destroyed.
Bug 3134403
Change-Id: I0d591e0dd147f73e70b0c027dc8037482197f7b4
- We used to (re-)load the content on every onStart(),
which is called too when coming back from other actibities.
So if you go home and come back with the task switcher,
all state get reset, including webview zoom/pan and the current tab.
- Introduce a new flag, mLoadWhenResumed, to tell if we really need to
load a message.
Also:
- Start loading a message in onResume() rather than onStart()
to keep it consistent with other fragments.
Bug 3215269
Change-Id: I1cc6e12c3cc3c08065da3696603a3247f341469a
- Show sender email address
- Show BCC for sent messages
- Don't show the default quick contact badge frame.
(change QuickContact to ImageView)
Bug 1501239
Bug 3138021
Change-Id: I0e8d91ad3a6a3a021c8aff0945a1ce11d13b2728
* Add preference for default text size
* Move saveSettings logic into onPreferenceChange handler
* Per user tests, default setting is large (not "normal") for XL devices.
* Use setting in MessageView's WebView
TODO: Investigate zooming header (to/from/subject/etc) as well.
Bug: 2282390
Change-Id: If32ed3626244b046941a461f974b3dbdb535f592
The problem is that ths method is called in a worker thread, so
there's nothing to prevent it from running just after/at the same
time as clearContent() (which sets -1 to mMessageIdToOpen).
If it does, it passes -1 to restoreMessageWithId() and crashes.
Also removed a half-obsolete comment which is a bit too obvious for its length.
Bug 3077387
Change-Id: I736d696046e6d8964a16c80515544c582aca3943
The method to start ReloadMessageTask() when detecting content
changed events is delay-called, so need to make sure the fragment
is still in the valid state.
Bug 3069896
Change-Id: I1991d902e8044b4f8ca3ffd7d3e2e66005f1e960
Added "tabs" to the message view according to the latset mock.
This removes the necessity of putting a WebView inside a ScrollView,
which caused the infinitely-growing email bug (issue 6882).
Right now the tabs are actually just Buttons. Complete visual refresh
should follow it.
http://code.google.com/p/android/issues/detail?id=6882
Bug 2349275
Change-Id: I897a3a32e0dd7a90d637ac5ea1d47e5e65a1eabe
Now MessageViewFragment detects changes made to the current message,
and update the UI.
(Although it doesn't really know if the message is really changed, or just
something else was changed in the DB. It updates the header regardless.)
Change-Id: I35627c7aff129723b83605fc84521da907078571
- Now we declare all fragments in the layouts.
- Added clearContent() to MessageList/MessageView to keep them calm when not
used. (e.g. MessageView.clearContent() will be called when closing message
view and going back to the mailbox list+message list screen.)
- Some of the processes have moved from onStop to onPause.
- Now that we don't use the fragment transaction, the "restored fragments"
has been removed, and the separation between selectXxx() methods and
updateXxx() methods are gone.
Bug 3045555
Bug 3041502
Change-Id: I958897a8a38bccea1dfed7cfcd900e6dd52d2eed
* assignContactFromEmail("") was causing the following exception on logcat.
"java.lang.IllegalArgumentException: URI: content://com.android.contacts/data/emails/lookup/,"
* This method is to set the contact to open when the badge is tapped,
but we trigger quick contact by ourselves, so don't have to do call this.
Bug 3013527
Change-Id: I16e1573bd82ffe5c39d30b69361354010f508f91
In message view mode, show MessageListFragment on the left pane.
TODO: Highlight opened message on message list
TODO: If the opened message is moved/deleted/starred/etc, update
message view
TODO: Collapsible left pane on portrait
Change-Id: I9b26f7291648da0e08bc526b79305ab65ce4d926
Create a custom view containing the bottons below MVF
(delete, move, reply, etc) and let MVF own this.
These buttons used to be owned by the XL activity itself, because
the UI for these commands will most likely be totally different
from the tablet UI, so the fragment having them looked wrong.
However, this made it harder to make changes suggested by the latest
mock, such as "put reply/forward in the message header".
I think the buttons are semantically part of the message view anyway,
so the fragment owning UI for these commands is probably the way to go.
(And let's worry about the phone UI later.)
Reason for the use of a custom view is that it will make it easier
to make non-trivial UI changes, e.g. "combine reply, reply-all and
forward and make it dropdown."
Also removed obsolete TODOs from MessageListXL.
Change-Id: Ibf93f4c70fe07bdbbe33d2adb6bbd2b96812830d
- Added "quick contact badge" to MessageView
- Removed PresenceUpdater, and added new implementation based
on Loader, which is much simpler.
- Changed some text color, so they're visible now.
Bug 2988625
Change-Id: I688a3217178ee8fd0b7245c0ab36a633687ea525
* Now the message shown/gone callbacks are called directly by
MessageViewFragment, rather than MessageListXLFragmentManager.
* The buttons are enabled/disabled per messages, so it even works
properly when you move around in All Starred. (if you ever star
trashed messages.)
* Fixed one-pane as well.
Bug 2968810
Change-Id: Ie6de1dc7ea0bd18c40c091a6685629c26ffb7110
Because "move" and "delete" are asynchronous operations, Message.mMailboxKey
can change any time. We can't use stored values.
(Fortunately it was used at only one place, and this was actually unused.)
Change-Id: Idc1300a00122fe0e6372b0374cddc98aa54a47fc
* Create AttachmentDownloadService to manage all attachment downloads
1) User requested
2) Required for email forwarding
3) Opportunistic downloads to enhance offline use
* New attachment related UI (pending UX approval, of course)
1) MessageView (attachment actions, progress bar, etc.)
2) MessageCompose (attachments for forwarded messages)
3) Associated toasts, notifications, etc.
TODO:
* Unit tests
* Cache Management (separate CL)
Change-Id: I7864a5fb1c3f4f2be68d98341a971edc6cbacfe1
Added RefreshManager, which is responsible for getting refresh requests
from UI and keeping track of what is being refreshed.
Conceptually it's a part of Controller, but extracted for easier testing.
- Now sendPendingMessagesForAllAccounts() is owned by RefreshManager
rather than Controller.
- Also updateMailboxRefreshTime/mailboxRequiresRefresh have been moved
in from the Email class.
- Now MessagingException implements a method to return an error message
for the UI.
The refresh button on 2-pane doesn't work as intended yet, because the
spec is a bit too complicated (as described in the TODO in
MessageListXLFragmentManager.onRefhres()).
This change touches many file mostly because it cleans up a lot
of code duplication.
Change-Id: I058ab745ccff10f6e574f6ec4569c84ac4a3e10e
doInBackground() returned a string[] when error, but onPostExecute() expects
null.
Also added isCancelled() check, just in case.
Bug 2918930
Change-Id: Ie87ff2e2e5b7c3fd77a062944759d03f8f09d3d9
Break MessageViewFragment up into two fragments, MessageViewFragment, which
is used to show regular messages, and MessageFileViewFragment, which shows
EML messages. (And their base class, MessageViewFragmentBase.)
MessageViewFragmentBase's javadoc has a class diagram.
MessageViewFragment is actually named MessageViewFragment2 at this point
so that GIT correctly finds out the rename from MessageViewFragment to
MessageViewFragmentBase. I'll rename it back in a following CL.
Also added very basic unit tests for MessageView and MessageFileView.
At this point, they just make sure the activities really open and show
messages without exceptions.
I feel like the current naming schema for the activities/fragments is
kinda confusing. Let me know if you come up with better names.
Change-Id: Iff948f4b68cfdb7c1e68f225927b0ce58d34766b
Makoto Onuki