Differences between revisions 2 and 3
Revision 2 as of 2012-02-14 15:57:51
Size: 3736
Comment:
Revision 3 as of 2012-12-10 21:33:58
Size: 3726
Editor: MarcelKinard
Comment: removed 'incubating' from repo names
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * For iOS, currently use of our custom NSURLProtocol is all or nothing - it's a whitelist for all connections. We'll have to figure out an exemption mechanism (it's possible with https://github.com/apache/incubator-cordova-ios/blob/master/PhoneGapLib/Classes/PGViewController.m#L379 and a config.xml setting I suppose)  * For iOS, currently use of our custom NSURLProtocol is all or nothing - it's a whitelist for all connections. We'll have to figure out an exemption mechanism (it's possible with https://github.com/apache/cordova-ios/blob/master/PhoneGapLib/Classes/PGViewController.m#L379 and a config.xml setting I suppose)

Place to list and discuss the navigation use cases that are/should be supported in PhoneGap

iframe within a cordova page

user just wants to display some other content within the page and sandbox it in an iframe. They do not want to have to worry about any PG commands getting invoked by the pages loaded in the iframe and do not want to have to specify a whitelist for the iframe. There have been requests where people DO want to run PG commands from the iframe - need to determine why.

childbrowser plugin

For example, an app that tracks my blood donations. The user wants to go out to the Red Cross web site to find the next donations in her area. In this case I don't want to use the whitelist and I do not want any PG commands invoked from within the Childbrowser (other than to deal with the events from the Childbrowser). There may be cases where the user does want PG commands within a ChildBrowser - with the new Web View /Cleaver implementations this could be an option.

  • iOS

    • For iOS, we will have to have an exemption mechanism for the "all or nothing" custom NSURLProtocol. I'm thinking something like this:
      1. ChildBrowser registers its app id with our custom NSURLProtocol (PGURLProtocol)

      2. ChildBrowser receives an access token (randomly generated, only valid for this app session) from the PGURLProtocol

      3. ChildBrowser uses this access token in a custom header in the NSURLRequest in webView:shouldStartLoadWithRequest:navigationType:

      4. PGURLProtocol will try to read this access token and app id in the header, and if it is found and it matches, skips the whitelist check

ajax requests and general resource loading (for example <img>)

Not really navigation but should respect the whitelist

  • iOS

    • Believe the UIWebViewNavigationType would give a clue in webView:shouldStartLoadWithRequest:navigationType: but this value is ambiguous / not reliable

page load is programmatic or occurs from a user interaction

For example, an ad can load in an iframe (programmatically), and the user can touch the ad (user interaction). The desired behavior may be different in those cases.

  • For iOS, the navigationType parameter to shouldStartLoadWithRequest exposes this - an example of implementing this use is case here https://gist.github.com/1503552

JavaScript invocations to open a new page

Should these open in the webview or open in the mobile browser (in the case of iOS this will leave the app with no way to return via a back button unless the Childbrowser is used).

  • One would suspect that you would want a remote URL to open in the mobile browser UNLESS you are loading PhoneGap.js from that location as well and thus want it in the webView (in which case the whitelist is enforced)

    • Remote url would be mobile browser. How would you know that a remote url has PhoneGap.js? I'm assuming this can be solved with answer below (API function)

  • window.location = url
  • <a href=url>new local or remote location</a>

  • Need a way to force opening in the browser (not the webview) and ignoring the whitelist check.
    • Use case? In any case I can't think of a 'standards' way for this - we would have to provide some API function - if not available, just use document.location
  • Need to support jQuery type navigation using # in the urls.

NavigationUseCases (last edited 2012-12-10 21:33:58 by MarcelKinard)