Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Android nRF-ToolBox multiple BLE services within a single Android Service

Hello all,

I've been working on creating a test app for a product that I've been developing for sometime. It has multiple BLE services such as Device information (DIS), Cycling Power (CP), Battery Service, DFU and a custom service. I've got no prior experience with Java or xml, so the answer might be obvious to the following questions.

I've adjusted the Cycling Speed and Cadence example in the nRF Toolbox application to receive and display the Cycling Power Measurement, the Cycling Power Feature, Sensor location and the DIS firmware, hardware, model number and serial number Characteristics.

I added all these characteristics in the Cycling Power Manager, but with so many services I'd like to implement this becomes quite a mess and I'd like to seperate each BLE service into a serperate manager/class(es).

I've noticed that the Battery service is already implemented by extension of the Cycling Power Manager (CSCManger in the original toolbox)

public class CPManager extends BatteryManager <CPManagerCallbacks>

From what I've attempted, failed and then read, I cannot extend this class further with other services like this. So what would be the best solution to extend the manager/service with more BLE services without putting all services and characteristics in a single class, while sending all handled BLE data to a single Activity?

Second question: I've removed all other BLE services in the first menu except the DFU and the Cycling Power services by removing the <service from the AndroidManifest.xml file as the template service readme file stated it would. However the Beacon service remains in the main menu, no matter which services I disable or remove. So where does the beacon service come from?

Thank you in advance for helping me out.

Parents
  • Hi

    Our Android expert took a look at your reply, and here are his suggestions for you:

    It seems like you might be creating multiple instances of the manager. You should use the same manager instance throughout the app. I would suggest moving your manager to the service and let all the communication happen in the service. You can then have a broadcast receiver on the activities to listen to all the broadcasts sent from the service. In addition, you should bind your activities to the service using a binder and then use that binder to access the same manager and call its public methods to send data. This will help you maintain one instance of the manager. One such example would be to look at the proximity profile which shows how a service can be bound to an activity and how to call the public API within the manager in the service from the activity using the binder.
    Best regards,
    Simon
Reply
  • Hi

    Our Android expert took a look at your reply, and here are his suggestions for you:

    It seems like you might be creating multiple instances of the manager. You should use the same manager instance throughout the app. I would suggest moving your manager to the service and let all the communication happen in the service. You can then have a broadcast receiver on the activities to listen to all the broadcasts sent from the service. In addition, you should bind your activities to the service using a binder and then use that binder to access the same manager and call its public methods to send data. This will help you maintain one instance of the manager. One such example would be to look at the proximity profile which shows how a service can be bound to an activity and how to call the public API within the manager in the service from the activity using the binder.
    Best regards,
    Simon
Children
  • Hello Simon,

    I've got the binder working and I got quite a lot of functionality already implemented, but I required a bit more layout space and I am currently implementing a tab layout.

    For further development and verification of the product I'm developing this app for I would like to capture the NUS service TX data with the app. The product uses the NUS to stream data to another nRF device at 200 messages per second, which writes it to an SD card. If I currently try to capture this with my app, I get an noticeable delay/responsiveness issue. From the streaming device I can also see that If i try to plot a single message per second in my app layout it starts to drop packets as my TX queue overflows. So I wonder if there's an solution for this by using a queue, interface, thread or other way to deal with high data throughput? I had a look at the NUS example in the toolbox, but i saw nothing special. Or should I use a separate thread for my GUI? I think i saw this being used for the proximity or glucose example.

    I also want to implement a text log for BLE messages just as is implemented in the nRF Connect app to display messages send between the app and the device. Is there something in the toolbox which already has this functionality or what I could use for this?

Related