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 Fri, 16 Mar 2012 18:00:00 GMT
Ok I'm doing it then!!! Incoming commit notification email bomb.

On 3/16/12 10:40 AM, "Filip Maj" <fil@adobe.com> wrote:

>Anyone against merging in the unified-js native changes to iOS into the
>master of cordova-ios? Deleting old javascript, integrating the cordova-js
>file, etc.?
>
>On 3/15/12 4:11 PM, "Filip Maj" <fil@adobe.com> wrote:
>
>>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/ca3fde6959d43
>>>>>>>0
>>>>>>>e
>>>>>>>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/platf
>>>>>>>o
>>>>>>>r
>>>>>>>m
>>>>>>>/b
>>>>>>>l
>>>>>>>a
>>>>>>>ckberry.js#L31-L39
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>


Mime
View raw message