incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [iOS] Factoring out JavaScript code from Objective-C
Date Fri, 13 Apr 2012 22:09:29 GMT
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
View raw message