### SwiftUI App Setup with Spezi

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Initial Setup.md

Integrates the Spezi framework into your SwiftUI application's main `App` instance. This involves using the `@ApplicationDelegateAdaptor` property wrapper to connect a custom `SpeziAppDelegate` and applying the `.spezi()` view modifier to your main view.

```swift
import Spezi
import SwiftUI


@main
struct ExampleApp: App {
    @ApplicationDelegateAdaptor(ExampleAppDelegate.self) var appDelegate

    var body: some Scene {
        WindowGroup {
            ContentView()
                .spezi(appDelegate)
        }
    }
}
```

--------------------------------

### SpeziAppDelegate Configuration

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Initial Setup.md

Defines the Spezi configuration by specifying the `Standard` and `Module`s used in your project. This example shows how to initialize `SpeziHealthKit` and collect step count data, conditionally based on HealthKit availability.

```swift
import HealthKit
import Spezi
import SpeziHealthKit


class ExampleAppDelegate: SpeziAppDelegate {
    override var configuration: Configuration {
        Configuration(standard: ExampleStandard()) {
            if HKHealthStore.isHealthDataAvailable() {
                HealthKit {
                    CollectSample(.stepCount, continueInBackground: true)
                }
            }
        }
    }
}
```

--------------------------------

### Swift Code Example with Syntax Highlighting

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Documentation Guide.md

Demonstrates how to format Swift code examples within documentation using markdown's fenced code blocks for syntax highlighting. This ensures readability and clarity for developers.

```markdown
```swift
let name = "Paul"
```
```

--------------------------------

### Spezi Module Protocol Example

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi Guide.md

Illustrates the basic Swift Module protocol that Spezi modules can optionally adopt to integrate with the Spezi ecosystem. This protocol serves as a fundamental building block for modular functionality.

```swift
protocol Module {
    // Define methods and properties required for Spezi integration
}
```

--------------------------------

### Standard Conformance to HealthKitConstraint

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Initial Setup.md

Illustrates how a custom `Standard` type can conform to the `HealthKitConstraint` protocol to handle HealthKit data. This includes implementing methods to process newly added samples and deleted objects, enabling data synchronization with your application's data store.

```swift
import Spezi
import SpeziHealthKit


actor ExampleStandard: Standard, HealthKitConstraint {
    // Add the newly collected HealthKit samples to your application.
    func handleNewSamples<Sample>(
        _ addedSamples: some Collection<Sample>,
        ofType sampleType: SampleType<Sample>
    ) async {
        // ...
    }

    // Remove the deleted HealthKit objects from your application.
    func handleDeletedObjects<Sample>(
        _ deletedObjects: some Collection<HKDeletedObject>,
        ofType sampleType: SampleType<Sample>
    ) async {
        // ...
    }
}
```

--------------------------------

### Spezi Onboarding Module

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi.md

Demonstrates the UI of the Spezi Onboarding module, used for initial setup and user guidance within digital health applications.

```Swift
/*
This code snippet is a placeholder representing the Spezi Onboarding module.
Refer to the official documentation or repository for actual implementation details.

Example usage might involve:
import SpeziOnboarding

struct ContentView: View {
    var body: some View {
        OnboardingView()
    }
}
*/
// Source: https://github.com/StanfordSpezi/SpeziOnboarding
```

--------------------------------

### Swift Package Index (.spi.yml) Configuration

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi Guide.md

The `.spi.yml` file configures how a Swift package is presented and built on the Swift Package Index, facilitating documentation hosting and package discovery.

```APIDOC
Swift Package Index Configuration:
  Description: Metadata file to configure the Swift Package Index setup.
  File:
    - .spi.yml
  Purpose:
    - Controls how the package is built and indexed.
    - Specifies documentation generation and hosting.
  Example Configuration:
    version: 1
    builder:
      configs:
        - xcodebuild -scheme "MyPackage"
      documentation:
        url: "/docs/MyPackage"
        target: "MyPackage"
  Usage:
    - Place at the root of the repository.
    - Ensures proper integration with the Swift Package Index for documentation hosting.
```

--------------------------------

### Spezi Account Module

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi.md

Displays the account setup view, including email/password prompts and social sign-in options, managed by the Spezi Account module.

```Swift
/*
This code snippet is a placeholder representing the Spezi Account module.
Refer to the official documentation or repository for actual implementation details.

Example usage might involve:
import SpeziAccount

struct AccountSetupView: View {
    @StateObject var accountManager = AccountManager()
    
    var body: some View {
        AccountSetupView(viewModel: accountManager)
    }
}
*/
// Source: https://github.com/StanfordSpezi/SpeziAccount
```

--------------------------------

### Configure Spezi Application with Standard

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Standard.md

Provides an example of how to define the application's `Configuration` within a `SpeziAppDelegate` subclass. It shows how to specify the `Standard` instance to be used by the application.

```swift
var configuration: Configuration {
    Configuration(standard: ExampleStandard()) {
        // ...
    }
}
```

--------------------------------

### Module Configuration Method

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Module.md

The `configure()` method is called during Spezi instance initialization for lightweight module configuration. Longer setup tasks should be initiated asynchronously within this method.

```APIDOC
Module/configure()-5pa83
  func configure()
    - Called on the initialization of the Spezi instance to perform lightweight configuration.
    - Advised to start longer setup tasks asynchronously.
    - Can access `@StandardActor` properties after this method is called.
```

--------------------------------

### SwiftLint for Swift Code Style

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi Guide.md

SwiftLint is a tool for enforcing Swift style and conventions. It can be configured via a `.swiftlint.yml` file and integrated into the development workflow.

```APIDOC
SwiftLint Configuration:
  Description: Configuration file for SwiftLint to enforce code style.
  File:
    - .swiftlint.yml
  Usage:
    swiftlint --config .swiftlint.yml
  Key Configurations (Examples):
    - identifier_name:
        min_length: 
          warning: 3
          error: 2
        excluded: "_"
    - line_length:
        max: 120
        warning: 100
        ignores_urls: true
    - trailing_whitespace: "strict"
  Integration:
    - Recommended for automatic checks in CI/CD pipelines (e.g., GitHub Actions).
    - Stanford Spezi provides a recommended SwiftLint configuration file.
```

--------------------------------

### Recommended Repository Files

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi Guide.md

Lists essential files recommended for a Spezi repository to ensure good project management, contribution tracking, and citation practices. These files help maintain project health and community engagement.

```git
# .gitignore
# Specifies intentionally untracked files that Git should ignore.
# Example: DerivedData/
# Example: *.xcodeproj
# Example: build/

```

```git
# CONTRIBUTORS.md
# Lists individuals who have contributed to the project.
# Example:
# ## Contributors
# - [Name](https://github.com/username) - Initial setup, core development
# - [Another Name](https://github.com/anotheruser) - Documentation, testing

```

```git
# CITATION.cff
# Citation File Format for citing the repository.
# Example:
cff-version: 1.2.0
message: If you use this software, please cite it using these metadata.
authors:
  - family-names: "Stanford University"
    given-names: ""
    orcid: ""
    affiliation: "Stanford University"
title: "Spezi"
version: 1.0.0
date-released: 2023-01-01

```

--------------------------------

### REUSE Tool for License Compliance

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi Guide.md

The REUSE tool helps ensure compliance with open-source licensing specifications. It can be integrated into CI/CD pipelines to automatically check license conformance.

```APIDOC
REUSE Tool:
  Description: Checks and manages software licenses and copyrights in files.
  Usage:
    reuse lint
    reuse addheader <file> --license <license_id> --copyright "<copyright_text>"
  Parameters:
    lint: Checks the repository for compliance with the REUSE specification.
    addheader: Adds license and copyright information to a file.
      - file: The path to the file to modify.
      - license: The SPDX license identifier (e.g., MIT).
      - copyright: The copyright text (e.g., "Copyright (c) 2023 Your Name").
  Integration:
    - Recommended for automated checks in pull requests and main branch.
    - Can be used with GitHub Actions like the Stanford BDHG REUSE reusable workflow.
```

--------------------------------

### GitHub Actions Workflows for Spezi Modules

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi Guide.md

Reusable workflows for automating tasks like license checking, code linting, testing, and coverage reporting within a Spezi module's development lifecycle.

```APIDOC
Spezi Module Automation Workflows:
  Description: Reusable GitHub Actions workflows for common development tasks.
  Examples:
    - Stanford BDHG REUSE reusable workflow:
        Purpose: Automates REUSE specification conformance checks.
        Trigger: Pull Request (PR) and main branch.
    - Stanford BDHG SwiftLint GitHub Action:
        Purpose: Integrates SwiftLint for code style checks.
        Trigger: Pull Request (PR) and main branch.
    - Stanford BDHG Test Using Xcodebuild or Run Fastlane reusable workflow:
        Purpose: Automates running unit and UI tests.
        Trigger: Pull Request (PR) and main branch.
    - Stanford BDHG Merge and Upload Coverage Report reusable workflow:
        Purpose: Merges coverage reports and uploads them (e.g., to codecov.io).
        Trigger: Pull Request (PR) and main branch.
  Integration:
    - Configure these workflows in the `.github/workflows/` directory of the repository.
```

--------------------------------

### Markdown Image Syntax for Dark/Light Mode

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Documentation Guide.md

Illustrates the markdown syntax for providing image variants that automatically adapt to dark and light mode interfaces. This ensures visual consistency across different viewing preferences.

```markdown
![Example Image](https://raw.githubusercontent.com/StanfordSpezi/.github/main/Example.png#gh-light-mode-only)
![Example Image](https://raw.githubusercontent.com/StanfordSpezi/.github/main/Example~dark.png#gh-dark-mode-only)
```

--------------------------------

### DocC Equivalent for Important Information

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Documentation Guide.md

Demonstrates the markdown formatting equivalent to DocC's 'Important' callout, using a simple blockquote with 'Important:' prefix. This ensures consistent presentation of key information in both READMEs and DocC documentation.

```markdown
> Important: An important element ...
```

--------------------------------

### Module Communication Example

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Module Communication.md

Demonstrates how to pass data between `Module`s using `@Provide` and `@Collect` property wrappers. `ModuleA` provides a string, `ModuleB` provides a string array, and `ModuleC` collects all provided strings for use in its `configure` method. Values must be provided during initialization and collected after `configure()` is called.

```swift
class ModuleA: Module {
    @Provide var someGreeting = "Hello"
}

class ModuleB: Module {
    @Provide var someGreeting: [String]

    init() {
        someGreeting = ["Hola", "Hallo"]
    }
}


class ModuleC: Module {
    @Collect var allGreetings: [String]

    func configure() {
        print("All the greetings we received: \(allGreetings)") // prints "Hello", "Hola", "Hallo" in any order
    }
}
```

--------------------------------

### Spezi Module Footer Markdown

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Documentation Guide.md

Markdown block for the footer of Spezi modules, including links to contributing guidelines, code of conduct, and license information, along with image links for light and dark modes.

```markdown
## Contributing

Contributions to this project are welcome. Please make sure to read the [contribution guidelines](https://github.com/StanfordSpezi/.github/blob/main/CONTRIBUTING.md) and the [contributor covenant code of conduct](https://github.com/StanfordSpezi/.github/blob/main/CODE_OF_CONDUCT.md) first.


## License

This project is licensed under the MIT License. See [Licenses](https://github.com/StanfordSpezi/Spezi/tree/main/LICENSES) for more information.

![Spezi Footer](https://raw.githubusercontent.com/StanfordSpezi/.github/main/assets/Footer.png#gh-light-mode-only)
![Spezi Footer](https://raw.githubusercontent.com/StanfordSpezi/.github/main/assets/Footer~dark.png#gh-dark-mode-only)
```

--------------------------------

### Spezi Module Dependency Resolution and Testing

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/SpeziTesting/SpeziTesting.docc/SpeziTesting.md

Demonstrates how to use `withDependencyResolution` to set up a Spezi Module for unit testing. This function resolves dependencies and simulates the module's lifecycle, allowing for isolated testing without a full SwiftUI App setup. It's crucial for testing module logic independently.

```swift
import SpeziTesting

let module = ModuleUnderTest()

// resolves all dependencies and configures your module ...
withDependencyResolution {
    module
}

// unit test your module ...
```

--------------------------------

### Markdown Callout for Important Information

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Documentation Guide.md

Shows how to use markdown's blockquote syntax with specific prefixes to create callouts for important information, similar to DocC's 'Note' or 'Important' elements. This helps draw attention to critical details.

```markdown
> [!IMPORTANT] 
> An important element ...
```

--------------------------------

### Swift Documentation Visibility Attribute

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Documentation Guide.md

Explains the usage of the Swift compiler attribute `_documentation(visibility: ...)` to control the visibility of symbols in generated documentation. It's recommended for hiding internal elements or exported imports.

```swift
You SHOULD use [`@_documentation(visibility: ...)`](https://github.com/apple/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md#_documentationvisibility-) to hide elements from the documentation that should not appear in the public documentation.
It is RECOMMENDED to use `@_documentation(visibility: internal)` to an `@_exported import` statement to ensure that all public symbols of the imported module are not exposed in the documentation of the Spezi module.
```

--------------------------------

### Declare Module Dependencies

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Module Dependency.md

Modules can declare dependencies on other modules using the @Dependency property wrapper. This establishes a strict initialization order, ensuring that a dependency's configuration is available before the dependent module is configured. The example shows how to declare a dependency and optionally provide a default initializer for cases where the dependency is not externally configured.

```swift
class ExampleModule: Module {
    @Dependency var exampleModuleDependency = ExampleModuleDependency()
}
```

```swift
class ExampleModuleDependency: Module, DefaultInitializable {
    init() {
        // default options ...
    }
}

class ExampleModule: Module {
    // dependency that uses the default init, if module is not externally configured.
    @Dependency var exampleModuleDependency = ExampleModuleDependency()
}
```

--------------------------------

### Implement Custom Standard Conformance

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Standard.md

Shows how to implement a custom `Standard` type that conforms to both the base `Standard` protocol and a custom constraint protocol like `ExampleConstraint`. This is for defining your own standard.

```swift
actor ExampleStandard: Standard, ExampleConstraint {
    // ...
}
```

--------------------------------

### ServiceModule Protocol

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Module.md

Conform to the `ServiceModule` protocol and implement the `run()` method to participate in the structured concurrency lifecycle of a SwiftUI app.

```APIDOC
ServiceModule
  protocol ServiceModule
    - Protocol for modules participating in the structured concurrency lifecycle.
    - Requires implementation of the `run()` method.

ServiceModule/run()
  func run()
    - Method to be implemented by conforming types to participate in the app's concurrency lifecycle.
```

--------------------------------

### Spezi Application Properties

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Interactions with Application.md

Access key application properties such as the logger and launch options. These properties provide insights into the application's state and configuration.

```APIDOC
Spezi/logger
  - Description: Access the application's logger instance.
  - Usage: Obtain the logger to log messages, warnings, or errors.
  - Returns: A logger object.

Spezi/launchOptions
  - Description: Access the options used when launching the application.
  - Usage: Retrieve configuration parameters passed during application startup.
  - Returns: An object containing launch options.
```

--------------------------------

### Extend Existing Standard with Constraints

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Standard.md

Illustrates extending an existing `Standard` type with a custom constraint protocol, such as `ExampleConstraint`. This is useful when you use a predefined standard that needs to meet module-specific requirements.

```swift
extension ExistingStandard: ExampleConstraint {
    // ...
}
```

--------------------------------

### Spezi Module Dependency Resolution Functions

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/SpeziTesting/SpeziTesting.docc/SpeziTesting.md

Provides functions for resolving dependencies and simulating the lifecycle of a Spezi Module. These are essential for unit testing individual modules. The `standard` parameter allows for specifying standard configurations, while `simulateLifecycle` controls the simulation process.

```APIDOC
withDependencyResolution(standard:simulateLifecycle:_:) 
  Resolves dependencies and simulates the lifecycle for a Spezi Module.
  Parameters:
    standard: An optional `Standard` configuration to apply.
    simulateLifecycle: A boolean indicating whether to simulate the module's lifecycle.
    _: A closure that returns the Spezi Module to be configured and tested.
  Returns: The configured Spezi Module.

withDependencyResolution(simulateLifecycle:_:) 
  Resolves dependencies and simulates the lifecycle for a Spezi Module without a standard configuration.
  Parameters:
    simulateLifecycle: A boolean indicating whether to simulate the module's lifecycle.
    _: A closure that returns the Spezi Module to be configured and tested.
  Returns: The configured Spezi Module.
```

--------------------------------

### Spezi Views and Validation Module

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi.md

Demonstrates UI components and input validation features provided by the Spezi Views module, specifically highlighting the SpeziValidation target.

```Swift
/*
This code snippet is a placeholder representing the Spezi Views and SpeziValidation modules.
Refer to the official documentation or repository for actual implementation details.

Example usage might involve:
import SpeziViews
import SpeziValidation

struct InputFormView: View {
    @State private var email: String = ""
    
    var body: some View {
        ValidatedTextField(
            label: "Email",
            text: $email,
            validator: EmailValidator()
        )
    }
}
*/
// Source: https://github.com/StanfordSpezi/SpeziViews
```

--------------------------------

### Spezi Devices and Bluetooth Module

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi.md

Illustrates the user interface for Spezi Devices and Bluetooth pairing, enabling seamless integration with health monitoring hardware.

```Swift
/*
This code snippet is a placeholder representing the Spezi Devices and Bluetooth modules.
Refer to the official documentation or repository for actual implementation details.

Example usage might involve:
import SpeziDevicesUI
import SpeziBluetooth

struct DevicePairingView: View {
    @StateObject var bluetoothManager = BluetoothManager()
    
    var body: some View {
        PairedDevicesView(viewModel: bluetoothManager)
    }
}
*/
// Source: https://github.com/StanfordSpezi/SpeziDevices
// Source: https://github.com/StanfordSpezi/SpeziBluetooth
```

--------------------------------

### Spezi Platform-agnostic Type Aliases

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Interactions with Application.md

Utilize platform-agnostic type aliases for common application-related types. These aliases ensure consistency across different platforms.

```APIDOC
ApplicationDelegateAdaptor
  - Description: A type alias for adapting application delegate behavior across platforms.

BackgroundFetchResult
  - Description: A type alias representing the result of a background fetch operation.
```

--------------------------------

### Define Custom Standard Constraint Protocol

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Standard.md

Demonstrates how to define a custom protocol that conforms to the `Standard` protocol. This allows modules to enforce specific requirements on the `Standard` instance used within the Spezi-based software.

```swift
protocol ExampleConstraint: Standard {
    // ...
}
```

--------------------------------

### Spezi LLM Module

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi.md

Features a Chat View for interacting with a locally executed Large Language Model (LLM), powered by the Spezi LLM module.

```Swift
/*
This code snippet is a placeholder representing the Spezi LLM module.
Refer to the official documentation or repository for actual implementation details.

Example usage might involve:
import SpeziLLM

struct ChatInterfaceView: View {
    @StateObject var llmService = LLMService()
    
    var body: some View {
        ChatView(viewModel: llmService)
    }
}
*/
// Source: https://github.com/StanfordSpezi/SpeziLLM
```

--------------------------------

### Define Standard Constraint Protocol

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Module.md

Defines a protocol that must conform to the `Standard` protocol, used for enforcing module constraints. This is the first step in the constraint mechanism.

```swift
protocol ExampleConstraint: Standard {
    // ...
}
```

--------------------------------

### Spezi Application Interaction

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Interactions with Application.md

Access application properties and actions using the Module/Application property wrapper within your Module or Standard. This provides a central point for interacting with the application's core functionalities.

```APIDOC
Module/Application
  - Description: Provides platform-agnostic mechanisms to interact with your application instance.
  - Usage: Access application properties or actions via this wrapper within your Module or Standard.
  - Related: Module, Standard
```

--------------------------------

### Spezi Questionnaire Module

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Spezi.md

Showcases the UI of the Spezi Questionnaire module, facilitating the collection of patient-reported outcomes and survey data.

```Swift
/*
This code snippet is a placeholder representing the Spezi Questionnaire module.
Refer to the official documentation or repository for actual implementation details.

Example usage might involve:
import SpeziQuestionnaire

struct QuestionnaireScreen: View {
    let questionnaire: Questionnaire
    
    var body: some View {
        QuestionnaireView(questionnaire: questionnaire)
    }
}
*/
// Source: https://github.com/StanfordSpezi/SpeziQuestionnaire
```

--------------------------------

### Enforce Standard Constraint in Module

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Module.md

Demonstrates how to use a constraint in a module to access a `Standard` instance that conforms to a specific protocol. The `@StandardActor` property is used for this purpose.

```swift
class ExampleModule: Module {
    @StandardActor var standard: any ExampleConstraint

    func configure() {
        // ...
    }
}
```

--------------------------------

### Register for Remote Notifications

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Notifications.md

Demonstrates how to register a module for remote notifications. This involves requesting user authorization for notification permissions and then calling the `registerRemoteNotifications` action to obtain the device token. The obtained token should typically be sent to a remote server for push notification generation.

```swift
class ExampleModule: Module {
    @Application(\.registerRemoteNotifications)
    var registerRemoteNotifications

    func handleNotificationsPermissions() async throws {
        // Make sure to request notifications permissions before registering for remote notifications
        try await UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound])
        let deviceToken = try await registerRemoteNotifications()

        // ... send the device token to your remote server that generates push notifications
    }
}
```

--------------------------------

### Manage Model State with @Observable in SwiftUI

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Interactions with SwiftUI.md

Demonstrates how to make a custom model type accessible within the SwiftUI environment using the `@Module/Model` property wrapper. This allows your `Module` to place an `@Observable` model into the global view environment, enabling easy access and state management across your SwiftUI application.

```swift
@Observable
class ExampleModel { // your model type you want to make accessible
    var someState: Bool = false

    init() {}
}


class ExampleModel: Module { // your model the app configures
    @Model var model = ExampleModel()
}


class ContentView: View { // access the model within SwiftUI
    @Environment(ExampleModel.self) var model

    var body: some View {
        // ...
    }
}
```

--------------------------------

### Spezi Notification Management

Source: https://github.com/stanfordspezi/spezi/blob/main/Sources/Spezi/Spezi.docc/Module/Interactions with Application.md

Manage remote notifications within your Spezi application. This includes registering for and unregistering from push notifications.

```APIDOC
Spezi/registerRemoteNotifications()
  - Description: Registers the application to receive remote notifications.
  - Usage: Call this function to enable push notification capabilities.
  - Returns: A promise that resolves when registration is complete.
  - Related: Spezi/unregisterRemoteNotifications

Spezi/unregisterRemoteNotifications()
  - Description: Unregisters the application from receiving remote notifications.
  - Usage: Call this function to disable push notification capabilities.
  - Returns: A promise that resolves when unregistration is complete.
  - Related: Spezi/registerRemoteNotifications
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.