Easily accessible logger infrastructure for Components and Modules

[Supereg]

Problem

Currently, every implementing Component is responsible to create and manage their instances of a Logger. This impose the following problems:

• Creating a Logger is often times a multi-step process and could be considered tedious. This might result in developers not adopting at all or falling back to non-structured logging techniques like a simple print statement. Both goes against our aims of have maintainable and traceable code.
• Developers might not have good guidance on what identifiers to choose (e.g., subsystem and category labels). This might result in choosing inconsistent identifiers.

Solution

This issue proposes a solution where Components or Modules can easily access a Logger instance that is tied to their specific implementation, such that:

• It is easy to access.
• It provides strong and consistent defaults for the logger subsystem and category.

Ultimately we want to encourage increased usage of log message such that we have maintainable code that is easy to debug.

Additional context

For some context, we currently have the internal SpeziLogger KnowledgeSource stored inside the SharedRepository of the Spezi instance which provides the global default logger for the Spezi framework.

A potential solution to address this issue could be implementing some kind of @Logger property wrapper which can be used inside Component and Module implementations. The property wrapper would make use of the SpeziStorage repository to retrieve and store the logger instance, similar to the SpeziLogger knowledge source.

One might need to think what challenges this design creates. How easy is it for the Component to pass around the Logger to other types which are created and managed by the Component?

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines