Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/sentry/sentry-docs/c9jhzib2k/sentry.dev |
| </application> | ||
| ``` | ||
|
|
||
| Or, if you are manually instrumenting Sentry: |
There was a problem hiding this comment.
Opting in to tracing with the sampling decision isn't really related to manual vs auto instrumentation (we can start capturing transactions automatically if we are able to if the users set a sampling decision in):
| Or, if you are manually instrumenting Sentry: | |
| Or, if you are initializing the SDK programatically: |
There was a problem hiding this comment.
this was the wording defined by the docs team about "auto init mode" vs "initializing the SDK by yourself".
I'd stick to it or we'd need to change everywhere, otherwise, only this page would differ.
it's not really related to tracing, but if you have the auto init mode or not
|
|
||
| Or, if you are manually instrumenting Sentry: | ||
|
|
||
| ```java {tabTitle:Java} |
There was a problem hiding this comment.
What about having Kotlin first?
Maybe better as a single PR across all of docs, right?
There was a problem hiding this comment.
I'd say so, also would need checking if docs somehow would order alphabetically or not
| </application> | ||
| ``` | ||
|
|
||
| Or, if you are manually instrumenting Sentry: |
There was a problem hiding this comment.
| Or, if you are manually instrumenting Sentry: | |
| Or, if you are initializing the SDK programatically: |
|
|
||
| SentryAndroid.init(this, | ||
| options -> { | ||
| ... |
There was a problem hiding this comment.
this is in all the performance Java/Kotlin examples, if we decide to remove it, I'd do a single PR.
|
@maciejwalkowiak I've changed a few scripts to be compatible with the new code like using interfaces instead of the implementation class, also nullability checks, added imports, and returning Doubles instead of Ints otherwise it'd never compile. |
maciejwalkowiak
left a comment
There was a problem hiding this comment.
Looks good to me.
|
|
||
| The next example contains the implementation of the hypothetical `processItem` function called from the code snippet in the previous section. Our SDK can determine if there is currently an open transaction and add all newly created spans as child operations to that transaction. Keep in mind that each individual span also needs to be manually finished; otherwise, spans will not show up in the transaction. | ||
|
|
||
| In cases where you want to attach Spans to an already ongoing Transaction you can use `Sentry#getSpan`. This method will return a `SentryTransaction` in case there is a running Transaction or a `Span` in case there is already a running Span, otherwise it returns `null`. |
There was a problem hiding this comment.
@maciejwalkowiak should we still keep SentryTransaction and Span or just ISpan?
|
|
||
| ### Retrieving a Transaction | ||
|
|
||
| In cases where you want to attach Spans to an already ongoing Transaction you can use `Sentry#getSpan`. This method will return a `SentryTransaction` in case there is a running Transaction or a `Span` in case there is already a running Span, otherwise it returns `null`. |
There was a problem hiding this comment.
Add Performance docs for Android
Also fixes #2849