Why are BLE service modules in the SDK implemented to work as instance managers?

RE: Why are BLE service modules in the SDK implemented to work as instance managers?

Bjørn Kvaale — Mon, 18 Mar 2019 10:15:44 GMT

I agree with you. I cannot think of a use case where it would make sense to add multiple services with the same UUID. I can see the point of having the same service with the same UUID on multiple devices or having multiple characteristics in one service.

RE: Why are BLE service modules in the SDK implemented to work as instance managers?

Andy — Wed, 13 Mar 2019 13:32:55 GMT

And what would be the use case of adding multiple services with the same UUID? How would you be able to tell them apart?

RE: Why are BLE service modules in the SDK implemented to work as instance managers?

Andy — Wed, 13 Mar 2019 13:32:13 GMT

I guess that makes sense for the central "services", which aren't really services, they are more like "service handlers". These are for example the BLE_BAS_C and BLE_DIS_C modules. For these modules I guess I agree it's useful to have the implementation as instance managers. But for the actual service modules, it still doesn't make much sense to me.

RE: Why are BLE service modules in the SDK implemented to work as instance managers?

Bjørn Kvaale — Wed, 13 Mar 2019 12:48:22 GMT

[quote user=""]But from the BLE service point-of-view it doesn't make much sense to me. Why would someone instantiate multiple battery services in a peripheral? Or multiple device information services? And is it even possible to add multiple services with the same UUID?[/quote]

I agree that it may not make sense to instantiate multiple battery services in a peripheral. However, it may make sense to instantiate multiple same services in a central that is connected to multiple peripherals. That way, you could have one service for each peripheral connection. Yes, it is possible to add multiple services with the same UUID.

Let me ask the team about why they have done this this way & I will get back to you.