For 2), what I was looking at was a well-known/documented localization key that, if the dev added to his/her Localizable.strings file(s), would override the default string. And in the absence of it, the default string would be used. Such a change wouldn't require any changes to the existing method signature for [CDVWhitelist errorStringForURL:]. So, for instance the user would define a value in en.lproj/Localizable.strings like:
/* My customized whitelist rejection string. 'CDVWhitelistRejectionFormatString' is well-known. */ "CDVWhitelistRejectionFormatString" = "Trying to go to %@? What's the matter with you?"; But your idea seems more flexible, as the user could override the suggested method, and then provide whatever implementation he/she wanted. Kevin -----Original Message----- From: Shazron [mailto:shaz...@gmail.com] Sent: Sunday, October 21, 2012 10:15 PM To: callback-dev@incubator.apache.org Subject: Re: A couple of proposed updates to the iOS Cordova library 1) ok 2) something like: [CDVWhiteList errorStringWithFormat:(NSString*) format forUrl:(NSString*)url] ? On Sun, Oct 21, 2012 at 4:03 PM, Kevin Hawkins <khawk...@salesforce.com> wrote: > I have a couple of (minor) proposed updates to the iOS Cordova library. I > have code for these already, so they'd be easy enough to add. It would be > good to get feedback before pulling the trigger, though. > > > 1) Add a [CDVPluginResult resultWithStatus:messageAsBool:] method to the > existing plugin result convenience methods. > > > 2) In [CDVWhitelist errorStringForURL:], allow the returned message to > be overridden by a consuming app with a (localized) custom format string in > their app. > > Any objections to or suggestions for either of these? > > Thanks, > Kevin >
