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
Modified location of the test to processUploadMessage() method. We do this to
prevent creating multiple EmailContent.Message objects.
Bug: 4096266
Backport from: Id83d3703283c0cd89a60c6210976093d39fb6934
Change-Id: Ie0e9c52182df96617cc942235135ef5ccf865d41
* This fix may resolve the bugs referenced below; the issue fixed
could cause pandemonium after the server commands a wipe of calendar
data and most likely explains these issues (via Occam's Razor)
* Also backport a SQL fix to more reliably delete calendar data
Bug: 4077499
Bug: 4064237
Backport from: I628fb14ea2c04150d4f27341751f0eab61ee33d1
Change-Id: I7667a11663d8720a92b9eba0748f60256a25edba
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
Backport of: I831e3abd100664c92f7af585014a03250e40ff64
Change-Id: Iffdf8cdc3a17c0ab691596eb9e240ef87acb2e37
On exchange servers that support "smart reply", the original message is
actually appended by the server. In this situation, we should not append
the original HTML text on the client.
bug 4177192
Change-Id: I0bdb34cf837e0cc0bfac8917f993ecb764814d97
* This happens if an open fails immediately (error message in the
initial banner) followed by a checkSettings.
* The fix is to harden checkSettings to force a clean connection
every time.
Bug: 2170147
Backport of: If7403bf517477d2b03b21d71caab511fe45e234c
Change-Id: Ia6cc0e3ab0c8a8a78b5d8b8fb7b8ba4b4cdd3ef2
On exchange servers that support "smart reply", the original message is
actually appended by the server. In this situation, we should not append
the original HTML text on the client.
but 4177192
Change-Id: I6fad74ac761e2abfe7cb0f536df4db30f7d5ca9a
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: I4cdfea5e5338f3bba70b3d04df6551516d3e1a85
