Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable sending complete JSON payloads, as proxy for other SDKs #155

Merged
merged 1 commit into from
Apr 19, 2019

Conversation

waltjones
Copy link
Contributor

@waltjones waltjones commented Apr 10, 2019

The public interface has been updated to use sendJsonPayload() instead of send(). This is meant to be consistent with rollbar/rollbar.js#724 as well as address the comments here.

@@ -80,6 +80,10 @@

+ (void)logCrashReport:(NSString*)crashReport;

// Send JSON payload

+ (void)send:(NSData*)payload;
Copy link
Contributor

Choose a reason for hiding this comment

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

it may make sense to rename it to:
+ (void)sendPayload:(NSData*)payload;
so it is in sync with the RollbarNotifier addition...

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 thought about that. The tradeoff is send is more consistent with the naming that is (now) introduced across the other SDK interfaces. The internal notifier naming differentiates sendItem and sendPayload. I suppose we could push that internal detail up to the public interface here. I was inclined to prefer the simpler send as long as it wouldn't be ambiguous in any context.

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 should add that in some SDKs (Java), Payload is a type and therefore sendPayload infers more that we would want. To the extent we want this to be consistent, like we do with log(), that's a reason to avoid sendPayload in the public interface.

Copy link
Contributor

Choose a reason for hiding this comment

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

we should be consistent across the SDKs semantically as much as possible, but necessarily syntactically. for example, in .NET/C# all the public methods are capitalized by convention and not all languages support method overloads (objective-c is somewhat different here: https://learning.oreilly.com/library/view/ios-6-programming/9781449342746/ch01s15.html )

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point.

Copy link
Contributor

Choose a reason for hiding this comment

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

Cocoa guidelines (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html) say sendPayload is probably the preferred name, although I hate quite a few of their guidelines.


@return YES if successful. NO if not.
*/
- (BOOL)sendPayload:(NSData*)payload;
Copy link
Contributor

Choose a reason for hiding this comment

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

@waltjones , I assume you are just stubbing it out since there is no implementation for this method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

@waltjones, i see. you essentially making it public here. missed that one...

@akornich akornich self-assigned this Apr 19, 2019
@waltjones waltjones changed the title WIP: Enable sending complete JSON payloads, as proxy for other SDKs Enable sending complete JSON payloads, as proxy for other SDKs Apr 19, 2019
Copy link
Contributor

@akornich akornich left a comment

Choose a reason for hiding this comment

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

Looks good!

@akornich akornich merged commit 3397e01 into master Apr 19, 2019
@akornich akornich deleted the wj-cordova branch September 28, 2020 19:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants