incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Unified JS and iOS
Date Thu, 15 Mar 2012 19:39:08 GMT
O and if I haven't already said it: Becky thank you so much for all your
hard work put in to get this done. We couldn't have done it without you!

On 3/15/12 12:36 PM, "Filip Maj" <> wrote:

>Hey all,
>Update for you: I'm going to be merging the iOS changes to cordova-js into
>master today. The common code affected is Contact, FileReader and
>MediaError. I've ran tests on Android and everything checks out (other
>than an interesting Contact bug that happens with Google accounts on
>Android devices - will post an issue for this after Joe and I investigate
>a bit more).
>The cordova-js changes to the native iOS code is still in a branch. We are
>looking at some final few tweaks. Basically the geolocation implementation
>needs to actually parse and take into account the W3C spec parameters
>(maximumAge, timeout, enableHighAccuracy).
>Moving forward Becky and I will be focusing on getting the native changes
>into the iOS master ASAP. Shaz, if you can help out with that that would
>be awesome. Would be nice to get the code switch in tomorrow and then we'd
>have two full weeks of testing before we drop 1.6.
>In any case, with the current ios+android unified js code, Android is
>sporting about 20 failing tests, and iOS about 23, out of 764 tests. 95%+
>passing. Pretty good!!!
>On 2/27/12 2:21 PM, "Filip Maj" <> wrote:
>>My responses in-line below.
>>On 12-02-24 12:25 PM, "Becky Gibson" <> wrote:
>>>Well, I'm sorry to say that I have been working most of the day on
>>>iOS and have made little real progress.
>>>1) First the File bug that Simon posted about slowed me down.   Can't go
>>>too much further until we agree on and fix for that one as well as
>>>on the FileError implementation that Drew pointed out.
>>We've got one other thread dealing with this particular issue. Let's
>>discuss and resolve this specific issue in that thread.
>>>2) Another issue is how iOS dealt with parameters into functions.   The
>>>code expects only one "object"  in the exec parameters.  This was passed
>>>an options argument into the actual plugins function.   Thus, if there
>>>two objects that needed to be passed, we created a wrapper object in the
>>>exec arguments array.  For example the exec call for contacts.find is
>>>unified as:
>>>exec(win, errorCB, "Contacts", "search", [fields, options]);
>>>The previous iOS version was:
>>>exec(successCB, errorCB, "org.apache.cordova.contacts","search",
>>>The [{"fields":fields, "findOptions":options}] would get converted into
>>>dictionary that was passed as an options argument into the plugin.
>>>than special casing all of the iOS functions that take more than one
>>>object, I guess we'll need to tweak the exec function of the unfolding
>>>parameters on the iOS side.  A big change that will need thorough
>>I like the named parameters approach with objects. However, as we already
>>have an array-based solution in place fully for Android and most of the
>>way there for BlacKberry, I will recommend we do a change in iOS native
>>code to use the array-based approach. It is, in the end, the same thing:
>>either using named parameters or array indices on the native side. Both
>>are as equally prone to error :)
>>Down the road, we can always refactor and change this and update the
>>native side on our platform implementations.
>>>3) Another issues is the removal of the casting in the Contacts api.  On
>>>iOS I used the cast functions in the contacts object to convert Dates
>>>properly between JS and the iOS device.  I think Android may have had
>>>same issue (the mobile-spec tests don't catch this). I guess the
>>>here is to create a conversion function for Dates and make it device
>>>specific.  Then, like has been done for other casting issues, wrap the
>>>casting into the inline success function. If a platform doesn't need
>>>conversion, then the functions would be empty.  I'll need some help
>>>this into the build system.
>>For conversions and casting, as long as native returns simple primitives
>>(I.e. Unix-style timestamps for dates, for example as long ints) and we
>>construct the necessary dates on the JavaScript side, we are safe.
>>>4) The accelerometer code seems to be very Android specific, I can make
>>>work more like Android but I think I would prefer to  make iOS specific
>>>versions for it and compass.
>>I've got a rewrite of the Accelerometer plugin on my fork of
>>incubator-cordova-ios on the cordova-js branch here:
>>It's working and using the android/blackberry/common way.
>>>5) There are some iOS specific apis.   Contacts.display() is one
>>> It was previously hung off of the Contact object but I'm not sure how
>>>would be accomplished in this new world.  Perhaps it should be  stand
>>>alone, iOS only api?  Compass.watchHeadingFilter() and
>>>Compass.clearHeadingFilter() are other examples.  iOS implements the
>>>standard compass api's but the watchHeadingFilter() is the more
>>>implementation on iOS because of the way the heading monitoring works on
>>>the device.   Just need to know how we want to handle these additions.
>>If you want to keep the ios-specific method additions to the contacts API
>>prototype, we can always implement the ios-specific methods as an
>>plugin and tack onto the contacts API prototype in the ios-specific
>>initialize method of the ios platform definition under
>>lib/platform/ios.js. Just like we do for certain BlackBerry File APIs,

View raw message