我正在创建一个需要登录的应用程序。我创建了主活动和登录活动。

在主活动onCreate方法中,我添加了以下条件:

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    ...

    loadSettings();
    if(strSessionString == null)
    {
        login();
    }
    ...
}

当登录表单终止时执行的onActivityResult方法看起来像这样:

@Override
public void onActivityResult(int requestCode,
                             int resultCode,
                             Intent data)
{
    super.onActivityResult(requestCode, resultCode, data);
    switch(requestCode)
    {
        case(SHOW_SUBACTICITY_LOGIN):
        {
            if(resultCode == Activity.RESULT_OK)
            {

                strSessionString = data.getStringExtra(Login.SESSIONSTRING);
                connectionAvailable = true;
                strUsername = data.getStringExtra(Login.USERNAME);
            }
        }
    }

问题是登录表单有时出现两次(login()方法被调用两次),也当电话键盘滑动登录表单再次出现,我猜问题是变量strSessionString。

有人知道如何设置变量全局,以避免登录表单出现后,用户已经成功验证?


当前回答

Soonil建议的保持应用程序状态的方法是好的,但是它有一个弱点——在某些情况下,操作系统会终止整个应用程序进程。这里是关于此的文档—流程和生命周期。

考虑一个案例-你的应用程序进入后台,因为有人正在呼叫你(电话应用程序现在在前台)。在这种情况下&&在其他一些情况下(检查上面的链接了解它们可能是什么),操作系统可能会杀死你的应用程序进程,包括application子类实例。结果,状态丢失了。当您稍后返回到应用程序时,操作系统将恢复其活动堆栈和application子类实例,但myState字段将为空。

AFAIK,保证状态安全的唯一方法是使用任何类型的持久化状态,例如为应用程序文件使用私有或sharedpreferences(它最终在内部文件系统中为应用程序文件使用私有)。

其他回答

您可以创建一个扩展Application类的类,然后将您的变量声明为该类的字段,并为它提供getter方法。

public class MyApplication extends Application {
    private String str = "My String";

    synchronized public String getMyString {
        return str;
    }
}

然后在你的Activity中访问这个变量,使用这个:

MyApplication application = (MyApplication) getApplication();
String myVar = application.getMyString();

如何使用这样的全局结构来确保本机内存的收集呢?

活动有一个onPause/onDestroy()方法,在销毁时调用,但Application类没有等价物。当应用程序被杀死或任务栈被放到后台时,建议采用什么机制来确保全局结构(特别是那些包含对本机内存的引用)被适当地垃圾收集?

你只需要定义一个应用程序的名称,如下所示:

<application
  android:name="ApplicationName" android:icon="@drawable/icon">
</application>

就像上面讨论的那样,操作系统可以在没有任何通知的情况下杀死应用程序(没有onDestroy事件),所以没有办法保存这些全局变量。

SharedPreferences可以是一个解决方案,除非你有复杂的结构化变量(在我的情况下,我有一个整数数组来存储用户已经处理的id)。SharedPreferences的问题在于,每次需要值时都很难存储和检索这些结构。

在我的情况下,我有一个后台服务,所以我可以把这些变量移动到那里,因为服务有onDestroy事件,我可以很容易地保存这些值。

Soonil建议的保持应用程序状态的方法是好的,但是它有一个弱点——在某些情况下,操作系统会终止整个应用程序进程。这里是关于此的文档—流程和生命周期。

考虑一个案例-你的应用程序进入后台,因为有人正在呼叫你(电话应用程序现在在前台)。在这种情况下&&在其他一些情况下(检查上面的链接了解它们可能是什么),操作系统可能会杀死你的应用程序进程,包括application子类实例。结果,状态丢失了。当您稍后返回到应用程序时,操作系统将恢复其活动堆栈和application子类实例,但myState字段将为空。

AFAIK,保证状态安全的唯一方法是使用任何类型的持久化状态,例如为应用程序文件使用私有或sharedpreferences(它最终在内部文件系统中为应用程序文件使用私有)。