Do all the clean-up stuff in onDestroyView() rather than onDestroy(),
so that no callbacks (such as the controller callbacks and
AsyncTask.onPostExecute()s) will work when it doesn't have views.
Change-Id: Ic4aa771d28209ee7b56ac4d228488768ae998dd8
All shortcuts now have a mailbox associated with them. When launching
the app via shortcut, we want to show the messages within that mailbox, but,
we do not want to navigate into the mailbox; unless the mailbox has children.
Since we don't want to put too much informatin into the shortcut, we must
perform these checks at runtime. So, if ever we try to load a mailbox that
doesn't contain children, we load it's parent instead.
Change-Id: Idb5dbc7cd740b270a0068811abe685f963ca2c0b
- Added more lifecycle logs to understand fragment lifecycle better.
- Made sure all code work fine even in the state where a MailboxListFragment
is create but doesn't have views.
- Cleaned up list state resoration code.
Removed the setListAdapter call from onLoadFinished, which lets the
ListView restore the state by itself, in the case where we're re-loading
list for DB changes. We still need to do the restoration manually for
the orientation change case.
Change-Id: I96bff4ace6d48cc02113c2f5bd6a995260122334
This is a cherry-pick of f872876699 :
- Use new recommended sw600dp instead of w600dp to avoid having the
"personality" change on configuration change
- remove the use of xlarge/large for specializing values since the
framework team discourages any use of the buckets (and have also changed
the ordering so that they take lower priority)
Change-Id: I645bfb7cddcda8b53569af927f6fa23180e73e1f
- Also removed the accoundId parameter, which wasn't used.
- Also cleaned up MailboxListFragment.onDrop.
(the restored Message was only used to get the account id, but
it's no longer needed.)
Bug 4384642
Change-Id: I8f6635011dae0529a82972617101e1c130090b76
This is a cherry-pick of 9f976e29a0 from
honeycomb-mr2. This is still using the old w600 qualifiers but the next
CL will cherry-pick the fix for that.
Change-Id: I40ab6717575cdfd02d5f7d05409f0355e96f2085
After choosing the account, we need to select a mailbox for the shortcut.
In order to replace the fragment, we cannot hardcode it in the XML. Instead,
we need to dynamically create it.
Also, restructure the fragment class and rely on the class to "do the right
thing"
Change-Id: I752ad5bbdf2484332ec2b73852cae74a5d2092fa
- Renamed some methods in MessageViewFragmentBase.Callback
- Removed unnecessary argument from a callback.
- Removed obsolete comment.
Change-Id: Ia5af222971bfe6b943c98208b539946f14f16aa8
The list used to contain both the display name (whatever special name the user
chose during account creation) and the email address. The new mocks only use
the display name.
Change-Id: I97f4f16af9865207f26e67aed5d07340775ea37c
instead of using an activity (which will be hard to manage multiple screens in
the 'back' stack), use a fragment. we can easily manage multiple fragments with
a fragment transaction.
Change-Id: Ibf75dd45941a0c1c6b6b6add8de78146cdae7c65
* Since DPM can erroneously report a password failure (specifically,
isActivePasswordSufficient() can return false when, in fact, the
active password is just fine)
* This is the proximate cause of the referenced bug; we just weren't
prepared to have the DPM mislead us...
Bug: 4464610
Change-Id: Ifcb85c0729e9a1884fbcf7b4180eb332bbfef1b5
- Use new recommended sw600dp instead of w600dp to avoid having the
"personality" change on configuration change
- remove the use of xlarge/large for specializing values since the
framework team discourages any use of the buckets (and have also changed
the ordering so that they take lower priority)
Change-Id: Ia6943af9207471b801ce79435ffe9d730b6786b7
This was causing a crash in settings when opening an incoming settings
fragment after initial setup.
Change-Id: Icedd24a3f5e8f378d6725a09c97525450ef74af7
