You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cordova.apache.org by Filip Maj <fi...@adobe.com> on 2012/03/15 20:36:02 UTC

Re: Unified JS and iOS

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" <fi...@adobe.com> wrote:

>My responses in-line below.
>
>On 12-02-24 12:25 PM, "Becky Gibson" <gi...@gmail.com> wrote:
>
>>Well, I'm sorry to say that I have been working most of the day on
>>updating
>>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 decide
>>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
>>iOS
>>code expects only one "object"  in the exec parameters.  This was passed
>>as
>>an options argument into the actual plugins function.   Thus, if there
>>were
>>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 now
>>unified as:
>>
>>exec(win, errorCB, "Contacts", "search", [fields, options]);
>>
>>The previous iOS version was:
>>
>>exec(successCB, errorCB, "org.apache.cordova.contacts","search",
>>[{"fields":fields,
>>"findOptions":options}]);
>>
>>The [{"fields":fields, "findOptions":options}] would get converted into a
>>dictionary that was passed as an options argument into the plugin.
>>Rather
>>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 of
>>parameters on the iOS side.  A big change that will need thorough
>>testing.
>
>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 the
>>same issue (the mobile-spec tests don't catch this). I guess the solution
>>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 date
>>conversion, then the functions would be empty.  I'll need some help
>>working
>>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
>>iOS
>>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:
>
>https://github.com/filmaj/incubator-cordova-ios/commit/ca3fde6959d430e234d
>1
>196db937ca8fdf24fcf7
>
>
>It's working and using the android/blackberry/common way.
>
>>
>>5) There are some iOS specific apis.   Contacts.display() is one example.
>> It was previously hung off of the Contact object but I'm not sure how
>>that
>>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 efficient
>>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 ios-only
>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,
>see:
>
>https://github.com/apache/incubator-cordova-js/blob/master/lib/platform/bl
>a
>ckberry.js#L31-L39
>