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 23:32:20 GMT
O_o
not really following - maybe it's Friday, will try again Monday

On Fri, Apr 13, 2012 at 4:23 PM, Jesse <purplecabbage@gmail.com> wrote:
> 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
View raw message