Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

Added -(BOOL)[MGLStyle removeSource:error:] that provides an NSError. #13399

Merged
merged 4 commits into from
Nov 20, 2018

Conversation

julianrex
Copy link
Contributor

@julianrex julianrex commented Nov 16, 2018

Addresses #9692 - adds a new method that returns YES if the source was removed successfully, or NO if not, in which case an NSError will be returned by reference (if an NSError** was provided).

/cc @jmkiley

@julianrex julianrex added iOS Mapbox Maps SDK for iOS macOS Mapbox Maps SDK for macOS labels Nov 16, 2018
@julianrex julianrex added this to the release-iowaska milestone Nov 16, 2018
@julianrex julianrex self-assigned this Nov 16, 2018
@julianrex julianrex requested review from jmkiley and fabian-guerra and removed request for jmkiley November 16, 2018 19:51
Copy link
Contributor

@fabian-guerra fabian-guerra left a 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.

}
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");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@julianrex julianrex Nov 19, 2018

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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: nil

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

@fabian-guerra fabian-guerra left a 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.
Copy link
Contributor

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.

@julianrex julianrex force-pushed the jrex/9692-remove-in-use-source branch from 865078d to 61dd7de Compare November 19, 2018 23:24
@julianrex julianrex requested a review from 1ec5 as a code owner November 19, 2018 23:24
@julianrex julianrex merged commit 90f609c into master Nov 20, 2018
@julianrex julianrex deleted the jrex/9692-remove-in-use-source branch November 20, 2018 15:26
}
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");
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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)"];
Copy link
Contributor

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");
Copy link
Contributor

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
iOS Mapbox Maps SDK for iOS macOS Mapbox Maps SDK for macOS
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants