Allow to dynamically load and unload Modules #105
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #105 +/- ##
==========================================
+ Coverage 84.97% 87.93% +2.96%
==========================================
Files 41 42 +1
Lines 951 1217 +266
==========================================
+ Hits 808 1070 +262
- Misses 143 147 +4
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
…le is unloaded
Supereg
changed the title
|
There is still one oversight where viewModifiers are not removed yet. However, the PR is generally reviewable 👍 |
PSchmiedmayer
approved these changes
Jun 4, 2024
There was a problem hiding this comment.
Nice job; great to see that @Supereg!
Thanks for addressing this and once the view modifiers are removed; great addition to Spezi! 💪
1 task
Supereg
added a commit
to StanfordSpezi/SpeziBluetooth
that referenced
this pull request
Jun 5, 2024
# Inject Bluetooth Devices as Spezi Modules ## ♻️ Current situation & Problem `BluetoothDevice`s were previously inaccessible from Spezi `Module`s without additional infrastructure. StanfordSpezi/Spezi#105 introduced functionality to dynamically load and unload Modules from the Spezi module systems. We use that new infrastructure to make every `BluetoohtDevice` to be a Spezi Module. This allows every `BluetoothDevice` to use the same functionality available to Spezi Modules. Further, Spezi Modules can seamlessly interact with `BluetoothDevice` as well. ## ⚙️ Release Notes * `BluetoothDevice`s are now Spezi `Module`s. ## 📚 Documentation Additional documentation section was added. ## ✅ Testing Verified in Engage. ## 📝 Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md).
1 task
1 task
Supereg
added a commit
that referenced
this pull request
Jul 23, 2024
# Allow to load multiple modules of the same type ## ♻️ Current situation & Problem Currently, Spezi enforces that there is maximum one module of the same type loaded at a time. By allowing the Module system to used much more dynamically via #105, we found that certain types of Modules might exist multiple times in the system (e.g., a Bluetooth device type modeled as a Spezi Module might have two physical devices connected at the same time). This PR makes the necessary infrastructure changes to support loading multiple modules of the same type. A check that the same module can only be loaded once is still in place. Restructuring the `@Dependency` to support multiple modules of the same type is not trivial and will be addressed in a follow-up PR which is tracked in #111. ## ⚙️ Release Notes * Allow to load multiple modules of the same type. ## 📚 Documentation -- ## ✅ Testing Additional unit testing was added to verify behavior. ## 📝 Code of Conduct & Contributing Guidelines By submitting creating this pull request, you agree to follow our [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md): - [x] I agree to follow the [Code of Conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) and [Contributing Guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allow to dynamically load and unload Modules
♻️ Current situation & Problem
Currently, the collection of Modules must be defined at application start and cannot be modified later on. This PR modifies the current infrastructure to allow to dynamically load and unload modules. This functionality was identified to be useful with SpeziBluetooth (e.g., making
BluetoothDevices automatically conform toModuleand allowing native and out of the box support for Spezi property wrappers). Similar SpeziAccount has a similar use case, where theAccountinstance itself can be made aModulemaking easy access to the current Account possible outside of the SwiftUI view hierarchy.Note:
@Collectand@Provideproperties are a bit tricky with dynamic loading and unloading. However, I think the PR introduces a relatively elegant solution for that. Upon module loading all@Collectproperties are updated with new values from the@Provideproperties of the loaded module. At the same time, these values are removed again if a module with a@Provideproperty is unloaded. There is currently no mechanism for Modules to detect if the value of a@Collectproperty changed and this is generally unexpected as per documentation. Therefore, no module makes use of this. We will need to evaluate if this is a use case at all (e.g., dynamically adding new account services) and if there is maybe generally a better approach for module inter-communication that better flows with dynamic loading and unloading of modules (@Provideand@Collectare currently, to my knowledge, only really used with SpeziAccount).⚙️ Release Notes
@Application(\.spezi)property to access the global Spezi instance.Spezi/loadModule(_:)method.Spezi/unloadModule(_:)method.📚 Documentation
Documentation catalog was updated to reflect new symbols. A small example was added in the
Spezitype documentation providing an example on how to load a module.✅ Testing
Unit tests were added to test the new functionality.
📝 Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines: