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
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
Todd Kennedy