incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Unified JS and iOS
Date Mon, 27 Feb 2012 22:21:45 GMT
My responses in-line below.

On 12-02-24 12:25 PM, "Becky Gibson" <gibson.becky@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/ca3fde6959d430e234d1
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/bla
ckberry.js#L31-L39


Mime
View raw message