incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: [iOS] Factoring out JavaScript code from Objective-C
Date Fri, 13 Apr 2012 23:23:56 GMT
Missed a }
Don't hate.

On Fri, Apr 13, 2012 at 4:22 PM, Jesse <purplecabbage@gmail.com> wrote:

> On WP7 I route ALL my plugin results to a single function, and use the
> status to determine if I call success or error with the result.
>
> Additionally, I check for string values to indicate the special cases
> where I need to fire an event: "backbutton","resume","pause"
>
>
> https://github.com/purplecabbage/incubator-cordova-js/blob/master/lib/wp7/plugin/wp7/CordovaCommandResult.js
>
> You should be able to do a similar thing, although you won't need a
> singular callback, the way I do. On WP7, I cannot call cordova.callbackSuccess
> from native, as I cannot easily dereference, iOS, however can do that fine.
>
> You could also do some magic in platform specific js that results in this:
>
> var channel = require('cordova/channel');
> cordova.callbacks["resume"] = {success:function(){
>  channel.onResume.fire();
> };
> cordova.callbacks["pause"] = {success:function(){
>  channel.onPause.fire();
> }};
>
> You would just need to make sure you callback with 'keepCallback:true" in
> the message, and always use a success status.
>
>
>
>
>
> On Fri, Apr 13, 2012 at 3:09 PM, Shazron <shazron@gmail.com> wrote:
>
>> We can't do that - for lifecycle events for example we have to call
>> cordova.fireWindowEvent, etc etc independent of it being a function
>> call from js
>>
>> On Fri, Apr 13, 2012 at 1:11 PM, Dave Johnson <dave.c.johnson@gmail.com>
>> wrote:
>> > In the case of android and bb (I think) we have tried to avoid JS in
>> > the actual plugin code by using the
>> > PluginResult.toSuccessCallbackString method that is (ideally) the only
>> > place (and toErrorCallbackString of course) that JS code is used in
>> > native.
>> >
>> > On Fri, Apr 13, 2012 at 12:37 PM, Shazron <shazron@gmail.com> wrote:
>> >> Just had the same thought after I sent that email - precisely since
>> >> all our stuff is "self-contained" in plugins, separating them out and
>> >> adding a dependency will add on to the work we would have to do.
>> >>
>> >> I added manual tests to the release checklist:
>> >> Step 2 of http://wiki.apache.org/cordova/IOSReleaseChecklist
>> >> http://wiki.apache.org/cordova/iOSManualTests
>> >>
>> >> On Fri, Apr 13, 2012 at 12:23 PM, Becky Gibson <gibson.becky@gmail.com>
>> wrote:
>> >>> I'm not sure that makes it any easier.  Yes, we can check for things
>> like
>> >>> Capital C Cordova, vs lower case c cordova, but it makes the actual
>> coding
>> >>> more disjoint IMHO.  Generally the strings are pretty specific to the
>> >>> plugin. And, having them all in a separate file makes it harder to
>> separate
>> >>> out the plugin code.   I think what we really need is better testing
>> >>> mechanisms to catch these type of errors.
>> >>>
>> >>> my two cents,
>> >>> -becky
>> >>>
>> >>> On Fri, Apr 13, 2012 at 2:58 PM, Shazron <shazron@gmail.com> wrote:
>> >>>
>> >>>> We currently have to write out JavaScript from Objective-C, and
these
>> >>>> strings can't be checked easily all in one place (note the bugs
found
>> >>>> today slated for 1.6.1)
>> >>>>
>> >>>> I'm proposing we either use:
>> >>>> 1. NSLocalizedString [1][2] where the strings are in an external
>> strings
>> >>>> file
>> >>>> 2. an Obj-C templating [3] solution that we need to create,
>> >>>> essentially the same as 1 but with more features, although that's
>> more
>> >>>> complex
>> >>>> 3. Move all the JS strings into an Obj-C file as string constants
>> >>>>
>> >>>> Items 1 and 2 require the .strings file to be in the user's
>> >>>> application potentially (I haven't tested whether loading strings
>> from
>> >>>> the current framework bundle will work) and may be an upgrade
>> >>>> nightmare (and we don't want users to edit them).
>> >>>> Item 3 might be easiest, since it will all be baked-in.
>> >>>>
>> >>>> My preference is 1 (if the framework bundle loading works), then
3.
>> >>>>
>> >>>>
>> >>>> [1] http://www.cocoadev.com/index.pl?NSLocalizedString
>> >>>> [2]
>> http://cocoawithlove.com/2011/04/user-interface-strings-in-cocoa.html
>> >>>> [3] A bit of overkill though, Mustache for Obj-C:
>> >>>> https://github.com/hiddenmemory/Tipi
>> >>>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message