0

У меня есть требование в моем приложении, в котором мое приложение всегда должно быть подключено к Интернету (только для 2G/3G). Для этого можно создать службу, которая продолжает проверять, устройство подключено к Интернету или нет. Если нет, тогда мы можем программно подключиться к Интернету (это связано с тем, что мое приложение будет работать в среде с очень небольшим взаимодействием с пользователем, поэтому большинство вещей должно происходить автоматически). «Сервисный» подход хорош, но потребляет значительную батарею из-за постоянного опроса, чего я хочу избежать.Самый эффективный подход к постоянной проверке подключения к Интернету Android.

Я недавно прочитал о трансляции под названием - CONNECTIVITY_ACTION, что система generates.As в ДоП Изменения в связи беспроводного устройства может быть очень часто, это широковещательный срабатывает каждый раз, когда вы перемещаетесь между мобильными данными и Wi-Fi..

В моем требовании устройство будет подключаться ТОЛЬКО к 2G/3G и никогда не подключаться к Wi-Fi. Так что есть трансляция из системы, с помощью которой я могу узнать изменения в подключении (ON/OFF) к 2G/3G в одиночку? Поскольку в соответствии с приведенной выше цитатой, я заключу, что CONNECTIVITY_ACTION будет запущен только тогда, когда состояние изменится с мобильных данных (2g/3g) на Wi-Fi. Это так? (Пожалуйста, поправьте меня, если я ошибаюсь).

Также, пожалуйста, просветите меня самым эффективным подходом, который я должен использовать, чтобы проверить, что мое устройство постоянно подключено к Интернету (2g/3g) (кроме подхода, основанного на услугах), чтобы затем я мог принять меры для автоматического подключения к Интернету? Заранее спасибо !

ответ

1

Указанная передача отправляется при полном отключении. Это даже упоминается в документах

Для события разъединения логическое значение extra EXTRA_NO_CONNECTIVITY равно true, если нет подключенных сетей вообще.

Просто слушайте CONNECTIVITY_ACTION и делайте все, что необходимо для повторного подключения вашего устройства.

Полный документ: https://developer.android.com/reference/android/net/ConnectivityManager.html#CONNECTIVITY_ACTION

1

«сервис» подход хорошо, но требует значительной батареи из-за постоянный опрос, который я хочу, чтобы избежать.

Нет, сервисного подхода нет. Infact вам нужно, чтобы ваши слушатели были в службе, чтобы сделать все это в бэкэнд.

Слушатели связи для Wi-Fi и данных - единственный способ сделать это. Если вы не используете Wi-Fi, тестирование будет кошмаром (представьте себе тестирование в сети 2g). Слушатель данных, который вам нужно проверить, когда на сценарии шоссе и плохой сети. Слушатели ведут себя плохо, иногда посылая несколько событий, а иногда и вообще никаких событий. Таким образом, проверьте это действительно с Wi-Fi перед тем, как вы проверите данные. Поскольку с данными вам нужно выйти из офиса и проверить на реальных дорогах и в подземельях, в лифте и в специальных режимах, таких как режим AIRPLANE. Подумайте об этой особенности, это стоит усилий? Слишком много сценариев (реального мира), которые могут потерпеть неудачу. Эффект огромен, если он плохо работает с батареей, функциональность и ваш сервер соединений могут получить слишком много запросов на соединение, отправляя их в атаку DOS :).

Подумайте о автоматический подключение тщательно.

Когда у меня был этот случай, я немного изменил UX/UI, чтобы подключиться, когда это необходимо, вместо этого добавив 2 секунды к производительности приложения.

Edit: Тестирование кошмар

Да, кодирование одна часть проблемы, тестирование может быть кошмаром. Представьте себе 10 ошибок в неделю только по этой проблеме подключения. Представьте себе атаку DOS на сервере, и вы не узнаете, пока не воспроизведете ее. Соединения DONT для подключения к серверу (с отметками времени). Представьте себе целую 3-дневную попытку исправить атаку DOS, вызванную вашим собственным приложением у одного клиента, который был в лифте. :) Я недавно столкнулся с этим дерьмом. Samsung сделал невозможным сделать что-то в Android из-за их плохой настройки каркаса.

+0

Не говоря уже о том, что разные вкусы андроида ведут себя по-разному с этими слушателями. Добавление к тому, что у Samsung есть свой единственный стек и беспорядок вокруг этих частей кода, до такой степени, что поведение на HTC и Samsung сильно отличается. Добавление к усложнению тестовой матрицы. Я тоже переосмыслил свою стратегию. – taxeeta

+0

Вау, спасибо, что выделили разных людей! Я поцарапаю свой мозг для различных подходов :) – Basher51

+0

Да, кодирование - это одна из проблем, тестирование может быть кошмаром. Представьте себе 10 ошибок в неделю только по этой проблеме подключения. Представьте себе атаку DOS на сервере, и вы не узнаете, пока не воспроизведете ее. Соединения DONT для подключения к серверу (с отметками времени). Представьте себе целую 3-дневную попытку исправить атаку DOS, вызванную вашим собственным приложением у одного клиента, который был в лифте. :) Я недавно столкнулся с этим дерьмом. Samsung сделал невозможным сделать что-то в Android из-за их плохой настройки каркаса. – Siddharth