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

feat: Added screen name to app context #3346

Merged
merged 55 commits into from
Nov 10, 2023
Merged

Conversation

brustolin
Copy link
Contributor

@brustolin brustolin commented Oct 17, 2023

📜 Description

Add screens name to app context

💡 Motivation and Context

close #3140

💚 How did you test it?

Unit tests

📝 Checklist

You have to check all boxes before merging:

  • I reviewed the submitted code.
  • I added tests to verify the changes.
  • No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
  • I updated the docs if needed.
  • Review from the native team if needed.
  • No breaking change or entry added to the changelog.
  • No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

@github-actions
Copy link

github-actions bot commented Oct 17, 2023

Messages
📖 Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 85f4d9e

@codecov
Copy link

codecov bot commented Oct 17, 2023

Codecov Report

Merging #3346 (85f4d9e) into main (734d507) will decrease coverage by 0.083%.
The diff coverage is 64.351%.

Impacted file tree graph

@@              Coverage Diff              @@
##              main     #3346       +/-   ##
=============================================
- Coverage   89.068%   88.986%   -0.083%     
=============================================
  Files          520       520               
  Lines        55884     56293      +409     
  Branches     19857     20259      +402     
=============================================
+ Hits         49775     50093      +318     
- Misses        5195      5283       +88     
- Partials       914       917        +3     
Files Coverage Δ
Sources/Sentry/SentryClient.m 97.649% <100.000%> (+0.061%) ⬆️
Sources/Sentry/SentryDispatchQueueWrapper.m 100.000% <100.000%> (ø)
Sources/Sentry/SentryTracer.m 96.276% <100.000%> (+0.205%) ⬆️
Tests/SentryTests/SentryClientTests.swift 95.962% <94.736%> (-0.061%) ⬇️
Sources/Sentry/SentryUIApplication.m 54.166% <31.775%> (-39.276%) ⬇️

... and 64 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 734d507...85f4d9e. Read the comment docs.

@github-actions
Copy link

github-actions bot commented Oct 17, 2023

Performance metrics 🚀

  Plain With Sentry Diff
Startup time 1210.71 ms 1221.37 ms 10.65 ms
Size 22.85 KiB 414.99 KiB 392.14 KiB

Baseline results on branch: main

Startup times

Revision Plain With Sentry Diff
7a7de19 1251.30 ms 1266.94 ms 15.64 ms
46f5eb8 1200.09 ms 1231.38 ms 31.29 ms
7f14650 1249.73 ms 1269.88 ms 20.14 ms
69d8759 1229.88 ms 1240.45 ms 10.57 ms
39b1c35 1244.71 ms 1248.60 ms 3.89 ms
f4e0299 1230.33 ms 1249.68 ms 19.35 ms
83d2d84 1211.31 ms 1227.34 ms 16.03 ms
01a28a9 1237.24 ms 1253.24 ms 16.00 ms
621ba9b 1190.66 ms 1230.84 ms 40.18 ms
ab6fee4 1227.63 ms 1239.80 ms 12.17 ms

App size

Revision Plain With Sentry Diff
7a7de19 20.76 KiB 435.64 KiB 414.88 KiB
46f5eb8 20.76 KiB 432.37 KiB 411.61 KiB
7f14650 22.84 KiB 402.63 KiB 379.79 KiB
69d8759 20.76 KiB 393.05 KiB 372.29 KiB
39b1c35 22.85 KiB 408.88 KiB 386.03 KiB
f4e0299 20.76 KiB 427.54 KiB 406.78 KiB
83d2d84 20.76 KiB 419.66 KiB 398.90 KiB
01a28a9 22.85 KiB 405.39 KiB 382.54 KiB
621ba9b 20.76 KiB 414.45 KiB 393.69 KiB
ab6fee4 22.84 KiB 401.67 KiB 378.83 KiB

Previous results on branch: feat/screen-name-events

Startup times

Revision Plain With Sentry Diff
d0ecf51 1230.45 ms 1242.73 ms 12.29 ms
1e297a8 1204.14 ms 1227.54 ms 23.40 ms
6086f29 1222.51 ms 1233.80 ms 11.29 ms
6ef1209 1245.68 ms 1250.68 ms 5.00 ms
bc12022 1232.84 ms 1259.57 ms 26.73 ms
d94450c 1234.14 ms 1251.32 ms 17.18 ms
2c15262 1236.59 ms 1240.00 ms 3.41 ms
3ad9ba7 1261.61 ms 1276.48 ms 14.87 ms
750145f 1262.98 ms 1276.68 ms 13.70 ms
ad03b34 1236.80 ms 1243.32 ms 6.52 ms

App size

Revision Plain With Sentry Diff
d0ecf51 22.85 KiB 414.25 KiB 391.41 KiB
1e297a8 22.85 KiB 413.21 KiB 390.36 KiB
6086f29 22.85 KiB 414.99 KiB 392.14 KiB
6ef1209 22.85 KiB 414.37 KiB 391.52 KiB
bc12022 22.85 KiB 413.21 KiB 390.36 KiB
d94450c 22.85 KiB 414.20 KiB 391.35 KiB
2c15262 22.85 KiB 414.45 KiB 391.60 KiB
3ad9ba7 22.85 KiB 412.96 KiB 390.11 KiB
750145f 22.85 KiB 414.33 KiB 391.48 KiB
ad03b34 22.85 KiB 414.54 KiB 391.69 KiB

@brustolin brustolin changed the title Feat/screen name events feat: Added screen name to app context Oct 17, 2023
@brustolin brustolin marked this pull request as ready for review October 20, 2023 09:50
Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

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

As mentioned on Slack, I'm unsure about the general approach of this PR, and we need to discuss it before continuing.

CHANGELOG.md Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
Sources/Sentry/Public/SentryScope.h Outdated Show resolved Hide resolved
Sources/Sentry/SentryClient.m Outdated Show resolved Hide resolved
Tests/SentryTests/SentryClientTests.swift Outdated Show resolved Hide resolved
Sources/Sentry/SentryUIApplication.m Outdated Show resolved Hide resolved
Sources/Sentry/SentryUIApplication.m Outdated Show resolved Hide resolved
Sources/Sentry/SentryUIApplication.m Show resolved Hide resolved
Sources/Sentry/SentryUIApplication.m Outdated Show resolved Hide resolved
Sources/Sentry/SentryUIApplication.m Show resolved Hide resolved
Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

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

We still miss some UITests or tests for the code in SentryUIApplication. Apart from that, this already looks great.

Sources/Sentry/SentryTracer.m Show resolved Hide resolved
Sources/Sentry/SentryTracer.m Show resolved Hide resolved
* view controller for each screen. If the topmost view controller
* is a split view controller, all of its sides are reported.
*/
- (nullable NSArray<UIViewController *> *)relevantViewControllers;
Copy link
Member

Choose a reason for hiding this comment

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

m: I think this method can now be internal to SentryUIApplication. No other class is using it, they all use relevantViewControllersNames.

Copy link
Member

@philipphofmann philipphofmann left a comment

Choose a reason for hiding this comment

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

LGTM with a couple of minor suggestions.

/**
* A helper tool to retrieve informations from the application instance.
*/
@interface SentryUIApplication : NSObject
Copy link
Member

Choose a reason for hiding this comment

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

m: Why do we need this header file here? Please add a short comment with the explanation or remove it.

Copy link
Member

Choose a reason for hiding this comment

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

If it is needed here for some reason, we should use the one already in /Sources. See how SentryDevice.h/.mm are included in iOS-Swift/tvOS-Swift.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Adding the comment.
This is exposing private API for testing.

I rather have a copy of the header instead of using the same .h file because we have a better control of what is being exposed, and any change in the #imports in the original file wont affect the sample.

if ([containerVC isKindOfClass:UISplitViewController.class]) {
UISplitViewController *splitVC = (UISplitViewController *)containerVC;
if (splitVC.viewControllers.count > 0) {
return [splitVC viewControllers];
Copy link
Member

Choose a reason for hiding this comment

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

So are these false positives? I see the UI test for split VC. Maybe we're not generating coverage from sample app UI tests? Otherwise we might want to raise this with codecov.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Exactly, I don't think we generate coverage from UI Tests.

@philipphofmann
Copy link
Member

One final question just popped into my head. How expensive is the traversing of the UIViewControllers? Could it be that we slow down apps if they have a complex hierarchy of UIViewControllers, @brustolin? Are there any other risks involved with that PR? Should we maybe do a beta or are you confident to ship this PR right away?

If all answers to my questions are no, let's ship this 🚢 @brustolin

@armcknight
Copy link
Member

One final question just popped into my head. How expensive is the traversing of the UIViewControllers? Could it be that we slow down apps if they have a complex hierarchy of UIViewControllers, @brustolin? Are there any other risks involved with that PR? Should we maybe do a beta or are you confident to ship this PR right away?

If all answers to my questions are no, let's ship this 🚢 @brustolin

We could get a quick idea on this if we create a perf test that measures the routine and create a full tree with N children per node and check it with various depths. Some quick numbers:

  • 5 children per VC
    • 1 level: 5 vcs
    • 2 levels: 25 vcs
    • 3 levels: 125 vcs
    • 4 levels: 625 vcs

I can't quite imagine a view hierarchy with that many children VCs and layers, but iterating through 625 pointer references shouldn't take very long.

It's not possible to push a nav controller onto itself, but what if someone accidentally adds a view controller as a child of itself? Infinite loop? Any other possibilities for that here?

@brustolin
Copy link
Contributor Author

  • Its impossible to create a infinite loop of UI Elements.
  • The speed to navigate the view controller tree is as fast as accessing properties of an objects, and vc trees are not big.
  • I believe this is good to go

@brustolin brustolin merged commit e4cc043 into main Nov 10, 2023
69 of 71 checks passed
@brustolin brustolin deleted the feat/screen-name-events branch November 10, 2023 10:24
@philipphofmann
Copy link
Member

I can't quite imagine a view hierarchy with that many children VCs and layers, but iterating through 625 pointer references shouldn't take very long.

That's also my assumption. I would be surprised if it takes very long.

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.

Report as app context what's the current screen during the error
4 participants