WARNING: The delegate for CBPeripheral does not implement -[peripheral:didModifyServices:] about rzbluetooth HOT 5 CLOSED

Oops, sorry about that, I ran the command but it didn't finish. I pushed again and it should be ready now.

from rzbluetooth.

Nice, I haven't noticed that in my testing with a simulation app, and I never had a device that would change it's services.

By design, RZBluetooth doesn't hold on to any Service or Characteristic objects, so none of the state managed by RZBluetooth should need invalidation. It was my assumption that the backing peripheral.services array and service.characteristics arrays would be managed by Core Bluetooth, either by updating the object state, or by removing the modified object from the parent -- The API surface of CBPeripheral just doesn't seem to present another option. With this assumption, RZBluetooth will just re-discover the service or characteristics if removed. The Core Bluetooth documentation is pretty thin here, so if you find any information to the contrary, I'd be very interested!

The delegate is actually implemented, but commented out, so if you don't need to respond to the event and would like to get rid of the log message, I can just uncomment it and route the log the RZBLog. However I think it could be desirable to expose the event for a consumer to respond to if desired. Do you have any opinions on if or how you would like to consume it? Currently, RZPeripheral has a lifecycle (connectionEvent:error:) and delegate (RZBPeripheralConnectionDelegate), which could be expanded to add support for modifyServices:. The change should be pretty trivial, as it's just percolating up some information, but the naming would be a bit off, and I'd want to tread carefully and avoid complicating the API if it's not required.

Thanks for the bug report. I can probably get a few hours on Monday to clean this up.

Brian

from rzbluetooth.

I realized (after writing the report) that RZBluetooth doesn't need to do anything in particular, as you said. I think I'm fine with just logging it to silence the warning. I don't need it for anything in my case at any rate. My apps are working fine without it; I just wanted to let you know about the warning.

from rzbluetooth.

I just pushed up 1.2 that has the fix you pushed up, a few others, and will route this delegate to the log. Thanks for the feedback!

from rzbluetooth.

Will you be merging 1.2 to master and updating the podspec?

from rzbluetooth.