User Data Service

[Supereg]

User Data Service

♻️ Current situation & Problem

Link any open issues or pull requests (PRs) related to this PR. Please ensure that all non-trivial PRs are first tracked and discussed in an existing GitHub issue or discussion.

⚙️ Release Notes

Add a bullet point list summary of the feature and possible migration guides if this is a breaking change so this section can be added to the release notes.
Include code snippets that provide examples of the feature implemented or links to the documentation if it appends or changes the public interface.

📚 Documentation

Please ensure that you properly document any additions in conformance to Spezi Documentation Guide.
You can use this section to describe your solution, but we encourage contributors to document your reasoning and changes using in-line documentation.

✅ Testing

Please ensure that the PR meets the testing requirements set by CodeCov and that new functionality is appropriately tested.
This section describes important information about the tests and why some elements might not be testable.

📝 Code of Conduct & Contributing Guidelines

By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

• I agree to follow the Code of Conduct and Contributing Guidelines.

[codecov]

Codecov Report

Attention: Patch coverage is 87.30159% with 24 lines in your changes missing coverage. Please review.

Project coverage is 76.23%. Comparing base (a6f0b1e) to head (6310d71).

❗ Current head 6310d71 differs from pull request most recent head 9c559f6

Please upload reports for the commit 9c559f6 to get more accurate results.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #36      +/-   ##
==========================================
+ Coverage   75.77%   76.23%   +0.47%     
==========================================
  Files          99      106       +7     
  Lines        4505     4694     +189     
==========================================
+ Hits         3413     3578     +165     
- Misses       1092     1116      +24     

Files	Coverage Δ
...racteristics/RecordAccess/RecordAccessOpCode.swift	91.67% <ø> (ø)
...s/UserData/UserControlPointResponseParameter.swift	100.00% <100.00%> (ø)
...es/Characteristics/UserData/UserControlPoint.swift	94.45% <94.45%> (ø)
...racteristics/UserData/UserControlPointOpCode.swift	91.67% <91.67%> (ø)
...stics/UserData/UserControlPointResponseValue.swift	91.67% <91.67%> (ø)
...cteristics/UserData/UserControlPointResponse.swift	93.45% <93.45%> (ø)
...cs/UserData/UserControlPointGenericParameter.swift	92.43% <92.43%> (ø)
...oothServices/Characteristics/UserData/Gender.swift	0.00% <0.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a6f0b1e...9c559f6. Read the comment docs.

[PSchmiedmayer]

@Supereg Wanted to follow up on this PR; do you think we should merge this in here or should some of that functionality move to Spezi Devices?

[Supereg]

@Supereg Wanted to follow up on this PR; do you think we should merge this in here or should some of that functionality move to Spezi Devices?

We generally went with incorporating Characteristic and Service definitions on SpeziBluetooth in the SpeziBluetoothServices target. This is what's done here.
We can think of moving all reusable services to SpeziDevices in the future.

[PSchmiedmayer]

Good point, I was just a bit confused by some Omron mentions in the code which seems quite specific to Spezi Devices's medical devices features.

I think keeping a core collection of reusable services and characteristics in here makes a lot of sense, I think this is useful. At some point we could think about some scoping in sub targets to avoid any larger API surfaces but IMO we should be fine with the current scope.

[Supereg]

Good point, I was just a bit confused by some Omron mentions in the code which seems quite specific to Spezi Devices's medical devices features.

Yes, this feature development was originally driven by the Omron devices we used as some of the exposed a User Data Service. They defined several extensions on the services which also made it tricky to decide how to best implement this service such that it stays customizable but we do not loose type safety. In the end, Omron specific parts would move to the Omron target in SpeziDevices.

I think keeping a core collection of reusable services and characteristics in here makes a lot of sense, I think this is useful. At some point we could think about some scoping in sub targets to avoid any larger API surfaces but IMO we should be fine with the current scope.

Agree. There might be benefits to, e.g., divide between generic, easily-reusable services (like battery service or device information) and some of the medical services and characteristics. But I think, currently this still works well 👍

[PSchmiedmayer]

Agree; thank you for continuing to work on this @Supereg; greatly appreciated!!