Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of purplecabbage@gmail.com
 designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAE6O_-YQVPbWmbiFeC1ftd0AqaHs5MK6VmbQEOu2=hTfvxdjhg@mail.gmail.com>
References: <CBC84520.5887%fil@adobe.com>
	<2484959577825821691@unknownmsgid>
	<CAE6O_-ZemDBQE5+hcf_dAu5L=1=VksVpTgPp-ZhN1RN7HcCs0w@mail.gmail.com>
	<5870768929662404887@unknownmsgid>
	<CAE6O_-ZZEbq5shthtL_7kgXjd+1oUjkW3yidgrx208qAHgD20w@mail.gmail.com>
	<CAE6O_-YQVPbWmbiFeC1ftd0AqaHs5MK6VmbQEOu2=hTfvxdjhg@mail.gmail.com>
Date: Thu, 3 May 2012 13:30:57 -0700
Message-ID: 
 <CAKP6k2sPgOwxKsSgGw=tu4yqWgd=P6Cd=RBkCM20x+Pte2yZfQ@mail.gmail.com>
Subject: Re: Checking platform + version in cordova-js
From: Jesse <purplecabbage@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e6dbdf2670126004bf27ae97

--0016e6dbdf2670126004bf27ae97
Content-Type: text/plain; charset=ISO-8859-1

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

--0016e6dbdf2670126004bf27ae97--