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-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;
|
2011-05-17 17:50:30 +00:00
|
|
|
import com.android.emailcommon.provider.EmailContent.Message;
|
2011-05-14 00:26:27 +00:00
|
|
|
import com.android.emailcommon.provider.Mailbox;
|
2011-04-28 00:55:13 +00:00
|
|
|
import com.android.emailcommon.utility.EmailAsyncTask;
|
2011-05-04 19:07:08 +00:00
|
|
|
import com.android.emailcommon.utility.Utility;
|
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-05-04 19:07:08 +00:00
|
|
|
import android.app.Activity;
|
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.content.Context;
|
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-13 18:30:56 +00:00
|
|
|
import java.util.Set;
|
2011-05-04 19:07:08 +00:00
|
|
|
import java.util.Stack;
|
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-05-09 21:31:11 +00:00
|
|
|
class UIControllerTwoPane extends UIControllerBase implements
|
2011-04-01 18:34:03 +00:00
|
|
|
MailboxFinder.Callback,
|
|
|
|
ThreePaneLayout.Callback,
|
|
|
|
MailboxListFragment.Callback,
|
|
|
|
MessageListFragment.Callback,
|
|
|
|
MessageViewFragment.Callback {
|
2011-05-04 19:07:08 +00:00
|
|
|
private static final String BUNDLE_KEY_MAILBOX_STACK
|
|
|
|
= "UIControllerTwoPane.state.mailbox_stack";
|
2011-04-28 00:55:13 +00:00
|
|
|
|
|
|
|
/* 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
|
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/** Current account id */
|
2011-05-17 17:50:30 +00:00
|
|
|
private long mAccountId = Account.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-05-04 19:07:08 +00:00
|
|
|
// TODO Remove this instance variable and replace it with a call to mMessageListFragment to
|
|
|
|
// retrieve it's mailbox ID. There's no reason we should be duplicating data
|
|
|
|
/**
|
|
|
|
* The id of the currently viewed mailbox in the mailbox list fragment.
|
|
|
|
* IMPORTANT: Do not confuse this with the value returned by {@link #getMessageListMailboxId()}
|
|
|
|
* which is the mailbox id associated with the message list fragment. The two may be different.
|
|
|
|
*/
|
2011-05-17 17:50:30 +00:00
|
|
|
private long mMailboxListMailboxId = Mailbox.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 */
|
2011-05-17 17:50:30 +00:00
|
|
|
private long mMessageId = Message.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-05-05 21:22:33 +00:00
|
|
|
private ActionBarController mActionBarController;
|
|
|
|
private final ActionBarControllerCallback mActionBarControllerCallback =
|
|
|
|
new ActionBarControllerCallback();
|
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-01 18:34:03 +00:00
|
|
|
private MessageOrderManager mOrderManager;
|
|
|
|
private final MessageOrderManagerCallback mMessageOrderManagerCallback =
|
|
|
|
new MessageOrderManagerCallback();
|
2011-05-04 19:07:08 +00:00
|
|
|
/** Mailbox IDs that the user has navigated away from; used to provide "back" functionality */
|
|
|
|
private final Stack<Long> mMailboxStack = new Stack<Long>();
|
2011-04-01 18:34:03 +00:00
|
|
|
|
2011-05-05 21:22:33 +00:00
|
|
|
/**
|
|
|
|
* The mailbox name selected on the mailbox list.
|
|
|
|
* Passed via {@link #onCurrentMailboxUpdated}.
|
|
|
|
*/
|
|
|
|
private String mCurrentMailboxName;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The unread count for the mailbox selected on the mailbox list.
|
|
|
|
* Passed via {@link #onCurrentMailboxUpdated}.
|
|
|
|
*
|
|
|
|
* 0 if the mailbox doesn't have the concept of "unread". e.g. Drafts.
|
|
|
|
*/
|
|
|
|
private int mCurrentMailboxUnreadCount;
|
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
public UIControllerTwoPane(EmailActivity activity) {
|
2011-05-09 21:31:11 +00:00
|
|
|
super(activity);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public int getLayoutId() {
|
|
|
|
return R.layout.email_activity_two_pane;
|
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() {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +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) {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +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) {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +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) {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +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-05-05 21:22:33 +00:00
|
|
|
refreshActionBar();
|
2011-04-26 17:28:18 +00:00
|
|
|
|
|
|
|
// 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-05-17 17:50:30 +00:00
|
|
|
mMessageId = Message.NO_MESSAGE;
|
2011-04-19 21:06:03 +00:00
|
|
|
if (mMessageListFragment != null) {
|
2011-05-17 17:50:30 +00:00
|
|
|
mMessageListFragment.setSelectedMessage(Message.NO_MESSAGE);
|
2011-04-19 21:06:03 +00:00
|
|
|
}
|
|
|
|
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-05-05 21:22:33 +00:00
|
|
|
private void refreshActionBar() {
|
|
|
|
if (mActionBarController != null) {
|
|
|
|
mActionBarController.refresh();
|
|
|
|
}
|
2011-04-26 17:28:18 +00:00
|
|
|
}
|
|
|
|
|
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 */);
|
2011-05-17 17:50:30 +00:00
|
|
|
} else if (mailboxId == Mailbox.NO_MAILBOX) {
|
2011-04-21 18:50:22 +00:00
|
|
|
// reload the top-level message list. Always implies navigate.
|
|
|
|
openAccount(accountId);
|
|
|
|
} else if (navigate) {
|
2011-05-04 19:07:08 +00:00
|
|
|
if (mMailboxStack.isEmpty() || mailboxId != mMailboxListMailboxId) {
|
|
|
|
// Don't navigate to the same mailbox id twice in a row
|
|
|
|
mMailboxStack.push(mMailboxListMailboxId);
|
|
|
|
openMailbox(accountId, mailboxId);
|
|
|
|
}
|
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);
|
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onCurrentMailboxUpdated(long mailboxId, String mailboxName, int unreadCount) {
|
2011-05-05 21:22:33 +00:00
|
|
|
mCurrentMailboxName = mailboxName;
|
|
|
|
mCurrentMailboxUnreadCount = unreadCount;
|
|
|
|
refreshActionBar();
|
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
|
|
|
*/
|
2011-05-09 21:31:11 +00:00
|
|
|
@Override
|
2010-09-21 22:36:23 +00:00
|
|
|
public void onActivityViewReady() {
|
2011-05-11 18:38:54 +00:00
|
|
|
super.onActivityViewReady();
|
2011-05-05 21:22:33 +00:00
|
|
|
mActionBarController = new ActionBarController(mActivity, mActivity.getLoaderManager(),
|
|
|
|
mActivity.getActionBar(), mActionBarControllerCallback);
|
2011-04-26 17:28:18 +00:00
|
|
|
|
|
|
|
// 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()
|
|
|
|
*/
|
2011-05-09 21:31:11 +00:00
|
|
|
@Override
|
2011-01-07 22:49:05 +00:00
|
|
|
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-05-04 19:07:08 +00:00
|
|
|
/**
|
|
|
|
* Returns the id of the mailbox used for the message list fragment.
|
|
|
|
* IMPORTANT: Do not confuse this with {@link #mMailboxListMailboxId} which is the id used
|
|
|
|
* for the mailbox list. The two may be different.
|
|
|
|
*/
|
2011-05-09 21:31:11 +00:00
|
|
|
private long getMessageListMailboxId() {
|
2011-05-12 00:40:36 +00:00
|
|
|
return (mMessageListFragment == null) ? Mailbox.NO_MAILBOX
|
|
|
|
: mMessageListFragment.getMailboxIdArg();
|
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-05-09 21:31:11 +00:00
|
|
|
/*
|
|
|
|
* STOPSHIP Remove this -- see the base class method.
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
public long getMailboxSettingsMailboxId() {
|
|
|
|
return getMessageListMailboxId();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* STOPSHIP Remove this -- see the base class method.
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
public long getSearchMailboxId() {
|
|
|
|
return getMessageListMailboxId();
|
|
|
|
}
|
|
|
|
|
|
|
|
private long getMessageId() {
|
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 mMessageId;
|
|
|
|
}
|
|
|
|
|
2011-05-11 18:38:54 +00:00
|
|
|
private boolean isMailboxSelected() {
|
2011-05-17 17:50:30 +00:00
|
|
|
return getMessageListMailboxId() != Mailbox.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-05-11 18:38:54 +00:00
|
|
|
private boolean isMessageSelected() {
|
2011-05-17 17:50:30 +00:00
|
|
|
return getMessageId() != Message.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.
|
|
|
|
*/
|
2011-05-11 18:38:54 +00:00
|
|
|
@Override
|
|
|
|
protected boolean isRefreshInProgress() {
|
2011-05-04 19:07:08 +00:00
|
|
|
long messageListMailboxId = getMessageListMailboxId();
|
|
|
|
return (messageListMailboxId >= 0)
|
|
|
|
&& mRefreshManager.isMessageListRefreshing(messageListMailboxId);
|
2011-04-26 17:28:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @return true if the UI should enable the "refresh" command.
|
|
|
|
*/
|
2011-05-11 18:38:54 +00:00
|
|
|
@Override
|
|
|
|
protected boolean isRefreshEnabled() {
|
2011-04-26 17:28:18 +00:00
|
|
|
// - Don't show for combined inboxes, but
|
|
|
|
// - Show even for non-refreshable mailboxes, in which case we refresh the mailbox list
|
2011-05-17 17:50:30 +00:00
|
|
|
return getActualAccountId() != Account.NO_ACCOUNT;
|
2011-04-26 17:28:18 +00:00
|
|
|
}
|
|
|
|
|
2011-04-28 00:55:13 +00:00
|
|
|
/**
|
|
|
|
* Called by the host activity at the end of {@link Activity#onCreate}.
|
|
|
|
*/
|
2011-05-09 21:31:11 +00:00
|
|
|
@Override
|
2011-04-28 00:55:13 +00:00
|
|
|
public void onActivityCreated() {
|
2011-05-09 21:31:11 +00:00
|
|
|
super.onActivityCreated();
|
2011-05-05 21:22:33 +00:00
|
|
|
mActionBarController.onActivityCreated();
|
2011-04-28 00:55:13 +00:00
|
|
|
}
|
|
|
|
|
2011-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
|
|
|
public void onActivityStart() {
|
|
|
|
super.onActivityStart();
|
2011-04-01 18:34:03 +00:00
|
|
|
if (isMessageSelected()) {
|
|
|
|
updateMessageOrderManager();
|
|
|
|
}
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
2011-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
|
|
|
public void onActivityResume() {
|
|
|
|
super.onActivityResume();
|
2011-05-05 21:22:33 +00:00
|
|
|
refreshActionBar();
|
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-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
|
|
|
public void onActivityPause() {
|
|
|
|
super.onActivityPause();
|
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-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
|
|
|
public void onActivityStop() {
|
2011-04-01 18:34:03 +00:00
|
|
|
stopMessageOrderManager();
|
2011-05-09 21:31:11 +00:00
|
|
|
super.onActivityStop();
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
2011-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
|
|
|
public void onActivityDestroy() {
|
2010-09-30 01:44:05 +00:00
|
|
|
closeMailboxFinder();
|
2011-05-09 21:31:11 +00:00
|
|
|
super.onActivityDestroy();
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
2011-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
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-05-09 21:31:11 +00:00
|
|
|
super.onSaveInstanceState(outState);
|
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);
|
2011-05-04 19:07:08 +00:00
|
|
|
outState.putLong(BUNDLE_KEY_MAILBOX_ID, mMailboxListMailboxId);
|
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_MESSAGE_ID, mMessageId);
|
2011-05-04 19:07:08 +00:00
|
|
|
if (!mMailboxStack.isEmpty()) {
|
|
|
|
// Save the mailbox stack
|
|
|
|
long[] mailboxIds = Utility.toPrimitiveLongArray(mMailboxStack);
|
|
|
|
outState.putLongArray(BUNDLE_KEY_MAILBOX_STACK, mailboxIds);
|
|
|
|
}
|
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-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
2011-04-19 21:06:03 +00:00
|
|
|
public void restoreInstanceState(Bundle savedInstanceState) {
|
2011-05-09 21:31:11 +00:00
|
|
|
super.restoreInstanceState(savedInstanceState);
|
2011-05-17 17:50:30 +00:00
|
|
|
mAccountId = savedInstanceState.getLong(BUNDLE_KEY_ACCOUNT_ID, Account.NO_ACCOUNT);
|
|
|
|
mMailboxListMailboxId = savedInstanceState.getLong(BUNDLE_KEY_MAILBOX_ID,
|
|
|
|
Mailbox.NO_MAILBOX);
|
|
|
|
mMessageId = savedInstanceState.getLong(BUNDLE_KEY_MESSAGE_ID, Message.NO_MESSAGE);
|
2011-05-04 19:07:08 +00:00
|
|
|
long[] mailboxIds = savedInstanceState.getLongArray(BUNDLE_KEY_MAILBOX_STACK);
|
|
|
|
if (mailboxIds != null) {
|
|
|
|
// Restore the mailbox stack; ugly hack to get around 'Long' versus 'long'
|
|
|
|
mMailboxStack.clear();
|
|
|
|
for (long id : mailboxIds) {
|
|
|
|
mMailboxStack.push(id);
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2011-05-09 21:31:11 +00:00
|
|
|
@Override
|
2011-05-13 20:18:35 +00:00
|
|
|
protected void installMailboxListFragment(MailboxListFragment fragment) {
|
|
|
|
mMailboxListFragment = fragment;
|
|
|
|
mMailboxListFragment.setCallback(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
protected void installMessageListFragment(MessageListFragment fragment) {
|
|
|
|
mMessageListFragment = fragment;
|
|
|
|
mMessageListFragment.setCallback(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
protected void installMessageViewFragment(MessageViewFragment fragment) {
|
|
|
|
mMessageViewFragment = fragment;
|
|
|
|
mMessageViewFragment.setCallback(this);
|
2011-04-19 21:06:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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-05-09 21:31:11 +00:00
|
|
|
* {@inheritDoc}
|
2011-04-21 18:50:22 +00:00
|
|
|
*
|
|
|
|
* On two-pane, it's the account's root mailboxes on the left pane with Inbox on the right pane.
|
|
|
|
*/
|
2011-05-09 21:31:11 +00:00
|
|
|
@Override
|
2011-04-21 18:50:22 +00:00
|
|
|
public void openAccount(long accountId) {
|
2011-05-04 19:07:08 +00:00
|
|
|
mMailboxStack.clear();
|
2011-05-17 17:50:30 +00:00
|
|
|
open(accountId, Mailbox.NO_MAILBOX, Message.NO_MESSAGE);
|
2011-05-05 21:22:33 +00:00
|
|
|
refreshActionBar();
|
2011-04-21 18:50:22 +00:00
|
|
|
}
|
|
|
|
|
2011-05-04 19:07:08 +00:00
|
|
|
/**
|
|
|
|
* Opens the given mailbox. on two-pane, this will update both the mailbox list and the
|
|
|
|
* message list.
|
|
|
|
*
|
|
|
|
* NOTE: It's assumed that the mailbox is associated with the specified account. If the
|
|
|
|
* mailbox is not associated with the account, the behaviour is undefined.
|
|
|
|
*/
|
|
|
|
private void openMailbox(long accountId, long mailboxId) {
|
|
|
|
updateMailboxList(accountId, mailboxId, true, true);
|
|
|
|
updateMessageList(mailboxId, true, true);
|
2011-05-05 21:22:33 +00:00
|
|
|
refreshActionBar();
|
2011-05-04 19:07:08 +00:00
|
|
|
}
|
|
|
|
|
2011-04-21 18:50:22 +00:00
|
|
|
/**
|
2011-05-09 21:31:11 +00:00
|
|
|
* {@inheritDoc}
|
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-05-09 21:31:11 +00:00
|
|
|
@Override
|
2011-04-21 18:50:22 +00:00
|
|
|
public void open(long accountId, long mailboxId, long messageId) {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +00:00
|
|
|
Log.d(Logging.LOG_TAG, this + " open accountId=" + accountId
|
2011-04-26 17:28:18 +00:00
|
|
|
+ " mailboxId=" + mailboxId + " messageId=" + messageId);
|
2011-04-21 18:50:22 +00:00
|
|
|
}
|
2011-05-17 17:50:30 +00:00
|
|
|
if (accountId == Account.NO_ACCOUNT) {
|
2011-04-21 18:50:22 +00:00
|
|
|
throw new IllegalArgumentException();
|
2011-05-17 17:50:30 +00:00
|
|
|
} else if (mailboxId == Mailbox.NO_MAILBOX) {
|
|
|
|
updateMailboxList(accountId, Mailbox.NO_MAILBOX, true, true);
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// 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();
|
|
|
|
}
|
2011-05-17 17:50:30 +00:00
|
|
|
} else if (messageId == Message.NO_MESSAGE) {
|
2011-04-21 18:50:22 +00:00
|
|
|
// STOPSHIP Use the appropriate parent mailbox ID
|
2011-05-04 19:07:08 +00:00
|
|
|
updateMailboxList(accountId, mailboxId, true, true);
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageList(mailboxId, true, true);
|
|
|
|
} else {
|
|
|
|
// STOPSHIP Use the appropriate parent mailbox ID
|
2011-05-04 19:07:08 +00:00
|
|
|
updateMailboxList(accountId, mailboxId, false, true);
|
2011-04-21 18:50:22 +00:00
|
|
|
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() {
|
2011-05-09 21:31:11 +00:00
|
|
|
if (!isFragmentInstallable()) {
|
2011-04-26 17:28:18 +00:00
|
|
|
// 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-05-17 17:50:30 +00:00
|
|
|
* @param accountId ID of the account to load. Must never be {@link Account#NO_ACCOUNT}.
|
2011-04-21 18:50:22 +00:00
|
|
|
* @param parentMailboxId ID of the mailbox to use as the parent mailbox. Pass
|
2011-05-17 17:50:30 +00:00
|
|
|
* {@link Mailbox#NO_MAILBOX} to show the root mailboxes.
|
2011-04-21 18:50:22 +00:00
|
|
|
* @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) {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +00:00
|
|
|
Log.d(Logging.LOG_TAG, this + " updateMailboxList accountId=" + accountId
|
2011-04-26 17:28:18 +00:00
|
|
|
+ " 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-05-17 17:50:30 +00:00
|
|
|
if (accountId == Account.NO_ACCOUNT) {
|
2011-05-17 00:29:13 +00:00
|
|
|
throw new IllegalArgumentException();
|
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
|
|
|
// 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-05-04 19:07:08 +00:00
|
|
|
mMailboxListMailboxId = 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-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) {
|
2011-05-17 17:50:30 +00:00
|
|
|
mMessageId = Message.NO_MESSAGE;
|
2011-04-21 18:50:22 +00:00
|
|
|
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-05-17 17:50:30 +00:00
|
|
|
* @param mailboxId ID of the mailbox to load. Must never be <code>0</code> or
|
|
|
|
* {@link Mailbox#NO_MAILBOX}.
|
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) {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +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-05-17 17:50:30 +00:00
|
|
|
if (mailboxId == 0 || mailboxId == Mailbox.NO_MAILBOX) {
|
2011-05-17 00:29:13 +00:00
|
|
|
throw new IllegalArgumentException();
|
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
|
|
|
|
|
|
|
// TODO Check if the current fragment has been initialized with the same parameters, and
|
|
|
|
// then return.
|
|
|
|
|
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);
|
2011-05-17 17:50:30 +00:00
|
|
|
mMessageId = Message.NO_MESSAGE;
|
2011-04-21 18:50:22 +00:00
|
|
|
}
|
2011-05-12 00:40:36 +00:00
|
|
|
ft.add(mThreePane.getMiddlePaneId(), MessageListFragment.newInstance(
|
|
|
|
mAccountId, mailboxId));
|
2011-04-19 21:06:03 +00:00
|
|
|
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
|
|
|
|
2011-05-04 19:07:08 +00:00
|
|
|
// TODO We shouldn't select the mailbox when we're updating the message list. These two
|
|
|
|
// functions should be done separately. Find a better location for this call to be done.
|
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.
|
|
|
|
*
|
2011-05-17 17:50:30 +00:00
|
|
|
* @param messageId ID of the mailbox to load. Must never be {@link Message#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) {
|
2011-05-13 18:20:04 +00:00
|
|
|
if (Logging.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-05-09 21:31:11 +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-05-17 17:50:30 +00:00
|
|
|
if (messageId == Message.NO_MESSAGE) {
|
2011-05-17 00:29:13 +00:00
|
|
|
throw new IllegalArgumentException();
|
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
|
|
|
|
|
|
|
// 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;
|
|
|
|
}
|
2011-05-04 19:07:08 +00:00
|
|
|
final long mailboxId = getMessageListMailboxId();
|
2011-04-01 18:34:03 +00:00
|
|
|
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
|
|
|
|
2011-05-09 21:31:11 +00:00
|
|
|
/** {@inheritDoc} */
|
|
|
|
@Override
|
2011-04-28 00:55:13 +00:00
|
|
|
public boolean onBackPressed(boolean isSystemBackKey) {
|
|
|
|
if (mThreePane.onBackPressed(isSystemBackKey)) {
|
|
|
|
return true;
|
2011-05-04 19:07:08 +00:00
|
|
|
} else if (!mMailboxStack.isEmpty()) {
|
|
|
|
long mailboxId = mMailboxStack.pop();
|
2011-05-17 17:50:30 +00:00
|
|
|
if (mailboxId == Mailbox.NO_MAILBOX) {
|
2011-05-04 19:07:08 +00:00
|
|
|
// No mailbox; reload the top-level message list
|
|
|
|
openAccount(mAccountId);
|
|
|
|
} else {
|
|
|
|
openMailbox(mAccountId, mailboxId);
|
|
|
|
}
|
|
|
|
return true;
|
2011-04-28 00:55:13 +00:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Handles the "refresh" option item. Opens the settings activity.
|
2011-05-09 21:31:11 +00:00
|
|
|
* TODO used by experimental code in the activity -- otherwise can be private.
|
2011-04-28 00:55:13 +00:00
|
|
|
*/
|
2011-05-09 21:31:11 +00:00
|
|
|
@Override
|
2011-04-28 00:55:13 +00:00
|
|
|
public void onRefresh() {
|
|
|
|
// Cancel previously running instance if any.
|
|
|
|
new RefreshTask(mTaskTracker, mActivity, getActualAccountId(),
|
2011-05-04 19:07:08 +00:00
|
|
|
getMessageListMailboxId()).cancelPreviousAndExecuteParallel();
|
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
|
2011-05-17 17:50:30 +00:00
|
|
|
if (mAccountId != Account.NO_ACCOUNT) {
|
2011-04-28 00:55:13 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
2011-05-05 21:22:33 +00:00
|
|
|
|
|
|
|
private class ActionBarControllerCallback implements ActionBarController.Callback {
|
|
|
|
@Override
|
|
|
|
public String getCurrentMailboxName() {
|
|
|
|
return mCurrentMailboxName;
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public int getCurrentMailboxUnreadCount() {
|
|
|
|
return mCurrentMailboxUnreadCount;
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public long getUIAccountId() {
|
|
|
|
return UIControllerTwoPane.this.getUIAccountId();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public boolean isAccountSelected() {
|
|
|
|
return UIControllerTwoPane.this.isAccountSelected();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onAccountSelected(long accountId) {
|
|
|
|
openAccount(accountId);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onNoAccountsFound() {
|
|
|
|
Welcome.actionStart(mActivity);
|
|
|
|
mActivity.finish();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public boolean shouldShowMailboxName() {
|
|
|
|
// Show when the left pane is hidden.
|
|
|
|
return (mThreePane.getVisiblePanes() & ThreePaneLayout.PANE_LEFT) == 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public boolean shouldShowUp() {
|
|
|
|
final int visiblePanes = mThreePane.getVisiblePanes();
|
|
|
|
final boolean leftPaneHidden = ((visiblePanes & ThreePaneLayout.PANE_LEFT) == 0);
|
|
|
|
return leftPaneHidden || !mMailboxStack.isEmpty();
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
}
|