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