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;
|
|
|
|
|
|
|
|
import com.android.email.Email;
|
|
|
|
import com.android.email.R;
|
2010-10-26 00:51:56 +00:00
|
|
|
import com.android.email.provider.EmailContent.Account;
|
2010-08-04 23:23:26 +00:00
|
|
|
import com.android.email.provider.EmailContent.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
|
|
|
|
2010-11-12 00:28:21 +00:00
|
|
|
import android.app.ActionBar;
|
2010-08-16 18:00:53 +00:00
|
|
|
import android.app.FragmentManager;
|
2010-08-04 23:23:26 +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;
|
2010-11-19 20:45:34 +00:00
|
|
|
import android.view.LayoutInflater;
|
2010-09-21 22:36:23 +00:00
|
|
|
import android.view.View;
|
2010-11-19 20:45:34 +00:00
|
|
|
import android.widget.TextView;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
|
|
|
import java.security.InvalidParameterException;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A class manages what are showing on {@link MessageListXL} (i.e. account id, mailbox id, and
|
|
|
|
* message id), and show/hide fragments accordingly.
|
|
|
|
*
|
2010-09-21 22:36:23 +00:00
|
|
|
* TODO Highlight selected message on message list
|
|
|
|
*
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
* TODO: Test it. It's testable if we implement MockFragmentTransaction, which may be too early
|
|
|
|
* to do so at this point. (API may not be stable enough yet.)
|
|
|
|
*/
|
|
|
|
class MessageListXLFragmentManager {
|
|
|
|
private static final String BUNDLE_KEY_ACCOUNT_ID = "MessageListXl.state.account_id";
|
|
|
|
private static final String BUNDLE_KEY_MAILBOX_ID = "MessageListXl.state.mailbox_id";
|
|
|
|
private static final String BUNDLE_KEY_MESSAGE_ID = "MessageListXl.state.message_id";
|
2010-08-31 20:13:44 +00:00
|
|
|
private static final String BUNDLE_KEY_MESSAGE_LIST_STATE
|
|
|
|
= "MessageListXl.state.message_list_state";
|
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 final Context mContext;
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
private boolean mIsActivityResumed;
|
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
|
|
|
|
|
|
|
/** Current account id. (-1 = not selected) */
|
|
|
|
private long mAccountId = -1;
|
|
|
|
|
|
|
|
/** Current mailbox id. (-1 = not selected) */
|
|
|
|
private long mMailboxId = -1;
|
|
|
|
|
|
|
|
/** Current message id. (-1 = not selected) */
|
|
|
|
private long mMessageId = -1;
|
|
|
|
|
2010-11-19 20:45:34 +00:00
|
|
|
private ActionBar mActionBar;
|
2010-09-24 00:10:46 +00:00
|
|
|
private ThreePaneLayout mThreePane;
|
2010-11-19 20:45:34 +00:00
|
|
|
private View mActionBarMailboxNameView;
|
|
|
|
private TextView mActionBarMailboxName;
|
|
|
|
private TextView mActionBarUnreadCount;
|
2010-09-21 22:36:23 +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
|
|
|
private MailboxListFragment mMailboxListFragment;
|
|
|
|
private MessageListFragment mMessageListFragment;
|
2010-07-30 22:41:40 +00:00
|
|
|
private MessageViewFragment mMessageViewFragment;
|
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;
|
|
|
|
private final MailboxFinderCallback mMailboxFinderCallback = new MailboxFinderCallback();
|
2010-11-12 00:28:21 +00:00
|
|
|
private final ThreePaneLayoutCallback mThreePaneLayoutCallback = new ThreePaneLayoutCallback();
|
2010-08-04 23:23:26 +00:00
|
|
|
|
2010-08-31 20:13:44 +00:00
|
|
|
/**
|
|
|
|
* Save state for the "message list -> message view -[back press]-> message list" transition.
|
|
|
|
*/
|
|
|
|
private MessageListFragment.State mMessageListFragmentState;
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* The interface that {@link MessageListXL} implements. We don't call its methods directly,
|
2010-08-04 23:23:26 +00:00
|
|
|
* in the hope that it'll make writing tests easier, and make it clear which methods are needed
|
|
|
|
* for MessageListXLFragmentManager.
|
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 interface TargetActivity {
|
2010-11-12 00:28:21 +00:00
|
|
|
public ActionBar getActionBar();
|
2010-08-16 18:00:53 +00:00
|
|
|
public FragmentManager getFragmentManager();
|
2010-08-04 23:23:26 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Called when the selected account is on security-hold.
|
|
|
|
*/
|
2010-09-09 21:13:47 +00:00
|
|
|
public void onAccountSecurityHold(long accountId);
|
2010-09-13 23:35:58 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Called when the current mailbox has changed.
|
|
|
|
*/
|
|
|
|
public void onMailboxChanged(long accountId, long newMailboxId);
|
2010-09-21 22:36:23 +00:00
|
|
|
|
|
|
|
public View findViewById(int id);
|
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 final TargetActivity mTargetActivity;
|
|
|
|
|
2010-08-04 23:23:26 +00:00
|
|
|
public MessageListXLFragmentManager(MessageListXL activity) {
|
|
|
|
mContext = activity;
|
|
|
|
mTargetActivity = activity;
|
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
|
|
|
|
* the constructor.)
|
|
|
|
*/
|
|
|
|
public void onActivityViewReady() {
|
2010-09-30 01:44:05 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "MessageListXLFragmentManager.onActivityViewReady");
|
|
|
|
}
|
2010-09-24 00:10:46 +00:00
|
|
|
mThreePane = (ThreePaneLayout) mTargetActivity.findViewById(R.id.three_pane);
|
2010-11-12 00:28:21 +00:00
|
|
|
mThreePane.setCallback(mThreePaneLayoutCallback);
|
2010-09-30 01:44:05 +00:00
|
|
|
|
|
|
|
FragmentManager fm = mTargetActivity.getFragmentManager();
|
|
|
|
mMailboxListFragment = (MailboxListFragment) fm.findFragmentById(
|
|
|
|
mThreePane.getLeftPaneId());
|
|
|
|
mMessageListFragment = (MessageListFragment) fm.findFragmentById(
|
|
|
|
mThreePane.getMiddlePaneId());
|
|
|
|
mMessageViewFragment = (MessageViewFragment) fm.findFragmentById(
|
|
|
|
mThreePane.getRightPaneId());
|
2010-11-19 20:45:34 +00:00
|
|
|
|
|
|
|
mActionBar = mTargetActivity.getActionBar();
|
|
|
|
|
|
|
|
// Set a view for the current mailbox to the action bar.
|
|
|
|
final LayoutInflater inflater = LayoutInflater.from(mContext);
|
|
|
|
mActionBarMailboxNameView = inflater.inflate(R.layout.action_bar_current_mailbox, null);
|
|
|
|
mActionBar.setDisplayOptions(ActionBar.DISPLAY_SHOW_CUSTOM, ActionBar.DISPLAY_SHOW_CUSTOM);
|
|
|
|
mActionBar.setCustomView(mActionBarMailboxNameView);
|
|
|
|
|
|
|
|
mActionBarMailboxName =
|
|
|
|
(TextView) mActionBarMailboxNameView.findViewById(R.id.mailbox_name);
|
|
|
|
mActionBarUnreadCount =
|
|
|
|
(TextView) mActionBarMailboxNameView.findViewById(R.id.unread_count);
|
2010-09-21 22:36:23 +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
|
|
|
/** Set callback for fragment. */
|
|
|
|
public void setMailboxListFragmentCallback(
|
|
|
|
MailboxListFragment.Callback mailboxListFragmentCallback) {
|
2010-09-30 01:44:05 +00:00
|
|
|
mMailboxListFragment.setCallback(mailboxListFragmentCallback);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/** Set callback for fragment. */
|
|
|
|
public void setMessageListFragmentCallback(
|
|
|
|
MessageListFragment.Callback messageListFragmentCallback) {
|
2010-09-30 01:44:05 +00:00
|
|
|
mMessageListFragment.setCallback(messageListFragmentCallback);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/** Set callback for fragment. */
|
|
|
|
public void setMessageViewFragmentCallback(
|
2010-07-30 22:41:40 +00:00
|
|
|
MessageViewFragment.Callback messageViewFragmentCallback) {
|
2010-09-30 01:44:05 +00:00
|
|
|
mMessageViewFragment.setCallback(messageViewFragmentCallback);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public long getAccountId() {
|
|
|
|
return mAccountId;
|
|
|
|
}
|
|
|
|
|
|
|
|
public long getMailboxId() {
|
|
|
|
return mMailboxId;
|
|
|
|
}
|
|
|
|
|
|
|
|
public long getMessageId() {
|
|
|
|
return mMessageId;
|
|
|
|
}
|
|
|
|
|
|
|
|
public boolean isAccountSelected() {
|
|
|
|
return getAccountId() != -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
public boolean isMailboxSelected() {
|
|
|
|
return getMailboxId() != -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
public boolean isMessageSelected() {
|
|
|
|
return getMessageId() != -1;
|
|
|
|
}
|
|
|
|
|
2010-08-17 22:07:28 +00:00
|
|
|
public MailboxListFragment getMailboxListFragment() {
|
|
|
|
return mMailboxListFragment;
|
|
|
|
}
|
|
|
|
|
|
|
|
public MessageListFragment getMessageListFragment() {
|
|
|
|
return mMessageListFragment;
|
|
|
|
}
|
|
|
|
|
|
|
|
public MessageViewFragment getMessageViewFragment() {
|
|
|
|
return mMessageViewFragment;
|
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
/**
|
2010-09-30 01:44:05 +00:00
|
|
|
* Called from {@link MessageListXL#onStart}.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2010-07-28 18:42:37 +00:00
|
|
|
public void onStart() {
|
2010-09-30 01:44:05 +00:00
|
|
|
// Nothing to do
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Called from {@link MessageListXL#onResume}.
|
|
|
|
*/
|
|
|
|
public void onResume() {
|
|
|
|
if (mIsActivityResumed) {
|
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;
|
|
|
|
}
|
2010-09-30 01:44:05 +00:00
|
|
|
mIsActivityResumed = true;
|
2010-11-16 19:11:22 +00:00
|
|
|
|
|
|
|
updateActionBar();
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2010-09-30 01:44:05 +00:00
|
|
|
* Called from {@link MessageListXL#onPause}.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2010-09-30 01:44:05 +00:00
|
|
|
public void onPause() {
|
|
|
|
if (!mIsActivityResumed) {
|
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;
|
|
|
|
}
|
2010-09-30 01:44:05 +00:00
|
|
|
mIsActivityResumed = false;
|
2010-08-31 20:13:44 +00:00
|
|
|
saveMessageListFragmentState();
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
/**
|
|
|
|
* Called from {@link MessageListXL#onStop}.
|
|
|
|
*/
|
|
|
|
public void onStop() {
|
|
|
|
// Nothing to do
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Called from {@link MessageListXL#onDestroy}.
|
|
|
|
*/
|
|
|
|
public void onDestroy() {
|
|
|
|
closeMailboxFinder();
|
|
|
|
}
|
|
|
|
|
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) {
|
|
|
|
outState.putLong(BUNDLE_KEY_ACCOUNT_ID, mAccountId);
|
|
|
|
outState.putLong(BUNDLE_KEY_MAILBOX_ID, mMailboxId);
|
|
|
|
outState.putLong(BUNDLE_KEY_MESSAGE_ID, mMessageId);
|
2010-08-31 20:13:44 +00:00
|
|
|
outState.putParcelable(BUNDLE_KEY_MESSAGE_LIST_STATE, mMessageListFragmentState);
|
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 loadState(Bundle savedInstanceState) {
|
2010-09-30 01:44:05 +00:00
|
|
|
long accountId = savedInstanceState.getLong(BUNDLE_KEY_ACCOUNT_ID, -1);
|
|
|
|
long mailboxId = savedInstanceState.getLong(BUNDLE_KEY_MAILBOX_ID, -1);
|
|
|
|
long messageId = savedInstanceState.getLong(BUNDLE_KEY_MESSAGE_ID, -1);
|
2010-08-31 20:13:44 +00:00
|
|
|
mMessageListFragmentState = savedInstanceState.getParcelable(BUNDLE_KEY_MESSAGE_LIST_STATE);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "MessageListXLFragmentManager: Restoring "
|
2010-09-30 01:44:05 +00:00
|
|
|
+ accountId + "," + mailboxId + "," + messageId);
|
|
|
|
}
|
|
|
|
if (accountId == -1) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// selectAccount() calls selectMailbox() if necessary
|
|
|
|
selectAccount(accountId, mailboxId, false);
|
|
|
|
if (messageId == -1) {
|
|
|
|
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
|
|
|
}
|
2010-09-30 01:44:05 +00:00
|
|
|
selectMessage(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
|
|
|
}
|
|
|
|
|
2010-08-31 20:13:44 +00:00
|
|
|
private void saveMessageListFragmentState() {
|
|
|
|
if (mMessageListFragment != null) {
|
|
|
|
mMessageListFragmentState = mMessageListFragment.getState();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private void restoreMesasgeListState() {
|
|
|
|
if ((mMessageListFragment != null) && (mMessageListFragmentState != null)) {
|
|
|
|
mMessageListFragmentState.restore(mMessageListFragment);
|
|
|
|
mMessageListFragmentState = null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-11-12 00:28:21 +00:00
|
|
|
private void updateActionBar() {
|
2010-11-19 20:45:34 +00:00
|
|
|
// If the left pane (mailbox list pane) is hidden, the back action on action bar will be
|
|
|
|
// enabled, and we also show the current mailbox name.
|
2010-11-12 00:28:21 +00:00
|
|
|
final int visiblePanes = mThreePane.getVisiblePanes();
|
2010-11-19 20:45:34 +00:00
|
|
|
final boolean leftPaneHidden = ((visiblePanes & ThreePaneLayout.PANE_LEFT) == 0);
|
|
|
|
mActionBar.setDisplayOptions(leftPaneHidden ? ActionBar.DISPLAY_HOME_AS_UP : 0,
|
2010-11-12 00:28:21 +00:00
|
|
|
ActionBar.DISPLAY_HOME_AS_UP);
|
2010-11-19 20:45:34 +00:00
|
|
|
mActionBarMailboxNameView.setVisibility(leftPaneHidden ? View.VISIBLE : View.GONE);
|
|
|
|
}
|
|
|
|
|
|
|
|
public void setCurrentMailboxName(String mailboxName, int unreadCount) {
|
|
|
|
mActionBarMailboxName.setText(mailboxName);
|
|
|
|
if (unreadCount == 0) {
|
|
|
|
// No unread messages, or it's the mailbox doesn't have the idea of "unread".
|
|
|
|
// (e.g. outbox)
|
|
|
|
mActionBarUnreadCount.setText("");
|
|
|
|
} else {
|
|
|
|
mActionBarUnreadCount.setText(Integer.toString(unreadCount));
|
|
|
|
}
|
2010-11-12 00:28:21 +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
|
|
|
/**
|
|
|
|
* Call it to select an account.
|
2010-08-25 02:09:34 +00:00
|
|
|
*
|
|
|
|
* @param accountId account ID. Must not be -1.
|
|
|
|
* @param mailboxId mailbox ID. Pass -1 to open account's inbox.
|
|
|
|
* @param byExplicitUserAction set true if the user is explicitly opening the mailbox,
|
|
|
|
* in which case we perform "auto-refresh".
|
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-25 02:09:34 +00:00
|
|
|
public void selectAccount(long accountId, long mailboxId, boolean byExplicitUserAction) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "selectAccount mAccountId=" + accountId);
|
|
|
|
}
|
|
|
|
if (accountId == -1) {
|
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
|
|
|
if (mAccountId == accountId) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Update members.
|
|
|
|
mAccountId = accountId;
|
|
|
|
mMailboxId = -1;
|
|
|
|
mMessageId = -1;
|
|
|
|
|
2010-08-31 20:13:44 +00:00
|
|
|
// In case of "message list -> message view -> change account", we don't have to keep it.
|
|
|
|
mMessageListFragmentState = null;
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
// Open mailbox list, clear message list / message view
|
|
|
|
mMailboxListFragment.openMailboxes(mAccountId);
|
|
|
|
mMessageListFragment.clearContent();
|
2010-11-16 19:11:22 +00:00
|
|
|
mThreePane.showLeftPane(); // Show mailbox list
|
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-10-26 00:51:56 +00:00
|
|
|
if ((accountId == Account.ACCOUNT_ID_COMBINED_VIEW) && (mailboxId == -1)) {
|
|
|
|
// When opening the Combined view, the right pane will be "combined inbox".
|
|
|
|
selectMailbox(Mailbox.QUERY_ALL_INBOXES, false);
|
|
|
|
} else if (mailboxId == -1) {
|
2010-08-25 02:09:34 +00:00
|
|
|
startInboxLookup();
|
|
|
|
} else {
|
|
|
|
selectMailbox(mailboxId, byExplicitUserAction);
|
|
|
|
}
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2010-11-12 00:28:21 +00:00
|
|
|
/**
|
2010-11-24 22:39:49 +00:00
|
|
|
* Handles the back event.
|
2010-11-12 00:28:21 +00:00
|
|
|
*
|
2010-11-24 22:39:49 +00:00
|
|
|
* @param isSystemBackKey See {@link ThreePaneLayout#onBackPressed}
|
|
|
|
* @return true if the event is handled.
|
2010-11-12 00:28:21 +00:00
|
|
|
*/
|
2010-11-24 22:39:49 +00:00
|
|
|
public boolean onBackPressed(boolean isSystemBackKey) {
|
|
|
|
return mThreePane.onBackPressed(isSystemBackKey);
|
2010-11-12 00:28:21 +00:00
|
|
|
}
|
|
|
|
|
2010-08-31 20:13:44 +00:00
|
|
|
/**
|
|
|
|
* If the current view is MessageView, go back to MessageList.
|
|
|
|
*/
|
|
|
|
public void goBackToMailbox() {
|
|
|
|
if (isMessageSelected()) {
|
|
|
|
selectMailbox(getMailboxId(), false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Call it to select a mailbox.
|
|
|
|
*
|
|
|
|
* We assume the mailbox selected here belongs to the account selected with
|
|
|
|
* {@link #selectAccount}.
|
2010-08-11 22:28:31 +00:00
|
|
|
*
|
|
|
|
* @param mailboxId ID of mailbox
|
2010-08-17 22:07:28 +00:00
|
|
|
* @param byExplicitUserAction set true if the user is explicitly opening the mailbox,
|
|
|
|
* in which case we perform "auto-refresh".
|
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-17 22:07:28 +00:00
|
|
|
public void selectMailbox(long mailboxId, boolean byExplicitUserAction) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "selectMailbox mMailboxId=" + mailboxId);
|
|
|
|
}
|
|
|
|
if (mailboxId == -1) {
|
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
2010-09-21 22:36:23 +00:00
|
|
|
|
|
|
|
if (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
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Update members.
|
|
|
|
mMailboxId = mailboxId;
|
|
|
|
mMessageId = -1;
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
// Open mailbox
|
|
|
|
if (byExplicitUserAction) {
|
|
|
|
mMessageListFragment.doAutoRefresh();
|
2010-08-24 23:55:44 +00:00
|
|
|
}
|
2010-08-31 20:13:44 +00:00
|
|
|
mMessageListFragment.openMailbox(mMailboxId);
|
|
|
|
restoreMesasgeListState();
|
2010-09-30 01:44:05 +00:00
|
|
|
|
|
|
|
mMailboxListFragment.setSelectedMailbox(mMailboxId);
|
2010-09-13 23:35:58 +00:00
|
|
|
mTargetActivity.onMailboxChanged(mAccountId, mMailboxId);
|
2010-11-16 19:11:22 +00:00
|
|
|
mThreePane.showLeftPane(); // Show mailbox list
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Call it to select a mailbox.
|
|
|
|
*
|
|
|
|
* We assume the message passed here belongs to the account/mailbox selected with
|
|
|
|
* {@link #selectAccount} and {@link #selectMailbox}.
|
|
|
|
*/
|
|
|
|
public void selectMessage(long messageId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "selectMessage messageId=" + messageId);
|
|
|
|
}
|
|
|
|
if (messageId == -1) {
|
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
|
|
|
if (mMessageId == messageId) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-08-31 20:13:44 +00:00
|
|
|
saveMessageListFragmentState();
|
|
|
|
|
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
|
|
|
// Update member.
|
|
|
|
mMessageId = messageId;
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
// Open message
|
2010-09-22 01:20:30 +00:00
|
|
|
mMessageListFragment.setSelectedMessage(mMessageId);
|
2010-09-30 01:44:05 +00:00
|
|
|
mMessageViewFragment.openMessage(mMessageId);
|
2010-11-16 19:11:22 +00:00
|
|
|
mThreePane.showRightPane(); // Show message view
|
2010-09-21 22:36:23 +00:00
|
|
|
}
|
|
|
|
|
2010-11-16 19:11:22 +00:00
|
|
|
/**
|
|
|
|
* Unselect the currently viewed message, if any, and release the resoruce grabbed by the
|
|
|
|
* message view.
|
|
|
|
*
|
|
|
|
* This must be called when the three pane reports that the message view pane gets hidden.
|
|
|
|
*/
|
|
|
|
private void onMessageViewClosed() {
|
2010-09-21 22:36:23 +00:00
|
|
|
mMessageId = -1;
|
2010-09-30 01:44:05 +00:00
|
|
|
mMessageListFragment.setSelectedMessage(-1);
|
|
|
|
mMessageViewFragment.clearContent();
|
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 void startInboxLookup() {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "startLookForInbox account=" + mAccountId);
|
|
|
|
}
|
|
|
|
closeMailboxFinder();
|
|
|
|
mMailboxFinder = new MailboxFinder(mContext, mAccountId, Mailbox.TYPE_INBOX,
|
|
|
|
mMailboxFinderCallback);
|
|
|
|
mMailboxFinder.startLookup();
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private class MailboxFinderCallback implements MailboxFinder.Callback {
|
|
|
|
@Override
|
|
|
|
public void onAccountNotFound() {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "MailboxFinderCallback.onAccountNotFound");
|
|
|
|
}
|
|
|
|
// Shouldn't happen
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onAccountSecurityHold(long accountId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "MailboxFinderCallback.onAccountSecurityHold");
|
|
|
|
}
|
2010-09-09 21:13:47 +00:00
|
|
|
mTargetActivity.onAccountSecurityHold(accountId);
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMailboxFound(long accountId, long mailboxId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, " Found inbox");
|
|
|
|
}
|
2010-08-11 22:28:31 +00:00
|
|
|
selectMailbox(mailboxId, true);
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMailboxNotFound(long accountId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "MailboxFinderCallback.onMailboxNotFound");
|
|
|
|
}
|
|
|
|
// Shouldn't happen
|
|
|
|
}
|
|
|
|
}
|
2010-11-12 00:28:21 +00:00
|
|
|
|
|
|
|
private class ThreePaneLayoutCallback implements ThreePaneLayout.Callback {
|
|
|
|
@Override
|
2010-11-16 19:11:22 +00:00
|
|
|
public void onVisiblePanesChanged(int previousVisiblePanes) {
|
2010-11-12 00:28:21 +00:00
|
|
|
updateActionBar();
|
2010-11-16 19:11:22 +00:00
|
|
|
final int visiblePanes = mThreePane.getVisiblePanes();
|
|
|
|
if (((visiblePanes & ThreePaneLayout.PANE_RIGHT) == 0) &&
|
|
|
|
((previousVisiblePanes & ThreePaneLayout.PANE_RIGHT) != 0)) {
|
|
|
|
// Message view just got hidden
|
|
|
|
onMessageViewClosed();
|
|
|
|
}
|
2010-11-12 00:28:21 +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
|
|
|
}
|