incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <>
Subject Re: Unified JS and iOS
Date Mon, 27 Feb 2012 23:44:42 GMT
On Mon, Feb 27, 2012 at 11: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
> >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 :)

My Vote is for a named parameters object: ala
exec(successCB, errorCB,
The object/payload passed to each call is a 'contract' between the
JavaScript code and the Native code.

> 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:
> 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:
> ckberry.js#L31-L39

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message