Dear wiki user,

You have subscribed to a wiki page "Cordova Wiki" for change notification.

The page "NavigationUseCases" has been deleted by purplecabbage:

https://wiki.apache.org/cordova/NavigationUseCases?action=diff&rev1=3&rev2=4

- 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.
-  * 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)
- 
- == 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)
-    1. ChildBrowser receives an access token (randomly generated, only valid 
for this app session) from the PGURLProtocol
-    1. ChildBrowser uses this access token in a custom header in the 
NSURLRequest in webView:shouldStartLoadWithRequest:navigationType:
-    1. 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|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.
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to