That's pretty cool! And pretty simple too!
On Wed, Dec 5, 2012 at 7:03 AM, Simon MacDonald
wrote:
> 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.
>
> https://github.com/Airblader/
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.
https://github.com/Airblader/FeatureDetector
Simon Mac Donald
http://hi.im/simonmacdonald
On Tue, Dec 4, 2012 at 11:37 AM, Brian LeRoux
>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.
On Dec 3, 2012 7:42 PM, "Andrew Grieve" wrote:
>
> 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?
In the Wikipedia app we have a single codebase for several platforms and
load the appropriate Cordova.
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
pars
On Mon, Dec 3, 2012 at 8:32 PM, Andrew Lunny 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 tha
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
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
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
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" wrote:
>document.addEventListener('deviceready', function() {navigator.in
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 illustrat
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 w
On Mon, Dec 3, 2012 at 3:53 PM, Brian LeRoux 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.
I'm of the opinion this isn't a Cordova problembut I do think
device capabilities introspection is. (Which is related.)
On Mon, Dec 3, 2012 at 11:45 PM, Gord Tanner wrote:
> I am having a hard time making this seem like a Cordova problem.
>
> There are many different and easy ways to fix this
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
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 (ge
actual code from gather:
if (inBrowser()) setTimeout(function() {
app.emit('deviceReady')
}, 50)
right now inBrowser looks at window.location.href and fires the event if it
isnt in phonegap. but I use the inBrowser function elsewhere to determine
what login strategy to use (see my previou
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 wrote:
> I dont think modifying the UA is a good idea but
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 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 browser
> JS on a
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 wrote:
> 1) Set a specific UA string like the w
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 wrote:
> Back to our original thread. I'm seeing a cou
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 wrote:
> My
> cordova apps simply point to the website URL to get its contents.
>
I don't know if this is really a g
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,
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 wrote:
> In Gather we have a login page that uses childbrowser popu
On Mon, Dec 3, 2012 at 11:40 AM, Max Ogden 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 guesses based
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
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 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
> cordova.js, then the native
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
cordova.js, then the native side will become available well before
cordova.js finished loading. So, I would either check for
device.cordova or register for dev
+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 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, 2012 at 4:07 PM, Jesse
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, 2012 at 4:07 PM, Jesse wrote:
> So the bigger question then is how to handle the differences ...
>
> On Fri, Nov 30, 2012 at 4:04 PM, Filip Maj wrote:
>>
So the bigger question then is how to handle the differences ...
On Fri, Nov 30, 2012 at 4:04 PM, Filip Maj wrote:
> 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" wrote:
>
>>Can w
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" wrote:
>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 p
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" wrote:
>Its yucky and may break in a future platform version, but since each
>platform requires its own cordova.js -- then each platform could define
>
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 wrote:
> Its yucky and may break in a
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 wrote:
> WP7 app is l
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 thoug
On Fri, Nov 30, 2012 at 6:27 PM, Filip Maj 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
> plugin?). If
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 wrote:
> I think in BB WEbWorks you get http://localhost/somethingsoemthing
>
> On 11/30/12 3:35
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 wrote:
> I think in BB WEbWorks you get http://loc
I think in BB WEbWorks you get http://localhost/somethingsoemthing
On 11/30/12 3:35 PM, "Shazron" wrote:
>"how do we know if we're in cordova or not?" --> document.location starts
>with file:// ?
"how do we know if we're in cordova or not?" --> document.location starts
with file:// ?
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 bot
42 matches
Mail list logo
