* Just in MessageListXL for now, as with search
* This allows us to test functionality within EAS, and confirm that
it's all working w/ unbundled Exchange (API 1)
Change-Id: I4f062ae871a28d2b57a23a269d6ec65903181d26
There's no need to use a different loader ID for each mailbox. Just use
one loader ID to keep things simple.
Change-Id: I46cf0a9ad48c8e0badf72ee73e2d5edadda66912
Exchange accounts support nested folders, so, we need to use the selection
that excludes any mailboxes with IDs greater than 0. Otherwise, we see all
mailboxes on the account.
Change-Id: If8c2085458176e8bd87013e3b598bd7740c652b2
currently only really works for exchange accounts. legacy accounts (imap
or pop) do not build a folder heirarchy.
Change-Id: Idb7c622b64a599a0776233a076359869f4ab4a4f
- All layouts are still temporary, but at least they're usable now.
- Removed reply/forward button from the bottom panel.
There're buttons in the layout.
- Switched to getView().
- removed the unnecessary LinearLayout from the xlarge layout.
- removed some backgrounds that'll probably not be used.
Change-Id: I3aa27c63ab139ae30e5714ac3d9a1eadce74b0e8
The roles between MessageListXLFragmentManager and MessageListXL was confusing
and not well defined. Now, the activity (MessageListXL) is responsible for
managing the application "chrome" (such as the action bar) and
MessageListXLFragmentManager is responsible for managing the content area.
Change-Id: I9a36d962bae5263f17fc7dccf133a6711229821c
Only pass along the things we need. For the message dialog, we were passing
in an Activity that was not needed. In the ActivityHelper, we were passing
in an Activity when all we needed was a Context.
Change-Id: I9a93ae07ff2bbdce9466c7e991410c87fb610673
the callback method name was not appropriate in all situations. This has been
renamed to just "onBind()" and will still be invoked whenever data is bound to
the adapter. also, create an empty callback that can be used if the adapter
doesn't need to be informed when a bind occurs.
Change-Id: Ifaa4aea3a59734557651270330ca9439e3ea4ab4
... assuming we're going to use the holo light on the phone as well.
Now the text on MailboxList is clearly visible.
Also updated/added some comments.
Change-Id: I280db2b82cbd1627c78a305dd31bbf1b1bb34d1d
There are currently two places where we use a mailbox list -- in the main
view and in the "move to" dialog. We've replaced the single, modally
configured adapter with two specialized subclasses.
Change-Id: I5dfd5ccd435fefbab4b7647c2bd7a14818f73bf3
There are two ways globals can be specified. There can be only one global
character ['*'] and/or multiple wildcard characters ['?']. The global
will match zero or more characters. The wildcard will match any character.
bug 4090086
Change-Id: I07e3edebd1fe989094c68cf047ce5bc9fb91aba0
... for Welcome and EmailWidget. So that now it's safe for onDestroy()
to be called while a task is running. (onDestroy cancels it.)
Change-Id: I660b471465170e1d1d0ce153571fb924ae703d7d
Added two new functions:
- UiUtilities.getView()
is a fail-fast version of findViewById(). Crashes when there's no view
- setVisibilitySafe()
same as View.setVisibility, but doesn't crash even if a view doesn't exist
Let's try to avoid the use of findViewById(), and instead use getView(), *right
after* the layout is inflated, so that we'll always fail-fast if a layout
doesn't have a required view. (Rather than getting a NPE only when the view
is really accessed, which can be in a code path which is rarely executed--e.g.
only when there's a protocol error.)
Let's only use findViewById() only when we're sure no all the variants of a
layout have the view in question and leave a comment to make it clear it's on
purpose.
(UiUtilities has been moved from com.android.email to
com.android.email.activity)
Change-Id: I36e0bab65a989f5d34cf636f13e1eaee084547af
After the account is created, don't allow editing the user name. We want to
prevent this as the user name is core to the account and changing the user
name is tantamount to creating a new account.
bug 3502279
Change-Id: I1d89710fd48aca67ba13abea5bdbdc1d87941618
We now allow a single global character ['*'] to be specified somewhere in
the domain attribute. Additionally, we will replace the string "$domain"
with the matched domain in all attributes -- user name, password and URIs.
bug 4090086
Change-Id: I46a637ed364c1a079e1230fa22393a1bac059b1f
- Menu now works
- Removed a lot of unnecessary/soon-to-be-unnecessary code.
Especially,
- multi-selection panel is now replaced with CAB
- SetTitleTask will be replaced with a loader
- Removed the option menu xml for magic mailboxes
(The regular one should work for them as well)
Bug 4184142
Change-Id: I52adff6d711232d536b6f00367a240e1faeea14b
If an IMAP server supports the UIDPLUS capability, it can return the new UID
as part of the response to the "UID COPY" command. However, if the server does
not support UIDPLUS, we perform a SEARCH to try to determine the new message
UID.
This is the second of a couple modifications.
bug 4092301
Change-Id: I1f548b63becfec8733cb8ba9a3fe6ff4be6fdd83
We were always loading from the network for HTML messages. Now we don't
load from the network until the user clicks the "display images" button.
Change-Id: I1838b6cb09d49a2b521baa12a80239107391534f
When copying messages between mailboxes using standard IMAP, we must perform
a QUERY or FETCH in order to determine the new message UID. However, if the
server supports the UIDPLUS capability, the server will return the new UID
as part of the response to the "UID COPY" command.
This is the first of a couple modifications. We still need to fallback to a
less efficient QUERY/FETCH if the server does not support UIDPLUS.
bug 4092301
Change-Id: I9279f7fd70daf85adba3b3e202c12d67ddf91f22
Refactor the changes introduced in Ib02842bb.
- Now Welcome and AccountSettingsXL accept intents with URLs of the following
style, and get IDs from query params, rather than extras.
Welcome:
content://ui.email.android.com/view/mailbox?ACCOUNT_ID=1&MAILBOX_ID=2&MESSAGE_ID=3
AccountSettingsXL:
content://ui.email.android.com/settings?ACCOUNT_ID=1
- Now the "new message" and "login failed" notifications use these new style
intents, so the system wouldn't merge PendingIntents for different accounts.
Also:
- Moved all notification creation logic to NotificationController.
(Except the one in CalendarSyncEnabler; which is used only to support
upgrading from pre-froyo and I don't think it's worth refactoring.)
- Note the "password expired/expiring" and "security needed" notifications
aren't changed; they still use extras to store account IDs. This is okay
because these notifications are not per-account.
Bug 4065269
Change-Id: I70737438d2e7c45fd7488a5b0a7105c8568e02f7
We initialize the focus with setNewMessageFocus(), but it's only called
from processSourceMessage() (for EDIT_DRAFT) initFromIntent() (for other
actions, except for "new draft"). We didn't intialize the focus for new
drafts. Let's just get the To field to get the focus by default to
cover this case.
Bug 4048238
Change-Id: I50cd69b8813198c96beab2025576d390520dc6a4
Modified location of the test to processUploadMessage() method. We do this to
prevent creating multiple EmailContent.Message objects.
bug 4096266
Change-Id: Id83d3703283c0cd89a60c6210976093d39fb6934
There is an optimization to prevent re-loading server settings if they've
arlready been loaded once. However, in certain circumstances (e.g., server
setting auto discover), we want to be able to reload the server settings.
bug 4091290
Change-Id: I03c47a7fe3b45d1c581401ac891895a00315d45b
When processing message updates, we handle messages in the "sent" folder
specially. We continue to do that. However, we must also check that the
given message is still in the "sent" folder.
bug 4096266
Change-Id: Iaa47512fad287e63d8216b755a761b52b324cfff
* We needed to set DevicePolicyMnager.PASSWORD_QUALITY_COMPLEX
* Setting this, we also need to clear some of the defaults for complex
mode that are not correct for Exchange's definition of "complex".
* Unit tests
Bug: 4092218
Change-Id: Iea7bd05d48f1aa9406222c1db5937cfd7f2662b8
* Caught & diagnosed by crash while checking settings
* Also possible in MoveMessageToDialog
Bug: 3412875
Change-Id: Ie78c61cf5ca10ce1eedc25ba2eb97ed0ac5bc615
We would update the attachment buttons if the UI was becoming visible (i.e.
coming back from a settings page), but, we weren't updating them after the
attachment finished loading.
bug 4074694
Change-Id: I9d235620b5a92c2bbb871f70c9d97350cc151ce8
The attachment info may be null when we attempt to mark them for downloading.
Add a null-check before we try to dereference the info structure.
bug 4053184
Change-Id: I831e3abd100664c92f7af585014a03250e40ff64
The problem was that:
- Each account now has own new message notification
- But PendingIntens for these all point to the same activity,
only with different long extras (for acount IDs).
- Framework merges these intents, because extras don't count
as a "difference" in this case.
- So when multiple new message notifications are shown, they'll
all share the same intent internally, so they'll all open the
same account.
A quick workaround seems to be to set a unique URI to each intents.
Bug 3509555
Change-Id: Ib02842bb32634cfdf01ae2d684dd04dfede23832
* Correct allignment of mailbox label
* Sender info & presence alignment fixed
* Header height corrected
* Sender header updated; new asset for background & remove the "fold" asset
* New asset icon and allignment for "show pictures"
* Selected rows have updated background; new assets
* New asset for checked items
* Update divider to be 2px high
* Update selected background for wide message list
bug 3510984
Change-Id: I028ed5619ea7127b0392d9f5b7b00c575b00f3c6
To determine mime-types of attachments from the ACTION_SEND and _MULTIPLE intents,
- Use ContentResolver.getType() for content: URIs
- Use inferMimeType() for file: URIs
Tested with Gallary and Downloads.
Bug 3510624
Backport of Ibfa4b383463f157e18fd634e55f5be4b9adf6aa5
Change-Id: Id2815738673f3822a97e92414b84f6a5d46eb96f
To determine mime-types of attachments from the ACTION_SEND and _MULTIPLE intents,
- Use ContentResolver.getType() for content: URIs
- Use inferMimeType() for file: URIs
Tested with Gallary and Downloads.
Bug 3510624
Change-Id: Ibfa4b383463f157e18fd634e55f5be4b9adf6aa5
When replying or fowarding an HTML message, we now send both plain text and
HTML bodies as a multi-part mime message. We take special care to ensure the
message bodies are in their own multi-part block and do not interfere with
any additional attachments to the message.
bug 3060920
Backport-Of: I2fc3cb4e1f65bcc28486a62731b44b0ee0a99719
Change-Id: I89ec2795b55ceb7472a8ee3db2dc8f50cf537d9c
The new class EmailAsyncTask might look overkill, but
this is what I've been wanting for long time.
In many activities we store all AsyncTasks we start to member fields
so that we can cancel them in onDestroy(). (e.g.
MessageViewFragmentBase.mLoadMessageTask and mReloadMessageTask)
With EmailAsyncTask these fields will no longer be necessary.
We'll be able to just fire up as many AsyncTasks as we want, and clean them
up in onDestroy() with just cancellAllInterrupt().
Bug 3480136
Backport of Id8aa1ba1500eee58cfab8b562b95e9ed852b3e29
Change-Id: I2d2966ff878862a5246c031d1d4e221da5a7e81a
The new class EmailAsyncTask might look overkill, but
this is what I've been wanting for long time.
In many activities we store all AsyncTasks we start to member fields
so that we can cancel them in onDestroy(). (e.g.
MessageViewFragmentBase.mLoadMessageTask and mReloadMessageTask)
With EmailAsyncTask these fields will no longer be necessary.
We'll be able to just fire up as many AsyncTasks as we want, and clean them
up in onDestroy() with just cancellAllInterrupt().
Bug 3480136
Change-Id: Id8aa1ba1500eee58cfab8b562b95e9ed852b3e29
When replying or fowarding an HTML message, we now send both plain text and
HTML bodies as a multi-part mime message. We take special care to ensure the
message bodies are in their own multi-part block and do not interfere with
any additional attachments to the message.
bug 3060920
Change-Id: I2fc3cb4e1f65bcc28486a62731b44b0ee0a99719
* This is is a minimal implementation that only supports the external
encryption policy when there is no physical/removable storage, and
the emulated external storage is located within an encrypted backing
store.
Bug: 3351426
Change-Id: Id96e9277f810beeebf816a914acd3d733eb713ea
If the account supports smart-forward. The old code assumed
attachments are not removable if the account supports smart-forward,
which is not true. Locally-added attachments should still be removable.
Bug 3505684
Change-Id: Ie6703551800c617dd224957a098311f0c279b3f1
The problem was:
- MessageFileViewFragment.clearContent (A) is called in onDestroy
- MessageFileViewFragment.openMessageSync (B) is called in a bg thread
to load an eml file
- And both try to hold the same lock. (mLock)
- If EML is large enough, B takes _seconds_. If you press back during this,
onDestroy gets blocked trying to lock mLock.
- This could also cause a crash, because the task that runs openMessageSync
won't get cancelled in this case, because that's done in clearContent.
Because of this, the task's onPostExecute tries to touch a UI element
when the fragment is actually being destroyed.
The lock was introduced to protect mFileEmailUri, only to keep the same
semantics for openMessage() as MessageViewFragment. i.e. openMessage can be
called multiple times for the same instance of the fragment.
However, in practice, this won't happen. Unlike the regular message view,
we never reuse MessageFileViewFragment. MessageFileViewFragment instances
are created per message. This lock was just reminiscence from the early
developmen stage.
So, fix is simple -- just remove the lock.
Bug 3500487
Change-Id: If2b22a683666de535454bb1293563796fa7acfd7
For now it only enables it for the main process. I've added a flag
to EmailServiceProxy for EAS, but it's not used in the exchange side.
Bug 3500292
Change-Id: I5b27c69fe7cc995a430e9def54b2463076032c78
