feat(user feedback): display a button in a window that presents a vc

[armcknight]

#skip-changelog; for #4270

Deliver a complete styled button like we have in the javascript SDK docs that opens a modal view where the form will go in a subsequent PR.

Check the linked issue for updates on what it looks like with various config settings and device settings like for accessibility and dark mode.

[brustolin]

h: We can debate it later, but currently we're organising Swift code under Swift folder, so

This	Should be here

You can keep the Obj-C integration here, but the file itself is in the wrong directory. The header should be in the include path, and the .m file in the Sentry folder. This organization relates to how we distribute via CocoaPods and, in the future, SPM, when we move back to sharing code instead of a pre-compiled framework.

Edit: I realized these files were included in a previous PR. We can either fix it in this one or in another one.

[armcknight]

The diff is currently a little over 500 lines added, note that half of that is just the UIBezier drawing the megaphone that I got from our SVG design asset :D

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1225.29 ms	1242.58 ms	17.29 ms
Size	21.90 KiB	724.52 KiB	702.62 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
0ecf042	1228.25 ms	1250.67 ms	22.42 ms
0d32275	1230.96 ms	1237.90 ms	6.94 ms
e0f077c	1224.65 ms	1243.52 ms	18.87 ms
af1f4dd	1207.33 ms	1230.04 ms	22.71 ms
7bc3c0d	1212.35 ms	1228.94 ms	16.59 ms
3f366ee	1242.28 ms	1260.80 ms	18.52 ms
cb6ab62	1213.47 ms	1248.46 ms	34.99 ms
42ef6ba	1219.58 ms	1245.37 ms	25.78 ms
b9d59f7	1222.23 ms	1227.16 ms	4.93 ms
888a145	1228.63 ms	1248.94 ms	20.30 ms

App size

Revision	Plain	With Sentry	Diff
0ecf042	21.58 KiB	631.82 KiB	610.24 KiB
0d32275	22.84 KiB	403.14 KiB	380.29 KiB
e0f077c	22.85 KiB	412.59 KiB	389.74 KiB
af1f4dd	22.85 KiB	414.71 KiB	391.86 KiB
7bc3c0d	20.76 KiB	427.35 KiB	406.59 KiB
3f366ee	20.76 KiB	427.84 KiB	407.08 KiB
cb6ab62	22.85 KiB	413.42 KiB	390.57 KiB
42ef6ba	21.58 KiB	417.86 KiB	396.28 KiB
b9d59f7	22.85 KiB	405.77 KiB	382.92 KiB
888a145	21.58 KiB	713.54 KiB	691.96 KiB

Previous results on branch: armcknight/feat(user-feedback)/widget

Startup times

Revision	Plain	With Sentry	Diff
77b46c1	1239.90 ms	1259.65 ms	19.76 ms
27fdb5f	1224.61 ms	1247.08 ms	22.47 ms
04583b1	1217.31 ms	1234.60 ms	17.28 ms
9a094af	1236.98 ms	1260.67 ms	23.70 ms

App size

Revision	Plain	With Sentry	Diff
77b46c1	21.90 KiB	723.83 KiB	701.93 KiB
27fdb5f	21.90 KiB	724.61 KiB	702.71 KiB
04583b1	21.90 KiB	724.61 KiB	702.71 KiB
9a094af	21.90 KiB	724.61 KiB	702.71 KiB

[brustolin]

For default values, we should respect iOS assessibility values:

This:

Should be:

In this configuration

[brustolin]

This need to be addressed before merging the PR.

[brustolin]

Just a suggestion for the megaphone drawing

[brustolin]

l: This is just a suggestion to use alongside the megaphoneShape suggestion.
Feel free to ignore it

Suggested change

	svgLayer.path = megaphoneShape
	func configureLightTheme() {
	svgLayer.fillColor = config.theme.foreground.cgColor
	}
	if #available(iOS 12.0, *) {
	if UIScreen.main.traitCollection.userInterfaceStyle == .dark {
	svgLayer.fillColor = config.darkTheme.foreground.cgColor
	} else {
	configureLightTheme()
	}
	} else {
	configureLightTheme()
	}
	svgLayer.fillRule = .evenOdd
	svgLayer.path = megaphoneShape
	svgLayer.lineWidth = 1.5
	svgLayer.lineJoin = .round
	svgLayer.fillColor = UIColor.clear.cgColor
	func configureLightTheme() {
	svgLayer.strokeColor = config.theme.foreground.cgColor
	}
	if #available(iOS 12.0, *) {
	if UIScreen.main.traitCollection.userInterfaceStyle == .dark {
	svgLayer.fillColor = config.darkTheme.foreground.cgColor
	} else {
	configureLightTheme()
	}
	} else {
	configureLightTheme()
	}

[brustolin]

l: I love the idea of drawing like this.

You can achieve a very similar result with the following code:

lazy var megaphoneShape: CGPath = {
        let path = CGMutablePath()
        
        path.move(to: CGPoint(x: 1, y: 3))
        path.addLine(to: CGPoint(x: 7, y: 3))
        path.addLine(to: CGPoint(x: 10, y: 1))
        path.addLine(to: CGPoint(x: 12, y: 1))
        path.addLine(to: CGPoint(x: 12, y: 11))
        path.addLine(to: CGPoint(x: 10, y: 11))
        path.addLine(to: CGPoint(x: 7, y: 9))
        path.addLine(to: CGPoint(x: 1, y: 9))
        path.closeSubpath()
        
        path.addRect(CGRect(x: 2, y: 9, width: 3.5, height: 6))
        
        path.move(to: CGPoint(x: 12, y: 6))
        path.addRelativeArc(center: CGPoint(x: 12, y: 6), radius: 3, startAngle: -(.pi/2), delta: .pi)
        
        return path
    }

Before	After

[armcknight]

I will let @Jesse-Box or @vuluongj20 comment on this. But it would make it much easier to vary the width if we decide to do so as I mentioned in Slack recently.

[armcknight]

I think i'm just gonna go with the simpler version and if anyone doesn't like it, we can always revert. Thanks @brustolin

[armcknight]

@brustolin accessibility sizes and right-to-left languages are known tasks: #4270 (comment)

I already have right-to-left support going after i linked the PR last night, see the latest update in the issue: #4270 (comment) with the implementation work in abc5119

and added dynamic type support in be4eb19: #4270 (comment)

[armcknight]

I think configureTheme, should be inside configureWidget, or at least the properties that configure the widget, it took me an extra second to find this out, when it would be much easier to set the widget theme inside the configureWidget callback

This can be debated separately from this PR if people want to. I'll just note here that theme options will also be needed in the form, so I tried creating a composition hierarchy that indicates they are used by more than just the widget (button):

Since the widget and form will use a lot of the same options I don't think it makes sense to make separate theme objects for each to own separately.

[armcknight]

This need to be addressed before merging the PR.

@brustolin Would you mind if we do it in a separate PR along with #4364 (comment)? I just don't want to mess the diff up here. Nothing is being shipped yet so there's no danger of a file not being delivered where it should be.

ETA: unless it's required for CI to pass anyways, that is...
ETA2: doesn't seem so, so i'd prefer to defer this

[brustolin]

@brustolin Would you mind if we do it in a separate PR along with #4364 (comment)? I just don't want to mess the diff up here. Nothing is being shipped yet so there's no danger of a file not being delivered where it should be.

Are you planning to merge this PR back to main without the form ready? If we make another release in the meantime, users will be able to show the button but it won't be working? What is the release plan/timeline for this?

I would happily agree to have a feature branch where we can merge this and any other partial work of user feedback.

[armcknight]

@brustolin Would you mind if we do it in a separate PR along with #4364 (comment)? I just don't want to mess the diff up here. Nothing is being shipped yet so there's no danger of a file not being delivered where it should be.

Are you planning to merge this PR back to main without the form ready? If we make another release in the meantime, users will be able to show the button but it won't be working? What is the release plan/timeline for this?

I would happily agree to have a feature branch where we can merge this and any other partial work of user feedback.

@brustolin yes, then plan is to merge to main for each PR. The option is currently in SentryOptions+Private so they should not be able to get a widget showing in their app.

[brustolin]

@brustolin yes, then plan is to merge to main for each PR. The option is currently in SentryOptions+Private so they should not be able to get a widget showing in their app.

Ok, good enough for me. Thanks!

[brustolin]

I have my reservations about the composition of theme configuration, but this is not a blocker.

LGTM

[brustolin]

l: Why was this changed?
Just curious.