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 23:11:34 GMT
Hey Shaz (and anyone else interested),

For reference in case anyone wants have a look over at the cordova-js
integration changes for cordova-ios, the JS stuff is all in cordova-js
master now [1].

The native changes are in my 'cordova-js' [2].

I made updates to geolocation and that is working now.

15 failing tests (out of 742) on my iPod :)

I think the iOS implementation is giving Android a run for its money in
terms of passing more tests!!

I'm aiming for merging in the native branch into mainline tomorrow. From
there on its testing mania, finding/filing bugs and improving as we go.

[1] https://github.com/apache/incubator-cordova-js
[2] https://github.com/filmaj/incubator-cordova-ios/tree/cordova-js

On 3/15/12 1:31 PM, "Filip Maj" <fil@adobe.com> wrote:

>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/ca3fde6959d430e
>>>>>2
>>>>>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/platfor
>>>>>m
>>>>>/b
>>>>>l
>>>>>a
>>>>>ckberry.js#L31-L39
>>>>>
>>>>
>>>
>


Mime
View raw message