Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Descriptor Interactions #11

Open
1 task done
Supereg opened this issue Feb 20, 2024 · 1 comment
Open
1 task done

Support Descriptor Interactions #11

Supereg opened this issue Feb 20, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@Supereg
Copy link
Member

Supereg commented Feb 20, 2024

Problem

Currently, it is only possible to read all Characteristic Descriptors upon discovery. However, it is not possible to read/write descriptors within the lifetime of a connected device.

Solution

Provide access to read/write descriptors within the BluetoothPeripheral actor and find a respective translation for the DSL language (e.g., a @Characteristic equivalent?).

Additional context

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct and Contributing Guidelines
@Supereg Supereg added the enhancement New feature or request label Feb 20, 2024
@Supereg
Copy link
Member Author

Supereg commented Jul 14, 2024

Maybe we could implement Descriptor support as another property wrapper usable in BluetoothService types with a syntax similar to the code snippet below.

public struct DeviceInformationService: BluetoothService, Sendable {
    public static let id: BTUUID = "180A"

    @Characteristic(id: "2A29")
    public var manufacturerName: String?

    @Descriptor(id: "2901", for: \Self.$manufacturerName)
    public var manufacturerNameDescription: String?

    // ...

    public init() {}
}

The property wrapper @Descriptor works similar to the @Characteristic with additionally requiring a KeyPath to the CharacteristicAccessor binding of the characteristic it refers to. This design would however require a runtime check that the KeyPath refers to a characteristic declared on the same Service type (in this case DeviceInformationService) as we can't express this relationship through the Swift type system.

The code snippet below roughly sketches the public interface of the Descriptor property wrapper. Note that we would likely want shorthand initializers for the common descriptor UUIDs (see CBDescriptor).

@propertyWrapper
public struct Descriptor<Value>: Sendable {
    public var wrappedValue: Value? {
        fatalError("Needs implementation")
    }

    public var projectedValue: DescriptorAccessor<Value> {
        fatalError("Needs implementation") // read and write accesses for the descriptor
    }


    public init<S: BluetoothService, V>(wrappedValue: Value? = nil, id: BTUUID, for characteristic: KeyPath<S, CharacteristicAccessor<V>>) {
        fatalError("Needs implementation")
    }
}

Supereg added a commit that referenced this issue Jul 14, 2024
@Supereg Supereg mentioned this issue Jul 14, 2024
1 task
Supereg added a commit that referenced this issue Jul 18, 2024
# Swift 6 compatibility

## ♻️ Current situation & Problem
This PR adds support for Strict Concurrency Checking in SpeziBluetooth.
With Xcode 16 beta 3, there are still some warnings about non-sendable
key paths (in the UITest app), however this will be resolved with the
next Xcode 16 beta (this is already resolved in the current release/6.0
swift toolchain snapshot).

## ⚙️ Release Notes 
* SpeziBluetooth now uses the `@SepziBluetooth` global actor to isolate
all its state. All current `actor` types were migrated to `classes` that
are isolated to the global actor.
* All uses of CoreBluetooth's CBUUID are replaced with a new string
literal expressible `BTUUID` type that is Sendable.
All places that declared a String overload for `CBUUID`-based arguments
(e.g., the `Characteristic` initializer or `DiscoveryCriteria` methods)
removed these overloads in favor of the expressible by string literal
conformance of `BTUUID`.
* We removed all accesses to characteristic descriptors from the
`@Characteristic` property wrapper. Descriptors are currently not
supported anyways, something that is tracked in #11.
* We removed the `BluetoothPeripheral/localName` property (also
`@DeviceState(\.localName)`). Migrate your code to directly access the
`AdvertisementData/localName` property.
* We removed the `AdvertisementData/rawAdvertisementData` property and
respective initializers to provide Sendable guarantees. Please use new
typed initializers to initialize your testing data.
* The `BluetoothPeripheral/services` property is no longer accessible
via `@DeviceState` and is now isolated to the `@SpeziBluetooth` global
actor. Use the existing `@Service` property wrapper for any service
interactions.
* The new
`bluetoothScanningOptions(minimumRSSI:advertisementStaleInterval:)` view
modifier replaces direct assignment of environment values of
`minimumRSSI` and `advertisementStaleInterval`. Please migrate to using
the new modifier.
* Retrieving nearby devices using the Bluetooth module via
`Bluetooth/nearbyDevices(for:)` is now isolated to the `@MainActor` for
easy interaction with SwiftUI.
* It is now recommended to implement `BluetoothService`s as structs
(SpeziBluetoothServices was migrated accordingly).
* A lot of state was synchronized through lock-free primitives using the
Swift Atomics package 🚀


## :books: Documentation
All documentation was updated to reflect changes described above.


## :white_check_mark: Testing
Existing unit tests and UI tests are still passing 🚀 


## :pencil: 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
Labels
enhancement New feature or request
Projects
Status: Backlog
Development

No branches or pull requests

1 participant