incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Re: App plugin and iOS
Date Fri, 25 Nov 2011 23:45:41 GMT
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 <shazron@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.johnson@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.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