2012-03-03 18 views
5

Pregunta básica: Si tiene una URL de activo y desea recuperar la imagen para ese activo, ¿cómo realmente verifica que el activo realmente exista? Consulte mi explicación completa a continuación para obtener detalles sobre lo que quiero decir.¿Cómo se puede saber si una URL de activo realmente apunta a un activo existente?

Tengo una aplicación que estoy desarrollando que permite a los usuarios agrupar imágenes en "paquetes" para su posterior procesamiento. Las imágenes pueden provenir del uso compartido de iTunes, la cámara del dispositivo (si hay una conectada) o la biblioteca de fotos del dispositivo. Además, el usuario puede editar las imágenes de algunas formas básicas. Los "paquetes" pueden durar mucho tiempo; se serializan y se deserializan a medida que la aplicación se detiene e inicia, por lo que el estado de la aplicación es persistente entre ejecuciones.

Mi diseño original tenía las imágenes guardadas en la zona de pruebas de la aplicación. Si se realiza alguna edición, la imagen simplemente se reescribe a su archivo local. Sin embargo, si un paquete contiene muchas imágenes, esto puede dar lugar a una duplicación innecesaria del contenido de la imagen, lo que da como resultado un uso del sistema de archivos "menos que óptimo".

Mi rediseño ahora lo tiene de modo que si una imagen proviene de la biblioteca de activos, simplemente almaceno la URL del activo y la recupero cada vez que necesito mostrar realmente la imagen o su contenido. Cuando el usuario edita una imagen, se escribe en un entorno limitado local, como en mi diseño original. Mi aplicación rastrea si la imagen proviene del sistema de archivos local o de la biblioteca de activos.

Mi problema surge cuando mi aplicación NO está activa. El usuario puede acceder perfectamente a la aplicación Fotos y eliminar imágenes a voluntad, incluidas las imágenes a las que mi aplicación ha almacenado punteros URL.

Hice un "¿y si?" prueba para ver qué pasaría en mi aplicación si el usuario hiciera algo como esto. Lo que vi sucedió fue un poco inesperado. Escribí un controlador que recorre la lista de paquete, la verificación de todas las imágenes que las URL de elementos usando el siguiente código:

[assetLibrary 
    assetForURL:url 
    resultBlock:^(ALAsset *asset) { 
     _image = [UIImage imageWithCGImage:[[asset defaultRepresentation] fullResolutionImage]]; 
     // ... everything works! 
    } 
    failureBlock:^(NSError *error) { 
     NSLog(@"Asset verify failed"); 
     if (_image != nil) { 
      // I already have a reference to the UIImage... write it locally 
     } else { 
      // Image is nil and we have an empty image. 
     } 
    }]; 

En mis pruebas, no alcanzo el bloque fracaso. La documentación de Apple dice "Si el usuario niega el acceso a la aplicación, o si ninguna aplicación tiene permiso para acceder a los datos, se llama al bloque de fallas." No dice lo que sucede cuando la URL no existe. De hecho, mi prueba muestra que algo está escribiendo un mensaje NSLog() que dice "No se pudo encontrar el elemento con UUID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" (las XXX se reemplazan por el UUID en la URL original). Aunque eso no es lo suficientemente malo. Todavía puedo ver la imagen en el UIImageView que tenía en el controlador de visualización en la pantalla, y cuando paso el controlador de vista al elemento principal, obtengo un restablecimiento del sistema.

Entonces, mi pregunta es, ¿hay alguna forma de saber si realmente existe una URL de activo? No me importa si tengo que eliminar la imagen (¡después de todo, el usuario eliminó la imagen!). No me gusta la idea de tener alguna ruta de comportamiento conocida que resulte consistentemente en un reinicio del dispositivo; No puedo enviar una aplicación con este comportamiento a la App Store.

¿Alguna sugerencia? Mientras espero respuestas, todavía voy a hacer mi propia prueba de algunas ideas, pero puedo usar cualquier sugerencia que la gente pueda darme sobre esto.

Gracias!

+0

para iOS5 apple proporciona Consulta de métodos NSURL en la clase NSURL.# checkResourceIsReachableAndReturnError: # - isFileReferenceURL # - isFileURL. No lo he usado, pero puede ser que esto pueda ayudar. – Ravin

+0

Una prueba simple demostró que: '[url checkResourceIsReachableAndReturnError: & error]' siempre devuelve NO para los activos, ya existan o no. ¿Alguna otra idea? – lar3ry

+0

Las otras dos consultas siempre devuelven NO a las URL de los activos, por cierto. – lar3ry

Respuesta

5

Tuve un problema similar - en el resultado bloqueé el parámetro de activo para nil - si es nulo, entonces no se encontró el activo.

Cuestiones relacionadas