incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: App plugin and iOS
Date Fri, 25 Nov 2011 22:07:43 GMT
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, and list it in
specified metadata section

On Fri, Nov 25, 2011 at 12:49 PM, Dave Johnson <> 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 <> 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
>>  *      loadUrlTimeoutValue: int            => time in msec to wait
before triggering a timeout error
>>  *      clearHistory: boolean              => clear webview history
>>  *      openExternal: boolean              => open in a new browser
>>  *
>>  * Example:
>>  *"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

View raw message