You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2012/04/13 20:58:40 UTC
[iOS] Factoring out JavaScript code from Objective-C
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
Re: [iOS] Factoring out JavaScript code from Objective-C
Posted by Shazron <sh...@gmail.com>.
O_o
not really following - maybe it's Friday, will try again Monday
On Fri, Apr 13, 2012 at 4:23 PM, Jesse <pu...@gmail.com> wrote:
> Missed a }
> Don't hate.
>
> On Fri, Apr 13, 2012 at 4:22 PM, Jesse <pu...@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 <sh...@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 <da...@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 <sh...@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 <gi...@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 <sh...@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
>>> >>>>
>>>
>>
>>
Re: [iOS] Factoring out JavaScript code from Objective-C
Posted by Jesse <pu...@gmail.com>.
Missed a }
Don't hate.
On Fri, Apr 13, 2012 at 4:22 PM, Jesse <pu...@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 <sh...@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 <da...@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 <sh...@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 <gi...@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 <sh...@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
>> >>>>
>>
>
>
Re: [iOS] Factoring out JavaScript code from Objective-C
Posted by Jesse <pu...@gmail.com>.
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 <sh...@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 <da...@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 <sh...@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 <gi...@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 <sh...@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
> >>>>
>
Re: [iOS] Factoring out JavaScript code from Objective-C
Posted by Shazron <sh...@gmail.com>.
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 <da...@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 <sh...@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 <gi...@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 <sh...@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
>>>>
Re: [iOS] Factoring out JavaScript code from Objective-C
Posted by Dave Johnson <da...@gmail.com>.
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 <sh...@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 <gi...@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 <sh...@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
>>>
Re: [iOS] Factoring out JavaScript code from Objective-C
Posted by Shazron <sh...@gmail.com>.
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 <gi...@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 <sh...@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
>>
Re: [iOS] Factoring out JavaScript code from Objective-C
Posted by Becky Gibson <gi...@gmail.com>.
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 <sh...@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
>