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 Thu, 15 Mar 2012 20:31:10 GMT
Cheers dude!! Hit me up on IM or email if anything is unclear

On 3/15/12 1:21 PM, "Shazron" <shazron@gmail.com> wrote:

>Will do once I'm done here at Cloudstock. Thanks Fil and Becky!
>
>On Thu, Mar 15, 2012 at 12:39 PM, Filip Maj <fil@adobe.com> wrote:
>> 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" <fil@adobe.com> 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" <fil@adobe.com> wrote:
>>>
>>>>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/ca3fde6959d430e2
>>>>34
>>>>d
>>>>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
>>>>/b
>>>>l
>>>>a
>>>>ckberry.js#L31-L39
>>>>
>>>
>>


Mime
View raw message