Currently, we assume a single account is always managed by a single Account Service. Some account providers like Firebase allow for a single account to be managed by multiple credentials (e.g., using password and single sign on providers like Google or Apple). A user should be able to configure that after his initial signup in their Account Overview.
Problem
This concepts currently doesn't perfectly map to SpeziAccount. We always assume a single Account Service to be responsible.
Solution
We need to rethink how we want to map this scenario to SpeziAccount.
Do we want to allow for arbitrary combination of Account Services? Usually, if two Account Services are wanted to link to the same user account, they are using the same account provider in the backgrounds (e.g. Firebase is a single thing!). The same would apply to a custom implementation.
One solution could be to reengineer Firebase such that it exposes only a single Account Service, but one that is capable of exposing multiple different signup UIs. This would require to introduce another abstraction level, the Account Service (e.g. Firebase) vs. the Account Provider (e.g., E-Mail-Password, Apple) with each of them being visualized in the UI separately.
Alternatives considered
Not introducing the above-presented abstraction layer, would require us to allow for arbitrarily mixing Account Services. This would heavily complicated how state is managed (maintaining multiple unique user ids, etc.). Therefore, this seems to not be the way to go.
Additional context
No response
Code of Conduct
[X] I agree to follow this project's Code of Conduct and Contributing Guidelines
Use Case
Currently, we assume a single account is always managed by a single Account Service. Some account providers like Firebase allow for a single account to be managed by multiple credentials (e.g., using password and single sign on providers like Google or Apple). A user should be able to configure that after his initial signup in their Account Overview.
Problem
This concepts currently doesn't perfectly map to SpeziAccount. We always assume a single Account Service to be responsible.
Solution
We need to rethink how we want to map this scenario to SpeziAccount.
Do we want to allow for arbitrary combination of Account Services? Usually, if two Account Services are wanted to link to the same user account, they are using the same account provider in the backgrounds (e.g. Firebase is a single thing!). The same would apply to a custom implementation.
One solution could be to reengineer Firebase such that it exposes only a single Account Service, but one that is capable of exposing multiple different signup UIs. This would require to introduce another abstraction level, the Account Service (e.g. Firebase) vs. the Account Provider (e.g., E-Mail-Password, Apple) with each of them being visualized in the UI separately.
Alternatives considered
Not introducing the above-presented abstraction layer, would require us to allow for arbitrarily mixing Account Services. This would heavily complicated how state is managed (maintaining multiple unique user ids, etc.). Therefore, this seems to not be the way to go.
Additional context
No response
Code of Conduct