incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: Checking platform + version in cordova-js
Date Thu, 03 May 2012 20:01:57 GMT
@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, probably not. We can test this by removing the
template for a version and see who complains :P

I'm not opposed to it, I just think if we want to change, might as
well go for the best solution.

However, we still haven't solved the "how do we detect they are using
the wrong cordova version without going to the bridge", this however
solves the "wrong platform cordova js in your www folder" problem.

On Thu, May 3, 2012 at 12:51 PM, Jesse MacFadyen
<> wrote:
> @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 wouldn't it?
> I guess the part of this approach that I like is that it is
> transparent, I do understand though that it may be 'not enough'
> Cheers,
>  Jesse
> Sent from my iPhone5
> On 2012-05-03, at 11:48 AM, Shazron <> wrote:
>> 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 file was
>>> referenced from the parent folder to www  That way when the dev
>>> dropped their www into a different project it was still valid.
>>> I mean this:
>>> <script src='../cordova-x.x.x.js'></script>
>>> So the package at runtime would look like:
>>> app/cordova.js
>>> app/www/index.html
>>> The injection approach is interesting, but a much larger change and
>>> potentially a long path until it works for all. Architecturally I like
>>> it, but worry about the number of moving parts in the move from here
>>> to there.
>>> Cheers,
>>> Jesse
>>> Sent from my iPhone5
>>> On 2012-05-03, at 11:22 AM, Filip Maj <> wrote:
>>>> Are you saying, seeding the webview with the JS contents before loading
>>>> app assets? We could even eliminate the need for having a <script>
>>>> reference to cordova.js.
>>>> BlackBerry can do that, and I think Drew, in his pure-plugin prototype
>>>> [1], implemented that.
>>>> Android in theory should be doable by calling loadUrl:<full cordova.js
>>>> string here> on-load.
>>>> All of this would need testing though. Would be nice!
>>>> [1]
>>>> On 5/3/12 2:08 PM, "Jesse MacFadyen" <> wrote:
>>>>> 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 possible on other platforms? I know it would work for WP7 and
>>>>> Cheers,
>>>>> Jesse
>>>>> Sent from my iPhone5
>>>>> On 2012-05-03, at 10:48 AM, Filip Maj <> wrote:
>>>>>> Wanted to solicit the list to get help on the issue. Just trying
>>>>>> 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 proposes the idea of checking that the native platform
>>>>>> app
>>>>>> is running on matches the platform the .js file is built for.
>>>>>> The question is: how?
>>>>>> One idea: could do checking in the device module (the one that returns
>>>>>> device info) and compare against the platform id (from platform.js).
>>>>>> However, this relies on the web view <-> native bridge working,
>>>>>> probably will not if the user is using the wrong .js file.

View raw message