0

I am working on a BLE app (using RxAndroidBle library!) that is able to connect to multiple devices for quite a while. Recently business requirements have slightly changed and I have to preserve connection with all the devices throughout whole app. What I mean after I connect with the device I have to keep stable connection on all the screens and If I get disconnected I have to prompt the user about that.

Until now I had some kind of a BleManager that was an abstraction over RxBleClient and BleDevice that was an abstraction over RxBleDevice. Both those classes were covered with some reactive interfaces, they were injected into proper modules and all the subscribing and unsubscribing them were done in those specific screen modules. However now I have to change the approach because I have to keep the connection all the time.

The question is: Is there any better way to keep the stable connection with the Ble Device other than creating it in Android Service and keeping the subscriptions in that Service? All the Ble examples/tutorials keep those connection in the service but I'm not a big fan of this solution as it also doesn't fit very well in my architecture. I was wondering if I could bind this somehow with the application instance or something like that. Any idea other than service will be very much appreciated.

Jogosb
  • 155
  • 1
  • 12
  • I've bumped into [this](https://stackoverflow.com/a/48132487/2792775) answer this morning and the solution is similar to what I have implemented but it still requires using a service. – Jogosb Jan 18 '18 at 07:36

1 Answers1

0

I would personally do a Service as well as it "guarantees" that it will last for a whole lifecycle of my app.

Then I'd build an abstraction on top of the service and communicate with it, no with the service directly.

pawel.urban
  • 1,031
  • 8
  • 10
  • 1
    What exactly do You mean by saying "on top"? I have an idea to inject this BleManager to this service and as it's a singleton inject it to the other modules. In service I would keep the subscriptions and I would publish results in the screen modules by some Subjects which will propagate the events. BleManager is covered with the reactive interface so I can subscribe to those subjects when I need to. – Jogosb Jan 18 '18 at 08:43
  • I meant that if your BleManager is an abstraction on a BLE connection, then I'd create another abstraction that would represent my domain of the device so the BLE would be only an implementation detail. Application modules don't necessarily need to know about BLE and all the stuff but about the business logic behind the device. – pawel.urban Jan 18 '18 at 11:49