I don't really understand using cordova.js outside of Cordova. There's one
for every platform, so which one gets included in the web version?
It's a neat idea to have a web-platform that just has things like
cordova/util in it, or that has everything except an exec() implementation
in it... Maybe for unit testing purposes, or to aid projects like Ripple.
I also like the idea of making it easy for apps to append a suffix to the
User-Agent. Good for analytics.
On Mon, Dec 3, 2012 at 8:32 PM, Andrew Lunny <alu...@gmail.com> wrote:
> The problem, afaict, is distinguishing between:
>
> 1) deviceready hasn't fired yet
> 2) deviceready isn't ever going to fire
>
> which right now boils down to "guess how long deviceready will take, and
> setTimeout() until some time after that."
>
> I tend to agree with Max - it'd be a worthwhile thing to have, unless the
> implementation is prohibitively difficult.
>
> On 3 December 2012 17:17, Anis KADRI <anis.ka...@gmail.com> wrote:
>
> > Well because it never fires you know that you are in a browser's context.
> > It will only fire if you're on a device or if you fire it yourself.
> >
> > There could be two reasons (as far as I know) that 'deviceready' would
> not
> > fire.
> > 1) not in a cordova app context (browser via file:// or http://).
> > 2) there is a problem with cordova itself (problem fetching
> device/network
> > info).
> >
> > actions for both
> > 1) You know whether or not you are in a cordova context: do whatever you
> > have to do: use childbrowser or a popup, don't use device apis that are
> > not available etc...
> > 2) find out if you're not missing anything and/or file a bug
> >
> > I believe that 'deviceready' is more reliable then document.location
> > because it really is cordova specific.
> >
> >
> >
> >
> > On Mon, Dec 3, 2012 at 5:06 PM, Filip Maj <f...@adobe.com> wrote:
> >
> > > But look at that situation from the browser's POV: it attaches to an
> > event
> > > that never fires.
> > >
> > > cordova.js is included and window.cordova exists, but in a browser's
> > > context, it does nothing.
> > >
> > > On 12/3/12 5:03 PM, "Anis KADRI" <anis.ka...@gmail.com> wrote:
> > >
> > > >document.addEventListener('deviceready', function()
> > {navigator.inCordova =
> > > >true;}, false);
> > > >
> > > >If you fire 'deviceready' yourself then you already know that you're
> not
> > > >in
> > > >a cordova app context. Don't you ?
> > > >
> > > >Sorry, I really don't see what the problem is. Maybe an real world
> > example
> > > >would help illustrate it. Or is there a reason why you don't want to
> use
> > > >deviceready as an indicator ?
> > > >
> > > >
> > > >On Mon, Dec 3, 2012 at 4:40 PM, Max Ogden <m...@maxogden.com> wrote:
> > > >
> > > >> if cordova polyfilled standard apis for everything it wouldn't be
> > > >>cordovas
> > > >> problem. but right now there are only-in-cordova APIs that I need to
> > > >>use if
> > > >> i'm in cordova. it would be more convenient for me as an app
> developer
> > > >>if
> > > >> there was a supported way to know i'm in cordova.
> > > >>
> > > >> I can keep looking at window.location.href and make sure to always
> > run a
> > > >> local web server for development (and never open the file directly
> on
> > my
> > > >> dev machine) but the point here is that doing those things is more
> > > >>pitfall
> > > >> prone and less user friendly for new devs than doing "if
> > > >> (navigator.inCordova)".
> > > >>
> > > >> if its a ton of work to implement then I can understand not doing it
> > (I
> > > >> dont know what it would take to implement). i'm just trying to say
> it
> > > >>would
> > > >> be a nicer api :) it seems from my perspective that it would be easy
> > for
> > > >> cordova to tell the browser that cordova is present and it would
> save
> > > >>app
> > > >> developers from having to use yet another hacky technique.
> > > >>
> > >
> > >
> >
>
