Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
267 views
in Technique[技术] by (71.8m points)

iphone - Lauching App with URL (via UIApplicationDelegate's handleOpenURL) working under iOS 4, but not under iOS 3.2

I have implemented UIApplicationDelegate's

application:didFinishLaunchingWithOptions:

and

application:handleOpenURL:

according to specification, i.e.,

application:didFinishLaunchingWithOptions:
returns YES 

and

application:handleOpenURL: opens the URL. 

The code works under iOS 4 (in both cases, i.e., when the app is launched and when it becomes active from suspended state). However, the code does not work under iOS 3.2.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

I give an answer to my own question. Finding out the solution took me a while and was quite frustrating. If you do an internet search you find some partial answers, but it still took me a while to work out the following solution and I do hope it adds some clarity.

So first, the recommended behavior of your app appears to be the following (see Opening Supported File Types in iOS Ref Lib):

  • Do not implement applicationDidFinishLaunching: (see the note at UIApplicationDelegate).
  • Implement application:didFinishLaunchingWithOptions: and check the URL, return YES if you can open it, otherwise NO, but do not open it.
  • Implement application:handleOpenURL: and open the URL, return YES if successful, otherwise NO.

In iOS 4, passing an URL to an app results in one of the following two behaviors:

  • If the app is launched then application:didFinishLaunchingWithOptions: is called and application:handleOpenURL: is called if and application:didFinishLaunchingWithOptions: returned YES.
  • If the app is becoming active from suspended state then application:didFinishLaunchingWithOptions: is not called but application:handleOpenURL: is called.

However, in iOS 3.2 it appears as if application:handleOpenURL: is never called! A hint that the behavior is different under iOS 3.2 can be found in Handling URL Requests. There you find that application:handleOpenURL: is called if application:didFinishLaunchingWithOptions: is not implemented, but applicationDidFinishLaunching: is implemented. But application:handleOpenURL: is not called if application:didFinishLaunchingWithOptions: is implemented.

Hence, one solution to make the code work under 3.2 and 4.0 is:

  • Open the URL in application:didFinishLaunchingWithOptions:, but then return NO to prevent that application:handleOpenURL: is called.
  • Open the URL in application:handleOpenURL:, in case you are under 4.0 and the app was in suspended state.

I found this solution in another post, but I was confused, because it contradicted the recommendation in iOS Ref Lib documentation (namely that we should return YES in application:didFinishLaunchingWithOptions:). (At that point I did not realize that the documentation contradicts it self).

I believe that the current iOS 4.0 behavior will be the future behavior I prefer the following solution:

  • Do not implement applicationDidFinishLaunching:.
  • Implement application:didFinishLaunchingWithOptions: and check the URL, return YES if you can open it, otherwise NO, but do not open it. If we are on 3.2, open the URL.
  • Implement application:handleOpenURL: and open the URL, return YES if successful, otherwise NO.

So in summary, I implement the iOS 4 behavior and added the following line to application:didFinishLaunchingWithOptions:

if([[[UIDevice currentDevice] systemVersion] hasPrefix:@"3.2"]) { [self application:application handleOpenURL:url]; }

which make the code work under 3.2.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...