incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Unified JS and iOS
Date Fri, 16 Mar 2012 21:58:31 GMT
Don't worry Fil - I'll give it a go and fix anything that needs fixing
wrt the installer

On Fri, Mar 16, 2012 at 11:27 AM, Filip Maj <fil@adobe.com> wrote:
> 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