My previous post explained how to get custom launch params so you can respond to different calling conditions, including a call from another app, or Mobile Safari. There is also a very good chance that your app may already be running, so what then?

Handle Open URL

With multitasking, this actually becomes quite likely, because users no longer kill your app, they simply move away from it. Your app is essentially suspended, so you should probably handle the non-launch option as well.

The ApplicationDelegate class defines a method just for this use, all you have to do is override it and hook it into your webView.

Copy the following to your AppDelegate.m and add the function to your js code:

Also, note that you can name your javascript function whatever you want, as long it is the same name that your AppDelegate passes into the webView. I chose to simply keep things clear and called the function "handleOpenURL(urlStr)", but it could just as easily be "appController.handleUrl(urlStr)". As in the previous post, this url is UrlEncoded, so you may need to decode it, depending on your needs.

One cool thing about the handleOpenURL function is that it is easily testable. You can put a link right inside your html to make the call using your protocol and it will be processed by the OS and passed right back to your app. This may not seem useful, but I can foresee situations where it might make sense, like passing info from a ChildBrowser control back to your main app, or completely decoupling your view from your app-controller. … Any other ideas?

I welcome your comments, questions, and suggestions. buy my single =>

I recently reworked some of the launchOption / handleOpenURL code in PhoneGap iPhone.
The commit is here.

You can expect these changes to be included in the next official release 0.9.5 later this month, however these are not considered PhoneGap functions, so I thought I would explain how this all works and save anyone having to wait for the next release.

The custom url schemes are an iOS thing, so it did not make sense to me to include them in the core of PhoneGap, but they are definitely useful, so they needed to be included somewhere.

When you create a new PhoneGap project in XCode, the template spits out a new XCode project containing a subclass of PhoneGapAppDelegate where you can choose to implement whatever you want without worrying about breaking the base classes. I chose to modify the template to make it easier for users to use custom urls. You can also add this functionality to an existing project quite simply.

For a very good description of how to set up the custom url, check out this post.

Once you have set up the plist and added your custom url, you can turn your attention to your app delegate files. First we will look at launchOptions.

Launch Options

In your MYPROJECT_AppDelegate.h add a variable to store the invoked url like this.

Now turning your attention to the implementation file, MYPROJECT_AppDelegate.m, you will need to respond to the didFinishLaunchingWithOptions: message. If you were previously handling applicationDidFinishLaunching: you can safely remove this call, and handle things in the withOptions variant. This is the way the baseClass ( PhoneGapDelegate.m/.h ) functions now, but the template was not updated to reflect the change.

Your didFinishLaunchingWithOptions should look like this:

The above stores the launchOptions url as a string for later use.
Next we will pass it into the UIWebView where our JS app loads, we have to wait for the page to load to do this, but we add it before we call super, so the value will be available when the deviceready event fires in our page.

Now moving to the html/js

Awesome, we have received the launchOptions in our Javascript code, and we can continue on and do something relevant with them.

To test this, open Mobile Safari on your device or simulator ( after having installed your app, and making sure it is not running in the background. )

In Mobile Safari’s address bar enter your customUrl scheme and verify that it launches your app and you see an alert with the freaking launchOptions.

Next up : handleOpenURL