incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Checking platform + version in cordova-js
Date Thu, 03 May 2012 20:48:20 GMT
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 <purplecabbage@gmail.com> 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 <shazron@gmail.com> 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 <shazron@gmail.com> 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
>> > <purplecabbage@gmail.com> 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 <shazron@gmail.com> 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
>> >>> <purplecabbage@gmail.com> 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 <fil@adobe.com> 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" <purplecabbage@gmail.com>
>> 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 <fil@adobe.com>
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

Mime
View raw message