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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >>>>
