incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <>
Subject Re: Unified JS and iOS
Date Fri, 24 Feb 2012 20:25:13 GMT
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.

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",

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.

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.

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.

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.


On Thu, Feb 23, 2012 at 2:56 PM, Filip Maj <> wrote:

> Hi all,
> I got the initialization working with the below to branches for iOS
> cordova-js. Huzzah!
> >
> >
> >
> So now we can load up mobile-spec as per usual at the least and chip away
> at the tests until it's working.

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