incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Johnson <>
Subject Re: [iOS] Factoring out JavaScript code from Objective-C
Date Fri, 13 Apr 2012 20:11:49 GMT
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

On Fri, Apr 13, 2012 at 12:37 PM, Shazron <> 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
> On Fri, Apr 13, 2012 at 12:23 PM, Becky Gibson <> 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 <> 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]
>>> [2]
>>> [3] A bit of overkill though, Mustache for Obj-C:

View raw message