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
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
* 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
* Replace crazy (and soon to be "full") bit fields stored in an account's
securityFlags with a row in a newly created Policy table (thus, fully
expandable)
* Update code from database version 17 to 18; adds Policy table, a
policyKey row in Account, and a revised trigger that deletes Policy
information for deleted Accounts
* Update old PolicySet unit tests to work against the new Policy class
* Add test for the conversion of securityFlags to Policy
* Tested in a variety of scenarios; appears to be functionally equivalent
Change-Id: I1505ee75230d6a0d3c2b62a46326f39c2c7f9eb5
- "save draft" no longer closes the message
- ensure consistent state if there are successive saves
- misc changes to the way a message is loaded if there is a pending save
Bug: 3072398
Change-Id: I9cd01319772293e4d410020ab27603821a95ec9f
This is a simple change to move +cc/bcc and +attachment action buttons
from the options menu to the visible UI (like honeycomb).
No attempt was made at styling the actual fields yet.
Change-Id: Ia1de8dbcf5e9ec9f7d3be3787cab657a2df72d70
* javadoc methods
* rename some methods
* remove duplicate code; now new message and other account notifications
are created with the same code
Change-Id: Iecf70494b6407a9a73380de103390a59d006191b
- Now all the UI stuff is owned by the UI controller
- Except temporary UI (exchange search and per-mailbox-settings)
- Except error banner
This should be moved too eventually, but I consider it as a low-priority.
I'll leave it as-is for the time being.
- Moved RefreshTask too. The spec for refresh has dependency to the UI.
(i.e. implicit refresh of the mailbox list may not be necessary for
the phone.)
Also renamed the main activity to EmailActivity.
Change-Id: I00585856bdacf69aa4e104178a5cf7352ff6d592
I don't know what I was thinking when I added them to ActivityHelper,
but DialogFragments have their own loader managers (because they're
really fragments), so loader IDs in it won't conflict with anything.
This class used to use (mistakenly) host activity's laoder manager,
which was probably the reason for my confusion.
Change-Id: I7cd4d08b77ce8ea74fbf13b3273692da791ed23e
It's a redo of changes made to MessageListXLFragmentManager on If4048d45.
It's a gerrit bug -- if you rename a file which has been changed in another CL,
gerrit allows you to submit it without rebasing it.
Change-Id: I1a9741befd1a4c2e74ce7afffca976b98e82a357
- Renamed XLFragmentManager to UIControllerTwoPane
- Moved UI code from the activity to UIControllerTwoPane
- Bunch of clean-ups (Mostly renames to make things self-descriptive)
- Removed unused class MessageListFragment.State
- Fix bug 4341563
Change-Id: Ia2230bd5ec501fbc5c92b07b2ba874153b577a39
- Now we always use a fragment as a callback, rather than assuming the parent
activity implements it.
- Use a generics trick to make sure the callback fragments really implements
Callback.
(Might be abuse of a language feature, but it's at least safer than runtime
check...)
Bug 4314669
Bug 4345496
Change-Id: If4048d456b298784097e202cffab170177ac7b2d
not making any real code changes:
* removed deprecated, unused methods
* remove 'throws' clauses when that exception is never thrown
* renamed method Controller#moveMessage()-->moveMessages()
Change-Id: Ifd006f760f0c19283e94a11a45c71295c8da35f7
For EAS accounts, we use the displayName column to populate the dialog. For all
other accounts, we use the serverId column. This means we will continue to not
have a fully-qualified pathname in the move-to dialog for EAS accounts.
Change-Id: I6dda89e037b0910180bee93a5bc091d65d2614b0
For IMAP, it's possible for a mailbox to exist on the server, but, to be
unselectable. Previously, these folders were never added to the folder list.
However, with nested folder support, we need to have these folders in the
UX so the user can get to its sub-folders (which may be selectable).
Change-Id: I11135fafbb14b40660983804fb86bd223e180d5e
With the recent changes to hierarchical folders, the move-to dialog is
quite unusable if you have multiple child folders with the same name.
While waiting for UX to decide on the exact display, make a few quick
changes to display the fully-qualified pathname instead of just the
child folder name.
Change-Id: Id5c1cc98364fbf7a82a05ac30e944507c7d16320
Create a new instance of the mailbox list fragment when navigating through
nested folders. (drill-in / going back to the root mailboxes.)
Also the fragment manager now has two public methdos for navigation that
are called by the activity. They will be the common interface for
the tablet UI manager (i.e. MessageListXLFragmentManager) and the
phone UI manager.
- openAccount(accountId)
Open the default view for the account. Used when switching accounts.
- open(long accountId, long mailboxId, long messageId)
Opne a particular view. Used when, for example, opening a message from the
widget.
Known issue:
- This breaks drag&drop through nested folder navigation.
This is because a new mailbox list fragment created during D&D doesn't
get the "drag started" event.
Change-Id: I69c14b71b4f681f8ab57f3ddd2cff9744a832076
We now create folder hierarcies for IMAP. This also includes a nifty SQL
statement that will get your existing database into shape.
Change-Id: If07a0632e9b250cf0c33c3e16bfba5816beab94c
