[MBL-856] Banner For Creator Dashboard Deprecation

[scottkicks]

📲 What

A banner at bottom of dashboard notifying users of planned deprecation.

🤔 Why

We'd want to give users a heads up that features they may be used to seeing/using are going to be removed.

🛠 How

• Decided to build this view as a SwiftUI View.
• In order to add a SwiftUI view to a UIKit Storyboard, like the Dashboard, we need to add it via a UIHostingViewController as a subview and add constraints programmatically. This is pretty simple as you'll see in the code.
  • we could add using the existing storyboard, but I found that doing it programmatically like this will make it easier to review and remove once the dashboard is fully deprecated.

Important

• DashboardViewController is a UITableViewController. My understanding here is that TableViewControllers automatically add views to the scrollable content that it contains. Because we want this banner to be "sticky", my solution is to add it directly to the window. This also means that we need to make sure to manually call removeFromSuperview in viewWillDisappear so that it does not show anywhere else when switch tabs or presenting other screens.

👀 See

Trello, screenshots, external resources?

After 🦋 (iPhone 14)	iPhone 8 (smaller screen)

Translations

German	Spanish	French	Japanese

✅ Acceptance criteria

• The banner should match the designs we have in figma
• banner should be a sticky view. Meaning, it should be constrained to the top of the tab bar and should not move when scrolling the dashboard view behind it.
• Banner should not hide any of the content on the Dashboard view
• Banner should only show when the DashboardViewController is presented. If the Creator Dashboard ff is off, the dashboard as well as this new banner should never be seen.

⏰ TODO

• The translations for the copy here need to be added, but in order to keep our PRs smaller and easier to review I'll be making a new one to address that first.

[codecov]

Codecov Report

Merging #1830 (a7a6279) into main (71cf0a6) will decrease coverage by 0.04%.
The diff coverage is 18.18%.

@@            Coverage Diff             @@
##             main    #1830      +/-   ##
==========================================
- Coverage   84.37%   84.33%   -0.04%     
==========================================
  Files        1276     1277       +1     
  Lines      115816   115881      +65     
  Branches    30793    30810      +17     
==========================================
+ Hits        97714    97730      +16     
- Misses      17036    17084      +48     
- Partials     1066     1067       +1     

Impacted Files	Coverage Δ
...rdDeprecationBanner/DashboardDeprecationView.swift	0.00% <0.00%> (ø)
...Features/RootTabBar/RootTabBarViewController.swift	4.85% <0.00%> (+0.07%)	⬆️
...Dashboard/Controller/DashboardViewController.swift	50.83% <38.88%> (-2.11%)	⬇️

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[scottkicks]

@msadoon Since this view is being added directly to the window, see my comment here, the DashboardViewController snapshots will still pass as is since the banner isn't technically being added to it.

I think this is ok in this case because the feature will be removed in a month, but if you have ideas on how to capture this in our snapshot tests please lmk. I'm not sure how to reference the window itself, or if we even want to for this test case.

[msadoon]

Ok, try to remember not to assign PR's that are in "draft".

I pushed a commit that basically is all the changes I worked on and tested. It uses the basic structure you have here, but cleaned up the code a lot.

There's a lot of changes here so let's go over them on a call, I think its' more efficient that way. You can also question any of the things I've done and I'll be happy to explain them.

The only thing I missed was covering the bottom scrollable area with the banner. I don't think its' super important, but if you think it is, we can work on that in the call together.

In the future let's start with an engineering plan so we're on the same page about the approach before coding.

[msadoon]

Tests not passing. Let's fix in pairing.

[msadoon]

Tests should pass - I did write a few commits because this PR was just taking too long.
So my advice here is to look at this commits and really understand what the diffs are between commits and why.
Again always happy to jump on a call and address any questions you have.

Otherwise I think this is good to go.

Like I said earlier let's start with an engineering plan first to avoid all this back and forth.

[msadoon]

So the reason tests were failing was because these functions were outside the struct but declared as private. They had the same name as the functions outside ManagePledgePaymentMethodsViewModel which were also private and outside the class. So ManagePledgeViewControllerTests.testView_CurrentUser_IsBacker() is the test that was breaking, it is no longer because these functions don't collide anymore.

[msadoon]

I had to do some rework here to configure the logic around getting the tab bar styling, which was still breaking.
Basically the logic is now - if the app is styling the dashboard tab bar item, it should not be the last tab bar item. If it is, then style it as profile.
So the cases are:

1. Logged in as backer (creator dashboard flag ON or OFF):

• The setTabBarItemStyles function never gets its' tab bar item case enum passed in as dashboard, because the function that calls this one checks if the user is a member first.

2. Logged in as a creator (creator dashboard flag ON):

• If set in Beta tools as ON then go from backer --> creator, then the dashboard is visible.
• Turning this flag OFF in beta tools doesn't reflect the hiding of the dashboard until the user relaunches the app.

3. Logged in as a creator (creator dashboard flag OFF):

• If set in Beta tools as OFF then go from backer --> creator, then the dashboard is not visible.
• Turning this flag ON in beta tools doesn't reflect the showing of the dashboard until the user relaunches the app.

Validate my logic here. I tested it, but if you can find a missing step I'm happy to rework this.

[scottkicks]

Interesting that I didn't see this bug, but I've tested the current logic for all cases listed and the app is working as expected. Good to go 👍

[msadoon]

Found that the depecrationWarningHostingController.view.bounds always returns the height and all other dimensions as .zero if viewWillAppear is called, so need to wait until viewDidAppear is called for the views to have correct dimensions. That's why the self.tabBarController.tabBar.bounds.height was needed - because it existed before viewWillAppear on this view controller.

[scottkicks]

nice