https://issues.apache.org/jira/browse/CB-385
Wanted to solicit the list to get help on the issue. Just trying to
generate ideas.
The core problem: people not using the proper .js file on their platform,
I.e. Copying their entire www/ folder from their iOS app to their Android
app.
This issue pro
Interesting. Good point in not depending on the bridge.
Maybe slightly off topic, and a potential breaking change...
Does it make sense to place the cordova.js file up one level? Ie
src='../cordova-x.x.x.js'
This would make it a packaging issue, and the www folder would be
truly portable.
Is this
@Jesse I don't like it wrt to maintenance - you'll have to think of
the Xcode templates. There's already trouble with dragging in the www
folder for users, this would make it a maintenance and user nightmare,
since the .js file will have to be part of the template now to be part
of the bundle.
I l
Yeah - read my post again wrt to maintenance. How do you think the
app/cordova.js gets in there in the bundle? It has to be a resource in
the the Xcode project - a hard-coded thing.
On Thu, May 3, 2012 at 11:46 AM, Jesse MacFadyen
wrote:
> Actually, I was just saying that the device specific js f
@shaz
I replied before reading yours...
I don't see really what the problem is with having it be a resource to
the project...
The only issue I see is updating to a new version, the dev would have
to update the js file manually if they started from a template.
In a CLI world it would be trivial wou
@jesse it's not a problem for "us", it's a problem with users. Trust
me it will be a headache for users judging from the mailing lists.
Better if we inject, no fuss - since a version of the .js is tightly
coupled with the .framework anyway. In a CLI world sure -- judging
from our user-base, probab
Just throwing out an idea - iOS used to inject a DeviceInfo js object
on load. Could we do a check in cordova.js based on a known variable
being set by the native wrapper?
On Thu, May 3, 2012 at 1:01 PM, Shazron wrote:
> @jesse it's not a problem for "us", it's a problem with users. Trust
> me it
I like that approach best so far, since it is relatively a small change,
and easily proven.
Given that we have detected a mis-match, how do we respond?
window.alert is NOT supported on all platforms ( pre deviceready)
console.log is NOT supported on all platforms ( pre deviceready)
Should we jus
On Thu, May 3, 2012 at 4:30 PM, Jesse wrote:
> I like that approach best so far, since it is relatively a small change,
> and easily proven.
>
> Given that we have detected a mis-match, how do we respond?
>
> window.alert is NOT supported on all platforms ( pre deviceready)
> console.log is NOT s
Might be fraught with problems, but how about a pure HTML+CSS+JS
overlay dialog or something?
On Thu, May 3, 2012 at 1:30 PM, Jesse wrote:
> I like that approach best so far, since it is relatively a small change,
> and easily proven.
>
> Given that we have detected a mis-match, how do we respond
On Thu, May 3, 2012 at 1:50 PM, Filip Maj wrote:
> https://issues.apache.org/jira/browse/CB-385
>
> This issue proposes the idea of checking that the native platform the app
> is running on matches the platform the .js file is built for.
>
> The question is: how?
>
So, the .js knows what platfor
+1 Patricks thoughts as an immediate action.
* * *
Looks like the latest JS is roughly 120-180k. I would take this to
mean that the platform specific business tends to be around 60k
depending on the platform.
Would it be tenable to combine the JS into a single file that
platform/feature loads it
On 5/3/12 4:54 PM, "Patrick Mueller" wrote:
>So, the .js knows what platform it was built for. We should create a
>marker in cordova.js, near the top, making it real obvious what platform
>it's for. Should also be machine readable.
Are you thinking a comment near the top "HEY THIS IS FOR BLA
13 matches
Mail list logo
