Добрый день.

Вопрос в том, где можно хранить глобальные методы UI потока?
Суть в том, что нужна независимость от стартовой активности, которая может
умирать и возрождаться множество раз в течении жизни приложения.
Приложение работает с сетью. Сеть живет в отдельном потоке.
И от сетевого потока периодически будет приходить информация о своем состоянии
в пользовательский интерфейс и заранее не известно в какую активность или в какой
фрагмент попадет.
Предполагается, что заинтересованные фрагменты или активности будут реализовывать
интерфейс слушателя интересующего события типа onNetworkConnected, onNetworkDisconnected,
onDataReceivedFromServer и т.д.
Так вот нужен единый диспетчер, генерирующий эти события для подписанных слушателей.
Этот диспетчер будет единственным получателем готовой информации от фоновых процессов,
хранителем данных и единственным распределителем по пользовательскому интерфейсу.
И диспетчер должен жить постоянно на протяжении всей жизни приложения.


Возможно ли вообще такое?

Про синглет читал тут http://developer.android.com/intl/ru/reference/android/app/Application.html :

developer.android.comThere is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

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

И вот далее про Контекст ,
есть пугающая фраза про невозможность разрегистрировать подписку на рассылки , что приведет к утечкам:

quote developer.android.comIf used from the Context returned here, the receiver is being registered with the global state associated with your application. Thus it will never be unregistered for you. This is necessary if the receiver is associated with static data, not a particular component. However using the ApplicationContext elsewhere can easily lead to serious leaks if you forget to unregister, unbind, etc.

А здесь видимо кто-то уже столкнулся с похожими проблемами на уровне Application.

Если у кого-нибудь есть подобный опыт, прокомментируйте пожалуйста.

Ilya81,

Если я правильно понял, то получается следующая схема:
В стартовой активности создается Singleton.getInstance(Context context), который в свою очередь получает глобальный контекст приложения Context.getApplicationContext() и будет хранить все необходимые данные и методы.
Стартовая активность может запускать другие активности и фрагменты и спокойно умирать если так решит ОС, а наш Singleton будет спокойно жить своей жизнью являясь получателем рассылок, Handler-ов, и т.д. данных других потоков и сервисов и предоставляя свои данные для других получателей. Фрагменты и активности сами ничего хранить не будут, а только получать ссылки на объекты внутри Singleton, который живет внутри потока UI и поэтому способен без ошибок взаимодействовать с пользовательским интерфейсом.

wadmanНет. Не будет жить или не будет жить спокойно.
Почему не будет?
Видимых причин для этого нет.

Я протестировал: В одной активности первый раз вызвал Singleton.getInstance(), контекст приложения взялся нормально, изменил в нем несколько полей. Вышел из активности. В другой активности все записанные данные прочитались. Ничего не грохнулось.
Единственно проблема, в том, что при выходе из приложения приложение не убивается и Singleton остается жить дальше
и в следующий запуск продолжает радовать данными из предыдущего запуска, но это тем или иным способом можно решить
принудительно очистив его при выходе из главной активности.

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

Вид приложения разделен на несколько фрагментов одновременно отображающихся.
В каждом из них в реальном времени отображается своя информация.

wadman, Ilya81
Спасибо за идеи.
Уже получается то, что нужно.

wadman,

Имеется ввиду контекст приложения?
Я в конструкторе Singleton получаю контекст самого приложения через контекст вызывающей активности.
this.apcontext=context.getApplicationContext();

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

докаReturn the context of the single, global Application object of the current process. This generally should only be used if you need a Context whose lifecycle is separate from the current context, that is tied to the lifetime of the process rather than the current component.

Как можно воспроизвести подобные сценарии, чтобы проверить?

Я пробовал убивать процесс, когда он на экране и когда из приложения вышли.
Всегда в этих случаях получается новый объект Singleton.getInstance(Context context)
и в нем соответственно получается новый контекст.
Если прибить процесс, когда открыта вторая активность(из стартовой), то андроид сам перезапускает
приложение и идет в стартовую активность как с нуля.

А в чем преимущества сервиса перед отдельными потоками в данном конкретном случае?

Сервис необходим в случае, когда работа должна продолжаться когда приложение закрыто,
например, почтовый клиент в фоне проверяет почту или какой-нибудь IM-чат сообщения ловит.
Или сервис должен работать на несколько других приложений.

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

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