- Notifications
You must be signed in to change notification settings - Fork 75
Add Screen-orientation instrumentation module #1333
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
Add Screen-orientation instrumentation module #1333
Conversation
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@ ## main #1333 +/- ## ========================================== - Coverage 64.12% 64.02% -0.10% ========================================== Files 154 157 +3 Lines 3063 3099 +36 Branches 316 318 +2 ========================================== + Hits 1964 1984 +20 - Misses 1009 1022 +13 - Partials 90 93 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
@RiyazurRazak thanks for the PR! It's exciting to see the instrumentation coverage expanding like this!
I want to request two changes:
First, can we remove the additional extractors? I know you're following a pattern that seems to exist elsewhere, but I think those other cases have specific uses in mind. In the case here, the Orientation class only has one field (value), so there is really no use case to having additional extractors (there's basically nothing they can do).
Second, let's work on tweaking the shape of the event. I think we should remove the body text entirely (it is redundant), and we should add an attribute that contains the orientation. Because I think there is not yet semantic convention for this, we have some wiggle room, but something like screen.orientation might be a reasonable starting key, and the value should be a string (portrait or landscape) because other systems (ios, web) may not have the same constants available, and it's more useful to have the strings.
There's also some merge conflicts that will need resolving/rebasing.
Thanks again!
| Thanks for the feedback, @breedx-splk. I’ll update the Event structure accordingly and remove the extractors. |
# Conflicts: # android-agent/src/main/kotlin/io/opentelemetry/android/agent/dsl/instrumentation/InstrumentationConfiguration.kt
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.
Thank you for your contribution! I think it's a great start, I just left a couple of comments.
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 don't need this file.
| } | ||
| | ||
| override fun uninstall(ctx: InstallationContext) { | ||
| if (!::detector.isInitialized) return |
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.
If we need to check whether some field is initialized or not, I prefer to make them nullable instead of resorting to the isInitialized check.
| ## Installation | ||
| | ||
| This instrumentation comes with the [android agent](../../android-agent) out of the box, so | ||
| if you depend on it, you don't need to do anything else to install this instrumentation. |
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.
Please add the dependency coordinates, in case someone isn't using the agent. This is an example of how we've added it to other instrumentations.
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.
Nice, thanks for following up. I think @LikeTheSalad has some good feedback as well, but I think we're close to a great start. I'd love to see the corresponding semantic conventions PR as well. Cheers!
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.
Thank you! 🙏
Resolves #932