You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Becky Gibson <gi...@gmail.com> on 2011/11/14 16:45:07 UTC
App plugin and iOS
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
Re: App plugin and iOS
Posted by Simon MacDonald <si...@gmail.com>.
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 <sh...@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 <da...@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 <gi...@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
>>
>
Re: App plugin and iOS
Posted by Shazron <sh...@gmail.com>.
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 <da...@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 <gi...@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
>
Re: App plugin and iOS
Posted by Dave Johnson <da...@gmail.com>.
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 <gi...@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