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;
|
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-02-11 23:05:17 +00:00
|
|
|
import com.android.emailcommon.Logging;
|
2011-02-10 18:26:56 +00:00
|
|
|
import com.android.emailcommon.provider.EmailContent.Account;
|
|
|
|
import com.android.emailcommon.provider.EmailContent.Mailbox;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2010-11-12 00:28:21 +00:00
|
|
|
import android.app.ActionBar;
|
2011-04-01 18:34:03 +00:00
|
|
|
import android.app.Activity;
|
2011-04-19 21:06:03 +00:00
|
|
|
import android.app.Fragment;
|
2010-08-16 18:00:53 +00:00
|
|
|
import android.app.FragmentManager;
|
2011-04-19 21:06:03 +00:00
|
|
|
import android.app.FragmentTransaction;
|
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-09-21 22:36:23 +00:00
|
|
|
import android.view.View;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
|
|
|
import java.security.InvalidParameterException;
|
2011-04-19 21:06:03 +00:00
|
|
|
import java.util.ArrayList;
|
2011-04-13 18:30:56 +00:00
|
|
|
import java.util.Set;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* A class manages what are showing on {@link MessageListXL} (i.e. account id, mailbox id, and
|
|
|
|
* message id), and show/hide fragments accordingly.
|
|
|
|
*
|
2011-04-19 21:06:03 +00:00
|
|
|
* Note: Always use {@link #commitFragmentTransaction} to commit fragment transactions. Currently
|
|
|
|
* we use synchronous transactions only, but we may want to switch back to asynchronous later.
|
|
|
|
*
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
* TODO: Test it. It's testable if we implement MockFragmentTransaction, which may be too early
|
|
|
|
* to do so at this point. (API may not be stable enough yet.)
|
2011-04-01 18:34:03 +00:00
|
|
|
*
|
|
|
|
* TODO Refine "move to".
|
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
|
|
|
class MessageListXLFragmentManager implements
|
|
|
|
MoveMessageToDialog.Callback,
|
|
|
|
MailboxFinder.Callback,
|
|
|
|
ThreePaneLayout.Callback,
|
|
|
|
MailboxListFragment.Callback,
|
|
|
|
MessageListFragment.Callback,
|
|
|
|
MessageViewFragment.Callback {
|
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 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";
|
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/** No account selected */
|
|
|
|
static final long NO_ACCOUNT = -1;
|
|
|
|
/** No mailbox selected */
|
|
|
|
static final long NO_MAILBOX = -1;
|
|
|
|
/** No message selected */
|
|
|
|
static final long NO_MESSAGE = -1;
|
|
|
|
/** Current account id */
|
|
|
|
private long mAccountId = NO_ACCOUNT;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/** Current mailbox id */
|
|
|
|
private long mMailboxId = NO_MAILBOX;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-07 17:48:10 +00:00
|
|
|
/** Current message id */
|
|
|
|
private long mMessageId = NO_MESSAGE;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
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-04-19 21:06:03 +00:00
|
|
|
/**
|
|
|
|
* List of fragments that are restored by the framework while the activity is being re-created
|
|
|
|
* for configuration changes (e.g. screen rotation). We'll install them later when the activity
|
|
|
|
* is created.
|
|
|
|
*/
|
|
|
|
private final ArrayList<Fragment> mRestoredFragments = new ArrayList<Fragment>();
|
|
|
|
|
|
|
|
private boolean mActivityCreated = 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
|
|
|
/**
|
|
|
|
* 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.
|
2011-04-01 18:34:03 +00:00
|
|
|
* TODO Consider getting rid of this. The fragment manager needs an {@link Activity}, so,
|
|
|
|
* merely passing around an interface is not sufficient.
|
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 {
|
2011-04-01 18:34:03 +00:00
|
|
|
/** Implemented by {@link Activity}, so, signature must match */
|
2010-11-12 00:28:21 +00:00
|
|
|
public ActionBar getActionBar();
|
2010-08-16 18:00:53 +00:00
|
|
|
public FragmentManager getFragmentManager();
|
2011-04-01 18:34:03 +00:00
|
|
|
public View findViewById(int id);
|
2010-08-04 23:23:26 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
/** Called when the selected account is on security-hold. */
|
2010-09-09 21:13:47 +00:00
|
|
|
public void onAccountSecurityHold(long accountId);
|
2011-04-01 18:34:03 +00:00
|
|
|
/** Called when the current account has changed. */
|
2011-01-04 22:02:09 +00:00
|
|
|
public void onAccountChanged(long accountId);
|
2011-04-01 18:34:03 +00:00
|
|
|
/** Called when the current mailbox has changed. */
|
2010-09-13 23:35:58 +00:00
|
|
|
public void onMailboxChanged(long accountId, long newMailboxId);
|
2011-04-01 18:34:03 +00:00
|
|
|
/** Called when the current mailbox name / unread count has changed. */
|
|
|
|
public void onMailboxNameChanged(String mailboxName, int unreadCount);
|
|
|
|
/** Called when the visible panes have changed. */
|
|
|
|
public void onVisiblePanesChanged(int visiblePanes);
|
|
|
|
}
|
2010-09-21 22:36:23 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
private final MessageListXL mActivity;
|
2011-01-11 22:36:00 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
public MessageListXLFragmentManager(MessageListXL activity) {
|
|
|
|
mActivity = activity;
|
|
|
|
}
|
2011-01-11 22:36:00 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
// MailboxFinder$Callback
|
|
|
|
@Override
|
|
|
|
public void onAccountNotFound() {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Logging.LOG_TAG, "MessageListXLFragmentManager#onAccountNotFound()");
|
|
|
|
}
|
|
|
|
// Shouldn't happen
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
@Override
|
|
|
|
public void onAccountSecurityHold(long accountId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Logging.LOG_TAG, "MessageListXLFragmentManager#onAccountSecurityHold()");
|
|
|
|
}
|
|
|
|
mActivity.onAccountSecurityHold(accountId);
|
|
|
|
}
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
@Override
|
|
|
|
public void onMailboxFound(long accountId, long mailboxId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Logging.LOG_TAG, "MessageListXLFragmentManager#onMailboxFound()");
|
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageList(mailboxId, true, true);
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMailboxNotFound(long accountId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Logging.LOG_TAG, "MessageListXLFragmentManager#onMailboxNotFound()");
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
// MoveMessageToDialog$Callback
|
|
|
|
@Override
|
|
|
|
public void onMoveToMailboxSelected(long newMailboxId, long[] messageIds) {
|
|
|
|
ActivityHelper.moveMessages(mActivity, newMailboxId, messageIds);
|
|
|
|
onCurrentMessageGone();
|
|
|
|
}
|
|
|
|
|
|
|
|
// ThreePaneLayoutCallback
|
|
|
|
@Override
|
|
|
|
public void onVisiblePanesChanged(int previousVisiblePanes) {
|
|
|
|
final int visiblePanes = mThreePane.getVisiblePanes();
|
|
|
|
mActivity.onVisiblePanesChanged(visiblePanes);
|
|
|
|
if (((visiblePanes & ThreePaneLayout.PANE_RIGHT) == 0) &&
|
|
|
|
((previousVisiblePanes & ThreePaneLayout.PANE_RIGHT) != 0)) {
|
|
|
|
// Message view just got hidden
|
2011-04-07 17:48:10 +00:00
|
|
|
mMessageId = NO_MESSAGE;
|
2011-04-19 21:06:03 +00:00
|
|
|
if (mMessageListFragment != null) {
|
|
|
|
mMessageListFragment.setSelectedMessage(NO_MESSAGE);
|
|
|
|
}
|
|
|
|
uninstallMessageViewFragment(mActivity.getFragmentManager().beginTransaction())
|
|
|
|
.commit();
|
|
|
|
}
|
|
|
|
if (mMessageListFragment != null) {
|
|
|
|
mMessageListFragment.setVisibility((visiblePanes & ThreePaneLayout.PANE_MIDDLE) != 0);
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// MailboxListFragment$Callback
|
|
|
|
@Override
|
2011-04-21 18:50:22 +00:00
|
|
|
public void onMailboxSelected(long accountId, long mailboxId, boolean navigate,
|
|
|
|
boolean dragDrop) {
|
|
|
|
if (dragDrop) {
|
|
|
|
// We don't want to change the message list for D&D.
|
|
|
|
|
|
|
|
// STOPSHIP fixit: the new mailbox list created here doesn't know D&D is in progress.
|
|
|
|
|
|
|
|
updateMailboxList(accountId, mailboxId, true,
|
|
|
|
false /* don't clear message list and message view */);
|
|
|
|
} else if (mailboxId == NO_MAILBOX) {
|
|
|
|
// reload the top-level message list. Always implies navigate.
|
|
|
|
openAccount(accountId);
|
|
|
|
} else if (navigate) {
|
|
|
|
updateMailboxList(accountId, mailboxId, true, true);
|
|
|
|
updateMessageList(mailboxId, true, true);
|
2011-04-07 17:48:10 +00:00
|
|
|
} else {
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageList(mailboxId, true, true);
|
2011-04-07 17:48:10 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onAccountSelected(long accountId) {
|
2011-04-21 18:50:22 +00:00
|
|
|
openAccount(accountId);
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onCurrentMailboxUpdated(long mailboxId, String mailboxName, int unreadCount) {
|
|
|
|
mActivity.onMailboxNameChanged(mailboxName, unreadCount);
|
|
|
|
}
|
|
|
|
|
|
|
|
// 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) {
|
|
|
|
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
|
|
|
|
public void onBeforeMessageDelete() {
|
|
|
|
onCurrentMessageGone();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMoveMessage() {
|
|
|
|
long messageId = getMessageId();
|
|
|
|
MoveMessageToDialog dialog = MoveMessageToDialog.newInstance(new long[] {messageId}, null);
|
|
|
|
dialog.show(mActivity.getFragmentManager(), "dialog");
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onForward() {
|
|
|
|
MessageCompose.actionForward(mActivity, getMessageId());
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onReply() {
|
|
|
|
MessageCompose.actionReply(mActivity, getMessageId(), false);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onReplyAll() {
|
|
|
|
MessageCompose.actionReply(mActivity, getMessageId(), true);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2010-09-21 22:36:23 +00:00
|
|
|
/**
|
|
|
|
* Must be called just after the activity sets up the content view.
|
|
|
|
*
|
|
|
|
* (Due to the complexity regarding class/activity initialization order, we can't do this in
|
2011-04-19 21:06:03 +00:00
|
|
|
* the constructor.) TODO this should no longer be true when we merge activities.
|
2010-09-21 22:36:23 +00:00
|
|
|
*/
|
|
|
|
public void onActivityViewReady() {
|
2010-09-30 01:44:05 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-19 21:06:03 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "MessageListXLFragmentManager onActivityViewReady");
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
mThreePane = (ThreePaneLayout) mActivity.findViewById(R.id.three_pane);
|
|
|
|
mThreePane.setCallback(this);
|
2010-09-30 01:44:05 +00:00
|
|
|
|
2011-01-11 22:36:00 +00:00
|
|
|
mMessageCommandButtons = mThreePane.getMessageCommandButtons();
|
|
|
|
mMessageCommandButtons.setCallback(new CommandButtonCallback());
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2011-01-07 22:49:05 +00:00
|
|
|
/**
|
|
|
|
* @return the currently selected account ID, *or* {@link Account#ACCOUNT_ID_COMBINED_VIEW}.
|
|
|
|
*
|
|
|
|
* @see #getActualAccountId()
|
|
|
|
*/
|
|
|
|
public long getUIAccountId() {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
return mAccountId;
|
|
|
|
}
|
|
|
|
|
2011-01-07 22:49:05 +00:00
|
|
|
/**
|
|
|
|
* @return the currently selected account ID. If the current view is the combined view,
|
2011-04-07 17:48:10 +00:00
|
|
|
* it'll return {@link #NO_ACCOUNT}.
|
2011-01-07 22:49:05 +00:00
|
|
|
*
|
|
|
|
* @see #getUIAccountId()
|
|
|
|
*/
|
|
|
|
public long getActualAccountId() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return mAccountId == Account.ACCOUNT_ID_COMBINED_VIEW ? NO_ACCOUNT : mAccountId;
|
2011-01-07 22:49:05 +00:00
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
public long getMailboxId() {
|
|
|
|
return mMailboxId;
|
|
|
|
}
|
|
|
|
|
|
|
|
public long getMessageId() {
|
|
|
|
return mMessageId;
|
|
|
|
}
|
|
|
|
|
2011-01-07 22:49:05 +00:00
|
|
|
/**
|
|
|
|
* @return true if an account is selected, or the current view is the combined view.
|
|
|
|
*/
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
public boolean isAccountSelected() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return getUIAccountId() != NO_ACCOUNT;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public boolean isMailboxSelected() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return getMailboxId() != NO_MAILBOX;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
public boolean isMessageSelected() {
|
2011-04-07 17:48:10 +00:00
|
|
|
return getMessageId() != NO_MESSAGE;
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
/**
|
|
|
|
* Called at the end of {@link MessageListXL#onCreate}.
|
|
|
|
*/
|
|
|
|
public void onActivityCreated() {
|
|
|
|
mActivityCreated = true;
|
|
|
|
|
|
|
|
// Install all the fragments restored by the framework.
|
|
|
|
for (Fragment fragment : mRestoredFragments) {
|
|
|
|
installFragment(fragment);
|
|
|
|
}
|
|
|
|
mRestoredFragments.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Called by {@link MessageListXL} when a {@link Fragment} is attached.
|
|
|
|
*
|
|
|
|
* If the activity has already been created, we initialize the fragment here. Otherwise we
|
|
|
|
* keep the fragment in {@link #mRestoredFragments} and initialize it after the activity's
|
|
|
|
* onCreate.
|
|
|
|
*/
|
|
|
|
public void onAttachFragment(Fragment fragment) {
|
|
|
|
if (!mActivityCreated) {
|
|
|
|
// Fragment being restored by the framework during the activity recreation.
|
|
|
|
mRestoredFragments.add(fragment);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
installFragment(fragment);
|
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
/**
|
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() {
|
2011-04-01 18:34:03 +00:00
|
|
|
if (isMessageSelected()) {
|
|
|
|
updateMessageOrderManager();
|
|
|
|
}
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Called from {@link MessageListXL#onResume}.
|
|
|
|
*/
|
|
|
|
public void onResume() {
|
2011-04-01 18:34:03 +00:00
|
|
|
int visiblePanes = mThreePane.getVisiblePanes();
|
|
|
|
mActivity.onVisiblePanesChanged(visiblePanes);
|
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() {
|
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() {
|
2011-04-01 18:34:03 +00:00
|
|
|
stopMessageOrderManager();
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Called from {@link MessageListXL#onDestroy}.
|
|
|
|
*/
|
|
|
|
public void onDestroy() {
|
2011-04-19 21:06:03 +00:00
|
|
|
mActivityCreated = false;
|
2010-09-30 01:44:05 +00:00
|
|
|
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) {
|
2011-04-19 21:06:03 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Logging.LOG_TAG, "MessageListXLFragmentManager onSaveInstanceState");
|
|
|
|
}
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
outState.putLong(BUNDLE_KEY_ACCOUNT_ID, mAccountId);
|
|
|
|
outState.putLong(BUNDLE_KEY_MAILBOX_ID, mMailboxId);
|
|
|
|
outState.putLong(BUNDLE_KEY_MESSAGE_ID, mMessageId);
|
|
|
|
}
|
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
public void restoreInstanceState(Bundle savedInstanceState) {
|
2010-12-14 00:32:02 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-19 21:06:03 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "MessageListXLFragmentManager restoreInstanceState");
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
mAccountId = savedInstanceState.getLong(BUNDLE_KEY_ACCOUNT_ID, NO_ACCOUNT);
|
|
|
|
mMailboxId = savedInstanceState.getLong(BUNDLE_KEY_MAILBOX_ID, NO_MAILBOX);
|
|
|
|
mMessageId = savedInstanceState.getLong(BUNDLE_KEY_MESSAGE_ID, NO_MESSAGE);
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// STOPSHIP If MailboxFinder is still running, it needs restarting after loadState().
|
|
|
|
// This probably means we need to start MailboxFinder if mMailboxId == -1.
|
2011-04-19 21:06:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
private void installFragment(Fragment fragment) {
|
|
|
|
if (fragment instanceof MailboxListFragment) {
|
|
|
|
mMailboxListFragment = (MailboxListFragment) fragment;
|
|
|
|
mMailboxListFragment.setCallback(this);
|
|
|
|
} else if (fragment instanceof MessageListFragment) {
|
|
|
|
mMessageListFragment = (MessageListFragment) fragment;
|
|
|
|
mMessageListFragment.setCallback(this);
|
|
|
|
} else if (fragment instanceof MessageViewFragment) {
|
|
|
|
mMessageViewFragment = (MessageViewFragment) fragment;
|
|
|
|
mMessageViewFragment.setCallback(this);
|
|
|
|
} else {
|
|
|
|
// Ignore -- uninteresting fragments such as dialogs.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private FragmentTransaction uninstallMailboxListFragment(FragmentTransaction ft) {
|
|
|
|
if (mMailboxListFragment != null) {
|
|
|
|
ft.remove(mMailboxListFragment);
|
|
|
|
mMailboxListFragment.setCallback(null);
|
|
|
|
mMailboxListFragment = null;
|
2010-09-30 01:44:05 +00:00
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
return ft;
|
|
|
|
}
|
|
|
|
|
|
|
|
private FragmentTransaction uninstallMessageListFragment(FragmentTransaction ft) {
|
|
|
|
if (mMessageListFragment != null) {
|
|
|
|
ft.remove(mMessageListFragment);
|
|
|
|
mMessageListFragment.setCallback(null);
|
|
|
|
mMessageListFragment = null;
|
|
|
|
}
|
|
|
|
return ft;
|
|
|
|
}
|
|
|
|
|
|
|
|
private FragmentTransaction uninstallMessageViewFragment(FragmentTransaction ft) {
|
|
|
|
if (mMessageViewFragment != null) {
|
|
|
|
ft.remove(mMessageViewFragment);
|
|
|
|
mMessageViewFragment.setCallback(null);
|
|
|
|
mMessageViewFragment = null;
|
|
|
|
}
|
|
|
|
return ft;
|
|
|
|
}
|
|
|
|
|
|
|
|
private void commitFragmentTransaction(FragmentTransaction ft) {
|
|
|
|
ft.commit();
|
|
|
|
mActivity.getFragmentManager().executePendingTransactions();
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-21 18:50:22 +00:00
|
|
|
* Show the default view for the account.
|
|
|
|
*
|
|
|
|
* On two-pane, it's the account's root mailboxes on the left pane with Inbox on the right pane.
|
|
|
|
*
|
|
|
|
* @param accountId ID of the account to load. Can be {@link Account#ACCOUNT_ID_COMBINED_VIEW}.
|
|
|
|
* Must never be {@link #NO_ACCOUNT}.
|
|
|
|
*/
|
|
|
|
public void openAccount(long accountId) {
|
|
|
|
open(accountId, NO_MAILBOX, NO_MESSAGE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Loads the given account and optionally selects the given mailbox and message. Used to open
|
|
|
|
* a particular view at a request from outside of the activity, such as the widget.
|
|
|
|
*
|
|
|
|
* @param accountId ID of the account to load. Can be {@link Account#ACCOUNT_ID_COMBINED_VIEW}.
|
|
|
|
* Must never be {@link #NO_ACCOUNT}.
|
2011-04-07 17:48:10 +00:00
|
|
|
* @param mailboxId ID of the mailbox to load. If {@link #NO_MAILBOX}, load the account's inbox.
|
|
|
|
* @param messageId ID of the message to load. If {@link #NO_MESSAGE}, do not open a message.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
public void open(long accountId, long mailboxId, long messageId) {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Logging.LOG_TAG, "open accountId=" + accountId + " mailboxId=" + mailboxId
|
|
|
|
+ " messageId=" + messageId);
|
|
|
|
}
|
|
|
|
if (accountId == NO_ACCOUNT) {
|
|
|
|
throw new IllegalArgumentException();
|
|
|
|
} else if (mailboxId == NO_MAILBOX) {
|
|
|
|
updateMailboxList(accountId, NO_MAILBOX, true, true);
|
|
|
|
|
|
|
|
// Show the appropriate message list
|
|
|
|
if (accountId == Account.ACCOUNT_ID_COMBINED_VIEW) {
|
|
|
|
// When opening the Combined view, the right pane will be "combined inbox".
|
|
|
|
updateMessageList(Mailbox.QUERY_ALL_INBOXES, true, true);
|
|
|
|
} else {
|
|
|
|
// Try to find the inbox for the account
|
|
|
|
closeMailboxFinder();
|
|
|
|
mMailboxFinder = new MailboxFinder(mActivity, mAccountId, Mailbox.TYPE_INBOX, this);
|
|
|
|
mMailboxFinder.startLookup();
|
|
|
|
}
|
|
|
|
} else if (messageId == NO_MESSAGE) {
|
|
|
|
// STOPSHIP Use the appropriate parent mailbox ID
|
|
|
|
updateMailboxList(accountId, NO_MAILBOX, true, true);
|
|
|
|
updateMessageList(mailboxId, true, true);
|
|
|
|
} else {
|
|
|
|
// STOPSHIP Use the appropriate parent mailbox ID
|
|
|
|
updateMailboxList(accountId, NO_MAILBOX, false, true);
|
|
|
|
updateMessageList(mailboxId, false, true);
|
|
|
|
updateMessageView(messageId);
|
|
|
|
}
|
2011-04-07 17:48:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Loads the given account and optionally selects the given mailbox and message. If the
|
|
|
|
* specified account is already selected, no actions will be performed unless
|
|
|
|
* <code>forceReload</code> is <code>true</code>.
|
2011-04-21 18:50:22 +00:00
|
|
|
*
|
2011-04-07 17:48:10 +00:00
|
|
|
* @param accountId ID of the account to load. Must never be {@link #NO_ACCOUNT}.
|
2011-04-21 18:50:22 +00:00
|
|
|
* @param parentMailboxId ID of the mailbox to use as the parent mailbox. Pass
|
|
|
|
* {@link #NO_MAILBOX} to show the root mailboxes.
|
|
|
|
* @param changeVisiblePane if true, the message view will be hidden.
|
|
|
|
* @param clearDependentPane if true, the message list and the message view will be cleared
|
2011-04-07 17:48:10 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// TODO The name "updateMailboxList" is misleading, as it also updates members such as
|
|
|
|
// mAccountId. We need better structure but let's do that after refactoring
|
|
|
|
// MailboxListFragment.onMailboxSelected, and removed the UI callbacks such as
|
|
|
|
// TargetActivity.onAccountChanged.
|
|
|
|
|
|
|
|
private void updateMailboxList(long accountId, long parentMailboxId,
|
|
|
|
boolean changeVisiblePane, boolean clearDependentPane) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-21 18:50:22 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "updateMailboxList accountId=" + accountId + " parentMailboxId="
|
|
|
|
+ parentMailboxId);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
2011-04-07 17:48:10 +00:00
|
|
|
if (accountId == NO_ACCOUNT) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
|
|
|
|
2011-04-21 18:50:22 +00:00
|
|
|
// TODO Check if the current fragment has been initialized with the same parameters, and
|
|
|
|
// then return.
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
mAccountId = accountId;
|
|
|
|
|
2011-04-19 21:06:03 +00:00
|
|
|
// Open mailbox list, remove message list / message view
|
|
|
|
final FragmentManager fm = mActivity.getFragmentManager();
|
|
|
|
final FragmentTransaction ft = fm.beginTransaction();
|
|
|
|
uninstallMailboxListFragment(ft);
|
2011-04-21 18:50:22 +00:00
|
|
|
if (clearDependentPane) {
|
|
|
|
mMailboxId = NO_MAILBOX;
|
|
|
|
mMessageId = NO_MESSAGE;
|
|
|
|
uninstallMessageListFragment(ft);
|
|
|
|
uninstallMessageViewFragment(ft);
|
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
ft.add(mThreePane.getLeftPaneId(),
|
2011-04-21 18:50:22 +00:00
|
|
|
MailboxListFragment.newInstance(getUIAccountId(), parentMailboxId));
|
2011-04-19 21:06:03 +00:00
|
|
|
commitFragmentTransaction(ft);
|
2010-08-31 20:13:44 +00:00
|
|
|
|
2011-04-21 18:50:22 +00:00
|
|
|
if (changeVisiblePane) {
|
|
|
|
mThreePane.showLeftPane();
|
2010-08-25 02:09:34 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
mActivity.onAccountChanged(mAccountId);
|
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
|
|
|
/**
|
2011-04-01 18:34:03 +00:00
|
|
|
* Go back to a mailbox list view. If a message view is currently active, it will
|
|
|
|
* be hidden.
|
2010-08-31 20:13:44 +00:00
|
|
|
*/
|
2011-04-01 18:34:03 +00:00
|
|
|
private void goBackToMailbox() {
|
2010-08-31 20:13:44 +00:00
|
|
|
if (isMessageSelected()) {
|
2010-11-29 22:46:27 +00:00
|
|
|
mThreePane.showLeftPane(); // Show mailbox list
|
2010-08-31 20:13:44 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
/**
|
2011-04-07 17:48:10 +00:00
|
|
|
* Selects the specified mailbox and optionally loads a message within it. If a message is
|
|
|
|
* not loaded, a list of the messages contained within the mailbox is shown. Otherwise the
|
|
|
|
* given message is shown. If <code>navigateToMailbox<code> is <code>true</code>, the
|
|
|
|
* mailbox is navigated to and any contained mailboxes are shown.
|
2010-08-11 22:28:31 +00:00
|
|
|
*
|
2011-04-07 17:48:10 +00:00
|
|
|
* @param mailboxId ID of the mailbox to load. Must never be <code>0</code> or <code>-1</code>.
|
2011-04-21 18:50:22 +00:00
|
|
|
* @param changeVisiblePane if true, the message view will be hidden.
|
|
|
|
* @param clearDependentPane if true, the message view will be cleared
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
private void updateMessageList(long mailboxId, boolean changeVisiblePane,
|
|
|
|
boolean clearDependentPane) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-21 18:50:22 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "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-07 17:48:10 +00:00
|
|
|
if (mailboxId == 0 || mailboxId == -1) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// TODO Check if the current fragment has been initialized with the same parameters, and
|
|
|
|
// then return.
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
mMailboxId = mailboxId;
|
2011-04-19 21:06:03 +00:00
|
|
|
|
|
|
|
final FragmentManager fm = mActivity.getFragmentManager();
|
|
|
|
final FragmentTransaction ft = fm.beginTransaction();
|
|
|
|
uninstallMessageListFragment(ft);
|
2011-04-21 18:50:22 +00:00
|
|
|
if (clearDependentPane) {
|
|
|
|
uninstallMessageViewFragment(ft);
|
|
|
|
mMessageId = NO_MESSAGE;
|
|
|
|
}
|
2011-04-19 21:06:03 +00:00
|
|
|
ft.add(mThreePane.getMiddlePaneId(), MessageListFragment.newInstance(mailboxId));
|
|
|
|
commitFragmentTransaction(ft);
|
|
|
|
|
2011-04-21 18:50:22 +00:00
|
|
|
mMailboxListFragment.setSelectedMailbox(mailboxId);
|
2011-04-07 17:48:10 +00:00
|
|
|
mActivity.onMailboxChanged(mAccountId, mailboxId);
|
2011-04-01 18:34:03 +00:00
|
|
|
|
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
|
|
|
}
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2011-04-21 18:50:22 +00:00
|
|
|
* Show a message on the message view.
|
|
|
|
*
|
|
|
|
* @param messageId ID of the mailbox to load. Must never be {@link #NO_MESSAGE}.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
*/
|
2011-04-21 18:50:22 +00:00
|
|
|
private void updateMessageView(long messageId) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
2011-04-21 18:50:22 +00:00
|
|
|
Log.d(Logging.LOG_TAG, "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-07 17:48:10 +00:00
|
|
|
if (messageId == NO_MESSAGE) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
2011-04-21 18:50:22 +00:00
|
|
|
|
|
|
|
// TODO Check if the current fragment has been initialized with the same parameters, and
|
|
|
|
// then return.
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
// Update member
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
mMessageId = messageId;
|
|
|
|
|
2010-09-30 01:44:05 +00:00
|
|
|
// Open message
|
2010-09-22 01:20:30 +00:00
|
|
|
mMessageListFragment.setSelectedMessage(mMessageId);
|
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
|
2010-09-21 22:36:23 +00:00
|
|
|
}
|
|
|
|
|
2010-08-04 23:23:26 +00:00
|
|
|
private void closeMailboxFinder() {
|
|
|
|
if (mMailboxFinder != null) {
|
2010-08-27 17:16:08 +00:00
|
|
|
mMailboxFinder.cancel();
|
2010-08-04 23:23:26 +00:00
|
|
|
mMailboxFinder = null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
private class CommandButtonCallback implements MessageCommandButtonView.Callback {
|
2010-08-04 23:23:26 +00:00
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMoveToNewer() {
|
2011-04-13 18:30:56 +00:00
|
|
|
moveToNewer();
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMoveToOlder() {
|
2011-04-13 18:30:56 +00:00
|
|
|
moveToOlder();
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private void onCurrentMessageGone() {
|
|
|
|
switch (Preferences.getPreferences(mActivity).getAutoAdvanceDirection()) {
|
|
|
|
case Preferences.AUTO_ADVANCE_NEWER:
|
2011-04-13 18:30:56 +00:00
|
|
|
if (moveToNewer()) return;
|
2011-04-01 18:34:03 +00:00
|
|
|
break;
|
|
|
|
case Preferences.AUTO_ADVANCE_OLDER:
|
2011-04-13 18:30:56 +00:00
|
|
|
if (moveToOlder()) return;
|
2011-04-01 18:34:03 +00:00
|
|
|
break;
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
// Last message in the box or AUTO_ADVANCE_MESSAGE_LIST. Go back to message list.
|
|
|
|
goBackToMailbox();
|
|
|
|
}
|
2010-08-04 23:23:26 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
/**
|
|
|
|
* Potentially create a new {@link MessageOrderManager}; if it's not already started or if
|
|
|
|
* the account has changed, and sync it to the current message.
|
|
|
|
*/
|
|
|
|
private void updateMessageOrderManager() {
|
|
|
|
if (!isMailboxSelected()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
final long mailboxId = getMailboxId();
|
|
|
|
if (mOrderManager == null || mOrderManager.getMailboxId() != mailboxId) {
|
|
|
|
stopMessageOrderManager();
|
|
|
|
mOrderManager =
|
|
|
|
new MessageOrderManager(mActivity, mailboxId, mMessageOrderManagerCallback);
|
|
|
|
}
|
|
|
|
if (isMessageSelected()) {
|
|
|
|
mOrderManager.moveTo(getMessageId());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
private class MessageOrderManagerCallback implements MessageOrderManager.Callback {
|
2010-08-04 23:23:26 +00:00
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMessagesChanged() {
|
|
|
|
updateNavigationArrows();
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
2011-04-01 18:34:03 +00:00
|
|
|
public void onMessageNotFound() {
|
|
|
|
// Current message gone.
|
|
|
|
goBackToMailbox();
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
}
|
2010-11-12 00:28:21 +00:00
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
/**
|
|
|
|
* Stop {@link MessageOrderManager}.
|
|
|
|
*/
|
|
|
|
private void stopMessageOrderManager() {
|
|
|
|
if (mOrderManager != null) {
|
|
|
|
mOrderManager.close();
|
|
|
|
mOrderManager = null;
|
|
|
|
}
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
|
|
|
|
2011-04-01 18:34:03 +00:00
|
|
|
/**
|
|
|
|
* Disable/enable the move-to-newer/older buttons.
|
|
|
|
*/
|
|
|
|
private void updateNavigationArrows() {
|
|
|
|
if (mOrderManager == null) {
|
|
|
|
// shouldn't happen, but just in case
|
|
|
|
mMessageCommandButtons.enableNavigationButtons(false, false, 0, 0);
|
|
|
|
} else {
|
|
|
|
mMessageCommandButtons.enableNavigationButtons(
|
|
|
|
mOrderManager.canMoveToNewer(), mOrderManager.canMoveToOlder(),
|
|
|
|
mOrderManager.getCurrentPosition(), mOrderManager.getTotalMessageCount());
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
}
|
2011-01-11 22:36:00 +00:00
|
|
|
|
2011-04-13 18:30:56 +00:00
|
|
|
private boolean moveToOlder() {
|
|
|
|
if ((mOrderManager != null) && mOrderManager.moveToOlder()) {
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageView(mOrderManager.getCurrentMessageId());
|
2011-04-01 18:34:03 +00:00
|
|
|
return true;
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
return false;
|
2011-01-11 22:36:00 +00:00
|
|
|
}
|
|
|
|
|
2011-04-13 18:30:56 +00:00
|
|
|
private boolean moveToNewer() {
|
|
|
|
if ((mOrderManager != null) && mOrderManager.moveToNewer()) {
|
2011-04-21 18:50:22 +00:00
|
|
|
updateMessageView(mOrderManager.getCurrentMessageId());
|
2011-04-01 18:34:03 +00:00
|
|
|
return true;
|
2010-11-12 00:28:21 +00:00
|
|
|
}
|
2011-04-01 18:34:03 +00:00
|
|
|
return false;
|
2010-11-12 00:28:21 +00:00
|
|
|
}
|
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
|
|
|
}
|