Singleton или Сервис для сокетного соединения

Question

Я новичок в разработке под Android, пытаюсь перенести приложение IOS на Android. В основном мое приложение должно общаться с сервером в режиме реального времени через сокет ввода-вывода. Он подключается к серверу, а затем обрабатывает различные сообщения, пока сервер не завершит обработку запроса.

В моем приложении IOS я использую шаблон Singleton для отправки запросов на мой сервер веб-сокетов, и я использую тот же экземпляр для делегирования ответа сервера. В Android я собирался использовать тот же шаблон с объектом обратного вызова в моей деятельности, чтобы перенаправить пользователя после получения ответа сервера.

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

Некоторые люди рекомендуют использовать Службу с широковещательным приемником вместо Singleton. Это лучше всего сделать в моем случае?

Answer 1

Использование Service - это именно то, что я сделал для очень похожих целей (осуществляя связь через сокеты для приложений Bluetooth и TCP / IP), и думаю, что вы наверняка захотите использовать Service, если связь должна продолжаться дажекогда пользователь закрыл приложение.

A Service по сути является средством для запуска кода в потоке пользовательского интерфейса (но, конечно, вы можете затем запускать другие потоки в нем), но без пользовательского интерфейса, в отличие отActivity, с которым связан пользовательский интерфейс.

Если бы вы попытались сделать это в статическом одноэлементном классе, как вы предлагаете в качестве альтернативы, то я думаю, что проблема заключается в том, что вы не захотитеиметь очень хороший контроль над жизненным циклом.Если пользователь уходит от приложения, то, насколько я понимаю, это зависит от фреймворка, когда он решает удалить процесс и все статические объекты вместе с ним.По этой причине, если у вас есть одноэлементные классы, заполненные данными, и вы выходите из приложения, а затем возвращаетесь в приложение, вы можете обнаружить или не обнаружить, что «старые» одноэлементные экземпляры все еще существуют.По этой причине в моем приложении (которое использует очень большое количество глобальных состояний) я прибегнул к хранению фактических экземпляров моих синглетов в расширении класса .Application, чтобы (надеюсь) лучше контролировать их жизненный цикл.

С Service у вас есть четко определенный жизненный цикл с соответствующими обратными вызовами жизненного цикла (onCreate(), onDestroy() и т. Д.), Как и с Activity.

Answer 2

Да, обязательно используйте Service. Из документов :

Служба - это компонент приложения, представляющий либо желание приложения выполнить более продолжительную операцию, не взаимодействуя с пользователем

Хотя использование синглтона может работать некоторое время, ваше приложение будет склонно к удалению операционной системой при переходе в фоновый режим, если у вас нет Service. Если вам удобнее использовать одноэлементный шаблон, вы можете реализовать его в одноэлементном режиме, а затем просто привязать его к Service просто, чтобы сохранить его жизненный цикл, но это кажется скорее беспорядком, чем стоит , Обратите внимание, что вы не должны выполнять сетевые операции в потоке пользовательского интерфейса, и по умолчанию служба работает в потоке пользовательского интерфейса. Вам нужно будет раскрутить другой поток, чтобы выполнить свою работу.

Я не вижу в вашем посте ничего, что требовало бы BroadcastReceiver, хотя, возможно, могут быть полезны сетевые радиовещательные намерения, такие как android.net.ConnectivityManager.CONNECTIVITY_ACTION.