-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Added -(BOOL)[MGLStyle removeSource:error:]
that provides an NSError.
#13399
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this. I added a question and minor tasks.
platform/darwin/src/MGLSource.mm
Outdated
} | ||
else if (outError) { | ||
// Consider raising an exception here | ||
NSString *format = NSLocalizedStringWithDefaultValue(@"REMOVE_SRC_FAIL_MISMATCH_FMT", nil, nil, @"Identifier '%@' does not match source identifier '%s'", @"User-friendly error description"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You will have to add the above and this localized string: https://github.com/mapbox/mapbox-gl-native/blob/master/platform/ios/DEVELOPING.md#adding-user-facing-text
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this isn't end-user-facing text (or perhaps shouldn't be) - what are the conventions here? Still use NSLocalizedStringWithDefaultValue
?
Perhaps it should be:
Use a generic, localized, error message for NSLocalizedDescriptionKey
, then move the existing, unlocalized, message to NSLocalizedFailureReasonErrorKey
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDIT: I updated the strings file as @fabian-guerra details above.
@@ -318,6 +318,27 @@ MGL_EXPORT | |||
*/ | |||
- (void)removeSource:(MGLSource *)source; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to live with both methods or should we deprecate this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can hold off on deprecation for the moment.
|
||
@param source The source to remove from the current style. | ||
@param outError Upon return, if an error has occurred, a pointer to an `NSError` | ||
object describing the error. Pass in `NULL` to ignore any error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: nil
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that is makes a difference in practice, but since nil
is used with objects (id
), and NSError**
isn't a pointer-to-object (rather a pointer-to-pointer-to-object), it should be NULL
in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but it's a " pointer-to-pointer-to-ObjC" object thus following the apple's convention on using nil
would be consistent with the platform and our SDK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a comment and this branch needs to fix conflicts before merging.
|
||
@param source The source to remove from the current style. | ||
@param outError Upon return, if an error has occurred, a pointer to an `NSError` | ||
object describing the error. Pass in `NULL` to ignore any error. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but it's a " pointer-to-pointer-to-ObjC" object thus following the apple's convention on using nil
would be consistent with the platform and our SDK.
… in case of failure. Updated existing test.
865078d
to
61dd7de
Compare
} | ||
else if (outError) { | ||
// Consider raising an exception here | ||
NSString *format = NSLocalizedStringWithDefaultValue(@"REMOVE_SRC_FAIL_MISMATCH_FMT", @"Foundation", nil, @"Identifier '%@' does not match source identifier '%s'", @"User-friendly error description"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a pretty specific error to use as the localized description. Note that localized descriptions are meant to be displayed to the end user, at least in theory. Other fields, such as the failure reason, can be used for technical details for the developer. In practice, it’s unlikely this error message would be displayed in an alert, but translators are going to find this string a bit more difficult to comprehend than the usual fare. By the way, I wonder if the Transifex and NSLocalizedString will correctly handle %s
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I thought I had add a comment about this somewhere: I'm tempted to change this before release so that the description is generic, and we just use a raw (not translated) message as the failure reason.
Do we have a generic error message that can be reused here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I guess it’s OK for these error messages to contain some technical details. -[MGLStyle removeSource:error:]
is likely to be called as part of some larger task, not directly in response to a user action. (Mapbox Studio Preview and macosapp are the only applications that would likely contain a user-facing Remove Source command.) ADD_FILE_CONTENTS_FAILED_DESC
is another localizable error description that wouldn’t be presented to the user, since the user has no awareness about file paths.
The documentation about underlying errors implies that some subsystem (in this case, the map SDK) would produce an error with less than user-friendly text. Examples include errors that originate from NSURLSession or NSFileManager. Such errors are sometimes localized, so it’s also OK to keep these strings in the localization files, but we should keep them to a minimum to avoid unnecessary translator effort.
Nonetheless, I’ve opened #13492 to revise these messages.
NSString *format = NSLocalizedStringWithDefaultValue(@"REMOVE_SRC_FAIL_MISMATCH_FMT", @"Foundation", nil, @"Identifier '%@' does not match source identifier '%s'", @"User-friendly error description"); | ||
NSString *localizedDescription = [NSString stringWithFormat:format, | ||
self.identifier, | ||
self.rawSource ? self.rawSource->getID().c_str() : "(null)"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By using an Objective-C %@
placeholder, we can avoid hard-coding a (null)
:
self.rawSource ? @(self.rawSource->getID().c_str()) : nil
} | ||
else if (outError) { | ||
// Consider raising an exception here | ||
NSString *format = NSLocalizedStringWithDefaultValue(@"REMOVE_SRC_FAIL_MISMATCH_FMT", @"Foundation", nil, @"Identifier '%@' does not match source identifier '%s'", @"User-friendly error description"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On second thought, I guess it’s OK for these error messages to contain some technical details. -[MGLStyle removeSource:error:]
is likely to be called as part of some larger task, not directly in response to a user action. (Mapbox Studio Preview and macosapp are the only applications that would likely contain a user-facing Remove Source command.) ADD_FILE_CONTENTS_FAILED_DESC
is another localizable error description that wouldn’t be presented to the user, since the user has no awareness about file paths.
The documentation about underlying errors implies that some subsystem (in this case, the map SDK) would produce an error with less than user-friendly text. Examples include errors that originate from NSURLSession or NSFileManager. Such errors are sometimes localized, so it’s also OK to keep these strings in the localization files, but we should keep them to a minimum to avoid unnecessary translator effort.
Nonetheless, I’ve opened #13492 to revise these messages.
Addresses #9692 - adds a new method that returns
YES
if the source was removed successfully, orNO
if not, in which case anNSError
will be returned by reference (if anNSError**
was provided)./cc @jmkiley