Как организовать хранение настроек?

Question

[Александр Синицын]

Наверно избито, но не могу найти законченный вариант ответа. Есть сервис, есть активити настроек. Настройки в SharedPreferences. Как организовать хранение, доступ во всех классах, уведомление об изменении.

Хотел сделать класс хелпер со статическими полями и методами, но SharedPreferences требуется Context, получается класс надо инициализировать каким-то методом с передачей этого контекста.

Кто как делает?

Answer 1

[GavriKos]

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

Comments

[Artem Gapchenko]

> Перегрузку application делаете синглтоном
Application и так по сути является синглтоном, система создает один инстанс этого класса на всё время жизни приложения.

[GavriKos]

Artem Gapchenko Через статическое поле в реализации синглтона просто удобнее обращаться :-) Так да. все проверки на единичный инстанс не нужны

Answer 2

[Юрий]

так и делаем.
Есть два способа, быстрый и правильный:
быстрый - в Application onCreate() берем контекст, суем его в статическую переменную, и в классе-хелпере статические методы используют этот контекст. решение плохое- концептуально мы нарушаем ООП,SOLID. Практически - такой код плохо тестировать, т.к. а) статические методы берет только PowerMock и б) наши классы будут иметь ничем не ограниченный доступ туда, т.е. проблема глобальных переменных во вей красе.
правильный : Натурально делаем SharedPreferenceFactory и далее по классическим жава канонам. Или, если вспомнили, что живем в 2016 - через DI.
И да, код писать быстро - поддерживать больно, зачем за мнимой скоростью гнаться - хз.

Comments

[Artem Gapchenko]

Какой из принципов SOLID нарушается при первом способе?

[Юрий]

Single Resposibility

[Artem Gapchenko]

И как он нарушается, какой класс в этой ситуации берёт на себя больше ответственности, чем ему нужно?

[mitaichik]

Юрий: Имхо, нарушения Single Resposibility тут нет: контекст и так принадлежит классу Application, мы просто выносим его для быстрого доступа, и вроде как можем так сделать, так как сам Application является синглтоном (поправьте меня если не так - я начинающий в Андройде).

Другое дело что это как то некрасиво, и, кстати, студя выводит подсказку, что это не хорошо, и возможны утечки памяти.

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

Лучший вариант - это DI, но на андройде я его пока не освоил.

[Юрий]

Ну какбэ тогда Application нарушает S, действуя не только по прямой своей функции, но и как Context provider. Либо, если мы используем SharedPrefernce как синглтон, то сам паттерн его нарушает, т.к. берет на себя ответственность не только за свои функции, но и за своё создание.