Всем привет. Проверяю подключения к интернету путем обычного коннекта к

ссылке и проверяю респонс статуса, собираюсь каждые десять секунд делать запрос на проверку (внутри карутин)

Сильно ли это скажется на потребления зарядки и ресурсов в целом?

один вопрос... зачем?

почему бы не делать проверку только когда делаешь запрос, ты похоже только начал писать на андроид да? просто и подход и код и кейс крайне не такой как нужно делать в реале

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

уже 3 года пишу почти сениор) Вопрос заинтересовал так как никогда не приходилось делать такое, стало интересно делает ли кто нибудь

что именно ? проверку коннекта?

да проверку коннекта имено к инету, а не состояние вайфая и моб данных

смотри , сеньор )

почему так? Не проще через BroadcastReceiver чекать?

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

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

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

Проверка вернула true, а интернет тут же пропал. Ваши действия?

я так же думал пока мои "умные" юзеры не начали мне 1 ставит, говорят что у них инет есть, а данных нет. Хочу ум натификацию внутри приложения сделать чтобы если не было доступа к сайту не портили мне оценку)

проверка там уже обычная проверка на статус и таймаут если инет пропал. К чему вопрос)

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

К тому что if (isConnected) { >>> ЗДЕСЬ ИНТEРНЕТ ПРОПАЛ <<< // do network exchange }

Леонид, дак наверное нужно при запросе проверять статус ответа, код ответа имею ввиду 200-500

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

Еще раз - проверка успешная, через наносекунду после этого интернет пропал. Ваши действия?

огорчение )

лив дату чтоли юзать на проверка инета или что как , расскажите маэстро

Ну я проверяю если конект есть делаю запрос (запрос длинный и тяжелый) а там уже по состоянию запроса принимаю решения))

а смысл?

Заказчик просить чтобы кнопка была не доступно если нет доступа к сайту.

думаю он не про это

про это)

он тот еще знатный троллл

Состояние сети можно проверять так: https://developer.android.com/training/monitoring-device-state/connectivity-status-type Проверка перед выполнением запроса в общем бесполезна, потому что, как я сказал раньше, соединение может пропасть через наносекунду после проверки и вы получите ту же самую проблему. Вообще принято просто выполнять запросы и обрабатывать ошибки, если они происходят. Потому что в любой момент что-то может пойти не так.

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

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

Тогда, наверное, лучше мониторить состояние через это: https://developer.android.com/training/monitoring-device-state/connectivity-status-type и обновлять флаг или LiveData по вкусу.

мой класс лучше )))

сейчас уже так, но юзеры ставят разные впн и у некоторых тупа нет доступа на наш сервер. А кнопка активна так как нетворк отвечает что все окей

сегодня реально тестили кейс на устройствах <23 апи ) там нужны методы которых нет там в доке

так никогда нельзя гарантировано знать, что тот или иной IO будет успешен. Зато есть ситуации, когда гарантировано будет ошибка)

для максимальной достоверности можно подсоединиться по вебсокетам (всё равно не гарантия, но хоть так)

Подробности подъехали :) Наверное, можно комбинировать проверки, раз все так непросто. И все равно будут проблемы.

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