Rethought Account Service Model with reimagined Account Setup and new Account Overview

[Supereg]

Unified Account View with rethought Account Service Model

♻️ Current situation & Problem

Currently, SepziAccount exposes two distinct views: Login and SignUp. While visually identical (expect for customizations), the AccountService buttons navigate to the respective Login or SignUp views for data entry. This introduces several navigation steps for the user even for simple workflows (e.g. just signing in a returning user).
Further, it is not clear where to place Identity Provider buttons (e.g., Sign in with Apple), as these create a new account or just sign you in to your existing one with the same, single button.

💡 Proposed solution

This PR makes the following changes:

• Unifying Login and SignUp views to be represented by a single view, placing identity providers on the same page as regular Account Services, the AccountSetup view.
• Restructure the Account Service Model:
  • Make the necessary preparations to support third-party Identity providers
  • Introduce the concept of an EmbeddableAccountService and a new KeyPasswordBasedAccountService as new abstraction layers.
    This replaces the current UsernamePasswordAccountService and EmailPasswordAccountService implementations. Those we really only Mock implementations which provided extensibility through class inheritance. This was replaced by providing the same functionality with a hierarchy of protocols being more powerful and providing much more flexibility. Further, we introduce new Mock Account services (e.g., used by PreviewProviders) which more clearly communicate their use through their updated name.
  • Move the UI parts of an AccountService out into a distinct abstraction layer (AccountSetupViewStyles).
• Introduce the Account Value (through AccountKey implementations) abstraction to support arbitrary account values
  • They provide a name, a category (for optimized placement in the UI), and a initial value
  • The provide the UI components do display (DataDisplayView) and setup or edit (DataEntryView) account values
  • The provide easy to use accessors using extensions on AccountKeys and AccountValues
• Optimized API surface for end-users:
  • Exposes the signedIn published property (same as previously)
  • Exposees the details shared repository to access the AccountDetails of the currently logged in use. This also provides access to the AccountService and its configuration that was used to setup the user account.
• Provide a new AccountOverview view:
  • Allows to view arbitrary account values
  • Allows to edit arbitrary account values
  • Provide Logout and account Removal functionality
• Enabled through Component communication Spezi#72, one can easily configure SpeziAccount centrally while other configured components can provide their AccountServices via Component Communication.

This PR tries to provide extensive documentation for all areas.

To provide some insights into the new user-facing API surface.

This is how you would configure Spezi Account now:

class YourAppDelegate: SpeziAppDelegate {
    override var configuration: Configuration {
        AccountConfiguration(configuration: [
            // the user defines what account values are used and if they are `required`, `collected` or just `supported`
            .requires(\.userId),
            .requires(\.password),
            .requires(\.name),
            .collects(\.dateOfBirth),
            .collects(\.genderIdentity)
        ])
    }
}

Below is an example on how to use the account setup view:

struct MyOnboardingView: View {
    var body: some View {
        AccountSetup {
           NavigationLink {
               // ... next view if already signed in
           } label: {
               Text("Continue")
           }
        }
    }
}

Lastly, the account overview is equally as easy to use:

struct MyView: View {
    var body: some View {
        AccountOverview()
    }
}

⚙️ Release Notes

• New, unified AccountSetup view
• New AccountOverview view
• Introduce new AccountService abstraction
• Support arbitrary account values through AccountKey-based shared repository implementation

➕ Additional Information

Related PRs and Issues

• This PR provides the groundwork necessary for Support for Single Sign On via Identity Providers SpeziFirebase#7
• The updated Firebase implementation: Upgrade to SpeziAccount 0.5.0 with account edit and removal support SpeziFirebase#8

Testing

Substantial UI tests were updated and added.

Reviewer Nudging

As this is quite a large PR it would make sense to start reviewing by reading through the documentation. First of all reviewing the documentation itself (structure and readability). Code example on the DocC article already explain a lot of the concepts.
The areas that sparked your attention, where you think that something is off or hard to understand, I would recommend to deep dive into the respective code area.

Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[codecov]

Codecov Report

Merging #7 (e13b1f2) into main (e5f8db6) will increase coverage by 0.04%.
The diff coverage is 76.44%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main       #7      +/-   ##
==========================================
+ Coverage   76.19%   76.22%   +0.04%     
==========================================
  Files          25      112      +87     
  Lines        1352     3839    +2487     
==========================================
+ Hits         1030     2926    +1896     
- Misses        322      913     +591     

Files Changed	Coverage Δ
...Account/AccountService/AccountServiceBuilder.swift	0.00% <0.00%> (ø)
...ountSetupViewStyle/IdentityProviderViewStyle.swift	0.00% <0.00%> (ø)
...ources/SpeziAccount/AccountValue/AccountKeys.swift	0.00% <0.00%> (ø)
...Configuration/AccountValueConfigurationError.swift	0.00% <0.00%> (ø)
...eziAccount/AccountValue/Keys/EmailAddressKey.swift	0.00% <0.00%> (ø)
...SpeziAccount/AccountValue/RequiredAccountKey.swift	0.00% <0.00%> (ø)
...s/SpeziAccount/Mock/MockSimpleAccountService.swift	0.00% <0.00%> (ø)
...ccount/Mock/MockUserIdPasswordAccountService.swift	0.00% <0.00%> (ø)
Sources/SpeziAccount/ViewModel/ViewSizing.swift	0.00% <0.00%> (ø)
...ue/Configuration/AccountKeyConfigurationImpl.swift	29.63% <29.63%> (ø)
... and 102 more

---

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 e5f8db6...e13b1f2. Read the comment docs.

[PSchmiedmayer]

@Supereg Thank you for all the great improvements and comments. I went through all of them and added some more context. Let me know if you need any further input here, a great job! 🚀

[Supereg]

In regard to your original comment

There are a lot of public interfaces that might be necessary for developers building account services but might not be necessary for people who want to use the Package in their application. I think it would make a lot of sense to hide a lot of these protocols and views that might not be needed for everyone into a separate SPI interface for now: https://github.com/apple/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md#_spispiname. I could imagine that we have 1-2 separate SPI interfaces that hide internal elements that must be public but are not needed to ever be used or adopted and one interface for developers who want to build their own Account Service. I think we can be a bit protective now and eventually move things up as we learn about the usage in the community and different applications.

Testing this approach it doesn't really work in our situation. E.g. I would mark the AccountServiceConfiguration as @_spi(AccountService). However, this will induce a requirement on AccountService to be marked @_spi(AccountService) as well. So far so good. Then however, the Account type is required to be marked @_spi(AccountService) as well, because the Account initializers are using the AccountService types as well. We could mark only the initializers to be part of the SPI. This would kind of complicate the import statements for apps that use the Account inits in their previews. Generally, doing @_spi(AccountService) becomes a hassle. While we could kind of resolve the issue with the Account type, the AccountConfiguration type uses the AccountService protocol in it's initializer which is intended to be used by the user and should not be placed into the SPI.
AFAIK, the SPI interfaces have to strictly separated and seemingly isn't really a good fit for our problem. Or am I missing something? Going forward, I think it makes much more sense to just split up the API surface into different targets. Declaring something SPI instead of API which is clearly API (just for a different target audience) doesn't seem right to me.

[PSchmiedmayer]

@Supereg Thank you for the SPI comment! Makes sense and thank you for taking a look at this. I would be fine with moving things out into separate targets, that sounds good to me 👍
Could even allow us to have a structure like this:

1. AccountService (everything you need to build an account service)
2. Mock Account Service (depends on Account Service)
3. Account Module (only @_implementationOnly imports Mock Account for the previews, and imports AccountService while only exposing (not sure if @_implementationOnly would work there, otherwise we just normally import it which only results into a few types being exposed)

What do you think about this idea? What do you think about tracking that in a separate issue? :)

[Supereg]

What do you think about this idea? What do you think about tracking that in a separate issue? :)

I'm currently tracking this within #19, if that is fine.