Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gibson.becky@gmail.com
 designates 209.85.160.175 as permitted sender)
From: Becky Gibson <gibson.becky@gmail.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_E1CC6C61-723D-4F58-BC5A-6FFA3028B79C"
Subject: App plugin and iOS
Date: Mon, 14 Nov 2011 10:45:07 -0500
Message-Id: <8EC614B9-1D38-4F39-9244-20C9CB859DD4@gmail.com>
To: callback-dev@incubator.apache.org
Mime-Version: 1.0 (Apple Message framework v1251.1)

--Apple-Mail=_E1CC6C61-723D-4F58-BC5A-6FFA3028B79C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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                           =3D> wait msec before =
loading URL
 *      loadingDialog: "Title,Message"      =3D> display a native =
loading dialog
 *      loadUrlTimeoutValue: int            =3D> time in msec to wait =
before triggering a timeout error
 *      clearHistory: boolean              =3D> clear webview history =
(default=3Dfalse)
 *      openExternal: boolean              =3D> open in a new browser =
(default=3Dfalse)
 *
 * 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. =20

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=3Doverride, F=3Dcancel 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. =20

addWhiteListEntry()
/**
 * Add entry to approved list of URLs (whitelist) that will be loaded =
into PhoneGap container instead of default browser.
 *=20
 * @param origin		URL regular expression to allow
 * @param subdomains	T=3Dinclude 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. =20


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=

--Apple-Mail=_E1CC6C61-723D-4F58-BC5A-6FFA3028B79C--