O_o not really following - maybe it's Friday, will try again Monday
On Fri, Apr 13, 2012 at 4:23 PM, Jesse <[email protected]> wrote: > Missed a } > Don't hate. > > On Fri, Apr 13, 2012 at 4:22 PM, Jesse <[email protected]> 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 <[email protected]> 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 <[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 >>> >>>> >>> >> >>
