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
>
