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:27:21 GMT
One last thing re: this - I updated the makefiles to point to the new
location of the JS file. I hope that's all I need to do҆ but not sure
about the installers or whatnot.

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

>It's done. Would love for people to pull in the latest iOS and see how it
>works out for you guys.
>
>testers: start your engines!
>
>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/ca3fde6959d4
>>>>>>>>3
>>>>>>>>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/plat
>>>>>>>>f
>>>>>>>>o
>>>>>>>>r
>>>>>>>>m
>>>>>>>>/b
>>>>>>>>l
>>>>>>>>a
>>>>>>>>ckberry.js#L31-L39
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>


Mime
View raw message