I did a quick look at Android and we could duck punch window.close() so that it does a navigator.app.exitApp(). That could be a good solution if we can determine what if any affect it will have on jQuery apps. As much as we all love to hate on jQuery a lot of our users are leveraging their jQuery experience to build mobile apps with Cordova and we don't want to totally screw them over. Also, in a multi page app if window.close is executed does this mean the entire app should close?
The other Android specific methods: *loadUrl/cancelLoadUrl* - we can probably get rid of them now as we load everything in a single web view. I believe they were more useful when we had multiple instance of DroidGap in the same app. Bryce, can you comment on this? *overrideBackButton* - Imma gonna take this out right now. This is a legacy piece of code. The proper way of doing this is to register an event listener for the "backbuttton" event. Simon Mac Donald http://hi.im/simonmacdonald On Tue, Jan 31, 2012 at 2:29 PM, Filip Maj <f...@adobe.com> wrote: > Bryce suggested leaving window.close alone due to how some frameworks > (*COUGH* jQuery) hoist into the history and whatnot. Not sure this is a > real issue - Bryce can you provide an example where piggybacking off of > window.close would mess stuff up? Plus, I don't want random web frameworks > dictating how we build our APIs. That's not how this works... > > Also I like the idea of reviewing what we have in app right now. Currently > we have, for stuff that is common across BB and Android: > > - exitApp > - clearCache > - clearHistory > - backHistory > - event stuff (pause/resume/hardware buttons). Don't think this is > applicable though... > > Android only: > > - loadUrl > - cancelLoadUrl > - overrideBackButton > > I think if we can stay away from the history api extensions we're all > gonna be better off. Worst case if history is not implemented properly on > some platforms, again, I would consider monkeypatching the `history` > methods with some native stubs to fill in an API that web devs expect to > "just work." > > LoadURL/CancelLoadURL - again, my opinion about these is the same as > history. Using "web" approaches such as setting `window.location` and > using `window.open` (if you wanted to open in the stock browser or a new > phonegap window instance, for example) are better, more intuitive > approaches. > > exitApp -> window.close > > clearCache is interesting. The BB WebWorks container *can* do some > caching, so WebWorks actually provides an API to clear the cache. > Presumably Android has some native equivalent for this. This is probably > the one method in `navigator.app` that is somewhat useful and has no web > equivalent. > > My $0.02. > > On 12-01-30 7:02 PM, "Brian LeRoux" <b...@brian.io> wrote: > > >I like window.close Fil --- exactly how we should look at PhoneGap > >APIs. If its not a spec, or something we can polyfil, then it should > >be a plugin. > > > >Think this is something we need to document in the wiki? > > > >On Mon, Jan 30, 2012 at 5:28 PM, Filip Maj <f...@adobe.com> wrote: > >> Apparently discussion triggered by a JIRA issue filed, and now further > >>discussion is happening in that thread: > >> > >> https://issues.apache.org/jira/browse/CB-206 > >> > >> Chime in if you like :) > >
