Extend XCTSpezi to Support the Individual Creation of Modules and Components about spezi HOT 3 CLOSED

Feedback as discussed in the meeting:

• withDependencyResolution static function (with timeout overload)
• Basic Lifecycle Handler Support (maybe flag based, default false)??

from spezi.

Completed as of #95

from spezi.

With recent changes in the Spezi framework, I wanted to provide some additional context to this issue.

The latest release of SpeziScheduler uses the following, greatly simplified setup to support the individual creation of Modules:

@testable import Spezi
@testable import SpeziScheduler

let scheduler = Scheduler<String>(tasks: [initialTasks])

// use the internal initializer to resolve dependencies via the `DependencyManager`
 _ = Spezi(standard: DefaultStandard(), modules: [scheduler])

// allow for async configuration of modules
try? await _Concurrency.Task.sleep(for: .seconds(0.1))

// use the `scheduler` ...

By making the Spezi import @testable, we gain access to the internal initializer of the Spezi type. This is great as it uses the exact same mechanisms as the spezi(_:) to resolve the dependency tree and doesn't rely on any unsafe usage of Mirror.

What is up to discussion is how we provide access to this API surface. Requiring a @testable import might not be the best option and the current initializer of the Spezi type is currently not really meant for external usage.

Further, some modules might do some asynchronous initialization after configuration. Certain users might want to wait for completion for these operations.

EDIT: Of course, as we do not attach to the SwiftUI view hierarchy, this doesn't set up an AppDelegate and therefore a LifecycleHandler will never be called.

from spezi.