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

BIT-155: Adds the landing screen and Auth module #20

Merged
merged 4 commits into from
Sep 12, 2023

Conversation

nathan-livefront
Copy link
Contributor

🎟️ Tracking

BIT-155

🚧 Type of change

  • 🚀 New feature development

📔 Objective

This PR adds a draft of the Landing screen. The UI for this screen is not final, and is only being added in its current state so that we can continue building out the app while the design team is finishing up the new designs. This draft was built with basic SwiftUI components that we can replace or style in a later PR.

In addition to adding the screen, I also added the scaffolding for navigating through the auth flow. Tapping any of the buttons on the landing screen will take the user to example screens that will be replaced in future PRs.

Note, the Bitwarden logo is missing from this screen, since the asset for the logo was added in #19. The logo will be added to this screen when the UI is updated to match the new designs.

📋 Code changes

  • AppRoute: Renamed the .onboarding route to .auth(AuthRoute) to support navigating to specific screens in the auth flow.
  • AuthRoute, AuthCoordinator, AuthModule: Files used to navigate between screens in the auth flow.
  • LandingView: The UI of the landing screen.
  • LandingProcessor, LandingState, LandingAction: Files used to support the functionality of the landing screen.

📸 Screenshots

RocketSim_Recording_iPhone_14_Pro_2023-09-05_16.52.26.mp4

⏰ Reminders before review

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation or informed the documentation team

🦮 Reviewer guidelines

  • 👍 (:+1:) or similar for great changes
  • 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
  • ❓ (:question:) for questions
  • 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
  • 🎨 (:art:) for suggestions / improvements
  • ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
  • 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
  • ⛏ (:pick:) for minor or nitpick changes

@bitwarden-bot
Copy link

bitwarden-bot commented Sep 6, 2023

Logo
Checkmarx One – Scan Summary & Details142dfd01-fca4-42b8-82eb-a27731eafb89

No New Or Fixed Issues Found

@github-actions
Copy link
Contributor

github-actions bot commented Sep 6, 2023

2 Warnings
⚠️ Total coverage less than 80%
⚠️ GlobalTestHelpers/MockAppModule.swift has less than 80% code coverage

Code coverage

Total coverage: 47.87%

File Coverage
GlobalTestHelpers/MockAppModule.swift 0.00%
GlobalTestHelpers/MockAppModule.swift 0.00%
GlobalTestHelpers/MockAppModule.swift 0.00%

Powered by Slather

Generated by 🚫 Danger

Comment on lines +17 to +25
override func setUp() {
super.setUp()
rootNavigator = MockRootNavigator()
stackNavigator = MockStackNavigator()
subject = AuthCoordinator(
rootNavigator: rootNavigator,
stackNavigator: stackNavigator
)
}
Copy link
Member

Choose a reason for hiding this comment

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

🤔 Should tests be added with rootNavigator being nil? Not sure which would be the real case where the AuthCoordinator receives a nil root value but if I'm not mistaken it's currently feasible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch! That is something that is currently feasible, so I'll add tests for that.

Copy link
Contributor Author

@nathan-livefront nathan-livefront Sep 7, 2023

Choose a reason for hiding this comment

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

On second thought, I'm going to change rootNavigator to not be optional. I can't think of a real-world use case for it being nil, since the auth flow will always need to be displayed within another context. So I'll update this property and not add any tests!

Scratch all this 🤦‍♂️ rootNavigator is optional because the variable is weak, I've added a test that validates that AuthCoordinator does not retain a strong reference to rootNavigator!

Copy link
Member

Choose a reason for hiding this comment

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

oh that makes perfect sense, thanks!

Copy link
Member

@fedemkr fedemkr Sep 7, 2023

Choose a reason for hiding this comment

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

Just one final question @nathan-livefront, is it possible that if the weak reference is lost, the caller can execute func navigate(to route: AuthRoute, context: AnyObject?) and if so, would you foresee any problems? I guess the stackNavigator would be still in memory so the action could be executed but nothing will be seen by the user given that I assume the rootNavigator won't be in screen if the reference has been lost.
Does it makes sense to add tests for when rootNavigator is nil for start and navigate?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

While it is possible for the caller to execute the navigate and start methods on an instance of AuthCoordinator while rootNavigator is nil, I don't think it's necessarily worth testing in this case.

rootNavigator is weak because the rootNavigator is a property of the parent that is displaying AuthCoordinator. We want this property to be weak so that AuthCoordinator does not strongly hold a reference to its parent (and thus create a circular reference/memory leak).

The only time that rootNavigator would be nil is if AuthCoordinator's parent was no longer being displayed, but a reference to AuthCoordinator was still retained somewhere. In that case, you are totally correct. Both the start and navigate methods could technically be called on AuthCoordinator, but they would have no visible effect if AuthCoordinator's stackNavigator is not being displayed.

@nathan-livefront nathan-livefront merged commit 416a672 into main Sep 12, 2023
@nathan-livefront nathan-livefront deleted the nathan/BIT-155-landing-screen branch September 12, 2023 01:36
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.

3 participants