Лучший способ реализовать Socket.io в android

Я планирую реализовать Socket.io в android с помощью этой библиотеки для приложения на основе чата. Насколько я понял, библиотека кажется довольно хорошей. Я хочу знать, как поддерживать соединение одиночное сокетов во всем приложении все время? Здесь я перечислил способы достижения, в которых мне нужен лучший и стабильный способ.

Три способа

MainApplication Класс расширяет Приложение

Таким образом, у нас есть хороший объем, который поддерживает сокет в главном потоке (или жизненном цикле приложения), и всякий раз, когда экземпляр сокета требуется от активности, мы можем легко его получить. Но это основная нить, которая тоже проблема. Он может блокировать основной поток.

BoundService

Таким образом, мы можем связывать службу с действиями, и мы можем просто ее использовать. Выполнение в отдельном потоке - это способ достижения IO/сетевых вызовов. Но перекрестная обработка передачи дороже, чем прямой доступ к тому же процессу.

Синглтон

Поддержание связи в Singleton также имеет смысл. Но мы не знаем, когда экземпляр убит процессом, потому что он не работает в жизненном цикле активности.

Если у меня есть смысл, пожалуйста, помогите мне. Если не прокомментировать это.

Изменить

Я дал ответ, который больше подходит для меня.

ОТВЕТЫ

Ответ 1

Служба поддержки socket соединения

Согласно Опеку Рону, упомянутому Service с BroadcaseReceivers, идея лучше, чем BoundService. Потому что его утомительный процесс для поддержания общения. И я также рекомендую pub/sub способ вещания, например Otto или EventBus (я сам предлагаю Отто по площади, что является чистым и блестящим api).

Преимущества OTTO
1. Очиститель Api
2. Вы можете подписаться и опубликовать в/любую деятельность, фрагмент, службу, класс.
3. Развязка. (Вы должны как можно меньше входить в свой код).

И еще один момент - использовать START_STICKY в onStartCommand для запуска службы после ее уничтожения. См. эту ссылку.

MainApplication для запуска службы

Лучше всего начать сервис в приложении MainApplication extends. Поскольку приложение будет убито при наличии ограничения памяти, или пользователь принудительно закрывает приложение из стека. Поэтому onStartCommand не будет вызываться часто, как если бы мы реализовали в Activity.

Реализация онлайн-статуса

Вы можете реализовать онлайн-статус, просто реализуя Application.LifeCycleCallbacks в классе MainApplication, который имеет большинство обратных вызовов жизненного цикла активности и будет уведомлен в обратном вызове. Благодаря этому вы можете реализовать статус Online просто без кодов пластин котла. (Если кому-то нужна помощь, дайте мне знать).

Загрузка или загрузка изображений или файлов.

Лучшей практикой является реализация IntentService, потому что она работает в отдельном потоке. Я обещаю, что даст лучшую производительность, потому что он обрабатывается самим андроидом, а не потоками, созданными нами.

Ответ 2

Прежде всего, приложение onCreate является непоправимым для вашего случая использования, потому что вы не можете иметь поток, выполняющийся в фоновом режиме, когда он был сначала инициирован в коде без обслуживания.

Кроме того, я бы рекомендовал вместо < Google Cloud Messaging создать собственный механизм. Это было бы лучше всего для аккумулятора устройства и гораздо меньше кода для вас.

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

Ответ 3

Вы можете комбинировать первый и третий способы, например:

Создайте Socket в Application и объявите их как static. Таким образом, вы можете поддерживать и получать доступ к ним, где бы вы ни находились. Не забудьте создать отдельный Thread для выполнения сетевых операций, вы можете использовать ThreadPool для управления этими Thread. Если вы хотите обновить свой интерфейс из этих Thread, вы можете использовать Handler и Message для связи с UI Thread

Ответ 4

Перед созданием собственной реализации клиента socket.io вы должны предоставить этой библиотеке шанс: https://github.com/socketio/socket.io-client-java

Я использую его в одном из моих проектов для связи с сервером node.js, который работает очень хорошо. Собственно, все ваши предложения верны и в основном зависят от того, чего вы хотите достичь. Тем не менее, один контекст всегда доступен: контекст приложения. Поэтому вы должны сохранить экземпляр singleton в классе Application и получить его с помощью getApplicationContext().

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

Чат: данные чата передаются только при активном приложении. Итак, это должно быть сделано в деятельности.

И служба, и действие могут обращаться к экземпляру singleton клиента socket.io из контекста приложения. Пока вы не обрабатываете сложные данные по основному потоку, все в порядке. Таким образом, переносите ваши вызовы в отдельный поток и запускайте их только тогда, когда они действительно необходимы.