В чем преимущество использования достижимости?

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

NSString *connectionString = [[NSString alloc] initWithContentsOfURL:[NSURL URLWithString:@"http://www.google.com"]];

if ([connectionString length] == 0) {

    //No connection

}

Теперь, если Google когда-нибудь опустится, это не сработает. Но в этом нет никаких шансов на это. Как вы думаете? Спасибо!

Ответ 1

Это на самом деле довольно хороший вопрос - так хорошо, что я действительно использую его в интервью разработчиков iOS, когда моя компания рекрутирует:

Почему пример достижимости Apple составляет сотни строк, когда вы можете просто использовать одну строку, чтобы проверить, реагирует ли URL-адрес?

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

Пользователь подключен к сети 3G, но израсходовал свое пособие на данные, поэтому каждый запрос перенаправляет на сайт оператора.
Пользователь подключен к общедоступной сети Wi-Fi, которая требует аутентификация/логин, поэтому запрос перенаправляется на страницу журнала

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

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

Но это действительно только верхушка айсберга. Достижимость делает гораздо больше, кроме того - например, у меня может быть приложение, которое должно загружать много информации, скажем, 50 МБ. Было бы неплохо просто загрузить 50 МБ данных, если бы пользователь подключился к 3G-соединению без их согласия, особенно если они находятся в роуминге или в ограниченном плане данных. Таким образом, Reachability также сообщит вам, к какому типу подключения подключен пользователь: EDGE, 3G, WiFi и т.д. (* NB: см. Примечание ниже, это, вероятно, не лучший совет).

ReadMe.txt внутри Reachability расскажет вам немного больше о том, что код может и не может сделать.

К сожалению, в сети слишком много людей, которые не понимают, что существует много повседневных сценариев, в которых initWithContentsOfURL вернет правильный ответ, но у пользователя не будет возможности подключения. [Сообщения в блоге, подобные этому] [1] индексируются в Google, и люди считают это приемлемой заменой: это не так!

Одна из причин, по которой я задаю этот вопрос при наборе, может показать, что разработчик не просто думает внутри коробки - как вы и многие другие разработчики, моя первая реакция, когда я увидел пример кода Reachability, был "вау, это кажется слишком сложным для чего-то очень простого". Но, надеюсь, этот ответ будет каким-то образом убедить вас в этом.

Изменить: Определенно обратите внимание на комментарии Стивена ниже. Он поднимает некоторые моменты, которые мой ответ не учитывал (т.е. Горячие точки MiFi), и делает правильный пример того, что Reachability не обязательно является пиком кодирования небесного кода. Во многих случаях разработчики будут модифицировать Reachability своими собственными улучшениями и т.д.

Ответ 2

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

Вот некоторые рекомендации по использованию возможности:

Да, используйте Reachability. Возможно, самый очевидный момент: доступность может стать огромным преимуществом, чтобы ваше приложение стало более естественным.
Никогда не используйте Досягаемость в качестве предварительной проверки. Просто потому, что Reachability сообщает, что сетевая связь в настоящее время недоступна, не означает, что она не станет доступной , если вы пытаетесь используй это. Этот сетевой запрос, который вы не отправляете, может быть тем, что пробуждает сеть iOS.
- Изменить: На самом деле, я, вероятно, должен немного смягчить это. Возможно, имеет смысл отложить невыполненную операцию на короткое время. При прочих равных условиях лучше делать всю свою сеть непрерывно, а не включать и выключать аппаратное обеспечение повторно. По возможности взрывайтесь! Но вы должны никогда не позволять пользователю делать что-то на основе Reachability.
Использовать Досягаемость, чтобы помочь диагностировать, почему что-то не получилось. После попытки создания сети Reachability сообщит, что сеть недоступна. Это ценная информация, которую вы можете использовать для построения хорошего сообщения об ошибке, и, вероятно, важнее точного кода ошибки, возвращаемого API.
Разрешить пользователю повторять вручную. Пользователь может знать, что сетевое взаимодействие должно работать с этого места. Не полагайтесь на iOS, заметив, что сеть теперь доступна, и информация о достижимости, информирующая вас. Опять же, попытка может быть тем, что делает его доступным.
Использовать уведомление о достижимости для автоматической повторной попытки.. Когда Reachability сообщает вам, что сеть доступна, она была доступна. Он может снова опуститься, прежде чем вы сможете закончить свою попытку, и это может быть сеть в неволе, но это хороший момент, чтобы снова попробовать ваш запрос.

Вы можете видеть это поведение в Mobile Safari. Если страница не загружается, вы можете повторить попытку, независимо от того, считает iPhone, что у вас есть соединение. Если сеть станет доступной, и уведомления Mobile Safari, тем не менее, она попытается снова автоматически. Это действительно естественно.

Помните следующие рекомендации:

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

Там несколько сессий WWDC 2011 по мобильным сетям, которые стоит посмотреть. (В 2010 году было несколько из них, и я уверен, что в WWDC 2012 будет несколько. Это не простая проблема, и она не исчезает.)

Также: initWithContentsOfURL является синхронным. Не используйте синхронную сеть в iOS. Если это произойдет неожиданно долгое время, ваше приложение будет закрыто сторожевым устройством iOS.

Ответ 3

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

Ответ 4

Все хорошие моменты. Я добавлю: рассмотрим использование NSURLConnection. Он имеет протокол делегатов, который информирует вас обо всех соответствующих событиях/инцидентах, возникающих при попытке установить соединение. Это дает вам гораздо больше контроля над простым методом initWithCintentsOfURL и позволяет выполнять асинхронную обработку. Но если вы используете его из многих классов, может оказаться громоздким многократно применять все методы делегата. Я завернул его в пользовательский класс только с двумя методами делегата: didFail и didFinish и повторно использовал этот класс во всем моем коде.

Ответ 5

Еще одна веская причина использовать Reachibility, в дополнение к большому ответу @lxt, заключается в том, что если вы не выполняете должную осмотрительность внутри своего приложения, чтобы учитывать сценарии подключения, ваше приложение будет отклонено. Apple проверит ваше приложение с подключением и без него, и если он не сработает ни с одним из этих сценариев, ваше приложение даже не будет рассмотрено.

Я полностью согласен с ответом lxt. Это дает вам гораздо больше деталей в вашем подключении, чем просто "можно подключиться к некоторому веб-сайту". Большой вопрос.