iphone - tutorial - ios getting started

¿Cuál es la ventaja de usar Reachability?

Question

¿Cuál es la ventaja de usar Reachability sobre el código a continuación? Siento que Alcachability tiene una gran cantidad de código, pero si es mejor de alguna manera, entonces usaría eso en su lugar.

NSString *connectionString = [[NSString alloc] initWithContentsOfURL:[NSURL URLWithString:@"http://www.google.com"]];
if ([connectionString length] == 0) {
//No connection
}

Ahora bien, si Google fallara alguna vez, esto no funcionaría. Pero literalmente no hay posibilidad de que eso suceda. ¿Qué piensas? ¡Gracias!

Answer 1

El mayor problema de la accesibilidad no es que sea un código incorrecto o que sea un código incorrecto. En realidad, es un código bastante bueno ahora. Pero es fácil malinterpretar y utilizar mal el código para un propósito que no fue intencionado.

Aquí hay algunas pautas para usar Reachability:

• Sí, usa Accesibilidad. Tal vez el punto más obvio: la accesibilidad puede ser una gran ventaja para hacer que tu aplicación se sienta más natural.
• Nunca use Accesibilidad como verificación previa. El hecho de que Reachability informe que las redes no están actualmente disponibles no significa que no estarán disponibles si intentas usarlas . Esa solicitud de red que no está enviando podría ser lo que despierta las redes de iOS.
  • Edición: en realidad, probablemente debería suavizar esto un poco. Puede tener sentido diferir una operación no solicitada por un corto tiempo. Todo lo demás es igual, es mejor hacer todas las conexiones de forma continua en lugar de encender y apagar el hardware repetidamente. ¡Sé ráfaga si es posible! Pero nunca debe detener al usuario para que no haga algo basado en Accesibilidad.
• Use Accesibilidad para ayudar a diagnosticar por qué algo falló. Después de intentar hacer una red, Reachability le dirá que la red no está disponible. Esta es información valiosa que puede usar para construir un buen mensaje de error, y probablemente sea más importante que el código de error exacto que devolvió la API.
• Permitir que el usuario intente de nuevo manualmente. El usuario puede saber que la red debería funcionar desde este punto. No confíe en que iOS se dé cuenta de que las redes ya están disponibles y que Reachability le informará. Una vez más, el intento podría ser lo que lo hace disponible.
• Use la notificación de Accesibilidad para volver a intentar automáticamente. Cuando Reachability le dice que la red está disponible, es porque estaba disponible. Puede volver a bajar antes de que puedas finalizar tu intento, y puede ser una red cautiva, pero es un buen momento para volver a intentar tu solicitud.

Puede ver este comportamiento en Mobile Safari. Si una página no se carga, puede volver a intentarlo, independientemente de si el iPhone cree que tiene una conexión. Si las redes están disponibles y Mobile Safari se da cuenta, lo intentará de nuevo automáticamente. Se siente muy natural.

Recuerde estas pautas:

1. Las redes móviles no son simples.
2. La única forma segura de determinar si una conexión de red tendrá éxito es probarla y ver si tuvo éxito.
3. Determinar si una conexión de red realmente tuvo éxito tampoco es siempre trivial.

Hay varias sesiones WWDC 2011 sobre redes móviles que vale la pena ver. (Hay varios de 2010 que abordaron esto, también, y estoy seguro de que habrá varios en WWDC 2012. No es un problema simple, y no va a desaparecer).

Además: initWithContentsOfURL es sincrónico. No use redes sincrónicas en iOS. Si lleva un tiempo inesperadamente largo, el perro guardián de iOS cerrará tu aplicación.

Answer 2

Esta es realmente una buena pregunta, tan buena que realmente la uso en las entrevistas de desarrolladores de iOS cuando mi empresa está reclutando:

¿Por qué el ejemplo de accesibilidad de Apple tiene cientos de líneas, cuando puede usar una sola línea para verificar si una URL responde?

En primer lugar, la accesibilidad de la red es realmente muy, muy complicada . Es mucho más que simplemente probar una URL. Piensa en los siguientes ejemplos:

• El usuario está en 3G, pero ha agotado su asignación de datos, por lo que cada solicitud redirige al sitio del operador.

• El usuario está conectado a una red WiFi pública que requiere autenticación / inicio de sesión, por lo que la solicitud redirige a una página de inicio de sesión

El último ejemplo es increíblemente común , sucede todo el tiempo. Pero si utilizó initWithContentsOfURL su aplicación se imaginaría que tenía conectividad, cuando en realidad no lo hizo: simplemente le devolvieron el contenido de la página a la que la red lo había redirigido.

Esta es una de las razones por las cuales el código de Apple es más complejo de lo que crees al principio. No se debe simplemente preguntar "¿Puedo acceder a esta URL?" , Sino "¿los datos que se devuelven desde esta URL son los que espero "?

Pero eso es solo la punta del iceberg. La accesibilidad hace mucho más que eso, por ejemplo, podría tener una aplicación que necesita descargar mucha información, digamos 50MB vale la pena. Sería una mala idea simplemente descargar 50MB de datos si el usuario estaba en una conexión 3G sin su consentimiento, especialmente si están en roaming o en un plan de datos restringido. Por lo tanto, Reachability también le indicará en qué tipo de conexión está el usuario: EDGE, 3G, WiFi, etc. (* NB: vea la nota a continuación, probablemente este no sea el mejor consejo).

ReadMe.txt dentro de Reachability le informará un poco más sobre lo que el código puede y no puede hacer.

Desafortunadamente, hay demasiadas personas en línea que no se dan cuenta de que hay muchos escenarios cotidianos donde initWithContentsOfURL devolverá una respuesta válida, pero el usuario no tendrá conectividad. [Las publicaciones del blog como esta] [1] se indexan en Google, y la gente asume que es un sustituto aceptable: ¡no lo es!

Una de las razones por las que formulo esta pregunta al reclutar es que puede mostrar que un desarrollador no solo está pensando en la caja, como usted y muchos otros desarrolladores, mi primera reacción cuando vi que el código de muestra de Reachability era "¡vaya !, parece demasiado complicado por algo que es muy simple ". Pero espero que esta respuesta haya sido de alguna manera para convencerte de lo contrario.

Editar: Definitivamente, tome nota de los comentarios de Steven a continuación. Él plantea algunos puntos que mi respuesta no había considerado (es decir, los hotspots de MiFi), y presenta un caso válido de que el alcance no es necesariamente el pico de codificación del código. En muchos casos, los desarrolladores modificarán la accesibilidad con sus propias mejoras y similares.

Answer 3

Otra buena razón para usar Reachibility, además de la gran respuesta de @lxt, es que si no está realizando su debida diligencia dentro de su aplicación para dar cuenta de los escenarios de conectividad, su aplicación será rechazada. Apple probará su aplicación con y sin conectividad, y si falla alguno de esos escenarios, su aplicación ni siquiera será vista.

Estoy totalmente de acuerdo con la respuesta de lxt. Le brinda muchos más detalles en su conectividad que solo "me puedo conectar a algún sitio web". Gran pregunta

Answer 4

Todos los puntos buenos. Añadiré: considere usar NSURLConnection. Tiene un protocolo de delegado que le informa de todos los eventos / incidentes relevantes que ocurren cuando se trata de establecer una conexión. Le da mucho más control que un método simple initWithCintentsOfURL, y permite el procesamiento asíncrono. Pero si lo usa de muchas clases, puede ser engorroso implementar todos los métodos de delegado muchas veces. Lo envolví en una clase personalizada con solo dos métodos de delegado: didFail y didFinish , y reutilicé esa clase en todo mi código.

Answer 5

Una de las ventajas de Accesibilidad es que puede enviarle una notificación cuando el estado de la conexión cambia. De esta manera, puede informar a su usuario que algunas funciones pueden estar restringidas.