it-roy-ru.com

Как объявить глобальные переменные в Android?

Я создаю приложение, которое требует входа в систему. Я создал основной и логин активности.

В основной метод деятельности 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.

Кто-нибудь знает, как установить переменную глобальную, чтобы избежать появления формы входа после того, как пользователь уже успешно прошел аутентификацию?

588
Niko Gamulin

Я написал этот ответ еще в '09, когда Android был относительно новым, и в процессе разработки [Android было много не очень устоявшихся областей. В конце этого поста я добавил длинное приложение, посвященное некоторой критике и подробному изложению философских разногласий, которые у меня возникают с использованием Singletons, а не подклассом Application. Прочитайте это на свой страх и риск.

ОРИГИНАЛЬНЫЙ ОТВЕТ:

Более общая проблема, с которой вы сталкиваетесь, заключается в том, как сохранить состояние для нескольких действий и всех частей вашего приложения. Статическая переменная (например, синглтон) - это обычный Java способ достижения этого. Однако я обнаружил, что в Android более элегантный способ - связать ваше состояние с контекстом приложения.

Как вы знаете, каждое действие также является контекстом, который представляет собой информацию о его среде выполнения в самом широком смысле. Ваше приложение также имеет контекст, и Android гарантирует, что оно будет существовать как единое целое в вашем приложении.

Способ сделать это - создать свой собственный подкласс Android.app.Application , а затем указать этот класс в теге приложения в манифесте. Теперь Android автоматически создаст экземпляр этого класса и сделает его доступным для всего вашего приложения. Вы можете получить к нему доступ из любого context, используя метод Context.getApplicationContext() (Activity также предоставляет метод getApplication(), который имеет точно такой же эффект). Ниже приведен чрезвычайно упрощенный пример с предостережениями:

class MyApp extends Application {

  private String myState;

  public String getState(){
    return myState;
  }
  public void setState(String s){
    myState = s;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyApp appState = ((MyApp)getApplicationContext());
    String state = appState.getState();
    ...
  }
}

По сути, это имеет тот же эффект, что и использование статической переменной или синглтона, но довольно хорошо интегрируется в существующую инфраструктуру Android. Обратите внимание, что это не будет работать между процессами (если ваше приложение является одним из редких, в котором есть несколько процессов).

На что обратить внимание из приведенного выше примера; Предположим, что вместо этого мы сделали что-то вроде:

class MyApp extends Application {

  private String myState = /* complicated and slow initialization */;

  public String getState(){
    return myState;
  }
}

Теперь эта медленная инициализация (например, попадание на диск, попадание в сеть, все, что блокируется и т.д.) Будет выполняться каждый раз, когда создается экземпляр приложения! Вы можете подумать, ну, это только один раз для процесса, и я все равно должен буду оплатить стоимость, верно? Например, как упоминает Дайан Хэкборн ниже, вполне возможно, что ваш процесс будет инстанцирован - просто - обработать событие фоновой трансляции. Если ваша обработка широковещания не нуждается в этом состоянии, вы, возможно, просто выполнили целый ряд сложных и медленных операций даром. Ленивый экземпляр - это название игры здесь. Ниже приведен чуть более сложный способ использования приложения, который имеет больше смысла для всего, кроме простейшего использования:

class MyApp extends Application {

  private MyStateManager myStateManager = new MyStateManager();

  public MyStateManager getStateManager(){
    return myStateManager ;
  }
}

class MyStateManager {

  MyStateManager() {
    /* this should be fast */
  }

  String getState() {
    /* if necessary, perform blocking calls here */
    /* make sure to deal with any multithreading/synchronicity issues */

    ...

    return state;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyStateManager stateManager = ((MyApp)getApplicationContext()).getStateManager();
    String state = stateManager.getState();
    ...
  }
}

В то время как я предпочитаю использование подклассов приложений для использования здесь синглетов в качестве более элегантного решения, я бы предпочел, чтобы разработчики использовали синглтоны, если это действительно необходимо, вместо того, чтобы вообще не думать о производительности и многопоточности, связанных с ассоциированием состояния с подклассом приложения.

ПРИМЕЧАНИЕ 1: Также, как прокомментировал антикафе, для правильной привязки переопределения вашего приложения к вашему приложению необходим тег в файле манифеста. Опять же, смотрите документацию Android для получения дополнительной информации. Пример:

<application
     Android:name="my.application.MyApp" 
     Android:icon="..."
     Android:label="...">
</application>

ПРИМЕЧАНИЕ 2. user608578 спрашивает ниже, как это работает с управлением жизненными циклами собственных объектов. Я не в курсе использования нативного кода с Android в малейшей степени, и я не квалифицирован, чтобы ответить, как это будет взаимодействовать с моим решением. Если у кого-то есть ответ на этот вопрос, я хочу отдать ему должное и разместить информацию в этом сообщении для максимальной наглядности.

ДОПОЛНЕНИЕ:

Как отмечали некоторые люди, это не является решением для постоянного состояния что-то, что я, возможно, должен был подчеркнуть больше в первоначальном ответе. То есть это не означает, что это решение для сохранения пользовательской или другой информации, которая должна сохраняться в течение всего времени жизни приложения. Таким образом, я считаю, что большинство нижеприведенных критических замечаний касаются уничтожения приложений в любое время и т.д., Спорных, поскольку все, что когда-либо требовалось сохранять на диск, не должно храниться через подкласс приложения. Он предназначен для хранения временного, легко воссоздаемого состояния приложения (например, вошел ли пользователь в систему) и компонентов, которые являются единым экземпляром (например, администратор сети приложения) (НЕ синглтон!) в природе.

Дайерман был достаточно любезен, чтобы указать на интересный разговор с Рето Мейером и Дайан Хэкборн , в котором использование подклассов Application не рекомендуется в пользу шаблонов Singleton. Соматик также указал на что-то подобное ранее, хотя я не видел этого в то время. Из-за роли Рето и Дайанны в поддержке платформы Android я не могу добросовестно рекомендовать игнорировать их советы. То, что они говорят, идет. Я хочу не согласиться с мнениями, высказанными в отношении предпочтения синглтонам над подклассами приложений. В своем несогласии я буду использовать понятия, лучше всего объясненные в это объяснение StackExchange шаблона проектирования Singleton , поэтому мне не нужно определять термины в этом ответе. Я настоятельно рекомендую просмотреть ссылку, прежде чем продолжить. Точка за точкой:

Дайанн заявляет: "Нет причин для создания подкласса в Application. Это ничем не отличается от создания синглтона ...". Это первое утверждение неверно. Для этого есть две основные причины. 1) класс Application обеспечивает лучшую пожизненную гарантию для разработчика приложения; он гарантированно имеет срок действия приложения. Синглтон не привязан ТОЛЬКО к времени жизни приложения (хотя это эффективно). Это может быть не проблема для вашего обычного разработчика приложений, но я бы сказал, что это именно тот тип контракта, который должен предлагать Android API, и он обеспечивает гораздо большую гибкость Android система, минимизируя время жизни связанных данных. 2) Класс Application предоставляет разработчику приложения один держатель экземпляра для состояния, который сильно отличается от держателя состояния Singleton. Список различий см. По ссылке выше.

Дайанн продолжает: "... в будущем вы, вероятно, пожалеете о том, что ваш объект Application станет таким большим запутанным беспорядком, который должен быть независимой логикой приложения". Это, конечно, не так, но это не причина для выбора Singleton вместо Application подкласса. Ни один из аргументов Дианы не дает оснований полагать, что использование Singleton лучше, чем подкласс Application, все, что она пытается установить, это то, что использование Singleton не хуже, чем подкласс Application, что я считаю ложным.

Она продолжает: "И это более естественно приводит к тому, как вы должны управлять этими вещами - инициализировать их по требованию". Это игнорирует тот факт, что нет никакой причины, по которой вы не можете инициализировать по требованию, также используя подкласс Application. Опять нет разницы.

Дайанн заканчивает словами: "Фреймворк имеет тонны и тонны синглетонов для всех небольших общих данных, которые он поддерживает для приложения, таких как кеши загруженных ресурсов, пулы объектов и т.д. Он прекрасно работает". Я не утверждаю, что использование Singletons не может работать нормально или не является законной альтернативой. Я утверждаю, что Singletons не обеспечивают такой сильный контракт с системой Android, как использование подкласса Application, и далее, что использование Singletons обычно указывает на негибкий дизайн, который нелегко изменить, и приводит ко многим проблемам по дороге. ИМХО, надежный контракт, который API-интерфейс Android предлагает разработчикам приложений, является одним из наиболее привлекательных и приятных аспектов программирования на Android и помог привести к скорейшему принятию разработчиком, что привело к созданию платформы Android к успеху, который он имеет сегодня. Предложение использовать Singletons неявно отходит от сильного контракта API и, на мой взгляд, ослабляет структуру Android.

Дайан также прокомментировала ниже, упомянув о дополнительном недостатке использования подклассов приложения, они могут способствовать или облегчать написание кода с меньшей производительностью. Это очень верно, и я отредактировал этот ответ, чтобы подчеркнуть важность рассмотрения здесь и правильного подхода, если вы используете подклассы Application. Как утверждает Дайанна, важно помнить, что ваш класс Application будет создаваться каждый раз при загрузке вашего процесса (может быть несколько раз за раз, если ваше приложение выполняется в нескольких процессах!), Даже если процесс загружается только для фоновой трансляции событие. Поэтому важно использовать класс Application больше как хранилище для указателей на общие компоненты вашего приложения, а не как место для какой-либо обработки!

Я оставляю вам следующий список недостатков для Singletons, украденный по более ранней ссылке StackExchange:

  • Невозможность использования абстрактных или интерфейсных классов;
  • Невозможность подкласса;
  • Высокая связь по приложению (трудно изменить);
  • Трудно проверить (не может подделать/издеваться в юнит-тестах);
  • Сложно распараллелить в случае изменяемого состояния (требуется обширная блокировка);

и добавить свой собственный:

  • Неясный и неуправляемый пожизненный контракт, не подходящий для Android (или большинства других) разработок;
948
sooniln

Создать этот подкласс

public class MyApp extends Application {
  String foo;
}

В AndroidManifest.xml добавьте Android: имя

пример

<application Android:name=".MyApp" 
       Android:icon="@drawable/icon" 
       Android:label="@string/app_name">
153
Guillaume

Предложенный Soonil способ сохранения состояния для приложения хорош, однако у него есть один слабый момент - бывают случаи, когда ОС убивает весь процесс приложения. Вот документация по этому вопросу Процессы и жизненные циклы .

Рассмотрим случай - ваше приложение переходит в фоновый режим, потому что кто-то вам звонит (приложение "Телефон" сейчас на переднем плане). В этом случае && при некоторых других условиях (проверьте приведенную выше ссылку, какими они могут быть) ОС может уничтожить ваш процесс приложения, включая экземпляр подкласса Application. В результате государство теряется. Когда вы позже вернетесь к приложению, ОС восстановит свой стек активности и экземпляр подкласса Application, однако поле myState будет null.

AFAIK, единственный способ гарантировать безопасность государства состоит в том, чтобы использовать любое сохранение государства, например, использование приватного файла приложения или SharedPrefernces (в конечном итоге он использует приватный файл приложения во внутренней файловой системе).

142
Vit Khudenko

Просто записка ..

добавлять:

Android:name=".Globals"

или как бы вы ни назвали свой подкласс в теге существующий<application>. Я продолжал пытаться добавить еще один тег <application> в манифест и получал исключение.

26
Gimbl

Я также не мог найти, как указать тег приложения, но после большого количества Google это стало очевидно из документов файла манифеста: используйте Android: name, в дополнение к значку и метке по умолчанию в разделе приложения.

Android: name Полное имя подкласса приложения, реализованное для приложения. Когда процесс приложения запускается, этот класс создается перед любым из компонентов приложения.

Подкласс является необязательным; большинству приложений он не нужен. В отсутствие подкласса Android использует экземпляр базового класса Application.

13
Mike Brown

Как насчет обеспечения сбора нативной памяти такими глобальными структурами?

У действий есть метод onPause/onDestroy(), который вызывается при уничтожении, но у класса Application нет эквивалентов. Какой механизм рекомендуется для обеспечения того, чтобы глобальные структуры (особенно те, которые содержат ссылки на собственную память) надлежащим образом собирались мусором, когда приложение либо уничтожается, либо стек задач помещается в фоновый режим?

13
user608578

Просто вам нужно определить имя приложения, как показано ниже, которое будет работать:

<application
  Android:name="ApplicationName" Android:icon="@drawable/icon">
</application>
5
Anand

Если некоторые переменные хранятся в sqlite, и вы должны использовать их в большинстве действий в вашем приложении. Тогда приложение может быть лучшим способом для достижения этого. Запросите переменные из базы данных при запуске приложения и сохраните их в поле. Затем вы можете использовать эти переменные в своей деятельности.

Так что найдите правильный путь, и лучшего пути не существует.

4
user716653

Как было сказано выше, ОС может уничтожить APPLICATION без какого-либо уведомления (нет события onDestroy), поэтому нет способа сохранить эти глобальные переменные.

SharedPreferences может быть решением, за исключением того, что у вас есть переменные COMPLEX STRUCTURED (в моем случае у меня был целочисленный массив для хранения идентификаторов, которые пользователь уже обработал). Проблема с SharedPreferences состоит в том, что трудно хранить и извлекать эти структуры каждый раз, когда требуются значения.

В моем случае у меня был фоновый СЕРВИС, чтобы я мог переместить эти переменные туда, и, поскольку у службы есть событие onDestroy, я мог бы легко сохранить эти значения.

4
Adorjan Princz

Вы можете иметь статическое поле для хранения такого рода состояния. Или поместите его в ресурс Bundle и восстановите оттуда на onCreate (Bundle saveInstanceState). Просто убедитесь, что вы полностью понимаете Android управляемый жизненный цикл приложения (например, почему login () вызывается при изменении ориентации клавиатуры).

3
yanchenko

DO N'T Используйте другой тег <application> в файле манифеста. Просто внесите одно изменение в существующий тег <application>, добавьте эту строку Android:name=".ApplicationName" где, ApplicationName будет именем вашего подкласса (используйте для хранения глобальных), который вы собирается создать.

итак, наконец, ваш ONE AND ONLY<application> тег в файле манифеста должен выглядеть следующим образом: -

<application
        Android:allowBackup="true"
        Android:icon="@mipmap/ic_launcher"
        Android:label="@string/app_name"
        Android:theme="@style/Theme.AppCompat.NoActionBar"
        Android:name=".ApplicationName"
        >
2
kumar kundan

Вы можете сделать это, используя два подхода:

  1. Использование класса приложения
  2. Использование общих настроек

  3. Использование класса приложения

Пример:

class SessionManager extends Application{

  String sessionKey;

  setSessionKey(String key){
    this.sessionKey=key;
  }

  String getSessisonKey(){
    return this.sessionKey;
  }
}

Вы можете использовать вышеупомянутый класс для реализации входа в систему MainActivity, как показано ниже. Код будет выглядеть примерно так:

@override 
public void onCreate (Bundle savedInstanceState){
  // you will this key when first time login is successful.
  SessionManager session= (SessionManager)getApplicationContext();
  String key=getSessisonKey.getKey();
  //Use this key to identify whether session is alive or not.
}

Этот метод будет работать для временного хранения. Вы действительно не представляете, когда операционная система убьет приложение из-за нехватки памяти. Когда ваше приложение работает в фоновом режиме, а пользователь перемещается по другому приложению, для работы которого требуется больше памяти, ваше приложение будет убито, поскольку операционная система отдает приоритет приоритетным процессам, а не фону. Следовательно, ваш объект приложения будет нулевым, прежде чем пользователь выйдет из системы. Следовательно для этого я рекомендую использовать второй метод, указанный выше.

  1. Использование общих настроек.

    String MYPREF="com.your.application.session"
    
    SharedPreferences pref= context.getSharedPreferences(MyPREF,MODE_PRIVATE);
    
    //Insert key as below:
    
    Editot editor= pref.edit();
    
    editor.putString("key","value");
    
    editor.commit();
    
    //Get key as below.
    
    SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
    
    String key= getResources().getString("key");
    
1
Krishna

вы можете использовать Intents, Sqlite или Shared Preferences. Когда дело доходит до хранилища мультимедиа, такого как документы, фотографии и видео, вы можете вместо этого создавать новые файлы.

1
Raju yourPepe

По результатам деятельности вызывается раньше по резюме. Поэтому перенесите проверку входа в систему на резюме, и ваш второй вход в систему может быть заблокирован, как только операция secomd вернула положительный результат. О резюме вызывается каждый раз, поэтому не стоит беспокоиться, что его не вызовут с первого раза.

0
user3044482
class GlobaleVariableDemo extends Application {

    private String myGlobalState;

    public String getGlobalState(){
     return myGlobalState;
    }
    public void setGlobalState(String s){
     myGlobalState = s;
    }
}

class Demo extends Activity {

@Override
public void onCreate(Bundle b){
    ...
    GlobaleVariableDemo appState = ((GlobaleVariableDemo)getApplicationContext());
    String state = appState.getGlobalState();
    ...
    }
}
0
Vaishali Sutariya

Подклассы также использовались в среде BARACUS. С моей точки зрения субклассирование Приложение предназначалось для работы с жизненными циклами Android; это то, что делает любой контейнер приложений. Вместо того, чтобы иметь глобальные переменные, я регистрирую bean-компоненты в этом контексте, чтобы они вводились в любой класс, управляемый контекстом. Каждый внедренный экземпляр компонента на самом деле является синглтоном.

подробности см. В этом примере

Зачем ручная работа, если вы можете иметь гораздо больше?

0
gorefest

Вы можете создать класс, который расширяет класс Application, а затем объявить вашу переменную как поле этого класса и предоставить для него метод getter.

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

    synchronized public String getMyString {
        return str;
    }
}

И затем, чтобы получить доступ к этой переменной в вашей деятельности, используйте это:

MyApplication application = (MyApplication) getApplication();
String myVar = application.getMyString();
0
Amit Tiwari