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.,
appl开发者_JAVA百科ication: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 andapplication:handleOpenURL:
is called if andapplication:didFinishLaunchingWithOptions:
returned YES. - If the app is becoming active from suspended state then
application:didFinishLaunchingWithOptions:
is not called butapplication: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 thatapplication: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.
application:handleOpenURL:
is now DEPRECATED.
As of iOS 4.2, you can use this for opening URLs:
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
Documentation:
https://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIApplicationDelegate_Protocol/Reference/Reference.html
I started writing application which used Dropbox api. To understand concept, I ran a sample application using my Key/secret mentioned at dropbox/developer documentation. Once sample app started working, I used same key/secret values for my application.
For sample app, implementation of handleOpenURL (or openURL on iOS 4.2) gets executed as expected. For some odd reason, it wasn't the case for my app. My app entered background in order to show login screen and authentication page of dropbox. After successful login and authentication, my app never entered foreground. It was true for both platform Simulator and device (iPad)
I tried almost everything listed on internet including this post. Thanks. There was NO success, though.
At last, it STARTED working for my application when I did following:
- On simulator, select "iOS Simulator --> Reset Content and Settings", and reset.
- On device, I deleted sample application related executable and which in turn delete cache associated to it.
Add the following to the end of application:DidFinishLaunchingWithOptions
:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
...
NSURL *url = (NSURL *)[launchOptions valueForKey:UIApplicationLaunchOptionsURLKey];
if (url != nil && [url isFileURL]) {
return YES;
} else return NO;
} // End of application:didFinishLaunchingWithOptions:
// New method starts
-(BOOL) application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
{
mvc = [nc.viewControllers objectAtIndex:0];
if (url != nil && [url isFileURL]) {
[mvc handleOpenURL:url];
}
return YES;
}
where mvc is my main ViewController, and nc my navigation controller.
Then in the MainViewController, do something like this:
- (void)handleOpenURL:(NSURL *)url {
[self.navigationController popToRootViewControllerAnimated:YES];
// Next bit not relevant just left in as part of the example
NSData *jsonData = [NSData dataWithContentsOfURL:url];
NSError *error;
NSDictionary *dictionary = [[NSJSONSerialization JSONObjectWithData:jsonData options:kNilOptions error:&error] objectAtIndex:0];
[self managedObjectFromStructure:dictionary withManagedObjectContext:self.context];
...
}
after declaring handleOpenURL in the .h of course.
Thanks goes to Christian for putting in the effort for this.
精彩评论