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 <[email protected]> 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 supported on all platforms ( pre deviceready) > > Should we just document.write('there is a problem'); ?? > > On Thu, May 3, 2012 at 1:14 PM, Shazron <[email protected]> wrote: > >> 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 <[email protected]> wrote: >> > @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 >> > <[email protected]> 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 <[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. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>> >> > > > > -- > @purplecabbage > risingj.com
