[PS-97]: Extend RaygunEnvironmentMessage to add Maui specific information. #4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Created a custom RaygunClient that uses a new method of building the RaygunMessage
to enable easy access to device info. Cleaned up The RaygunMauiClient
Hamish-taylor
changed the title
PanosNB
requested changes
May 10, 2023
PanosNB
approved these changes
May 10, 2023
README.md
Outdated
| @@ -131,7 +131,17 @@ try { | |||
|
|
|||
| --- | |||
| ## Platform specific information | |||
| Raygun4Maui will automatically collect information specific to the environment the application is being run in. However, on iOS, Raygun4Maui cannot obtain the devices name. This is a privacy restriction put in place by Apple. If you would like this information to be collected and sent with crash reports you will have to [request for permission from apple](https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_device-information_user-assigned-device-name?language=objc). | |||
| Raygun4Maui will automatically collect information specific to the environment the application is being run in. However, there are inconsistency's between certain values across platforms. | |||
There was a problem hiding this comment.
use plural: "inconsistencies"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem
The problem this pull request is trying to solve is that the Raygun4net environment message is limited and does not contain mobile specific fields that other Raygun mobile specific providers support. We would like to support these fields in the Maui provider. This pr also covers populating the fields with the appropriate data.
The implementation
There are two areas that were changed to enable this support, firstly a new
RaygunMauiEnvironmentMessageclass was created that extends the raygun4net.coreRaygunEnvironmentMessageclass. This new class contains the extra fields mentioned above. Secondly aRaygunClientTest(this name is only temporary) class was created extendingRaygunClient. This class overrides theBuildMessagemethod, adding custom code to build the message with the newRaygunMauiEnvironmentMessageclass.Note
This PR proposes a approach to building the
RaygunMessagethat breaks from convention. Typically builder classes have been used to create and populate the message and its child classes. This is how it is done inside the Raygun4net.core provider.My argument against this approach is that this creates unnecessary abstractions away from the data. Many of the builder methods just taking in a field as a parameter and store it inside of the underlying data structure, I propose eliminating the middle layer and instead to work with the data its self. In my approach the objects are explicitly created and populated, this makes it very clear what is going on and makes it very easy to modify in the future. With the builder approach, if you want to change one of the underlying datatypes, for example the
RaygunEnvironmentMessage, you then have to change theRaygunEnvironmentMessageBuilderand theRaygunMessageBuilder. With this approach you simply have to change theEnvironmentMessageobject you are creating and populate any extra fields. Given how small the code is to explicitly construct the objects without the builder I do not believe this is a concern that needs to be split of into its own classes. KISSAuthor to check:
Reviewer to check: