Использование getApplicationContext () против ссылки на пользовательский класс приложения в Android - PullRequest
Новая
       37

Использование getApplicationContext () против ссылки на пользовательский класс приложения в Android

0 голосов
/ 12 февраля 2012

Я исследовал способы хранения глобальных настроек для моего приложения Android, и до сих пор кажется, что наилучшим способом является расширение класса Application и сохранение в нем общих данных, как описано здесь .Я обнаружил, что вместо использования (CustomApplicationClass)getApplicationContext().getSomething() я могу сделать то же самое, ссылаясь непосредственно на статический метод внутри класса, например: CustomApplicationClass.getSomething(), и оба способа работают просто отлично.

Вот фрагмент изCustomApplicationClass: 

public class CustomApplicationClass extends Application {

  private static boolean something;

  @Override
  public void onCreate() {
    [...]
  }

  public static boolean isSomething() {
    return something;
  }

  public static void setSomething(boolean something) {
    this.something = something;
  }

}

Теперь, если я хочу получить значение переменной "что-то" где-то в моем коде, скажем, из моего приложения Activity, есть ли разница между:

boolean var1 = ((CustomApplicationClass)getApplicationContext()).isSomething();

и

boolean var1 = CustomApplicationClass.isSomething();

?При запуске приложения оба работают нормально.Является ли второй способ безопасным для использования или нецелесообразным?

Ответы [ 2 ]

1 голос
/ 12 февраля 2012

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

За исключением того, что вы этого не делаете.

Я обнаружил, что вместо использования (CustomApplicationClass) getApplicationContext (). GetSomething () я могу сделать то же самое, ссылаясь непосредственно настатический метод внутри класса, подобный этому: CustomApplicationClass.getSomething () и оба способа работают просто отлично.

Конечно.С таким же успехом вы могли бы CustomApplicationClass продлить Object, а затем выполнить CustomApplicationClass.getSomething().Вы ничего не получаете от своего текущего подхода по сравнению с обычным одноэлементным шаблоном в Java и теряете гибкость, поскольку у приложения может быть только один пользовательский подкласс Application.

Является ли второйбезопасный способ использования, или это нецелесообразно?

Первый способ не имеет смысла, поскольку ваш член данных и методы статичны.

Либо:

  1. Сделайте ваши вещи в CustomApplicationClass не be static, а затем используйте getApplicationContext().

  2. Refactor CustomApplicationClass, чтобы не расширять Application, а затем использовать статический член данных и / или методы доступа или более формально переключиться на шаблон синглтона Java .

Лично я бы пошел свариант № 2.

0 голосов
/ 14 ноября 2012

Если вы проверяете API android.app.Application (http://developer.android.com/reference/android/app/Application.html), то в «Обзоре классов» вы найдете следующее:

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

Обычно нетнеобходимо создать подкласс Application. В большинстве случаев статические синглтоны могут предоставлять ту же функциональность более модульным способом. Если вашему синглтону нужен глобальный контекст (например, для регистрации широковещательных приемников), функции для его получения может быть данаКонтекст, который внутренне использует Context.getApplicationContext () при первом создании синглтона.

...