You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Filip Maj <fi...@adobe.com> on 2012/01/31 02:28:24 UTC
Is navigator.app an API we want to support?
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 :)
Re: Is navigator.app an API we want to support?
Posted by Bryce Curtis <cu...@gmail.com>.
I don't suspect that window.close will cause a problem - but we have to
know how various js frameworks will react and do testing when hijacking.
Also, we need to take a look at expected behavior either by spec or common
use. We overrode history in 0.9.6 or 1.0 timeframe. Regular PhoneGap apps
worked fine, but turns out that it broke jQuery (Since we don't use jQuery,
we found out via the forums). So the intent is to determine if there are
any gotcha's for a particular solution.
There was discussion around integrating childbrowser in base, and loadUrl
morphed into that for Android. Most of the code already existed in
DroidGap, so this was a simple extension to wrap the functionality. This
is used to load urls in the PhoneGap webview plus launch in separate
browser, depending upon whitelist url, protocol, etc.
Users can register for backbutton events, however, the register event
method is hooked (phonegap.js.base) and actually calls App
overrideBackButton method. If there's a web way to do this, then that's
great, but I'm not aware of anything on Android.
The Device.* methods that Drew mentioned are all deprecated and should be
removed.
On Tue, Jan 31, 2012 at 3:07 PM, Drew Walters <de...@gmail.com> wrote:
> Should the following be wacked too?
>
> Device.overrideBackButton
> Device.exitApp
> Device.resetBackButton
>
> On Tue, Jan 31, 2012 at 2:11 PM, Simon MacDonald
> <si...@gmail.com>wrote:
>
> > On Tue, Jan 31, 2012 at 3:04 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> > >
> > > >*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.
> > >
> > > Yeh in Cordova-js this is done in a "standard" way - no need for native
> > > magiks.
> > >
> > >
> > It's gone. Change already pushed to the Apache GIT repo.
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
>
Re: Is navigator.app an API we want to support?
Posted by Drew Walters <de...@gmail.com>.
Should the following be wacked too?
Device.overrideBackButton
Device.exitApp
Device.resetBackButton
On Tue, Jan 31, 2012 at 2:11 PM, Simon MacDonald
<si...@gmail.com>wrote:
> On Tue, Jan 31, 2012 at 3:04 PM, Filip Maj <fi...@adobe.com> wrote:
>
> >
> > >*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.
> >
> > Yeh in Cordova-js this is done in a "standard" way - no need for native
> > magiks.
> >
> >
> It's gone. Change already pushed to the Apache GIT repo.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
Re: Is navigator.app an API we want to support?
Posted by Simon MacDonald <si...@gmail.com>.
On Tue, Jan 31, 2012 at 3:04 PM, Filip Maj <fi...@adobe.com> wrote:
>
> >*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.
>
> Yeh in Cordova-js this is done in a "standard" way - no need for native
> magiks.
>
>
It's gone. Change already pushed to the Apache GIT repo.
Simon Mac Donald
http://hi.im/simonmacdonald
Re: Is navigator.app an API we want to support?
Posted by Filip Maj <fi...@adobe.com>.
>As much as we all love to hate on jQuery
I sure do :D
>Also, in a multi page app if window.close is executed does
>this mean the entire app should close?
Yes.
>*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.
Yeh in Cordova-js this is done in a "standard" way - no need for native
magiks.
Re: Is navigator.app an API we want to support?
Posted by Simon MacDonald <si...@gmail.com>.
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 <fi...@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 <fi...@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 :)
>
>
Re: Is navigator.app an API we want to support?
Posted by Filip Maj <fi...@adobe.com>.
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 <fi...@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 :)
Re: Is navigator.app an API we want to support?
Posted by Brian LeRoux <b...@brian.io>.
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 <fi...@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 :)