I just did a pull request to remove addWhiteList from Android. If we are all in a agreement that it should be removed on our Monday call I will merge the request.
https://github.com/callback/callback-android/pull/41 Also, for anything that isn't implemented on iOS do you thing we should have a no op function in the JavaScript so we won't run into errors when people port the code from platform to platform? Simon Mac Donald http://hi.im/simonmacdonald On Fri, Nov 25, 2011 at 5:07 PM, Shazron <shaz...@gmail.com> wrote: > I agree that plugins should not be able to add to the whitelist > automatically - but in their metadata perhaps there could be > "required" whitelist additions for the plugin to work properly - so it > will save the dev time later wondering why it's not working. eg a > facebook plugin might need http://facebook.com, and list it in > specified metadata section > > On Fri, Nov 25, 2011 at 12:49 PM, Dave Johnson <dave.c.john...@gmail.com> > wrote: >> 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 >> >
