Ситуация такая. Имеем андроид-приложение и некий класс в нем, содержащий какие-то служебные данные, необходимые для работы практически всех компонентов приложения.
Класс этот всегда существует и всегда в единственном экземпляре, и, изначально, был сделан в виде синглтона. Однако, впоследствии выяснилось, что, в случае, если свернуть приложение и запустить что-то ресурсоемкое, то андроид без зазрения совести освобождает память синглтона, а результате после восстановления при обращении к синглтону получаю NullPointerException.
Начитавшись stackoverflow и прочих, сделал вывод, что в случае андроида более правильно будет реализовать хранение подобных глобальных данных в виде полей своего наследника класса Application, указанного в соответствующем теге <application… > манифеста приложения. Что, впрочем, не дало ровным счетом никакого профита — все так же в случайный момент времени пользователи получают NullPointerException при восстановлении приложения после длительного пребывания в фоне, либо после чего-то весьма ресурсоемкого и прожорливого на память, что означает, что андроид все так же прибивает эту используемую память (что странно, ибо я раньше думал, что при паузе и восстановлении пересоздаются Activity и прочие виды, а объект Application живет от старта приложения до его конца).
Собственно, сам вопрос. Каким способом можно реализовать хранения глобальных данных, а именно — одиночного экземпляра некоего класса, и, при этом, как я могу гарантировать существование этого объекта на протяжении всего жизненного цикла запуска приложения?
Буду весьма признателен любой помощи, т.к. сам уже довольно-таки ощутимое время безуспешно бьюсь над этой задачей.
Лучше данные хранить либо в SharedPreferences, либо в файлах кеша. Зависит от размера и формата самих данных. А доступ к ним обеспечить через наследника Application. Если данных очень много, то лучше их хранить в базе SQLite и работать через провайдер. Никто никогда не гарантирует время жизни приложения — система сама определяет когда выгружать по мере надобности. Теоретически можно написать свой Service, который будет «висеть» в памяти постоянно, но пользователи приложения это не оценят.
SharedPreferences, как я понимаю, позволяет хранить лишь простые типы данных, int, float, String и т.д. Так что он сразу не подходит.
Была мысль сделать сохранение в кэш посредством ObjectOutputStream.writeObject, однако получаю NotSerializableException, ибо класс содержит в себе Context.
Насчет сервиса — сдается мне, что это единственный вариант. Вот только не может ли система так же прибить сервис в случае нехватки памяти?
Возможен запуск сервиса в режиме, когда он будет постоянно находиться в памяти. Однако еще раз повторюсь — пользователи не оценят. Может попробовать сделать объекты сериализируемыми? И возможно пересмотреть структуру приложения, уж очень сложно представить нужность хранения контекста — данные лучше отделять от представления.
А можете подсказать насчет «запуска сервиса в режиме, когда он будет постоянно находиться в памяти»?
Насчет архитектуры тоже мысль верная, конечно, подумаю в эту сторону.
Сервис будет «висеть» в памяти, если он запущен и не будут вызваны методы stopSelf или stopService. Все же варианты, когда сервис будет остановлен остаются, например принудительно пользователем. Так что это лучше не использовать. Не предназначены сервисы для хранения данных. Лучше все же подумать над архитектурой.