There is now only one LogTag class. The static initializer of
GmailApplication (existing) and EmailApplication (new) will now set
the log tag to "Gmail" and "Email", respectively. Up until that code
is run, it will be "UnifiedEmail".
"setprop log.tag.Gmail VERBOSE" (or .Email) will trigger all logs to
be printed as long as they go through LogUtils, regardless of what tag
is used by that individual log. This lets us still turn on logging
everywhere in one command, but also lets us use more descriptive tags
(like the class name).
And since we no longer have three com.android.mail.utils.LogTag
classes, builds will be much easier.
Also, we now use LogUtils everywhere.
Change-Id: I55f1c7a66ce50ead54877a13e40256422a56dc39
* Spinner onItemSelected is called prior to user input; this
reverts the port to the security-based default
Change-Id: I1cb67e519e9305ef2384b5f5f305bff1e950e7c4
We were unconditionally setting auth credentials even if the checkbox to
require credentials was unchecked. This prevented setup for certain
outgoing servers
Bug: 4291105
Change-Id: I27f94f02b85b097d2c6dbb896254367e8a15415b
* Remove per-store limitations
* Use constants for VISIBLE_WINDOW, rather than having the
potential for differences between Stores
Change-Id: Idd5e0874bba6e3390e4f093bcb03f4b1bb399c11
* Use EmailProvider to backup/restore into a backup database
* Remove all of the old AccountBackupRestore code
* Get rid of the legacy Account class and all of the Preferences
crap that referenced it
* Remove corresponding tests
Change-Id: I2de75aafdacc87246174303961e58547303f641e
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
There were two TODO's from a prior CL where deprecated HostAuth methods
were removed.
1. Do not use a generated URI to determine if account settings have changed.
Instead, use the HostAuth structure for this purpose.
2. The account key in the HostAuth structure has been deprecated. Remove as
much of it as possible (until the schema of the host auth database changes,
we must still refer to it when adding rows).
In the process, HostAuth tests were broken out into a separate unit test
file.
Change-Id: I4075da09af168f734db7b20a9ef63d4178ac2064
* There are three pieces to this CL (sorry):
1) Move and/or rename some constants into emailcommon
2) Move Utility to emailcommon, moving the few UI
related utilities back into Email (FolderProperties
and UiUtilities)
3) Remove all references to resources from emailcommon
* The three pieces relate in that, between them, they allow
the emailcommon static library to compile cleanly
Bug: 3442973
Change-Id: Ic5e3abaa2a1b36999e0b6653c6c2134ea1bd544f
* Allow, but provide warnings via EditText.setError()
* Remove one last instance of password trim()
Bug: 2981433
Change-Id: I406a4f8b8f27cc5ce90424a8cafe88a677e72f45
Signed-off-by: Andy Stadler <stadler@google.com>
When navigating away from a preferences screen and unsaved settings would be
lost, display a confirmation dialog. The user can either accept or cancel the
action. If canceling, the user is returned to the settings screen they were
currently on. Otherwise, they are taken to a new fragment (the exact
destination depends upon whether the user navigated "back" or selected another
header)
There is one additional change that needs to be made. In the case of navigating
to another header, we are notified _after_ the new header is selected. In this
scenario, the action is not cancelable and the user will lose any changes. We
must display an appropriate message when this happens. [note: this is the same
behaviour as when the user selects a breadcrumb]
bug 3327737
Change-Id: I4bd3b393a6323f3e63510e3ed08e4e1e745b04c4
* Switch to newer startPreferenceActivity API
* Newer API lets us pass a string for the breadcrumb
* Get rid of newInstance() calls in all three server settings fragments
Bug: 3188951
Change-Id: I86ae91d63ff7bd32fa0eab96ac18686bb5e3e313
* Create shared async worker to check for duplicate accounts
* Use it in AccountSetupIncomingFragment
* Use it in AccountSetupExchangeFragment
* Debounce proceed/next button because work is now async
* Also, upgrade leftover old-style code in AccountSetupOutgoingFragment
Bug: 3134666
Change-Id: I5c24a6546d1ab66aedc5c4ac826ddf4f1ff53446
* For each of incoming, outgoing, exchange fragment, create a "settings
mode" which slightly alters the layout for use in AccountSettingsXL.
* Build a settings mode wrapper layout around the basic fragment
* Add new constructor to set "settings mode" and select layout
* Add wiring for cancel/next buttons in the fragment
* AccountSettingsXL configures each fragment in its settings mode
* Remove old actionbar "Next" options (no longer needed)
TODO: Pixel perfect adjustments, colors, fonts, etc.
Bug: 3188951
Change-Id: Iba26281b214333db301dd40d6c016b6c5a932c2d
* Fix incomplete tracking of mLoaded flag
* Defer validation on automatic reload of fields (on rotation)
until reconstruction completes and we're ready to do validation.
* (For Incoming only) Split loadSettings into configure and reload phases;
We need to configure the UI every time we restart, but we don't want
to reload & overwrite user-entered values on rotation.
* (For Exchange only) Properly show/hide trust certificates options on
rotation, and show/hide divider too.
Bug: 3170922
Change-Id: If3de30ee2d4d5668b29698af73f545510692777e
* Separate/identical fixes for incoming, outgoing, exchange
* Unit tests
* Some protocols will fail anyway (e.g. POP3)
TODO: Some sort of warning (master only - won't backport that)
Bug: 2981433
Change-Id: I82984e5912fc7fcb88e747815d0fe33cb36605e7
* Activities modified to use new check-settings fragment:
* AccountSetupBasics (auto-setup for imap/pop)
* AccountSetupIncoming
* AccountSetupOutgoing
Next CL: Same work for exchange, and terminate old CheckSettings activity.
Change-Id: If5c5bfe331161b2429f7d7a4bd13290932f03c47
* Create new retained fragment + asynctask as the worker
* Stateless dialog fragments for everything else (progress & errors)
* Used for account settings, incoming & outgoing, only so far
TODO: Support for account setup workflow
TODO: Support for autodiscover workflow
TODO: Remove old checker activity when complete
Change-Id: I1fdafa1a51c53b934e59ea4af7d3e0ac24a3da17
* From account settings, switch to incoming/outgoing/eas fragments
* Show "Next" button in actionbar (may be dup'd in single-pane view)
* Common base class for in/out/eas fragments
* Depends on PreferenceActivity.startPreferenceFragment(), new API
* If the user clicks an account header while editing server settings,
present a dialog before discarding the changes that haven't been
checked yet.
* Confirm working (if a bit ungainly in appearance) on phone screen
Change-Id: I03591b9a8ffd11fe26fc6f58a5698740e61d0090
Scott Kennedy