Зачем использовать подкласс приложения для хранения глобальных переменных?

Question

В моем приложении я использую общедоступный класс Globals для хранения статических переменных, которые я устанавливаю и получаю во всем приложении, просто обращаясь к ним с помощью p.e. Globals.someString:

public class Globals { 
    // several static variables for use in the whole application: 
    static String someString = ""; 
} 

Мое приложение работает нормально. Но теперь я везде читаю, что глобальные переменные должны быть определены в подклассе приложения или в собственном классе singleton, и к ним могут обращаться сеттеры и геттеры.

Мой вопрос сейчас: Есть ли недостатки в моем собственном способе использования глобальных переменных? Утечки памяти p.e. или другие вопросы?

Answer 1

две части Ответ:

первая часть: мифы и теории

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

Подкласс Application или ваш собственный открытый класс не имеет значения, если все, что вы используете, это строки, int и т. Д. Это обычное дело в Интернете для подкласса приложения, если вы инициализируете объекты, которым нужен контекст, для пример базы данных. Лично мне не нравится этот подход слишком много. Это замедляет время загрузки и может содержать большие объекты, которые мне действительно не нужны в памяти. Для этих типов я обычно использую lazy-initialisation, где я держу ссылку public static моего приложения, и всякий раз, когда я звоню, например, MyDatabase.get(); внутри get(), я проверяю if(instance==null) и затем инициализирую его с помощью общедоступного объекта Application.

Если вы сохраняете статическую ссылку на объекты Activity, Fragment или View для Android, вы всегда будете сталкиваться с проблемами памяти. Эти классы являются БОЛЬШОЙ, они содержат ссылки на другие большие объекты, они используют много памяти, и поэтому в Рамочной структуре есть все досадные life-cycle и saveState. Таким образом, они могут быть уничтожены, когда требуется память и перестроены, когда они вернутся на экран.

вторая часть: Android путь

в Android не очень желательно, чтобы просто держать ссылки объектов на public static, потому что те останутся в памяти навсегда, и мобильный телефон не похож на веб-сервер с терабайт оперативной памяти , Вся платформа Android имеет очень хорошо документированную и стабильную структуру передачи и сохранения значений (строки, int и т. Д.) Через объекты Bundle. Эти связки вы можете перейти к активности через Intent или к фрагментам через setArguments(Bundle), и их можно использовать для сохранения текущего состояния с использованием методов onSavedInstanceState. И это разумный способ делать вещи по-разному. И это также помогает продвигать разделение классов, и даже вы могли бы походить на большую работу для небольших проектов, для крупных проектов это один из способов сохранить структуру и организацию.

Answer 2

От http://developer.android.com/guide/faq/framework.html:

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

От http://developer.android.com/reference/android/app/Application.html:

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

Так что мне кажется, что использование статических переменных совершенно справедливо.