2010-07-21 21:29:49 +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;
|
|
|
|
|
2010-08-27 17:25:03 +00:00
|
|
|
import com.android.email.Clock;
|
2010-07-21 21:29:49 +00:00
|
|
|
import com.android.email.Email;
|
2010-09-10 00:23:53 +00:00
|
|
|
import com.android.email.Preferences;
|
2010-07-21 21:29:49 +00:00
|
|
|
import com.android.email.R;
|
2010-08-18 23:47:42 +00:00
|
|
|
import com.android.email.RefreshManager;
|
2010-08-06 21:49:57 +00:00
|
|
|
import com.android.email.Utility;
|
2010-09-09 21:13:47 +00:00
|
|
|
import com.android.email.activity.setup.AccountSecurity;
|
2010-08-18 23:47:42 +00:00
|
|
|
import com.android.email.activity.setup.AccountSettingsXL;
|
2010-08-27 17:25:03 +00:00
|
|
|
import com.android.email.provider.EmailContent.Account;
|
2010-08-25 02:09:34 +00:00
|
|
|
import com.android.email.provider.EmailContent.Mailbox;
|
2010-07-21 21:29:49 +00:00
|
|
|
|
2010-07-28 18:42:37 +00:00
|
|
|
import android.app.ActionBar;
|
2010-07-21 21:29:49 +00:00
|
|
|
import android.app.Activity;
|
|
|
|
import android.app.LoaderManager.LoaderCallbacks;
|
|
|
|
import android.content.Context;
|
2010-08-04 22:38:25 +00:00
|
|
|
import android.content.Intent;
|
2010-07-21 21:29:49 +00:00
|
|
|
import android.content.Loader;
|
2010-07-28 18:42:37 +00:00
|
|
|
import android.database.Cursor;
|
2010-08-27 17:25:03 +00:00
|
|
|
import android.os.AsyncTask;
|
2010-07-21 21:29:49 +00:00
|
|
|
import android.os.Bundle;
|
|
|
|
import android.util.Log;
|
2010-08-04 23:54:08 +00:00
|
|
|
import android.view.Menu;
|
|
|
|
import android.view.MenuItem;
|
2010-07-21 21:29:49 +00:00
|
|
|
|
2010-08-25 02:09:34 +00:00
|
|
|
import java.security.InvalidParameterException;
|
|
|
|
|
2010-07-21 21:29:49 +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
|
|
|
* The main (two-pane) activity for XL devices.
|
2010-08-04 22:43:55 +00:00
|
|
|
*
|
Let MessageViewFragment own bottom buttons.
Create a custom view containing the bottons below MVF
(delete, move, reply, etc) and let MVF own this.
These buttons used to be owned by the XL activity itself, because
the UI for these commands will most likely be totally different
from the tablet UI, so the fragment having them looked wrong.
However, this made it harder to make changes suggested by the latest
mock, such as "put reply/forward in the message header".
I think the buttons are semantically part of the message view anyway,
so the fragment owning UI for these commands is probably the way to go.
(And let's worry about the phone UI later.)
Reason for the use of a custom view is that it will make it easier
to make non-trivial UI changes, e.g. "combine reply, reply-all and
forward and make it dropdown."
Also removed obsolete TODOs from MessageListXL.
Change-Id: Ibf93f4c70fe07bdbbe33d2adb6bbd2b96812830d
2010-09-16 18:16:46 +00:00
|
|
|
* TODO Refine "move to".
|
2010-07-21 21:29:49 +00:00
|
|
|
*/
|
Let MessageViewFragment own bottom buttons.
Create a custom view containing the bottons below MVF
(delete, move, reply, etc) and let MVF own this.
These buttons used to be owned by the XL activity itself, because
the UI for these commands will most likely be totally different
from the tablet UI, so the fragment having them looked wrong.
However, this made it harder to make changes suggested by the latest
mock, such as "put reply/forward in the message header".
I think the buttons are semantically part of the message view anyway,
so the fragment owning UI for these commands is probably the way to go.
(And let's worry about the phone UI later.)
Reason for the use of a custom view is that it will make it easier
to make non-trivial UI changes, e.g. "combine reply, reply-all and
forward and make it dropdown."
Also removed obsolete TODOs from MessageListXL.
Change-Id: Ibf93f4c70fe07bdbbe33d2adb6bbd2b96812830d
2010-09-16 18:16:46 +00:00
|
|
|
public class MessageListXL extends Activity implements
|
2010-08-25 16:53:19 +00:00
|
|
|
MessageListXLFragmentManager.TargetActivity, MoveMessageToDialog.Callback {
|
2010-08-25 02:09:34 +00:00
|
|
|
private static final String EXTRA_ACCOUNT_ID = "ACCOUNT_ID";
|
|
|
|
private static final String EXTRA_MAILBOX_ID = "MAILBOX_ID";
|
2010-07-28 18:42:37 +00:00
|
|
|
private static final int LOADER_ID_ACCOUNT_LIST = 0;
|
2010-08-27 17:25:03 +00:00
|
|
|
/* package */ static final int MAILBOX_REFRESH_MIN_INTERVAL = 30 * 1000; // in milliseconds
|
|
|
|
/* package */ static final int INBOX_AUTO_REFRESH_MIN_INTERVAL = 10 * 1000; // in milliseconds
|
2010-07-21 21:29:49 +00:00
|
|
|
|
|
|
|
private Context mContext;
|
2010-08-16 21:14:40 +00:00
|
|
|
private RefreshManager mRefreshManager;
|
|
|
|
private final RefreshListener mMailRefreshManagerListener
|
|
|
|
= new RefreshListener();
|
2010-07-21 21:29:49 +00:00
|
|
|
|
2010-07-28 18:42:37 +00:00
|
|
|
private AccountSelectorAdapter mAccountsSelectorAdapter;
|
|
|
|
private final ActionBarNavigationCallback mActionBarNavigationCallback
|
|
|
|
= new ActionBarNavigationCallback();
|
|
|
|
|
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 MessageOrderManager mOrderManager;
|
2010-07-21 21:29:49 +00:00
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private final MessageListXLFragmentManager mFragmentManager
|
|
|
|
= new MessageListXLFragmentManager(this);
|
2010-07-21 21:29:49 +00:00
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private final MessageOrderManagerCallback mMessageOrderManagerCallback
|
|
|
|
= new MessageOrderManagerCallback();
|
2010-07-21 21:29:49 +00:00
|
|
|
|
2010-08-27 17:25:03 +00:00
|
|
|
private RefreshTask mRefreshTask;
|
|
|
|
|
2010-08-09 23:17:53 +00:00
|
|
|
/**
|
|
|
|
* Launch and open account's inbox.
|
2010-08-25 02:09:34 +00:00
|
|
|
*
|
|
|
|
* @param accountId If -1, default account will be used.
|
2010-08-09 23:17:53 +00:00
|
|
|
*/
|
2010-08-25 02:09:34 +00:00
|
|
|
public static void actionOpenAccount(Activity fromActivity, long accountId) {
|
2010-08-09 23:17:53 +00:00
|
|
|
Intent i = new Intent(fromActivity, MessageListXL.class);
|
|
|
|
if (accountId != -1) {
|
|
|
|
i.putExtra(EXTRA_ACCOUNT_ID, accountId);
|
|
|
|
}
|
2010-08-25 02:09:34 +00:00
|
|
|
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
|
|
|
|
fromActivity.startActivity(i);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Launch and open a mailbox.
|
|
|
|
*
|
|
|
|
* @param accountId must not be -1.
|
|
|
|
* @param mailboxId must not be -1.
|
|
|
|
*/
|
|
|
|
public static void actionOpenMailbox(Activity fromActivity, long accountId, long mailboxId) {
|
|
|
|
Intent i = new Intent(fromActivity, MessageListXL.class);
|
|
|
|
if (accountId == -1 || mailboxId == -1) {
|
|
|
|
throw new InvalidParameterException();
|
|
|
|
}
|
|
|
|
i.putExtra(EXTRA_ACCOUNT_ID, accountId);
|
|
|
|
i.putExtra(EXTRA_MAILBOX_ID, Mailbox.QUERY_ALL_INBOXES);
|
|
|
|
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
|
2010-08-09 23:17:53 +00:00
|
|
|
fromActivity.startActivity(i);
|
2010-08-04 22:38:25 +00:00
|
|
|
}
|
|
|
|
|
2010-07-21 21:29:49 +00:00
|
|
|
@Override
|
|
|
|
protected void onCreate(Bundle savedInstanceState) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) Log.d(Email.LOG_TAG, "MessageListXL onCreate");
|
2010-07-21 21:29:49 +00:00
|
|
|
super.onCreate(savedInstanceState);
|
2010-11-01 23:15:15 +00:00
|
|
|
ActivityHelper.debugSetWindowFlags(this);
|
2010-07-21 21:29:49 +00:00
|
|
|
setContentView(R.layout.message_list_xl);
|
2010-09-21 22:36:23 +00:00
|
|
|
mFragmentManager.onActivityViewReady();
|
2010-07-21 21:29:49 +00:00
|
|
|
|
|
|
|
final boolean isRestoring = (savedInstanceState != null);
|
|
|
|
|
|
|
|
mContext = getApplicationContext();
|
2010-08-16 21:14:40 +00:00
|
|
|
mRefreshManager = RefreshManager.getInstance(this);
|
|
|
|
mRefreshManager.registerListener(mMailRefreshManagerListener);
|
2010-07-21 21:29:49 +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
|
|
|
mFragmentManager.setMailboxListFragmentCallback(new MailboxListFragmentCallback());
|
|
|
|
mFragmentManager.setMessageListFragmentCallback(new MessageListFragmentCallback());
|
|
|
|
mFragmentManager.setMessageViewFragmentCallback(new MessageViewFragmentCallback());
|
2010-07-21 21:29:49 +00:00
|
|
|
|
2010-07-28 18:42:37 +00:00
|
|
|
mAccountsSelectorAdapter = new AccountSelectorAdapter(mContext, null);
|
|
|
|
|
2010-07-21 21:29:49 +00:00
|
|
|
if (isRestoring) {
|
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
|
|
|
mFragmentManager.loadState(savedInstanceState);
|
2010-08-09 23:17:53 +00:00
|
|
|
} else {
|
|
|
|
initFromIntent();
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
2010-07-28 18:42:37 +00:00
|
|
|
loadAccounts();
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
2010-08-09 23:17:53 +00:00
|
|
|
private void initFromIntent() {
|
|
|
|
final Intent i = getIntent();
|
|
|
|
final long accountId = i.getLongExtra(EXTRA_ACCOUNT_ID, -1);
|
2010-08-25 02:09:34 +00:00
|
|
|
final long mailboxId = i.getLongExtra(EXTRA_MAILBOX_ID, -1);
|
|
|
|
if (Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG,
|
|
|
|
String.format("Welcome: %d %d", accountId, mailboxId));
|
|
|
|
}
|
|
|
|
|
2010-08-09 23:17:53 +00:00
|
|
|
if (accountId != -1) {
|
2010-08-25 02:09:34 +00:00
|
|
|
mFragmentManager.selectAccount(accountId, mailboxId, true);
|
2010-08-09 23:17:53 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-21 21:29:49 +00:00
|
|
|
@Override
|
|
|
|
protected void onSaveInstanceState(Bundle outState) {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "MessageListXL onSaveInstanceState");
|
|
|
|
}
|
2010-07-21 21:29:49 +00:00
|
|
|
super.onSaveInstanceState(outState);
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
mFragmentManager.onSaveInstanceState(outState);
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
protected void 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
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) Log.d(Email.LOG_TAG, "MessageListXL onStart");
|
2010-07-21 21:29:49 +00:00
|
|
|
super.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
|
|
|
mFragmentManager.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
|
|
|
if (mFragmentManager.isMessageSelected()) {
|
|
|
|
updateMessageOrderManager();
|
|
|
|
}
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
protected void onResume() {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) Log.d(Email.LOG_TAG, "MessageListXL onResume");
|
2010-07-21 21:29:49 +00:00
|
|
|
super.onResume();
|
2010-08-25 02:09:34 +00:00
|
|
|
|
2010-09-08 18:05:25 +00:00
|
|
|
// On MessageList.onResume, we go back to Welcome if an account has been added/removed.
|
|
|
|
// We don't need to do that here, because when the activity resumes, the account list loader
|
|
|
|
// will load the latest list.
|
2010-10-08 18:29:57 +00:00
|
|
|
// And if all the accounts have been removed, the loader will detect it and do
|
|
|
|
// appropriate things.
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
protected 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
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) Log.d(Email.LOG_TAG, "MessageListXL onPause");
|
2010-07-21 21:29:49 +00:00
|
|
|
super.onPause();
|
2010-09-30 01:44:05 +00:00
|
|
|
mFragmentManager.onPause();
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
protected void onStop() {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) Log.d(Email.LOG_TAG, "MessageListXL onStop");
|
2010-07-21 21:29:49 +00:00
|
|
|
super.onStop();
|
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
|
|
|
|
|
|
|
mFragmentManager.onStop();
|
2010-07-21 21:29:49 +00:00
|
|
|
stopMessageOrderManager();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
protected void onDestroy() {
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) Log.d(Email.LOG_TAG, "MessageListXL onDestroy");
|
2010-08-27 17:25:03 +00:00
|
|
|
Utility.cancelTaskInterrupt(mRefreshTask);
|
2010-08-16 21:14:40 +00:00
|
|
|
mRefreshManager.unregisterListener(mMailRefreshManagerListener);
|
2010-09-30 01:44:05 +00:00
|
|
|
mFragmentManager.onDestroy();
|
2010-07-21 21:29:49 +00:00
|
|
|
super.onDestroy();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
@Override
|
|
|
|
public void onBackPressed() {
|
|
|
|
if (Email.DEBUG_LIFECYCLE && Email.DEBUG) {
|
|
|
|
Log.d(Email.LOG_TAG, "MessageListXL onBackPressed");
|
|
|
|
}
|
|
|
|
if (mFragmentManager.isMessageSelected()) {
|
|
|
|
// Go back to the message list.
|
2010-08-31 20:13:44 +00:00
|
|
|
// We currently don't use the built-in back mechanism.
|
|
|
|
// It'd be nice if we could make use of it, but the semantics of the built-in back is
|
|
|
|
// a bit different from how we do it in MessageListXLFragmentManager.
|
|
|
|
// Switching to the built-in back will probably require re-writing
|
|
|
|
// MessageListXLFragmentManager quite a bit.
|
|
|
|
mFragmentManager.goBackToMailbox();
|
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
|
|
|
} else {
|
|
|
|
// Perform the default behavior == close the activity.
|
|
|
|
super.onBackPressed();
|
2010-07-21 21:29:49 +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
|
|
|
|
2010-09-10 00:23:53 +00:00
|
|
|
private void onCurrentMessageGone() {
|
|
|
|
switch (Preferences.getPreferences(this).getAutoAdvanceDirection()) {
|
|
|
|
case Preferences.AUTO_ADVANCE_NEWER:
|
|
|
|
if (moveToNewer()) return;
|
|
|
|
if (moveToOlder()) return;
|
|
|
|
break;
|
|
|
|
case Preferences.AUTO_ADVANCE_OLDER:
|
|
|
|
if (moveToOlder()) return;
|
|
|
|
if (moveToNewer()) return;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
// Last message in the box or AUTO_ADVANCE_MESSAGE_LIST. Go back to message list.
|
|
|
|
mFragmentManager.goBackToMailbox();
|
2010-08-17 22:07:28 +00:00
|
|
|
}
|
|
|
|
|
2010-08-25 16:53:19 +00:00
|
|
|
private void onMoveMessage() {
|
|
|
|
long messageId = mFragmentManager.getMessageId();
|
2010-09-02 21:49:36 +00:00
|
|
|
MoveMessageToDialog dialog = MoveMessageToDialog.newInstance(this, new long[] {messageId},
|
|
|
|
null);
|
2010-08-25 16:53:19 +00:00
|
|
|
dialog.show(getFragmentManager(), "dialog");
|
|
|
|
}
|
|
|
|
|
2010-09-02 21:49:36 +00:00
|
|
|
@Override
|
|
|
|
public void onMoveToMailboxSelected(long newMailboxId, long[] messageIds) {
|
|
|
|
ActivityHelper.moveMessages(this, newMailboxId, messageIds);
|
2010-09-13 21:27:13 +00:00
|
|
|
onCurrentMessageGone();
|
2010-09-02 21:49:36 +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
|
|
|
/**
|
|
|
|
* Start {@link MessageOrderManager} if not started, and sync it to the current message.
|
|
|
|
*/
|
|
|
|
private void updateMessageOrderManager() {
|
|
|
|
if (!mFragmentManager.isMailboxSelected()) {
|
2010-07-21 21:29:49 +00:00
|
|
|
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
|
|
|
final long mailboxId = mFragmentManager.getMailboxId();
|
|
|
|
if (mOrderManager == null || mOrderManager.getMailboxId() != mailboxId) {
|
|
|
|
stopMessageOrderManager();
|
|
|
|
mOrderManager = new MessageOrderManager(this, mailboxId, mMessageOrderManagerCallback);
|
2010-07-21 21:29:49 +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
|
|
|
if (mFragmentManager.isMessageSelected()) {
|
|
|
|
mOrderManager.moveTo(mFragmentManager.getMessageId());
|
|
|
|
}
|
|
|
|
}
|
2010-07-21 21:29:49 +00:00
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private class MessageOrderManagerCallback implements MessageOrderManager.Callback {
|
|
|
|
@Override
|
|
|
|
public void onMessagesChanged() {
|
|
|
|
updateNavigationArrows();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMessageNotFound() {
|
2010-08-17 22:07:28 +00:00
|
|
|
// Current message gone.
|
2010-08-31 20:13:44 +00:00
|
|
|
mFragmentManager.goBackToMailbox();
|
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-21 21:29:49 +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
|
|
|
/**
|
|
|
|
* Stop {@link MessageOrderManager}.
|
|
|
|
*/
|
2010-07-21 21:29:49 +00:00
|
|
|
private void stopMessageOrderManager() {
|
|
|
|
if (mOrderManager != null) {
|
|
|
|
mOrderManager.close();
|
|
|
|
mOrderManager = null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Called when the default account is not found, i.e. there's no account set up.
|
|
|
|
*/
|
2010-07-21 21:29:49 +00:00
|
|
|
private void onNoAccountFound() {
|
|
|
|
// Open Welcome, which in turn shows the adding a new account screen.
|
|
|
|
Welcome.actionStart(this);
|
|
|
|
finish();
|
|
|
|
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
|
|
|
/**
|
Let MessageViewFragment own bottom buttons.
Create a custom view containing the bottons below MVF
(delete, move, reply, etc) and let MVF own this.
These buttons used to be owned by the XL activity itself, because
the UI for these commands will most likely be totally different
from the tablet UI, so the fragment having them looked wrong.
However, this made it harder to make changes suggested by the latest
mock, such as "put reply/forward in the message header".
I think the buttons are semantically part of the message view anyway,
so the fragment owning UI for these commands is probably the way to go.
(And let's worry about the phone UI later.)
Reason for the use of a custom view is that it will make it easier
to make non-trivial UI changes, e.g. "combine reply, reply-all and
forward and make it dropdown."
Also removed obsolete TODOs from MessageListXL.
Change-Id: Ibf93f4c70fe07bdbbe33d2adb6bbd2b96812830d
2010-09-16 18:16:46 +00:00
|
|
|
* Disable/enable the move-to-newer/older buttons.
|
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 void updateNavigationArrows() {
|
Let MessageViewFragment own bottom buttons.
Create a custom view containing the bottons below MVF
(delete, move, reply, etc) and let MVF own this.
These buttons used to be owned by the XL activity itself, because
the UI for these commands will most likely be totally different
from the tablet UI, so the fragment having them looked wrong.
However, this made it harder to make changes suggested by the latest
mock, such as "put reply/forward in the message header".
I think the buttons are semantically part of the message view anyway,
so the fragment owning UI for these commands is probably the way to go.
(And let's worry about the phone UI later.)
Reason for the use of a custom view is that it will make it easier
to make non-trivial UI changes, e.g. "combine reply, reply-all and
forward and make it dropdown."
Also removed obsolete TODOs from MessageListXL.
Change-Id: Ibf93f4c70fe07bdbbe33d2adb6bbd2b96812830d
2010-09-16 18:16:46 +00:00
|
|
|
MessageViewFragment f = mFragmentManager.getMessageViewFragment();
|
|
|
|
if (f == null) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (mOrderManager == null) {
|
|
|
|
f.enableNavigationButons(false, false); // shouldn't happen, but just in case
|
|
|
|
} else {
|
|
|
|
f.enableNavigationButons(mOrderManager.canMoveToNewer(),
|
|
|
|
mOrderManager.canMoveToOlder());
|
|
|
|
}
|
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-21 21:29:49 +00:00
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private boolean moveToOlder() {
|
|
|
|
if (mFragmentManager.isMessageSelected() && (mOrderManager != null)
|
|
|
|
&& mOrderManager.moveToOlder()) {
|
|
|
|
mFragmentManager.selectMessage(mOrderManager.getCurrentMessageId());
|
|
|
|
return true;
|
2010-07-21 21:29:49 +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
|
|
|
return false;
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private boolean moveToNewer() {
|
|
|
|
if (mFragmentManager.isMessageSelected() && (mOrderManager != null)
|
|
|
|
&& mOrderManager.moveToNewer()) {
|
|
|
|
mFragmentManager.selectMessage(mOrderManager.getCurrentMessageId());
|
|
|
|
return true;
|
2010-07-21 21:29:49 +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
|
|
|
return false;
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private class MailboxListFragmentCallback implements MailboxListFragment.Callback {
|
|
|
|
@Override
|
|
|
|
public void onMailboxSelected(long accountId, long mailboxId) {
|
2010-08-11 22:28:31 +00:00
|
|
|
mFragmentManager.selectMailbox(mailboxId, true);
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
2010-10-26 00:51:56 +00:00
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onAccountSelected(long accountId) {
|
|
|
|
mFragmentManager.selectAccount(accountId, -1, true);
|
|
|
|
loadAccounts(); // This will update the account spinner, and select the account.
|
|
|
|
}
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
Refactoring MessageListXL
I always thought our Activities are way too fat, meaning we've put too many
things into activities without any structure.
The major problems with this are:
- They have too many fields, which are not final and not even orthogonal.
This makes them very hard to understand/maintain. Changing one tiny bit
can always cause unanticipated side-effects.
- Very hard, or almost impossible to test.
I really think we should break them into independent and self-contained
subcomponents which can be tested separately.
Introducing MessageListXLStateManager, which manages the current account,
mailbox and message, and show/hide/update fragments accordingly
for MessageListXL.
With this class, MessageListXL will be able to switch accounts/mailboxes/
messages by just calling the methods such as selectAccount(), without
worrying about when to show/hide what fragment and how to initialize them.
(In other words, MessageListXLStateManager encapsulates the two-pane screen
transition. It's not intended to be reused for the phone UI.)
I didn't make it a nested class in MessageListXL, because nested classes can't
have real private members (private member are accessible from outer classes and
even brother classes!!), and I wanted it to be really self-contained anyway.
Change-Id: I1c121e99e30f12cc118e1c35abc9b30f49939a4a
2010-07-22 22:01:31 +00:00
|
|
|
private class MessageListFragmentCallback implements MessageListFragment.Callback {
|
|
|
|
@Override
|
2010-08-10 01:36:44 +00:00
|
|
|
public void onMessageOpen(long messageId, long messageMailboxId, long listMailboxId,
|
|
|
|
int type) {
|
|
|
|
if (type == MessageListFragment.Callback.TYPE_DRAFT) {
|
|
|
|
MessageCompose.actionEditDraft(MessageListXL.this, messageId);
|
|
|
|
} else {
|
|
|
|
mFragmentManager.selectMessage(messageId);
|
|
|
|
}
|
2010-07-21 21:29:49 +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
|
|
|
@Override
|
2010-08-17 22:07:28 +00:00
|
|
|
public void onMailboxNotFound() {
|
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: What to do??
|
|
|
|
}
|
2010-09-22 23:17:53 +00:00
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onEnterSelectionMode(boolean enter) {
|
|
|
|
}
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
|
|
|
|
2010-07-30 22:41:40 +00:00
|
|
|
private class MessageViewFragmentCallback implements MessageViewFragment.Callback {
|
2010-09-02 01:40:10 +00:00
|
|
|
@Override
|
|
|
|
public void onMessageViewShown(int mailboxType) {
|
|
|
|
updateMessageOrderManager();
|
|
|
|
updateNavigationArrows();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMessageViewGone() {
|
|
|
|
stopMessageOrderManager();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
@Override
|
|
|
|
public boolean onUrlInMessageClicked(String url) {
|
2010-08-17 22:07:28 +00:00
|
|
|
return ActivityHelper.openUrlInMessage(MessageListXL.this, url,
|
|
|
|
mFragmentManager.getAccountId());
|
2010-07-21 21:29:49 +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
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMessageSetUnread() {
|
2010-08-31 20:13:44 +00:00
|
|
|
mFragmentManager.goBackToMailbox();
|
2010-07-21 21:29:49 +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
|
|
|
@Override
|
|
|
|
public void onMessageNotExists() {
|
2010-08-31 20:13:44 +00:00
|
|
|
mFragmentManager.goBackToMailbox();
|
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-21 21:29:49 +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
|
|
|
@Override
|
|
|
|
public void onLoadMessageStarted() {
|
2010-08-17 22:07:28 +00:00
|
|
|
// We show indeterminate progress on one-pane.
|
|
|
|
// TODO Any nice UI for this?
|
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-21 21:29:49 +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
|
|
|
@Override
|
|
|
|
public void onLoadMessageFinished() {
|
2010-08-17 22:07:28 +00:00
|
|
|
// We hide indeterminate progress on one-pane.
|
|
|
|
// TODO Any nice UI for this?
|
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-21 21:29:49 +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
|
|
|
@Override
|
|
|
|
public void onLoadMessageError() {
|
2010-08-17 22:07:28 +00:00
|
|
|
// We hide indeterminate progress on one-pane.
|
|
|
|
// TODO Any nice UI for this?
|
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-21 21:29:49 +00:00
|
|
|
|
2010-08-17 22:07:28 +00:00
|
|
|
@Override
|
|
|
|
public void onRespondedToInvite(int response) {
|
2010-09-10 00:23:53 +00:00
|
|
|
onCurrentMessageGone();
|
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-21 21:29:49 +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
|
|
|
@Override
|
|
|
|
public void onCalendarLinkClicked(long epochEventStartTime) {
|
2010-08-17 22:07:28 +00:00
|
|
|
ActivityHelper.openCalendar(MessageListXL.this, epochEventStartTime);
|
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-21 21:29:49 +00:00
|
|
|
|
Let MessageViewFragment own bottom buttons.
Create a custom view containing the bottons below MVF
(delete, move, reply, etc) and let MVF own this.
These buttons used to be owned by the XL activity itself, because
the UI for these commands will most likely be totally different
from the tablet UI, so the fragment having them looked wrong.
However, this made it harder to make changes suggested by the latest
mock, such as "put reply/forward in the message header".
I think the buttons are semantically part of the message view anyway,
so the fragment owning UI for these commands is probably the way to go.
(And let's worry about the phone UI later.)
Reason for the use of a custom view is that it will make it easier
to make non-trivial UI changes, e.g. "combine reply, reply-all and
forward and make it dropdown."
Also removed obsolete TODOs from MessageListXL.
Change-Id: Ibf93f4c70fe07bdbbe33d2adb6bbd2b96812830d
2010-09-16 18:16:46 +00:00
|
|
|
@Override
|
|
|
|
public void onMoveToNewer() {
|
|
|
|
moveToNewer();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMoveToOlder() {
|
|
|
|
moveToOlder();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onBeforeMessageDelete() {
|
|
|
|
onCurrentMessageGone();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onMoveMessage() {
|
|
|
|
MessageListXL.this.onMoveMessage();
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onForward() {
|
|
|
|
MessageCompose.actionForward(MessageListXL.this, mFragmentManager.getMessageId());
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onReply() {
|
|
|
|
MessageCompose.actionReply(MessageListXL.this, mFragmentManager.getMessageId(), false);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onReplyAll() {
|
|
|
|
MessageCompose.actionReply(MessageListXL.this, mFragmentManager.getMessageId(), true);
|
|
|
|
}
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|
2010-07-26 18:14:09 +00:00
|
|
|
|
2010-08-04 23:23:26 +00:00
|
|
|
@Override
|
2010-09-09 21:13:47 +00:00
|
|
|
public void onAccountSecurityHold(long accountId) {
|
|
|
|
startActivity(AccountSecurity.actionUpdateSecurityIntent(this, accountId));
|
2010-08-04 23:23:26 +00:00
|
|
|
}
|
|
|
|
|
2010-09-13 23:35:58 +00:00
|
|
|
@Override
|
|
|
|
public void onMailboxChanged(long accountId, long newMailboxId) {
|
|
|
|
updateProgressIcon();
|
|
|
|
}
|
|
|
|
|
2010-10-26 00:51:56 +00:00
|
|
|
/**
|
|
|
|
* Load account list for the action bar.
|
|
|
|
*
|
|
|
|
* If there's only one account configured, show the account name in the action bar.
|
|
|
|
* If more than one account are configured, show a spinner in the action bar, and select the
|
|
|
|
* current account.
|
|
|
|
*/
|
2010-07-28 18:42:37 +00:00
|
|
|
private void loadAccounts() {
|
|
|
|
getLoaderManager().initLoader(LOADER_ID_ACCOUNT_LIST, null, new LoaderCallbacks<Cursor>() {
|
|
|
|
@Override
|
|
|
|
public Loader<Cursor> onCreateLoader(int id, Bundle args) {
|
|
|
|
return AccountSelectorAdapter.createLoader(mContext);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onLoadFinished(Loader<Cursor> loader, Cursor data) {
|
|
|
|
updateAccountList(data);
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
private void updateAccountList(Cursor accountsCursor) {
|
2010-08-25 23:04:55 +00:00
|
|
|
final int count = accountsCursor.getCount();
|
|
|
|
if (count == 0) {
|
2010-07-28 18:42:37 +00:00
|
|
|
onNoAccountFound();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-08-25 23:04:55 +00:00
|
|
|
// If ony one acount, don't show dropdown.
|
|
|
|
final ActionBar ab = getActionBar();
|
|
|
|
if (count == 1) {
|
|
|
|
accountsCursor.moveToFirst();
|
|
|
|
ab.setStandardNavigationMode();
|
2010-09-15 23:20:01 +00:00
|
|
|
ab.setTitle(AccountSelectorAdapter.getAccountDisplayName(accountsCursor));
|
2010-08-25 23:04:55 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-07-28 18:42:37 +00:00
|
|
|
// Find the currently selected account, and select it.
|
|
|
|
int defaultSelection = 0;
|
|
|
|
if (mFragmentManager.isAccountSelected()) {
|
2010-08-04 18:33:52 +00:00
|
|
|
accountsCursor.moveToPosition(-1);
|
2010-07-28 18:42:37 +00:00
|
|
|
int i = 0;
|
|
|
|
while (accountsCursor.moveToNext()) {
|
|
|
|
final long accountId = AccountSelectorAdapter.getAccountId(accountsCursor);
|
|
|
|
if (accountId == mFragmentManager.getAccountId()) {
|
|
|
|
defaultSelection = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Update the dropdown list.
|
|
|
|
mAccountsSelectorAdapter.changeCursor(accountsCursor);
|
2010-10-26 00:51:56 +00:00
|
|
|
ab.setDropdownNavigationMode(mAccountsSelectorAdapter,
|
|
|
|
mActionBarNavigationCallback, defaultSelection);
|
2010-07-28 18:42:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
private class ActionBarNavigationCallback implements ActionBar.NavigationCallback {
|
|
|
|
@Override
|
|
|
|
public boolean onNavigationItemSelected(int itemPosition, long accountId) {
|
|
|
|
if (Email.DEBUG) Log.d(Email.LOG_TAG, "Account selected: accountId=" + accountId);
|
2010-08-25 02:09:34 +00:00
|
|
|
mFragmentManager.selectAccount(accountId, -1, true);
|
2010-07-28 18:42:37 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-08-16 21:14:40 +00:00
|
|
|
private class RefreshListener
|
|
|
|
implements RefreshManager.Listener {
|
|
|
|
@Override
|
2010-10-19 21:27:21 +00:00
|
|
|
public void onMessagingError(final long accountId, long mailboxId, final String message) {
|
|
|
|
// STOPSHIP temporary UI
|
|
|
|
Utility.runAsync(new Runnable() {
|
|
|
|
@Override
|
|
|
|
public void run() {
|
2010-10-22 22:29:26 +00:00
|
|
|
String msg = message;
|
|
|
|
if (accountId != -1) {
|
|
|
|
Account account = Account.restoreAccountWithId(mContext, accountId);
|
|
|
|
if (account != null) {
|
|
|
|
msg = account.mDisplayName + ": " + msg;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
Utility.showToast(MessageListXL.this, msg);
|
|
|
|
}});
|
2010-10-19 21:27:21 +00:00
|
|
|
// END STOPSHIP
|
2010-09-13 23:35:58 +00:00
|
|
|
updateProgressIcon();
|
2010-08-16 21:14:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public void onRefreshStatusChanged(long accountId, long mailboxId) {
|
2010-09-13 23:35:58 +00:00
|
|
|
updateProgressIcon();
|
2010-08-16 21:14:40 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-09-13 23:35:58 +00:00
|
|
|
/**
|
|
|
|
* If we're refreshing the current mailbox, animate the "mailbox refreshing" progress icon.
|
|
|
|
*/
|
|
|
|
private void updateProgressIcon() {
|
|
|
|
// TODO See the comment on onPrepareOptionsMenu -- change this when we get a better progress
|
|
|
|
// bar support.
|
|
|
|
invalidateOptionsMenu();
|
|
|
|
}
|
|
|
|
|
2010-08-16 21:14:40 +00:00
|
|
|
private boolean isProgressActive() {
|
|
|
|
final long mailboxId = mFragmentManager.getMailboxId();
|
|
|
|
return (mailboxId >= 0) && mRefreshManager.isMessageListRefreshing(mailboxId);
|
|
|
|
}
|
|
|
|
|
2010-08-04 23:54:08 +00:00
|
|
|
@Override
|
|
|
|
public boolean onCreateOptionsMenu(Menu menu) {
|
|
|
|
super.onCreateOptionsMenu(menu);
|
|
|
|
getMenuInflater().inflate(R.menu.message_list_xl_option, menu);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2010-08-16 21:14:40 +00:00
|
|
|
// STOPSHIP - this is a placeholder if/until there's support for progress in actionbar
|
|
|
|
// Remove it, or replace with a better icon
|
|
|
|
@Override
|
|
|
|
public boolean onPrepareOptionsMenu(Menu menu) {
|
|
|
|
MenuItem item = menu.findItem(R.id.refresh);
|
|
|
|
if (isProgressActive()) {
|
|
|
|
item.setIcon(android.R.drawable.progress_indeterminate_horizontal);
|
|
|
|
} else {
|
|
|
|
item.setIcon(R.drawable.ic_menu_refresh);
|
|
|
|
}
|
|
|
|
return super.onPrepareOptionsMenu(menu);
|
|
|
|
}
|
|
|
|
|
2010-08-04 23:54:08 +00:00
|
|
|
@Override
|
|
|
|
public boolean onOptionsItemSelected(MenuItem item) {
|
|
|
|
switch (item.getItemId()) {
|
|
|
|
case R.id.compose:
|
|
|
|
return onCompose();
|
|
|
|
case R.id.refresh:
|
2010-08-16 21:14:40 +00:00
|
|
|
onRefresh();
|
2010-08-04 23:54:08 +00:00
|
|
|
return true;
|
|
|
|
case R.id.account_settings:
|
2010-08-10 00:25:42 +00:00
|
|
|
return onAccountSettings();
|
2010-08-04 23:54:08 +00:00
|
|
|
}
|
|
|
|
return super.onOptionsItemSelected(item);
|
|
|
|
}
|
|
|
|
|
|
|
|
private boolean onCompose() {
|
|
|
|
if (!mFragmentManager.isAccountSelected()) {
|
|
|
|
return false; // this shouldn't really happen
|
|
|
|
}
|
|
|
|
MessageCompose.actionCompose(this, mFragmentManager.getAccountId());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2010-08-10 00:25:42 +00:00
|
|
|
private boolean onAccountSettings() {
|
2010-08-18 23:47:42 +00:00
|
|
|
AccountSettingsXL.actionSettings(this, mFragmentManager.getAccountId());
|
2010-08-10 00:25:42 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2010-08-16 21:14:40 +00:00
|
|
|
private void onRefresh() {
|
2010-08-27 17:25:03 +00:00
|
|
|
// Cancel previously running instance if any.
|
|
|
|
Utility.cancelTaskInterrupt(mRefreshTask);
|
|
|
|
mRefreshTask = new RefreshTask(this, mFragmentManager.getAccountId(),
|
|
|
|
mFragmentManager.getMailboxId());
|
|
|
|
mRefreshTask.execute();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Class to handle refresh.
|
|
|
|
*
|
|
|
|
* When the user press "refresh",
|
|
|
|
* <ul>
|
|
|
|
* <li>Refresh the current mailbox, if it's refreshable. (e.g. don't refresh combined inbox,
|
|
|
|
* drafts, etc.
|
|
|
|
* <li>Refresh the mailbox list, if it hasn't been refreshed in the last
|
|
|
|
* {@link #MAILBOX_REFRESH_MIN_INTERVAL}.
|
|
|
|
* <li>Refresh inbox, if it's not the current mailbox and it hasn't been refreshed in the last
|
|
|
|
* {@link #INBOX_AUTO_REFRESH_MIN_INTERVAL}.
|
|
|
|
* </ul>
|
|
|
|
*/
|
|
|
|
/* package */ static class RefreshTask extends AsyncTask<Void, Void, Boolean> {
|
|
|
|
private final Clock mClock;
|
|
|
|
private final Context mContext;
|
|
|
|
private final long mAccountId;
|
|
|
|
private final long mMailboxId;
|
|
|
|
private final RefreshManager mRefreshManager;
|
|
|
|
/* package */ long mInboxId;
|
|
|
|
|
|
|
|
public RefreshTask(Context context, long accountId, long mailboxId) {
|
|
|
|
this(context, accountId, mailboxId, Clock.INSTANCE,
|
|
|
|
RefreshManager.getInstance(context));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* package */ RefreshTask(Context context, long accountId, long mailboxId, Clock clock,
|
|
|
|
RefreshManager refreshManager) {
|
|
|
|
mClock = clock;
|
|
|
|
mContext = context;
|
|
|
|
mRefreshManager = refreshManager;
|
|
|
|
mAccountId = accountId;
|
|
|
|
mMailboxId = mailboxId;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Do DB access on a worker thread.
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
protected Boolean doInBackground(Void... params) {
|
|
|
|
mInboxId = Account.getInboxId(mContext, mAccountId);
|
|
|
|
return Mailbox.isRefreshable(mContext, mMailboxId);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Do the actual refresh.
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
protected void onPostExecute(Boolean isCurrentMailboxRefreshable) {
|
|
|
|
if (isCancelled() || isCurrentMailboxRefreshable == null) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (isCurrentMailboxRefreshable) {
|
|
|
|
mRefreshManager.refreshMessageList(mAccountId, mMailboxId);
|
|
|
|
}
|
|
|
|
// Refresh mailbox list
|
|
|
|
if (mAccountId != -1) {
|
|
|
|
if (shouldRefreshMailboxList()) {
|
|
|
|
mRefreshManager.refreshMailboxList(mAccountId);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Refresh inbox
|
|
|
|
if (shouldAutoRefreshInbox()) {
|
|
|
|
mRefreshManager.refreshMessageList(mAccountId, mInboxId);
|
2010-08-18 22:39:55 +00:00
|
|
|
}
|
2010-08-16 21:14:40 +00:00
|
|
|
}
|
|
|
|
|
2010-08-27 17:25:03 +00:00
|
|
|
/**
|
|
|
|
* @return true if the mailbox list of the current account hasn't been refreshed
|
|
|
|
* in the last {@link #MAILBOX_REFRESH_MIN_INTERVAL}.
|
|
|
|
*/
|
|
|
|
/* package */ boolean shouldRefreshMailboxList() {
|
|
|
|
if (mRefreshManager.isMailboxListRefreshing(mAccountId)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
final long nextRefreshTime = mRefreshManager.getLastMailboxListRefreshTime(mAccountId)
|
|
|
|
+ MAILBOX_REFRESH_MIN_INTERVAL;
|
|
|
|
if (nextRefreshTime > mClock.getTime()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2010-08-16 21:14:40 +00:00
|
|
|
|
2010-08-27 17:25:03 +00:00
|
|
|
/**
|
|
|
|
* @return true if the inbox of the current account hasn't been refreshed
|
|
|
|
* in the last {@link #INBOX_AUTO_REFRESH_MIN_INTERVAL}.
|
|
|
|
*/
|
|
|
|
/* package */ boolean shouldAutoRefreshInbox() {
|
|
|
|
if (mInboxId == mMailboxId) {
|
|
|
|
return false; // Current ID == inbox. No need to auto-refresh.
|
|
|
|
}
|
|
|
|
if (mRefreshManager.isMessageListRefreshing(mInboxId)) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
final long nextRefreshTime = mRefreshManager.getLastMessageListRefreshTime(mInboxId)
|
|
|
|
+ INBOX_AUTO_REFRESH_MIN_INTERVAL;
|
|
|
|
if (nextRefreshTime > mClock.getTime()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2010-08-16 21:14:40 +00:00
|
|
|
}
|
2010-07-21 21:29:49 +00:00
|
|
|
}
|