@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 <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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] https://github.com/deedubbu/cordova-blackberry-pluggable >>> >>> On 5/3/12 2:08 PM, "Jesse MacFadyen" <[email protected]> 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 iOS. >>>> >>>> Cheers, >>>> Jesse >>>> >>>> Sent from my iPhone5 >>>> >>>> On 2012-05-03, at 10:48 AM, Filip Maj <[email protected]> wrote: >>>> >>>>> 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 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? >>>>> >>>>> 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, which >>>>> probably will not if the user is using the wrong .js file. >>>>> >>>>> >>>>> >>>>> >>>
