You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Patrick Mueller <pm...@gmail.com> on 2011/11/17 18:43:36 UTC
Callback version available in platform natives and JS
With the change of the JSON code from PhoneGap 1.1 to 1.2, I had a
potential issue that could perhaps had been avoided if I knew what version
of PhoneGap I was using, as a C preproccessor define, in my native code.
Specifically, I had used the SBJSON include (whatever name that was) in the
BarcodeScanner plugin. That code no longer compiled once 1.2 was
installed. If I knew the version of PhoneGap, I might have been able to do
something like:
#if (expression evaluating whether I'm running 1.2 or greater)
#import [[JSONKit include]]
#else
#import [[SBJSON include]]
#endif
Likely, I would have had to had similar #ifs in my runtime code, unless
both libraries have same API.
Turns out, in this case, my code no longer was using any JSON utility
methods directly anymore, so deleting the existing SBJSON includes was my
"fix".
This just got me thinking that we probably DO want to have the PhoneGap
version available SOMEHOW for the natives, as well as the JavaScript
runtime. Having this available in JS would be nice, as we can arrange to do
a "version check" early to see if people are using different versions of
.js and native code - a problem I've run into myself.
Sound right? If so, I'll open a bug, where we can talk about what the
"names" and "values" of these version identifiers should be.
--
Patrick Mueller
http://muellerware.org
Re: Callback version available in platform natives and JS
Posted by Shazron <sh...@gmail.com>.
For #defines perhaps we can take a cue on how Apple does it. In Xcode
--> File --> Open Quickly... --> type in "Availability.h".
http://www.opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/Availability.h
http://www.opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/AvailabilityInternal.h
On Thu, Nov 17, 2011 at 1:07 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Thu, Nov 17, 2011 at 14:17, Shazron <sh...@gmail.com> wrote:
>
>> For iOS, there is a version method available in native code as well:
>>
>> https://github.com/callback/callback-ios/blob/master/PhoneGapLib/Classes/PhoneGapDelegate.m#L149-170
>>
>> Only a runtime approach - so from a plugin, you would call:
>> NSString* pgVersion = [PhoneGapDelegate phoneGapVersion];
>>
>> There are currently two ways that the library gets the version - one
>> is through a build preprocessor macro (this is for PhoneGap.framework,
>> version is baked in), one from reading from the VERSION file (legacy
>> code - mainly for Xcode 3 based projects).
>>
>
> In this particular case, I actually needed the version at the time the
> preprocessor is invoked. The runtime version wouldn't have helped. Nor
> would the VERSION file, I don't think.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Callback version available in platform natives and JS
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, Nov 17, 2011 at 14:17, Shazron <sh...@gmail.com> wrote:
> For iOS, there is a version method available in native code as well:
>
> https://github.com/callback/callback-ios/blob/master/PhoneGapLib/Classes/PhoneGapDelegate.m#L149-170
>
> Only a runtime approach - so from a plugin, you would call:
> NSString* pgVersion = [PhoneGapDelegate phoneGapVersion];
>
> There are currently two ways that the library gets the version - one
> is through a build preprocessor macro (this is for PhoneGap.framework,
> version is baked in), one from reading from the VERSION file (legacy
> code - mainly for Xcode 3 based projects).
>
In this particular case, I actually needed the version at the time the
preprocessor is invoked. The runtime version wouldn't have helped. Nor
would the VERSION file, I don't think.
--
Patrick Mueller
http://muellerware.org
Re: Callback version available in platform natives and JS
Posted by Shazron <sh...@gmail.com>.
For iOS, there is a version method available in native code as well:
https://github.com/callback/callback-ios/blob/master/PhoneGapLib/Classes/PhoneGapDelegate.m#L149-170
Only a runtime approach - so from a plugin, you would call:
NSString* pgVersion = [PhoneGapDelegate phoneGapVersion];
There are currently two ways that the library gets the version - one
is through a build preprocessor macro (this is for PhoneGap.framework,
version is baked in), one from reading from the VERSION file (legacy
code - mainly for Xcode 3 based projects).
On Thu, Nov 17, 2011 at 11:10 AM, Patrick Mueller <pm...@gmail.com> wrote:
> On Thu, Nov 17, 2011 at 13:05, Jesse MacFadyen <pu...@gmail.com>wrote:
>
>> Runtime js code can look at device.phonegap for the version.
>>
>> http://docs.phonegap.com/en/1.2.0/phonegap_device_device.md.html#device.phonegap
>
>
> ah, didn't see that. Not clear what's being returned here, presumably a
> string like "1.2.0". We may want to make it more elaborate, like
> separating out major/minor/fix numbers or something, depending on what we
> do in the native side.
>
>
>> For build-time I like the #define approach, but this can vary by platform.
>>
>
> Right. For Java-based platforms, presumably we'd have final static
> Thing(s) with the version #'s; for C-based platforms, preprocessor defines
> make more sense. We can evaluate a couple of different styles of these if
> we want to move forward on it.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Callback version available in platform natives and JS
Posted by Patrick Mueller <pm...@gmail.com>.
On Thu, Nov 17, 2011 at 13:05, Jesse MacFadyen <pu...@gmail.com>wrote:
> Runtime js code can look at device.phonegap for the version.
>
> http://docs.phonegap.com/en/1.2.0/phonegap_device_device.md.html#device.phonegap
ah, didn't see that. Not clear what's being returned here, presumably a
string like "1.2.0". We may want to make it more elaborate, like
separating out major/minor/fix numbers or something, depending on what we
do in the native side.
> For build-time I like the #define approach, but this can vary by platform.
>
Right. For Java-based platforms, presumably we'd have final static
Thing(s) with the version #'s; for C-based platforms, preprocessor defines
make more sense. We can evaluate a couple of different styles of these if
we want to move forward on it.
--
Patrick Mueller
http://muellerware.org
Re: Callback version available in platform natives and JS
Posted by Jesse MacFadyen <pu...@gmail.com>.
Runtime js code can look at device.phonegap for the version.
http://docs.phonegap.com/en/1.2.0/phonegap_device_device.md.html#device.phonegap
For build-time I like the #define approach, but this can vary by platform.
Cheers,
Jesse
Sent from my iPhone5
On 2011-11-17, at 9:44 AM, Patrick Mueller <pm...@gmail.com> wrote:
> With the change of the JSON code from PhoneGap 1.1 to 1.2, I had a
> potential issue that could perhaps had been avoided if I knew what version
> of PhoneGap I was using, as a C preproccessor define, in my native code.
>
> Specifically, I had used the SBJSON include (whatever name that was) in the
> BarcodeScanner plugin. That code no longer compiled once 1.2 was
> installed. If I knew the version of PhoneGap, I might have been able to do
> something like:
>
> #if (expression evaluating whether I'm running 1.2 or greater)
> #import [[JSONKit include]]
> #else
> #import [[SBJSON include]]
> #endif
>
> Likely, I would have had to had similar #ifs in my runtime code, unless
> both libraries have same API.
>
> Turns out, in this case, my code no longer was using any JSON utility
> methods directly anymore, so deleting the existing SBJSON includes was my
> "fix".
>
> This just got me thinking that we probably DO want to have the PhoneGap
> version available SOMEHOW for the natives, as well as the JavaScript
> runtime. Having this available in JS would be nice, as we can arrange to do
> a "version check" early to see if people are using different versions of
> .js and native code - a problem I've run into myself.
>
> Sound right? If so, I'll open a bug, where we can talk about what the
> "names" and "values" of these version identifiers should be.
>
> --
> Patrick Mueller
> http://muellerware.org