使用URL（通过UIApplicationDelegate的handleOpenURL）在iOS 4下工作，但不在iOS 3.2下工作 [英] Lauching App with URL (via UIApplicationDelegate's handleOpenURL) working under iOS 4, but not under iOS 3.2

问题描述

我已经实现了UIApplicationDelegate的

 应用程序：didFinishLaunchingWithOptions：
  

和

 申请：handleOpenURL：
  

根据规格，即

 申请：didFinishLaunchingWithOptions：
返回YES 
  

和

  application：handleOpenURL：打开URL。 
  

该代码适用于iOS 4（在这两种情况下，即应用程序启动时和从暂停状态变为活跃状态）。但是，代码在iOS 3.2下无效。

解决方案

我回答了我自己的问题。找出解决方案花了我一段时间，非常令人沮丧。如果你进行互联网搜索，你会发现一些部分答案，但我仍然需要一段时间来制定以下解决方案，我希望它能增加一些清晰度。

所以首先，您的应用的推荐行为如下所示（请参阅打开支持的文件类型：

• 不要实现 applicationDidFinishLaunching：（参见 UIApplicationDelegate ）。


• 实施 application：didFinishLaunchingWithOptions：并检查URL，返回YE S如果可以打开它，否则为NO，但不要打开它。


• 实现应用程序：handleOpenURL：并打开URL，如果成功则返回YES，否则返回NO。

在iOS 4中，将URL传递给应用程序会导致以下两种行为之一：

• 如果应用程序已启动，则应用程序：didFinishLaunchingWithOptions：被调用并且 application：handleOpenURL：调用if和 application：didFinishLaunchingWithOptions：返回YES。


• 如果应用程序从挂起状态变为活动状态，则应用程序：didFinishLaunchingWithOptions：未被调用，但应用程序：handleOpenURL：被调用。

然而，在iOS 3.2中，它看起来好像是应用程序：handleOpenURL：永远不会被称为！可以在处理URL请求。在那里你发现应用程序：handleOpenURL：如果应用程序：didFinishLaunchingWithOptions：未实现，则会被调用，但 applicationDidFinishLaunching：已实施。但是应用程序：handleOpenURL：如果应用程序：didFinishLaunchingWithOptions：已实现，则不会被调用。

因此，使代码在3.2和4.0下运行的一个解决方案是：

• 在<$中打开URL c $ c> application：didFinishLaunchingWithOptions：，但是然后返回NO以防止调用应用程序：handleOpenURL：。


• 打开应用程序中的URL：handleOpenURL：，以防您处于4.0以下并且应用程序处于挂起状态。

我在另一篇文章中找到了这个解决方案，但我很困惑，因为它与iOS Ref Lib文档中的建议相矛盾（即我们应该在中返回YES应用中：didFinishLaunchingWithOptions：）。 （那时我没有意识到文档与它自相矛盾。）

我相信当前的iOS 4.0行为将是未来的行为我更喜欢以下解决方案：

• 不要实现 applicationDidFinishLaunching：。


• 实现应用程序：didFinishLaunchingWithOptions：并检查URL，如果可以打开则返回YES，否则为NO，但不要打开它。如果我们在3.2上，请打开URL。


• 实施应用程序：handleOpenURL：并打开URL，如果成功则返回YES，否则NO。

总而言之，我实现了iOS 4的行为并将以下行添加到应用程序：didFinishLaunchingWithOptions ：




 
 if（[[[UIDevice currentDevice ] systemVersion] hasPrefix：@3.2]）{
 [self application：application handleOpenURL：url]; 
} 
 




使代码在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.

解决方案

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.

这篇关于使用URL（通过UIApplicationDelegate的handleOpenURL）在iOS 4下工作，但不在iOS 3.2下工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！