Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2010 The Android Open Source Project
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
package com.android.email.activity;
|
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
import com.android.email.Clock;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
import com.android.email.Email;
|
2011-04-01 18:34:03 +00:00
|
|
|
import com.android.email.Preferences;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
import com.android.email.R;
|
2011-04-26 17:28:18 +00:00
|
|
|
import com.android.email.RefreshManager;
|
|
|
|
import com.android.email.activity.setup.AccountSecurity;
|
2011-04-28 00:55:13 +00:00
|
|
|
import com.android.email.activity.setup.AccountSettingsXL;
|
2011-02-11 23:05:17 +00:00
|
|
|
import com.android.emailcommon.Logging;
|
2011-02-10 18:26:56 +00:00
|
|
|
import com.android.emailcommon.provider.EmailContent.Account;
|
|
|
|
import com.android.emailcommon.provider.EmailContent.Mailbox;
|
2011-04-28 00:55:13 +00:00
|
|
|
import com.android.emailcommon.utility.EmailAsyncTask;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2010-11-12 00:28:21 +00:00
|
|
|
import android.app.ActionBar;
|
2011-04-19 21:06:03 +00:00
|
|
|
import android.app.Fragment;
|
2010-08-16 18:00:53 +00:00
|
|
|
import android.app.FragmentManager;
|
2011-04-19 21:06:03 +00:00
|
|
|
import android.app.FragmentTransaction;
|
2011-04-28 00:55:13 +00:00
|
|
|
import android.app.LoaderManager.LoaderCallbacks;
|
|
|
|
import android.content.Context;
|
|
|
|
import android.content.Loader;
|
|
|
|
import android.database.Cursor;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
import android.os.Bundle;
|
|
|
|
import android.util.Log;
|
2011-04-26 17:28:18 +00:00
|
|
|
import android.view.LayoutInflater;
|
2011-04-28 00:55:13 +00:00
|
|
|
import android.view.Menu;
|
|
|
|
import android.view.MenuInflater;
|
|
|
|
import android.view.MenuItem;
|
2010-09-21 22:36:23 +00:00
|
|
|
import android.view.View;
|
2011-04-26 17:28:18 +00:00
|
|
|
import android.widget.TextView;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
|
|
|
import java.security.InvalidParameterException;
|
2011-04-19 21:06:03 +00:00
|
|
|
import java.util.ArrayList;
|
2011-04-13 18:30:56 +00:00
|
|
|
import java.util.Set;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
|
|
|
/**
|
2011-04-28 00:55:13 +00:00
|
|
|
* UI Controller for x-large devices. Supports a multi-pane layout.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*
|
2011-04-19 21:06:03 +00:00
|
|
|
* Note: Always use {@link #commitFragmentTransaction} to commit fragment transactions. Currently
|
|
|
|
* we use synchronous transactions only, but we may want to switch back to asynchronous later.
|
|
|
|
*
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
* TODO: Test it. It's testable if we implement MockFragmentTransaction, which may be too early
|
|
|
|
* to do so at this point. (API may not be stable enough yet.)
|
2011-04-01 18:34:03 +00:00
|
|
|
*
|
2011-04-28 00:55:13 +00:00
|
|
|
* TODO Consider extracting out a separate class to manage the action bar
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-26 17:28:18 +00:00
|
|
|
class UIControllerTwoPane implements
|
2011-04-01 18:34:03 +00:00
|
|
|
MailboxFinder.Callback,
|
|
|
|
ThreePaneLayout.Callback,
|
|
|
|
MailboxListFragment.Callback,
|
|
|
|
MessageListFragment.Callback,
|
|
|
|
MessageViewFragment.Callback {
|
2011-04-28 00:55:13 +00:00
|
|
|
private static final String BUNDLE_KEY_ACCOUNT_ID = "UIControllerTwoPane.state.account_id";
|
|
|
|
private static final String BUNDLE_KEY_MAILBOX_ID = "UIControllerTwoPane.state.mailbox_id";
|
|
|
|
private static final String BUNDLE_KEY_MESSAGE_ID = "UIControllerTwoPane.state.message_id";
|
|
|
|
|
|
|
|
/* package */ static final int MAILBOX_REFRESH_MIN_INTERVAL = 30 * 1000; // in milliseconds
|
|
|
|
/* package */ static final int INBOX_AUTO_REFRESH_MIN_INTERVAL = 10 * 1000; // in milliseconds
|
|
|
|
|
|
|
|
private static final int LOADER_ID_ACCOUNT_LIST
|
|
|
|
= EmailActivity.UI_CONTROLLER_LOADER_ID_BASE + 0;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/** No account selected */
|
|
|
|
static final long NO_ACCOUNT = -1;
|
|
|
|
/** No mailbox selected */
|
|
|
|
static final long NO_MAILBOX = -1;
|
|
|
|
/** No message selected */
|
|
|
|
static final long NO_MESSAGE = -1;
|
|
|
|
/** Current account id */
|
|
|
|
private long mAccountId = NO_ACCOUNT;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/** Current mailbox id */
|
|
|
|
private long mMailboxId = NO_MAILBOX;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/** Current message id */
|
|
|
|
private long mMessageId = NO_MESSAGE;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
// Action bar
|
2011-04-26 17:28:18 +00:00
|
|
|
private ActionBar mActionBar;
|
2011-04-28 00:55:13 +00:00
|
|
|
private AccountSelectorAdapter mAccountsSelectorAdapter;
|
|
|
|
private final ActionBarNavigationCallback mActionBarNavigationCallback =
|
|
|
|
new ActionBarNavigationCallback();
|
2011-04-26 17:28:18 +00:00
|
|
|
private View mActionBarMailboxNameView;
|
|
|
|
private TextView mActionBarMailboxName;
|
|
|
|
private TextView mActionBarUnreadCount;
|
2011-04-28 00:55:13 +00:00
|
|
|
|
|
|
|
// Other UI elements
|
2010-09-24 00:10:46 +00:00
|
|
|
private ThreePaneLayout mThreePane;
|
2010-09-21 22:36:23 +00:00
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
/**
|
|
|
|
* Fragments that are installed.
|
|
|
|
*
|
|
|
|
* A fragment is installed when:
|
|
|
|
* - it is attached to the activity
|
|
|
|
* - the parent activity is created
|
|
|
|
* - and it is not scheduled to be removed.
|
|
|
|
*
|
|
|
|
* We set callbacks to fragments only when they are installed.
|
|
|
|
*/
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private MailboxListFragment mMailboxListFragment;
|
|
|
|
private MessageListFragment mMessageListFragment;
|
2010-07-30 22:41:40 +00:00
|
|
|
private MessageViewFragment mMessageViewFragment;
|
2011-04-19 21:06:03 +00:00
|
|
|
|
2011-01-11 22:36:00 +00:00
|
|
|
private MessageCommandButtonView mMessageCommandButtons;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2010-08-04 23:23:26 +00:00
|
|
|
private MailboxFinder mMailboxFinder;
|
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
private final RefreshManager mRefreshManager;
|
2011-04-28 19:02:09 +00:00
|
|
|
private final RefreshListener mRefreshListener = new RefreshListener();
|
2011-04-01 18:34:03 +00:00
|
|
|
private MessageOrderManager mOrderManager;
|
|
|
|
private final MessageOrderManagerCallback mMessageOrderManagerCallback =
|
|
|
|
new MessageOrderManagerCallback();
|
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
/**
|
|
|
|
* List of fragments that are restored by the framework while the activity is being re-created
|
|
|
|
* for configuration changes (e.g. screen rotation). We'll install them later when the activity
|
2011-04-26 17:28:18 +00:00
|
|
|
* is created in {@link #installRestoredFragments()}.
|
2011-04-19 21:06:03 +00:00
|
|
|
*/
|
|
|
|
private final ArrayList<Fragment> mRestoredFragments = new ArrayList<Fragment>();
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
/**
|
2011-04-26 17:28:18 +00:00
|
|
|
* Whether fragment installation should be hold.
|
|
|
|
* We hold installing fragments until {@link #installRestoredFragments()} is called.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-26 17:28:18 +00:00
|
|
|
private boolean mHoldFragmentInstallation = true;
|
2010-09-21 22:36:23 +00:00
|
|
|
|
2011-04-26 17:28:18 +00:00
|
|
|
/** The owner activity */
|
2011-04-28 00:55:13 +00:00
|
|
|
private final EmailActivity mActivity;
|
|
|
|
|
|
|
|
private final EmailAsyncTask.Tracker mTaskTracker = new EmailAsyncTask.Tracker();
|
2011-01-11 22:36:00 +00:00
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
public UIControllerTwoPane(EmailActivity activity) {
|
2011-04-01 18:34:03 +00:00
|
|
|
mActivity = activity;
|
2011-04-26 17:28:18 +00:00
|
|
|
mRefreshManager = RefreshManager.getInstance(mActivity);
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
2011-01-11 22:36:00 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
// MailboxFinder$Callback
|
|
|
|
@Override
|
|
|
|
public void onAccountNotFound() {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " onAccountNotFound()");
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
// Shouldn't happen
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
@Override
|
|
|
|
public void onAccountSecurityHold(long accountId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " onAccountSecurityHold()");
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
2011-04-26 17:28:18 +00:00
|
|
|
mActivity.startActivity(AccountSecurity.actionUpdateSecurityIntent(mActivity, accountId,
|
|
|
|
true));
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
@Override
|
|
|
|
public void onMailboxFound(long accountId, long mailboxId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " onMailboxFound()");
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageList(mailboxId, true, true);
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMailboxNotFound(long accountId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " onMailboxNotFound()");
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
2011-04-18 16:48:58 +00:00
|
|
|
// TODO: handle more gracefully.
|
|
|
|
Log.e(Logging.LOG_TAG, "unable to find mailbox for account " + accountId);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMailboxNotFound() {
|
|
|
|
// TODO: handle more gracefully.
|
|
|
|
Log.e(Logging.LOG_TAG, "unable to find mailbox");
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// ThreePaneLayoutCallback
|
|
|
|
@Override
|
|
|
|
public void onVisiblePanesChanged(int previousVisiblePanes) {
|
2011-04-26 17:28:18 +00:00
|
|
|
|
|
|
|
updateActionBar();
|
|
|
|
|
|
|
|
// If the right pane is gone, remove the message view.
|
2011-04-01 18:34:03 +00:00
|
|
|
final int visiblePanes = mThreePane.getVisiblePanes();
|
|
|
|
if (((visiblePanes & ThreePaneLayout.PANE_RIGHT) == 0) &&
|
|
|
|
((previousVisiblePanes & ThreePaneLayout.PANE_RIGHT) != 0)) {
|
|
|
|
// Message view just got hidden
|
2011-04-07 17:48:10 +00:00
|
|
|
mMessageId = NO_MESSAGE;
|
2011-04-19 21:06:03 +00:00
|
|
|
if (mMessageListFragment != null) {
|
|
|
|
mMessageListFragment.setSelectedMessage(NO_MESSAGE);
|
|
|
|
}
|
|
|
|
uninstallMessageViewFragment(mActivity.getFragmentManager().beginTransaction())
|
|
|
|
.commit();
|
|
|
|
}
|
2011-04-26 17:28:18 +00:00
|
|
|
// Disable CAB when the message list is not visible.
|
2011-04-19 21:06:03 +00:00
|
|
|
if (mMessageListFragment != null) {
|
2011-04-26 17:28:18 +00:00
|
|
|
mMessageListFragment.onHidden((visiblePanes & ThreePaneLayout.PANE_MIDDLE) == 0);
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-26 17:28:18 +00:00
|
|
|
/**
|
|
|
|
* Update the action bar according to the current state.
|
|
|
|
*
|
|
|
|
* - Show/hide the "back" button next to the "Home" icon.
|
|
|
|
* - Show/hide the current mailbox name.
|
|
|
|
*/
|
|
|
|
private void updateActionBar() {
|
|
|
|
final int visiblePanes = mThreePane.getVisiblePanes();
|
|
|
|
|
|
|
|
// If the left pane (mailbox list pane) is hidden, the back action on action bar will be
|
|
|
|
// enabled, and we also show the current mailbox name.
|
|
|
|
final boolean leftPaneHidden = ((visiblePanes & ThreePaneLayout.PANE_LEFT) == 0);
|
|
|
|
mActionBar.setDisplayOptions(leftPaneHidden ? ActionBar.DISPLAY_HOME_AS_UP : 0,
|
|
|
|
ActionBar.DISPLAY_HOME_AS_UP);
|
|
|
|
mActionBarMailboxNameView.setVisibility(leftPaneHidden ? View.VISIBLE : View.GONE);
|
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
// MailboxListFragment$Callback
|
|
|
|
@Override
|
2011-04-21 18:50:22 +00:00
|
|
|
public void onMailboxSelected(long accountId, long mailboxId, boolean navigate,
|
|
|
|
boolean dragDrop) {
|
|
|
|
if (dragDrop) {
|
|
|
|
// We don't want to change the message list for D&D.
|
|
|
|
|
|
|
|
// STOPSHIP fixit: the new mailbox list created here doesn't know D&D is in progress.
|
|
|
|
|
|
|
|
updateMailboxList(accountId, mailboxId, true,
|
|
|
|
false /* don't clear message list and message view */);
|
|
|
|
} else if (mailboxId == NO_MAILBOX) {
|
|
|
|
// reload the top-level message list. Always implies navigate.
|
|
|
|
openAccount(accountId);
|
|
|
|
} else if (navigate) {
|
|
|
|
updateMailboxList(accountId, mailboxId, true, true);
|
|
|
|
updateMessageList(mailboxId, true, true);
|
2011-04-07 17:48:10 +00:00
|
|
|
} else {
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageList(mailboxId, true, true);
|
2011-04-07 17:48:10 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onAccountSelected(long accountId) {
|
2011-04-28 00:55:13 +00:00
|
|
|
// TODO openAccount should do the check eventually, but it's necessary for now.
|
|
|
|
if (accountId != getUIAccountId()) {
|
|
|
|
openAccount(accountId);
|
|
|
|
loadAccounts(); // update account spinner
|
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onCurrentMailboxUpdated(long mailboxId, String mailboxName, int unreadCount) {
|
2011-04-26 17:28:18 +00:00
|
|
|
mActionBarMailboxName.setText(mailboxName);
|
|
|
|
|
|
|
|
// Note on action bar, we show only "unread count". Some mailboxes such as Outbox don't
|
|
|
|
// have the idea of "unread count", in which case we just omit the count.
|
|
|
|
mActionBarUnreadCount.setText(
|
|
|
|
UiUtilities.getMessageCountForUi(mActivity, unreadCount, true));
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// MessageListFragment$Callback
|
|
|
|
@Override
|
|
|
|
public void onMessageOpen(long messageId, long messageMailboxId, long listMailboxId,
|
|
|
|
int type) {
|
|
|
|
if (type == MessageListFragment.Callback.TYPE_DRAFT) {
|
|
|
|
MessageCompose.actionEditDraft(mActivity, messageId);
|
|
|
|
} else {
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageView(messageId);
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onEnterSelectionMode(boolean enter) {
|
|
|
|
}
|
|
|
|
|
2011-04-13 18:30:56 +00:00
|
|
|
/**
|
|
|
|
* Apply the auto-advance policy upon initation of a batch command that could potentially
|
|
|
|
* affect the currently selected conversation.
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
public void onAdvancingOpAccepted(Set<Long> affectedMessages) {
|
2011-04-27 20:28:52 +00:00
|
|
|
if (!isMessageSelected()) {
|
|
|
|
// Do nothing if message view is not visible.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-04-13 18:30:56 +00:00
|
|
|
int autoAdvanceDir = Preferences.getPreferences(mActivity).getAutoAdvanceDirection();
|
|
|
|
if ((autoAdvanceDir == Preferences.AUTO_ADVANCE_MESSAGE_LIST) || (mOrderManager == null)) {
|
|
|
|
if (affectedMessages.contains(getMessageId())) {
|
|
|
|
goBackToMailbox();
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Navigate to the first unselected item in the appropriate direction.
|
|
|
|
switch (autoAdvanceDir) {
|
|
|
|
case Preferences.AUTO_ADVANCE_NEWER:
|
|
|
|
while (affectedMessages.contains(mOrderManager.getCurrentMessageId())) {
|
|
|
|
if (!mOrderManager.moveToNewer()) {
|
|
|
|
goBackToMailbox();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageView(mOrderManager.getCurrentMessageId());
|
2011-04-13 18:30:56 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case Preferences.AUTO_ADVANCE_OLDER:
|
|
|
|
while (affectedMessages.contains(mOrderManager.getCurrentMessageId())) {
|
|
|
|
if (!mOrderManager.moveToOlder()) {
|
|
|
|
goBackToMailbox();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageView(mOrderManager.getCurrentMessageId());
|
2011-04-13 18:30:56 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
@Override
|
|
|
|
public void onListLoaded() {
|
|
|
|
}
|
2011-04-13 18:30:56 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
// MessageViewFragment$Callback
|
|
|
|
@Override
|
|
|
|
public void onMessageViewShown(int mailboxType) {
|
|
|
|
updateMessageOrderManager();
|
|
|
|
updateNavigationArrows();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMessageViewGone() {
|
|
|
|
stopMessageOrderManager();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public boolean onUrlInMessageClicked(String url) {
|
|
|
|
return ActivityHelper.openUrlInMessage(mActivity, url, getActualAccountId());
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMessageSetUnread() {
|
|
|
|
goBackToMailbox();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMessageNotExists() {
|
|
|
|
goBackToMailbox();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onLoadMessageStarted() {
|
|
|
|
// TODO Any nice UI for this?
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onLoadMessageFinished() {
|
|
|
|
// TODO Any nice UI for this?
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onLoadMessageError(String errorMessage) {
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onRespondedToInvite(int response) {
|
|
|
|
onCurrentMessageGone();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onCalendarLinkClicked(long epochEventStartTime) {
|
|
|
|
ActivityHelper.openCalendar(mActivity, epochEventStartTime);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
2011-04-27 20:28:52 +00:00
|
|
|
public void onBeforeMessageGone() {
|
2011-04-01 18:34:03 +00:00
|
|
|
onCurrentMessageGone();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onForward() {
|
|
|
|
MessageCompose.actionForward(mActivity, getMessageId());
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onReply() {
|
|
|
|
MessageCompose.actionReply(mActivity, getMessageId(), false);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onReplyAll() {
|
|
|
|
MessageCompose.actionReply(mActivity, getMessageId(), true);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2010-09-21 22:36:23 +00:00
|
|
|
/**
|
|
|
|
* Must be called just after the activity sets up the content view.
|
|
|
|
*
|
|
|
|
* (Due to the complexity regarding class/activity initialization order, we can't do this in
|
2011-04-19 21:06:03 +00:00
|
|
|
* the constructor.) TODO this should no longer be true when we merge activities.
|
2010-09-21 22:36:23 +00:00
|
|
|
*/
|
|
|
|
public void onActivityViewReady() {
|
2010-09-30 01:44:05 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " onActivityViewReady");
|
|
|
|
}
|
|
|
|
// Set up action bar
|
|
|
|
mActionBar = mActivity.getActionBar();
|
|
|
|
mActionBar.setDisplayOptions(ActionBar.DISPLAY_SHOW_TITLE | ActionBar.DISPLAY_SHOW_HOME);
|
|
|
|
|
|
|
|
// Set a view for the current mailbox to the action bar.
|
|
|
|
final LayoutInflater inflater = LayoutInflater.from(mActivity);
|
|
|
|
mActionBarMailboxNameView = inflater.inflate(R.layout.action_bar_current_mailbox, null);
|
|
|
|
mActionBar.setDisplayOptions(ActionBar.DISPLAY_SHOW_CUSTOM, ActionBar.DISPLAY_SHOW_CUSTOM);
|
|
|
|
final ActionBar.LayoutParams customViewLayout = new ActionBar.LayoutParams(
|
|
|
|
ActionBar.LayoutParams.WRAP_CONTENT,
|
|
|
|
ActionBar.LayoutParams.MATCH_PARENT);
|
|
|
|
customViewLayout.setMargins(mActivity.getResources().getDimensionPixelSize(
|
|
|
|
R.dimen.action_bar_mailbox_name_left_margin) , 0, 0, 0);
|
|
|
|
mActionBar.setCustomView(mActionBarMailboxNameView, customViewLayout);
|
|
|
|
|
|
|
|
mActionBarMailboxName =
|
|
|
|
(TextView) mActionBarMailboxNameView.findViewById(R.id.mailbox_name);
|
|
|
|
mActionBarUnreadCount =
|
|
|
|
(TextView) mActionBarMailboxNameView.findViewById(R.id.unread_count);
|
|
|
|
|
|
|
|
|
|
|
|
// Set up content
|
2011-04-01 18:34:03 +00:00
|
|
|
mThreePane = (ThreePaneLayout) mActivity.findViewById(R.id.three_pane);
|
|
|
|
mThreePane.setCallback(this);
|
2010-09-30 01:44:05 +00:00
|
|
|
|
2011-01-11 22:36:00 +00:00
|
|
|
mMessageCommandButtons = mThreePane.getMessageCommandButtons();
|
|
|
|
mMessageCommandButtons.setCallback(new CommandButtonCallback());
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2011-01-07 22:49:05 +00:00
|
|
|
/**
|
|
|
|
* @return the currently selected account ID, *or* {@link Account#ACCOUNT_ID_COMBINED_VIEW}.
|
|
|
|
*
|
|
|
|
* @see #getActualAccountId()
|
|
|
|
*/
|
|
|
|
public long getUIAccountId() {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
return mAccountId;
|
|
|
|
}
|
|
|
|
|
2011-01-07 22:49:05 +00:00
|
|
|
/**
|
|
|
|
* @return the currently selected account ID. If the current view is the combined view,
|
2011-04-07 17:48:10 +00:00
|
|
|
* it'll return {@link #NO_ACCOUNT}.
|
2011-01-07 22:49:05 +00:00
|
|
|
*
|
|
|
|
* @see #getUIAccountId()
|
|
|
|
*/
|
|
|
|
public long getActualAccountId() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return mAccountId == Account.ACCOUNT_ID_COMBINED_VIEW ? NO_ACCOUNT : mAccountId;
|
2011-01-07 22:49:05 +00:00
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
public long getMailboxId() {
|
|
|
|
return mMailboxId;
|
|
|
|
}
|
|
|
|
|
|
|
|
public long getMessageId() {
|
|
|
|
return mMessageId;
|
|
|
|
}
|
|
|
|
|
2011-01-07 22:49:05 +00:00
|
|
|
/**
|
|
|
|
* @return true if an account is selected, or the current view is the combined view.
|
|
|
|
*/
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
public boolean isAccountSelected() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return getUIAccountId() != NO_ACCOUNT;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public boolean isMailboxSelected() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return getMailboxId() != NO_MAILBOX;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public boolean isMessageSelected() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return getMessageId() != NO_MESSAGE;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
/**
|
2011-04-26 17:28:18 +00:00
|
|
|
* @return true if refresh is in progress for the current mailbox.
|
|
|
|
*/
|
|
|
|
public boolean isRefreshInProgress() {
|
|
|
|
return (mMailboxId >= 0) && mRefreshManager.isMessageListRefreshing(mMailboxId);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @return true if the UI should enable the "refresh" command.
|
|
|
|
*/
|
|
|
|
public boolean isRefreshEnabled() {
|
|
|
|
// - Don't show for combined inboxes, but
|
|
|
|
// - Show even for non-refreshable mailboxes, in which case we refresh the mailbox list
|
|
|
|
return -1 != getActualAccountId();
|
|
|
|
}
|
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
/**
|
|
|
|
* Called by the host activity at the end of {@link Activity#onCreate}.
|
|
|
|
*/
|
|
|
|
public void onActivityCreated() {
|
2011-04-28 19:02:09 +00:00
|
|
|
mRefreshManager.registerListener(mRefreshListener);
|
2011-04-28 00:55:13 +00:00
|
|
|
loadAccounts();
|
|
|
|
}
|
|
|
|
|
2011-04-26 17:28:18 +00:00
|
|
|
/**
|
|
|
|
* Install all the fragments kept in {@link #mRestoredFragments}.
|
|
|
|
*
|
2011-04-28 00:55:13 +00:00
|
|
|
* Must be called at the end of {@link EmailActivity#onCreate}.
|
2011-04-19 21:06:03 +00:00
|
|
|
*/
|
2011-04-26 17:28:18 +00:00
|
|
|
public void installRestoredFragments() {
|
|
|
|
mHoldFragmentInstallation = false;
|
2011-04-19 21:06:03 +00:00
|
|
|
|
|
|
|
// Install all the fragments restored by the framework.
|
|
|
|
for (Fragment fragment : mRestoredFragments) {
|
|
|
|
installFragment(fragment);
|
|
|
|
}
|
|
|
|
mRestoredFragments.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-28 00:55:13 +00:00
|
|
|
* Called by {@link EmailActivity} when a {@link Fragment} is attached.
|
2011-04-19 21:06:03 +00:00
|
|
|
*
|
|
|
|
* If the activity has already been created, we initialize the fragment here. Otherwise we
|
|
|
|
* keep the fragment in {@link #mRestoredFragments} and initialize it after the activity's
|
|
|
|
* onCreate.
|
|
|
|
*/
|
|
|
|
public void onAttachFragment(Fragment fragment) {
|
2011-04-26 17:28:18 +00:00
|
|
|
if (mHoldFragmentInstallation) {
|
2011-04-19 21:06:03 +00:00
|
|
|
// Fragment being restored by the framework during the activity recreation.
|
|
|
|
mRestoredFragments.add(fragment);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
installFragment(fragment);
|
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
/**
|
2011-04-28 00:55:13 +00:00
|
|
|
* Called from {@link EmailActivity#onStart}.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2010-07-28 18:42:37 +00:00
|
|
|
public void onStart() {
|
2011-04-01 18:34:03 +00:00
|
|
|
if (isMessageSelected()) {
|
|
|
|
updateMessageOrderManager();
|
|
|
|
}
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-28 00:55:13 +00:00
|
|
|
* Called from {@link EmailActivity#onResume}.
|
2010-09-30 01:44:05 +00:00
|
|
|
*/
|
|
|
|
public void onResume() {
|
2011-04-26 17:28:18 +00:00
|
|
|
updateActionBar();
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-28 00:55:13 +00:00
|
|
|
* Called from {@link EmailActivity#onPause}.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2010-09-30 01:44:05 +00:00
|
|
|
public void onPause() {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
/**
|
2011-04-28 00:55:13 +00:00
|
|
|
* Called from {@link EmailActivity#onStop}.
|
2010-09-30 01:44:05 +00:00
|
|
|
*/
|
|
|
|
public void onStop() {
|
2011-04-01 18:34:03 +00:00
|
|
|
stopMessageOrderManager();
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-28 00:55:13 +00:00
|
|
|
* Called from {@link EmailActivity#onDestroy}.
|
2010-09-30 01:44:05 +00:00
|
|
|
*/
|
|
|
|
public void onDestroy() {
|
2011-04-26 17:28:18 +00:00
|
|
|
mHoldFragmentInstallation = true; // No more fragment installation.
|
2011-04-28 00:55:13 +00:00
|
|
|
mTaskTracker.cancellAllInterrupt();
|
2010-09-30 01:44:05 +00:00
|
|
|
closeMailboxFinder();
|
2011-04-28 19:02:09 +00:00
|
|
|
mRefreshManager.unregisterListener(mRefreshListener);
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
public void onSaveInstanceState(Bundle outState) {
|
2011-04-19 21:06:03 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " onSaveInstanceState");
|
2011-04-19 21:06:03 +00:00
|
|
|
}
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
outState.putLong(BUNDLE_KEY_ACCOUNT_ID, mAccountId);
|
|
|
|
outState.putLong(BUNDLE_KEY_MAILBOX_ID, mMailboxId);
|
|
|
|
outState.putLong(BUNDLE_KEY_MESSAGE_ID, mMessageId);
|
|
|
|
}
|
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
public void restoreInstanceState(Bundle savedInstanceState) {
|
2010-12-14 00:32:02 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " restoreInstanceState");
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
mAccountId = savedInstanceState.getLong(BUNDLE_KEY_ACCOUNT_ID, NO_ACCOUNT);
|
|
|
|
mMailboxId = savedInstanceState.getLong(BUNDLE_KEY_MAILBOX_ID, NO_MAILBOX);
|
|
|
|
mMessageId = savedInstanceState.getLong(BUNDLE_KEY_MESSAGE_ID, NO_MESSAGE);
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// STOPSHIP If MailboxFinder is still running, it needs restarting after loadState().
|
|
|
|
// This probably means we need to start MailboxFinder if mMailboxId == -1.
|
2011-04-19 21:06:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
private void installFragment(Fragment fragment) {
|
|
|
|
if (fragment instanceof MailboxListFragment) {
|
|
|
|
mMailboxListFragment = (MailboxListFragment) fragment;
|
|
|
|
mMailboxListFragment.setCallback(this);
|
|
|
|
} else if (fragment instanceof MessageListFragment) {
|
|
|
|
mMessageListFragment = (MessageListFragment) fragment;
|
|
|
|
mMessageListFragment.setCallback(this);
|
|
|
|
} else if (fragment instanceof MessageViewFragment) {
|
|
|
|
mMessageViewFragment = (MessageViewFragment) fragment;
|
|
|
|
mMessageViewFragment.setCallback(this);
|
|
|
|
} else {
|
|
|
|
// Ignore -- uninteresting fragments such as dialogs.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private FragmentTransaction uninstallMailboxListFragment(FragmentTransaction ft) {
|
|
|
|
if (mMailboxListFragment != null) {
|
|
|
|
ft.remove(mMailboxListFragment);
|
|
|
|
mMailboxListFragment.setCallback(null);
|
|
|
|
mMailboxListFragment = null;
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
return ft;
|
|
|
|
}
|
|
|
|
|
|
|
|
private FragmentTransaction uninstallMessageListFragment(FragmentTransaction ft) {
|
|
|
|
if (mMessageListFragment != null) {
|
|
|
|
ft.remove(mMessageListFragment);
|
|
|
|
mMessageListFragment.setCallback(null);
|
|
|
|
mMessageListFragment = null;
|
|
|
|
}
|
|
|
|
return ft;
|
|
|
|
}
|
|
|
|
|
|
|
|
private FragmentTransaction uninstallMessageViewFragment(FragmentTransaction ft) {
|
|
|
|
if (mMessageViewFragment != null) {
|
|
|
|
ft.remove(mMessageViewFragment);
|
|
|
|
mMessageViewFragment.setCallback(null);
|
|
|
|
mMessageViewFragment = null;
|
|
|
|
}
|
|
|
|
return ft;
|
|
|
|
}
|
|
|
|
|
|
|
|
private void commitFragmentTransaction(FragmentTransaction ft) {
|
|
|
|
ft.commit();
|
|
|
|
mActivity.getFragmentManager().executePendingTransactions();
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-21 18:50:22 +00:00
|
|
|
* Show the default view for the account.
|
|
|
|
*
|
|
|
|
* On two-pane, it's the account's root mailboxes on the left pane with Inbox on the right pane.
|
|
|
|
*
|
|
|
|
* @param accountId ID of the account to load. Can be {@link Account#ACCOUNT_ID_COMBINED_VIEW}.
|
|
|
|
* Must never be {@link #NO_ACCOUNT}.
|
|
|
|
*/
|
|
|
|
public void openAccount(long accountId) {
|
|
|
|
open(accountId, NO_MAILBOX, NO_MESSAGE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Loads the given account and optionally selects the given mailbox and message. Used to open
|
|
|
|
* a particular view at a request from outside of the activity, such as the widget.
|
|
|
|
*
|
|
|
|
* @param accountId ID of the account to load. Can be {@link Account#ACCOUNT_ID_COMBINED_VIEW}.
|
|
|
|
* Must never be {@link #NO_ACCOUNT}.
|
2011-04-07 17:48:10 +00:00
|
|
|
* @param mailboxId ID of the mailbox to load. If {@link #NO_MAILBOX}, load the account's inbox.
|
|
|
|
* @param messageId ID of the message to load. If {@link #NO_MESSAGE}, do not open a message.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
public void open(long accountId, long mailboxId, long messageId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " open accountId=" + accountId
|
|
|
|
+ " mailboxId=" + mailboxId + " messageId=" + messageId);
|
2011-04-21 18:50:22 +00:00
|
|
|
}
|
|
|
|
if (accountId == NO_ACCOUNT) {
|
|
|
|
throw new IllegalArgumentException();
|
|
|
|
} else if (mailboxId == NO_MAILBOX) {
|
|
|
|
updateMailboxList(accountId, NO_MAILBOX, true, true);
|
|
|
|
|
|
|
|
// Show the appropriate message list
|
|
|
|
if (accountId == Account.ACCOUNT_ID_COMBINED_VIEW) {
|
|
|
|
// When opening the Combined view, the right pane will be "combined inbox".
|
|
|
|
updateMessageList(Mailbox.QUERY_ALL_INBOXES, true, true);
|
|
|
|
} else {
|
|
|
|
// Try to find the inbox for the account
|
|
|
|
closeMailboxFinder();
|
|
|
|
mMailboxFinder = new MailboxFinder(mActivity, mAccountId, Mailbox.TYPE_INBOX, this);
|
|
|
|
mMailboxFinder.startLookup();
|
|
|
|
}
|
|
|
|
} else if (messageId == NO_MESSAGE) {
|
|
|
|
// STOPSHIP Use the appropriate parent mailbox ID
|
|
|
|
updateMailboxList(accountId, NO_MAILBOX, true, true);
|
|
|
|
updateMessageList(mailboxId, true, true);
|
|
|
|
} else {
|
|
|
|
// STOPSHIP Use the appropriate parent mailbox ID
|
|
|
|
updateMailboxList(accountId, NO_MAILBOX, false, true);
|
|
|
|
updateMessageList(mailboxId, false, true);
|
|
|
|
updateMessageView(messageId);
|
|
|
|
}
|
2011-04-07 17:48:10 +00:00
|
|
|
}
|
|
|
|
|
2011-04-26 17:28:18 +00:00
|
|
|
/**
|
|
|
|
* Pre-fragment transaction check.
|
|
|
|
*
|
|
|
|
* @throw IllegalStateException if updateXxx methods can't be called in the current state.
|
|
|
|
*/
|
|
|
|
private void preFragmentTransactionCheck() {
|
|
|
|
if (mHoldFragmentInstallation) {
|
|
|
|
// Code assumes mMailboxListFragment/etc are set right within the
|
|
|
|
// commitFragmentTransaction() call (because we use synchronous transaction),
|
|
|
|
// so updateXxx() can't be called if fragments are not installable yet.
|
|
|
|
throw new IllegalStateException();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/**
|
|
|
|
* Loads the given account and optionally selects the given mailbox and message. If the
|
|
|
|
* specified account is already selected, no actions will be performed unless
|
|
|
|
* <code>forceReload</code> is <code>true</code>.
|
2011-04-21 18:50:22 +00:00
|
|
|
*
|
2011-04-07 17:48:10 +00:00
|
|
|
* @param accountId ID of the account to load. Must never be {@link #NO_ACCOUNT}.
|
2011-04-21 18:50:22 +00:00
|
|
|
* @param parentMailboxId ID of the mailbox to use as the parent mailbox. Pass
|
|
|
|
* {@link #NO_MAILBOX} to show the root mailboxes.
|
|
|
|
* @param changeVisiblePane if true, the message view will be hidden.
|
|
|
|
* @param clearDependentPane if true, the message list and the message view will be cleared
|
2011-04-07 17:48:10 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// TODO The name "updateMailboxList" is misleading, as it also updates members such as
|
|
|
|
// mAccountId. We need better structure but let's do that after refactoring
|
|
|
|
// MailboxListFragment.onMailboxSelected, and removed the UI callbacks such as
|
|
|
|
// TargetActivity.onAccountChanged.
|
|
|
|
|
|
|
|
private void updateMailboxList(long accountId, long parentMailboxId,
|
|
|
|
boolean changeVisiblePane, boolean clearDependentPane) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " updateMailboxList accountId=" + accountId
|
|
|
|
+ " parentMailboxId=" + parentMailboxId);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
2011-04-26 17:28:18 +00:00
|
|
|
preFragmentTransactionCheck();
|
2011-04-07 17:48:10 +00:00
|
|
|
if (accountId == NO_ACCOUNT) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
|
|
|
|
2011-04-21 18:50:22 +00:00
|
|
|
// TODO Check if the current fragment has been initialized with the same parameters, and
|
|
|
|
// then return.
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
mAccountId = accountId;
|
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
// Open mailbox list, remove message list / message view
|
|
|
|
final FragmentManager fm = mActivity.getFragmentManager();
|
|
|
|
final FragmentTransaction ft = fm.beginTransaction();
|
|
|
|
uninstallMailboxListFragment(ft);
|
2011-04-21 18:50:22 +00:00
|
|
|
if (clearDependentPane) {
|
|
|
|
mMailboxId = NO_MAILBOX;
|
|
|
|
mMessageId = NO_MESSAGE;
|
|
|
|
uninstallMessageListFragment(ft);
|
|
|
|
uninstallMessageViewFragment(ft);
|
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
ft.add(mThreePane.getLeftPaneId(),
|
2011-04-21 18:50:22 +00:00
|
|
|
MailboxListFragment.newInstance(getUIAccountId(), parentMailboxId));
|
2011-04-19 21:06:03 +00:00
|
|
|
commitFragmentTransaction(ft);
|
2010-08-31 20:13:44 +00:00
|
|
|
|
2011-04-21 18:50:22 +00:00
|
|
|
if (changeVisiblePane) {
|
|
|
|
mThreePane.showLeftPane();
|
2010-08-25 02:09:34 +00:00
|
|
|
}
|
2011-04-28 19:02:09 +00:00
|
|
|
updateRefreshProgress();
|
2010-11-12 00:28:21 +00:00
|
|
|
}
|
|
|
|
|
2010-08-31 20:13:44 +00:00
|
|
|
/**
|
2011-04-01 18:34:03 +00:00
|
|
|
* Go back to a mailbox list view. If a message view is currently active, it will
|
|
|
|
* be hidden.
|
2010-08-31 20:13:44 +00:00
|
|
|
*/
|
2011-04-01 18:34:03 +00:00
|
|
|
private void goBackToMailbox() {
|
2010-08-31 20:13:44 +00:00
|
|
|
if (isMessageSelected()) {
|
2010-11-29 22:46:27 +00:00
|
|
|
mThreePane.showLeftPane(); // Show mailbox list
|
2010-08-31 20:13:44 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
/**
|
2011-04-07 17:48:10 +00:00
|
|
|
* Selects the specified mailbox and optionally loads a message within it. If a message is
|
|
|
|
* not loaded, a list of the messages contained within the mailbox is shown. Otherwise the
|
|
|
|
* given message is shown. If <code>navigateToMailbox<code> is <code>true</code>, the
|
|
|
|
* mailbox is navigated to and any contained mailboxes are shown.
|
2010-08-11 22:28:31 +00:00
|
|
|
*
|
2011-04-07 17:48:10 +00:00
|
|
|
* @param mailboxId ID of the mailbox to load. Must never be <code>0</code> or <code>-1</code>.
|
2011-04-21 18:50:22 +00:00
|
|
|
* @param changeVisiblePane if true, the message view will be hidden.
|
|
|
|
* @param clearDependentPane if true, the message view will be cleared
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
private void updateMessageList(long mailboxId, boolean changeVisiblePane,
|
|
|
|
boolean clearDependentPane) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " updateMessageList mMailboxId=" + mailboxId);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
2011-04-26 17:28:18 +00:00
|
|
|
preFragmentTransactionCheck();
|
2011-04-07 17:48:10 +00:00
|
|
|
if (mailboxId == 0 || mailboxId == -1) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// TODO Check if the current fragment has been initialized with the same parameters, and
|
|
|
|
// then return.
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
mMailboxId = mailboxId;
|
2011-04-19 21:06:03 +00:00
|
|
|
|
|
|
|
final FragmentManager fm = mActivity.getFragmentManager();
|
|
|
|
final FragmentTransaction ft = fm.beginTransaction();
|
|
|
|
uninstallMessageListFragment(ft);
|
2011-04-21 18:50:22 +00:00
|
|
|
if (clearDependentPane) {
|
|
|
|
uninstallMessageViewFragment(ft);
|
|
|
|
mMessageId = NO_MESSAGE;
|
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
ft.add(mThreePane.getMiddlePaneId(), MessageListFragment.newInstance(mailboxId));
|
|
|
|
commitFragmentTransaction(ft);
|
|
|
|
|
2011-04-21 18:50:22 +00:00
|
|
|
if (changeVisiblePane) {
|
2011-04-01 18:34:03 +00:00
|
|
|
mThreePane.showLeftPane();
|
2010-12-04 00:28:25 +00:00
|
|
|
}
|
2011-04-26 17:28:18 +00:00
|
|
|
|
|
|
|
mMailboxListFragment.setSelectedMailbox(mailboxId);
|
2011-04-28 19:02:09 +00:00
|
|
|
updateRefreshProgress();
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-21 18:50:22 +00:00
|
|
|
* Show a message on the message view.
|
|
|
|
*
|
|
|
|
* @param messageId ID of the mailbox to load. Must never be {@link #NO_MESSAGE}.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
private void updateMessageView(long messageId) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-26 17:28:18 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "" + this + " updateMessageView messageId=" + messageId);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
2011-04-26 17:28:18 +00:00
|
|
|
preFragmentTransactionCheck();
|
2011-04-07 17:48:10 +00:00
|
|
|
if (messageId == NO_MESSAGE) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// TODO Check if the current fragment has been initialized with the same parameters, and
|
|
|
|
// then return.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
// Update member
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
mMessageId = messageId;
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
// Open message
|
2011-04-19 21:06:03 +00:00
|
|
|
final FragmentManager fm = mActivity.getFragmentManager();
|
|
|
|
final FragmentTransaction ft = fm.beginTransaction();
|
|
|
|
uninstallMessageViewFragment(ft);
|
|
|
|
ft.add(mThreePane.getRightPaneId(), MessageViewFragment.newInstance(messageId));
|
|
|
|
commitFragmentTransaction(ft);
|
|
|
|
|
2010-11-16 19:11:22 +00:00
|
|
|
mThreePane.showRightPane(); // Show message view
|
2011-04-26 17:28:18 +00:00
|
|
|
|
|
|
|
mMessageListFragment.setSelectedMessage(mMessageId);
|
2010-09-21 22:36:23 +00:00
|
|
|
}
|
|
|
|
|
2010-08-04 23:23:26 +00:00
|
|
|
private void closeMailboxFinder() {
|
|
|
|
if (mMailboxFinder != null) {
|
2010-08-27 17:16:08 +00:00
|
|
|
mMailboxFinder.cancel();
|
2010-08-04 23:23:26 +00:00
|
|
|
mMailboxFinder = null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
private class CommandButtonCallback implements MessageCommandButtonView.Callback {
|
2010-08-04 23:23:26 +00:00
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMoveToNewer() {
|
2011-04-13 18:30:56 +00:00
|
|
|
moveToNewer();
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMoveToOlder() {
|
2011-04-13 18:30:56 +00:00
|
|
|
moveToOlder();
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private void onCurrentMessageGone() {
|
|
|
|
switch (Preferences.getPreferences(mActivity).getAutoAdvanceDirection()) {
|
|
|
|
case Preferences.AUTO_ADVANCE_NEWER:
|
2011-04-13 18:30:56 +00:00
|
|
|
if (moveToNewer()) return;
|
2011-04-01 18:34:03 +00:00
|
|
|
break;
|
|
|
|
case Preferences.AUTO_ADVANCE_OLDER:
|
2011-04-13 18:30:56 +00:00
|
|
|
if (moveToOlder()) return;
|
2011-04-01 18:34:03 +00:00
|
|
|
break;
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
// Last message in the box or AUTO_ADVANCE_MESSAGE_LIST. Go back to message list.
|
|
|
|
goBackToMailbox();
|
|
|
|
}
|
2010-08-04 23:23:26 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
/**
|
|
|
|
* Potentially create a new {@link MessageOrderManager}; if it's not already started or if
|
|
|
|
* the account has changed, and sync it to the current message.
|
|
|
|
*/
|
|
|
|
private void updateMessageOrderManager() {
|
|
|
|
if (!isMailboxSelected()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
final long mailboxId = getMailboxId();
|
|
|
|
if (mOrderManager == null || mOrderManager.getMailboxId() != mailboxId) {
|
|
|
|
stopMessageOrderManager();
|
|
|
|
mOrderManager =
|
|
|
|
new MessageOrderManager(mActivity, mailboxId, mMessageOrderManagerCallback);
|
|
|
|
}
|
|
|
|
if (isMessageSelected()) {
|
|
|
|
mOrderManager.moveTo(getMessageId());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private class MessageOrderManagerCallback implements MessageOrderManager.Callback {
|
2010-08-04 23:23:26 +00:00
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMessagesChanged() {
|
|
|
|
updateNavigationArrows();
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMessageNotFound() {
|
|
|
|
// Current message gone.
|
|
|
|
goBackToMailbox();
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
}
|
2010-11-12 00:28:21 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
/**
|
|
|
|
* Stop {@link MessageOrderManager}.
|
|
|
|
*/
|
|
|
|
private void stopMessageOrderManager() {
|
|
|
|
if (mOrderManager != null) {
|
|
|
|
mOrderManager.close();
|
|
|
|
mOrderManager = null;
|
|
|
|
}
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
/**
|
|
|
|
* Disable/enable the move-to-newer/older buttons.
|
|
|
|
*/
|
|
|
|
private void updateNavigationArrows() {
|
|
|
|
if (mOrderManager == null) {
|
|
|
|
// shouldn't happen, but just in case
|
|
|
|
mMessageCommandButtons.enableNavigationButtons(false, false, 0, 0);
|
|
|
|
} else {
|
|
|
|
mMessageCommandButtons.enableNavigationButtons(
|
|
|
|
mOrderManager.canMoveToNewer(), mOrderManager.canMoveToOlder(),
|
|
|
|
mOrderManager.getCurrentPosition(), mOrderManager.getTotalMessageCount());
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
2011-01-11 22:36:00 +00:00
|
|
|
|
2011-04-13 18:30:56 +00:00
|
|
|
private boolean moveToOlder() {
|
|
|
|
if ((mOrderManager != null) && mOrderManager.moveToOlder()) {
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageView(mOrderManager.getCurrentMessageId());
|
2011-04-01 18:34:03 +00:00
|
|
|
return true;
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
return false;
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
|
|
|
|
2011-04-13 18:30:56 +00:00
|
|
|
private boolean moveToNewer() {
|
|
|
|
if ((mOrderManager != null) && mOrderManager.moveToNewer()) {
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageView(mOrderManager.getCurrentMessageId());
|
2011-04-01 18:34:03 +00:00
|
|
|
return true;
|
2010-11-12 00:28:21 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
return false;
|
2010-11-12 00:28:21 +00:00
|
|
|
}
|
2011-04-28 00:55:13 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Load account list for the action bar.
|
|
|
|
*
|
|
|
|
* If there's only one account configured, show the account name in the action bar.
|
|
|
|
* If more than one account are configured, show a spinner in the action bar, and select the
|
|
|
|
* current account.
|
|
|
|
*/
|
|
|
|
private void loadAccounts() {
|
|
|
|
if (mAccountsSelectorAdapter == null) {
|
|
|
|
mAccountsSelectorAdapter = new AccountSelectorAdapter(mActivity);
|
|
|
|
}
|
|
|
|
mActivity.getLoaderManager().initLoader(LOADER_ID_ACCOUNT_LIST, null,
|
|
|
|
new LoaderCallbacks<Cursor>() {
|
|
|
|
@Override
|
|
|
|
public Loader<Cursor> onCreateLoader(int id, Bundle args) {
|
|
|
|
return AccountSelectorAdapter.createLoader(mActivity);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onLoadFinished(Loader<Cursor> loader, Cursor data) {
|
|
|
|
updateAccountList(data);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onLoaderReset(Loader<Cursor> loader) {
|
|
|
|
mAccountsSelectorAdapter.swapCursor(null);
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Called when the LOADER_ID_ACCOUNT_LIST loader loads the data. Update the account spinner
|
|
|
|
* on the action bar.
|
|
|
|
*/
|
|
|
|
private void updateAccountList(Cursor accountsCursor) {
|
|
|
|
final int count = accountsCursor.getCount();
|
|
|
|
if (count == 0) {
|
|
|
|
// Open Welcome, which in turn shows the adding a new account screen.
|
|
|
|
Welcome.actionStart(mActivity);
|
|
|
|
mActivity.finish();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If ony one acount, don't show dropdown.
|
|
|
|
final ActionBar ab = mActionBar;
|
|
|
|
if (count == 1) {
|
|
|
|
accountsCursor.moveToFirst();
|
|
|
|
|
|
|
|
// Show the account name as the title.
|
|
|
|
ab.setDisplayOptions(ActionBar.DISPLAY_SHOW_TITLE, ActionBar.DISPLAY_SHOW_TITLE);
|
|
|
|
ab.setNavigationMode(ActionBar.NAVIGATION_MODE_STANDARD);
|
|
|
|
ab.setTitle(AccountSelectorAdapter.getAccountDisplayName(accountsCursor));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Find the currently selected account, and select it.
|
|
|
|
int defaultSelection = 0;
|
|
|
|
if (isAccountSelected()) {
|
|
|
|
accountsCursor.moveToPosition(-1);
|
|
|
|
int i = 0;
|
|
|
|
while (accountsCursor.moveToNext()) {
|
|
|
|
final long accountId = AccountSelectorAdapter.getAccountId(accountsCursor);
|
|
|
|
if (accountId == getUIAccountId()) {
|
|
|
|
defaultSelection = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Update the dropdown list.
|
|
|
|
mAccountsSelectorAdapter.swapCursor(accountsCursor);
|
|
|
|
|
|
|
|
// Don't show the title.
|
|
|
|
ab.setDisplayOptions(0, ActionBar.DISPLAY_SHOW_TITLE);
|
|
|
|
ab.setNavigationMode(ActionBar.NAVIGATION_MODE_LIST);
|
|
|
|
ab.setListNavigationCallbacks(mAccountsSelectorAdapter, mActionBarNavigationCallback);
|
|
|
|
ab.setSelectedNavigationItem(defaultSelection);
|
|
|
|
}
|
|
|
|
|
|
|
|
private class ActionBarNavigationCallback implements ActionBar.OnNavigationListener {
|
|
|
|
@Override
|
|
|
|
public boolean onNavigationItemSelected(int itemPosition, long accountId) {
|
|
|
|
// TODO openAccount should do the check eventually, but it's necessary for now.
|
|
|
|
if (accountId != getUIAccountId()) {
|
|
|
|
openAccount(accountId);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles {@link android.app.Activity#onCreateOptionsMenu} callback.
|
|
|
|
*/
|
|
|
|
public boolean onCreateOptionsMenu(MenuInflater inflater, Menu menu) {
|
|
|
|
inflater.inflate(R.menu.message_list_xl_option, menu);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles {@link android.app.Activity#onPrepareOptionsMenu} callback.
|
|
|
|
*/
|
|
|
|
public boolean onPrepareOptionsMenu(MenuInflater inflater, Menu menu) {
|
|
|
|
ActivityHelper.updateRefreshMenuIcon(menu.findItem(R.id.refresh),
|
|
|
|
isRefreshEnabled(),
|
|
|
|
isRefreshInProgress());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles {@link android.app.Activity#onOptionsItemSelected} callback.
|
|
|
|
*
|
|
|
|
* @return true if the option item is handled.
|
|
|
|
*/
|
|
|
|
public boolean onOptionsItemSelected(MenuItem item) {
|
|
|
|
switch (item.getItemId()) {
|
|
|
|
case android.R.id.home:
|
|
|
|
// Comes from the action bar when the app icon on the left is pressed.
|
|
|
|
// It works like a back press, but it won't close the activity.
|
|
|
|
return onBackPressed(false);
|
|
|
|
case R.id.compose:
|
|
|
|
return onCompose();
|
|
|
|
case R.id.refresh:
|
|
|
|
onRefresh();
|
|
|
|
return true;
|
|
|
|
case R.id.account_settings:
|
|
|
|
return onAccountSettings();
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Performs the back action.
|
|
|
|
*
|
|
|
|
* @param isSystemBackKey <code>true</code> if the system back key was pressed.
|
|
|
|
* <code>true</code> if it's caused by the "home" icon click on the action bar.
|
|
|
|
*/
|
|
|
|
public boolean onBackPressed(boolean isSystemBackKey) {
|
|
|
|
if (mThreePane.onBackPressed(isSystemBackKey)) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles the "Compose" option item. Opens the message compose activity.
|
|
|
|
*/
|
|
|
|
private boolean onCompose() {
|
|
|
|
if (!isAccountSelected()) {
|
|
|
|
return false; // this shouldn't really happen
|
|
|
|
}
|
|
|
|
MessageCompose.actionCompose(mActivity, getActualAccountId());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles the "Compose" option item. Opens the settings activity.
|
|
|
|
*/
|
|
|
|
private boolean onAccountSettings() {
|
|
|
|
AccountSettingsXL.actionSettings(mActivity, getActualAccountId());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles the "refresh" option item. Opens the settings activity.
|
|
|
|
*/
|
|
|
|
// TODO used by experimental code in the activity -- otherwise can be private.
|
|
|
|
public void onRefresh() {
|
|
|
|
// Cancel previously running instance if any.
|
|
|
|
new RefreshTask(mTaskTracker, mActivity, getActualAccountId(),
|
|
|
|
getMailboxId()).cancelPreviousAndExecuteParallel();
|
|
|
|
}
|
|
|
|
|
2011-04-28 19:02:09 +00:00
|
|
|
/**
|
|
|
|
* Start/stop the "refresh" animation on the action bar according to the current refresh state.
|
|
|
|
*
|
|
|
|
* (We start the animation if {@link UIControllerTwoPane#isRefreshInProgress} returns true,
|
|
|
|
* and stop otherwise.)
|
|
|
|
*/
|
|
|
|
private void updateRefreshProgress() {
|
|
|
|
mActivity.invalidateOptionsMenu();
|
|
|
|
}
|
|
|
|
|
|
|
|
private class RefreshListener
|
|
|
|
implements RefreshManager.Listener {
|
|
|
|
@Override
|
|
|
|
public void onMessagingError(final long accountId, long mailboxId, final String message) {
|
|
|
|
updateRefreshProgress();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onRefreshStatusChanged(long accountId, long mailboxId) {
|
|
|
|
updateRefreshProgress();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
/**
|
|
|
|
* Class to handle refresh.
|
|
|
|
*
|
|
|
|
* When the user press "refresh",
|
|
|
|
* <ul>
|
|
|
|
* <li>Refresh the current mailbox, if it's refreshable. (e.g. don't refresh combined inbox,
|
|
|
|
* drafts, etc.
|
|
|
|
* <li>Refresh the mailbox list, if it hasn't been refreshed in the last
|
|
|
|
* {@link #MAILBOX_REFRESH_MIN_INTERVAL}.
|
|
|
|
* <li>Refresh inbox, if it's not the current mailbox and it hasn't been refreshed in the last
|
|
|
|
* {@link #INBOX_AUTO_REFRESH_MIN_INTERVAL}.
|
|
|
|
* </ul>
|
|
|
|
*/
|
|
|
|
/* package */ static class RefreshTask extends EmailAsyncTask<Void, Void, Boolean> {
|
|
|
|
private final Clock mClock;
|
|
|
|
private final Context mContext;
|
|
|
|
private final long mAccountId;
|
|
|
|
private final long mMailboxId;
|
|
|
|
private final RefreshManager mRefreshManager;
|
|
|
|
/* package */ long mInboxId;
|
|
|
|
|
|
|
|
public RefreshTask(EmailAsyncTask.Tracker tracker, Context context, long accountId,
|
|
|
|
long mailboxId) {
|
|
|
|
this(tracker, context, accountId, mailboxId, Clock.INSTANCE,
|
|
|
|
RefreshManager.getInstance(context));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* package */ RefreshTask(EmailAsyncTask.Tracker tracker, Context context, long accountId,
|
|
|
|
long mailboxId, Clock clock, RefreshManager refreshManager) {
|
|
|
|
super(tracker);
|
|
|
|
mClock = clock;
|
|
|
|
mContext = context;
|
|
|
|
mRefreshManager = refreshManager;
|
|
|
|
mAccountId = accountId;
|
|
|
|
mMailboxId = mailboxId;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Do DB access on a worker thread.
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
protected Boolean doInBackground(Void... params) {
|
|
|
|
mInboxId = Account.getInboxId(mContext, mAccountId);
|
|
|
|
return Mailbox.isRefreshable(mContext, mMailboxId);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Do the actual refresh.
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
protected void onPostExecute(Boolean isCurrentMailboxRefreshable) {
|
|
|
|
if (isCancelled() || isCurrentMailboxRefreshable == null) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (isCurrentMailboxRefreshable) {
|
|
|
|
mRefreshManager.refreshMessageList(mAccountId, mMailboxId, false);
|
|
|
|
}
|
|
|
|
// Refresh mailbox list
|
|
|
|
if (mAccountId != -1) {
|
|
|
|
if (shouldRefreshMailboxList()) {
|
|
|
|
mRefreshManager.refreshMailboxList(mAccountId);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Refresh inbox
|
|
|
|
if (shouldAutoRefreshInbox()) {
|
|
|
|
mRefreshManager.refreshMessageList(mAccountId, mInboxId, false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @return true if the mailbox list of the current account hasn't been refreshed
|
|
|
|
* in the last {@link #MAILBOX_REFRESH_MIN_INTERVAL}.
|
|
|
|
*/
|
|
|
|
/* package */ boolean shouldRefreshMailboxList() {
|
|
|
|
if (mRefreshManager.isMailboxListRefreshing(mAccountId)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
final long nextRefreshTime = mRefreshManager.getLastMailboxListRefreshTime(mAccountId)
|
|
|
|
+ MAILBOX_REFRESH_MIN_INTERVAL;
|
|
|
|
if (nextRefreshTime > mClock.getTime()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @return true if the inbox of the current account hasn't been refreshed
|
|
|
|
* in the last {@link #INBOX_AUTO_REFRESH_MIN_INTERVAL}.
|
|
|
|
*/
|
|
|
|
/* package */ boolean shouldAutoRefreshInbox() {
|
|
|
|
if (mInboxId == mMailboxId) {
|
|
|
|
return false; // Current ID == inbox. No need to auto-refresh.
|
|
|
|
}
|
|
|
|
if (mRefreshManager.isMessageListRefreshing(mInboxId)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
final long nextRefreshTime = mRefreshManager.getLastMessageListRefreshTime(mInboxId)
|
|
|
|
+ INBOX_AUTO_REFRESH_MIN_INTERVAL;
|
|
|
|
if (nextRefreshTime > mClock.getTime()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|