incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <dave.c.john...@gmail.com>
Subject Re: App plugin and iOS
Date Fri, 25 Nov 2011 20:49:50 GMT
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.becky@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

Mime
View raw message