That's pretty cool! And pretty simple too!
On Wed, Dec 5, 2012 at 7:03 AM, Simon MacDonald
simon.macdon...@gmail.comwrote:
On the subject of capability detection a user just created a plugin for
Android to check if features are available. Pretty useful for devices
without cameras.
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
This situation all still smells of userland issue not something
Cordova should be doing.
I do think we need device capability detection, but analytics use case
not strong enough to justify adding to the fragmented world that is
user agents strings (and the even more brittle world of code that
The primary alternative is maybe to use a build system that adds in the
platform-specific files when packaging apps, while keeping your source
tree
runnable in a browser...
This is the way to go. Take advantage of the compile step to customize
packages/binaries for specific platforms.
In Gather we have a login page that uses childbrowser popup windows for
oauth if its running in phonegap or popup windows in javascript if in
browser. It would be nice childbrowser polyfilled target=_blank (which I
understand is happening in the future) but as for now the heuristics for
detecting
On Mon, Dec 3, 2012 at 11:40 AM, Max Ogden m...@maxogden.com wrote:
- I already do conditional loading of stylesheets and JS based on user
agent. I think it would be super useful if there was a user agent
equivalent for cordova so the code could decide what to do based on
environment and not
Yup, window.open(url, _blank) will load the InAppBrowser which is
basically a renamed ChildBrowser that actually follows a spec for
events.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Dec 3, 2012 at 2:40 PM, Max Ogden m...@maxogden.com wrote:
In Gather we have a login page that uses
Back to our original thread. I'm seeing a couple of scenarios.
1. wants to do analytics reporting (needs user agent)
2. wants to do be capability responsive (needs to see if there are
device apis, usually a specific capability/api combo such as camera)
Thoughts?
On Mon, Dec 3, 2012 at 9:10 PM,
Setting Cordova in the UA is not really hard to achieve (at least on
Android). Not sure if we would want to make this default though.
On Fri, Nov 30, 2012 at 3:27 PM, Filip Maj f...@adobe.com wrote:
My
cordova apps simply point to the website URL to get its contents.
I don't know if this is
1) Set a specific UA string like the wikimedia guys do (even tough they do
it for other reasons).
2) I remember us talking about a capabilities api. Not sure what transpired
from that discussion.
On Mon, Dec 3, 2012 at 1:29 PM, Brian LeRoux b...@brian.io wrote:
Back to our original thread. I'm
I dont think modifying the UA is a good idea but I strongly believe that
cordova needs to set *something* that is immediately available from browser
JS on app load that says hi you're running in cordova
On Mon, Dec 3, 2012 at 1:31 PM, Anis KADRI anis.ka...@gmail.com wrote:
1) Set a specific UA
Is what people in the browser wanting the deviceready event to fire?
Sent from my iPhone
On 2012-12-03, at 5:54 PM, Max Ogden m...@maxogden.com wrote:
I dont think modifying the UA is a good idea but I strongly believe that
cordova needs to set *something* that is immediately available from
So, would that not be deviceready? (I get that those apps that run in
browser probably fake this event but, if thats the case, then the
faking would be a userland place to put that sort of thing.)
On Mon, Dec 3, 2012 at 10:54 PM, Max Ogden m...@maxogden.com wrote:
I dont think modifying the UA
I am having a hard time making this seem like a Cordova problem.
There are many different and easy ways to fix this for the developer but I
can't see a good way for us to handle it.
Do we create a Cordova.web.js that a developer can include on their server?
It would enable as much as it can
But the deviceready event is unique to Cordova distributions so, my
point is, you have that code in user land already so it makes sense to
keep it there. (To me.)
Is this just something you'd prefer we handled though? Something that
makes inBrowser() tidier?
On Mon, Dec 3, 2012 at 11:30 PM, Max
On Mon, Dec 3, 2012 at 3:53 PM, Brian LeRoux b...@brian.io wrote:
I'm of the opinion this isn't a Cordova problembut I do think
device capabilities introspection is. (Which is related.)
+1
There are so many ways to find out.
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
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
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',
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
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,
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
Eh Fil, is this so they can detect if they have device apis ultimately?
On Sat, Dec 1, 2012 at 1:31 AM, Bryce Curtis curtis.br...@gmail.com wrote:
I think the answer depends upon when the app checks to see if it is
running in cordova webview. If it is loading a remote url with remote
I'm seeing this question pop up on our IRC, as well as in person after
meet ups, as well as on stack overflow here and there.
Scenario: I have a website, and I have a native app that uses cordova. My
cordova apps simply point to the website URL to get its contents.
The question becomes: since
I think in BB WEbWorks you get http://localhost/somethingsoemthing
On 11/30/12 3:35 PM, Shazron shaz...@gmail.com wrote:
how do we know if we're in cordova or not? -- document.location starts
with file:// ?
My gut told me _nativeReady but I don't think that is cross platform.
I think we should work harder at making Cordova.js be a noop when in a standard
browser which shouldn't be to hard.
Sent from my iPhone
On 2012-11-30, at 6:38 PM, Filip Maj f...@adobe.com wrote:
I think in BB WEbWorks you
document.location starts with http://localhost OR starts with file:// then?
;)
In any case, any js variable that we could set can be overridden of course.
On Fri, Nov 30, 2012 at 3:38 PM, Filip Maj f...@adobe.com wrote:
I think in BB WEbWorks you get http://localhost/somethingsoemthing
On
On Fri, Nov 30, 2012 at 6:27 PM, Filip Maj f...@adobe.com wrote:
The question becomes: since both browser and native versions of the app
include cordova.js, how do we know if we're in cordova or not?
Great question.
What about during cordova.js' initialization we test the bridge (echo
WP7 app is loaded from x-wmapp1:/
WP8 app is loaded from x-wmapp0:/
So file:// will not work
There are probably numerous other approches ...
deviceready will/should never fire, but that is difficult to test for,
because it could just be taking a real long time.
I see many issues with this
Its yucky and may break in a future platform version, but since each
platform requires its own cordova.js -- then each platform could define its
own cordova.isWebView?
wp7 is x-wmapp
iOS is file://
BB is http://localhost
Android is ?
On Fri, Nov 30, 2012 at 3:49 PM, Jesse
Can we back up and discuss the goal?
Is it to use the same code on the server + inside an app ( that is
packaged for multiple platforms ) ?
OR
Is it to load an app on multiple devices all served by the same server?
On Fri, Nov 30, 2012 at 3:56 PM, Shazron shaz...@gmail.com wrote:
Its yucky
Yeh this makes more sense.. Delegate iswebview to each platform
implementation.
BTW Android is file:// as well
On 11/30/12 3:56 PM, Shazron shaz...@gmail.com wrote:
Its yucky and may break in a future platform version, but since each
platform requires its own cordova.js -- then each platform
It is to run a single codebase (or as close to it as possible minus the
differences in cordova.js) across web and cordova apps.
On 11/30/12 4:02 PM, Jesse purplecabb...@gmail.com wrote:
Can we back up and discuss the goal?
Is it to use the same code on the server + inside an app ( that is
+1
This isn't a platform issue but rather a developer issue
Sent from my iPhone
On 2012-11-30, at 7:11 PM, Jesse purplecabb...@gmail.com wrote:
Presumably the developer knows the url of their own server, so
wouldn't it be easier to just test for that in window.location?
On Fri, Nov 30,
34 matches
Mail list logo
