iphone - precio - Tratar con solicitudes web asíncronas abiertas cuando UIViewController aparece(AFNetworking)
iphone xs (2)
Aquí está el escenario:
-U UIViewController (A) se inserta en la pila de navegación
-en viewDidLoad, se llama a un GET asincrónico utilizando AFNetworking (un AFHTTPClient único compartido en la aplicación) para llenar varios elementos de usuario en la vista (digamos un UILabel).
-El usuario presiona el botón Atrás antes de que la solicitud regrese
-Asumir que otros controladores de vista activos pueden estar haciendo solicitudes para que no pueda cancelar todas las operaciones abiertas
Entonces, la pregunta n. ° 1 es, ¿debería hacer un seguimiento de las solicitudes abiertas realizadas por UIViewController A y cancelar las pendientes cuando el usuario abandona esa vista, o debería dejarlas terminar e ignorarlas? Dado que AFNetworking usa bloques, los elementos del usuario que se están actualizando se retienen dentro del bloque y, por lo tanto, no provocarán un bloqueo cuando el bloque de éxito / error se ejecute una vez que se haya visualizado la vista. Sin embargo, la desventaja de ignorarlos parece ser el tráfico de red innecesario.
La pregunta 2 es, ¿dónde ejecutarías el código para cancelar las operaciones realizadas por UIViewController A? viewDidDisappear no parece correcto porque el usuario puede haber avanzado (insertado una nueva vista en la pila) en lugar de volver (apareció la vista actual), en cuyo caso no desea cancelar las solicitudes abiertas porque el usuario puede venir volver a la vista actual y no se cargará nuevamente. Sin embargo, no creo que se invoque a dealloc o viewDidUnload mientras se está ejecutando la solicitud, ya que el bloque mantendrá una retención en los elementos del usuario, por lo que no creo que pueda llegar allí.
Apreciaría pensamientos sobre esto. ¿Cuál crees que es la mejor práctica?
Tal vez podrías tener un singleton que administre todo el material de la red, y simplemente establecer su delegado al vc actual (en viewDidLoad) para que obtengas los datos entrantes, y enviar un mensaje de cancelación cuando el vc desaparezca (o bien dejar un vc diferente) convertirse en su delegado). O el singleton podría mantener los datos de acceso por cualquier vc en una etapa posterior. Tiendo a no poner código asíncrono en mi VC por este motivo.
En términos generales, no es necesario que canceles las solicitudes cuando un usuario abandona un controlador de vista. En términos de gestión de la memoria, una referencia al bloque self evitará los bloqueos causados por el envío de mensajes a las instancias desasignadas, por lo que no se preocupe.
En cuanto a la experiencia del usuario, diría que no deberías preocuparte realmente hasta que sea un problema (nosotros los desarrolladores tenemos una habilidad especial para adivinar completamente lo que será lento en nuestras aplicaciones). Sin embargo, si está realizando grandes solicitudes GET y está creando una lentitud notable, mi sugerencia sería que el controlador haga HTTPClient -cancelAllHTTPOperationsWithMethod:path: en -viewDidUnload: (cualquier otra devolución de llamada sería prematura).