I agree that we should not implement this all on iOS.
addWhiteListEntry should be removed from Android. It seems like we
should not give the runtime code the ability to change the whitelist
defined at build time!
On Mon, Nov 14, 2011 at 7:45 AM, Becky Gibson <gibson.be...@gmail.com> wrote:
> I took a look at the app plugin for Android to see if it makes sense to
> implement this for iOS as well. Below is a review of the apis and the iOS
> ability to implement:
>
> clearCache() - This seems do-able with iOS NSURLCache object.
>
> loadURL()
> /**
> * Load the url into the webview or into new browser instance.
> *
> * @param url The URL to load
> * @param props Properties that can be passed in to the activity:
> * wait: int => wait msec before loading URL
> * loadingDialog: "Title,Message" => display a native loading dialog
> * loadUrlTimeoutValue: int => time in msec to wait before
> triggering a timeout error
> * clearHistory: boolean => clear webview history
> (default=false)
> * openExternal: boolean => open in a new browser
> (default=false)
> *
> * Example:
> * navigator.app.loadUrl("http://server/myapp/index.html";, {wait:2000,
> loadingDialog:"Wait,Loading App", loadUrlTimeoutValue: 60000});
> */
> We can implement all of these parameters in iOS. Although, I'm not sure what
> is meant by a "native loading dialog" as iOS generally just uses a spinner
> with this. We could create and display a standard dialog until the load
> request is complete. This is an example of where only supporting iOS 4 or
> greater would make this easier since we could use a block to potentially
> simplify the code. Open in a new browser would launch is a standard Safari
> window - there would be no mechanism for returning to the app since iOS
> devices have no back button like Android. I think we would have to maintain
> the history ourselves in order to implement clearHistory as I can't find any
> "easy" api to do this.
>
> cancelLoadURL() - this is do-able in iOS.
>
> clearHistory()
> /**
> * Clear web history in this web view.
> * Instead of BACK button loading the previous web page, it will exit the app.
> */
> Given the description I'm not sure this makes sense for iOS since there is no
> back button and no way to programmatically exit an app - the app should be
> put into the background. We would have to maintain our own history list in
> order to clear it.
>
> backHistory() - this can be implemented using UIWebView goBack api.
>
> overrideBackbutton()
> **
> * Override the default behavior of the Android back button.
> * If overridden, when the back button is pressed, the "backKeyDown"
> JavaScript event will be fired.
> *
> * Note: The user should not have to call this method. Instead, when the user
> * registers for the "backbutton" event, this is automatically done.
> *
> * @param override T=override, F=cancel override
> */
> This doesn't make sense for iOS since there is no back button.
>
> exitApp()
> /**
> * Exit and terminate the application.
> */
>
> This is not allowed on iOS. There is an option to not put apps into the
> background but I think Apple would frown on an exitApp() api.
>
> addWhiteListEntry()
> /**
> * Add entry to approved list of URLs (whitelist) that will be loaded into
> PhoneGap container instead of default browser.
> *
> * @param origin URL regular expression to allow
> * @param subdomains T=include all subdomains under origin
> */
>
> This is do-able but I question the security of adding an api to allow
> bypassing the hardcoded whitelist entry. I do believe that the current iOS
> command polling mechanism to invoke gap commands is fairly secure but I need
> people with better security skills than mine to confirm.
>
>
> Thus, other than offering a loadURL() command with more options, I'm not sure
> I see the benefit of implenting this plugin for iOS. Do people have examples
> of use cases where the achievable apis are needed?
>
> thanks,
> -becky
