Respondo a mi pregunta. Descubrir la solución me llevó un tiempo y fue bastante frustrante. Si haces una búsqueda en Internet, encuentras algunas respuestas parciales, pero todavía me tomó un tiempo encontrar la siguiente solución y espero que añada algo de claridad.
Así que, primero, el comportamiento recomendado de su aplicación parece ser el siguiente (ver Opening Supported File Types en IOS Ref Lib):
- no implementan
applicationDidFinishLaunching:
(véase la nota al UIApplicationDelegate).
- Implemente
application:didFinishLaunchingWithOptions:
y revise la URL, devuelva SÍ si puede abrirla, de lo contrario NO, pero no la abra.
- Implemente
application:handleOpenURL:
y abra la URL, devuelva SÍ si tiene éxito, de lo contrario NO.
En IOS 4, el paso de una dirección URL a un resultado de la aplicación de uno de los dos comportamientos siguientes:
- Si la aplicación se inicia a continuación
application:didFinishLaunchingWithOptions:
se llama y application:handleOpenURL:
se llama si y application:didFinishLaunchingWithOptions:
regresaron SÍ.
- Si la aplicación se está activando desde el estado suspendido, entonces no se llama a
application:didFinishLaunchingWithOptions:
pero se llama a application:handleOpenURL:
.
Sin embargo, en iOS 3.2 parece que nunca se llama a application:handleOpenURL:
! Una sugerencia de que el comportamiento es diferente en iOS 3.2 se puede encontrar en Handling URL Requests. Ahí encuentra que se llama application:handleOpenURL:
si application:didFinishLaunchingWithOptions:
no está implementado, pero se implementa applicationDidFinishLaunching:
. Pero application:handleOpenURL:
no se llama si se implementa application:didFinishLaunchingWithOptions:
.
Por lo tanto, una solución para hacer que el código bajo 3.2 y 4.0 es:
- abrir la URL
application:didFinishLaunchingWithOptions:
, pero luego no retorno para evitar que application:handleOpenURL:
se llama.
- Abra la URL en
application:handleOpenURL:
, en caso de que tenga menos de 4.0 y la aplicación estuviera en estado suspendido.
He encontrado esta solución en otro post, pero yo estaba confundido, ya que contradice la recomendación en la documentación IOS Ref Lib (es decir, que debemos volver SI en application:didFinishLaunchingWithOptions:
). (En ese momento no me di cuenta de que la documentación se contradice).
creo que el comportamiento actual de iOS 4.0 será el comportamiento futuro prefiero la siguiente solución:
- no implementan
applicationDidFinishLaunching:
.
- Implemente
application:didFinishLaunchingWithOptions:
y revise la URL, devuelva SÍ si puede abrirla, de lo contrario NO, pero no la abra. Si estamos en 3.2, abre la URL.
- Implemente
application:handleOpenURL:
y abra la URL, devuelva SÍ si tiene éxito, de lo contrario NO.
Así que en resumen, puedo implementar el comportamiento IOS 4, y añadió la siguiente línea a application:didFinishLaunchingWithOptions:
if([[[UIDevice currentDevice] systemVersion] hasPrefix:@"3.2"]) {
[self application:application handleOpenURL:url];
}
que hacen que el código funcione en el punto 3.2.
¿Cuál es el problema en 3.2? ¿Error de mensajes? ¿Las líneas de código se rompen? –
Parece que el delegado no recibe el mensaje handleOpenURL en absoluto si respondió el mensaje didFinishLaunchingWithOptions, incluso si ese método devolvió SÍ. La documentación de la API me sugirió un comportamiento diferente. –