I developed a Ble Android App composed from three activity and one service:
- the first one to scan the device
- the second one to connect to device
- the third one to write communication result on the screen
- inside the service there are some functions to connect to device, to check the connection , to automatically reconnect etc etc and this service is a started service and binded to each activity (the first app start this service)
On some tutorial I have seen that in this case is being used a not started service but a binded one. But I wonder myself, when we switch between two activity, if the service is not "started" one, is there the risk of ower service may be closed from the system, because in the switch between activity the service is binded with nothing ?
Two answer your question - there is a risk your service will get stopped at any time. If you design your app around the idea that the service will be on as you switch through activities then you're going to have a much more complicated design than you need.
You might notice that there is a service defined in the example: http://developer.android.com/guide/topics/connectivity/bluetooth-le.html
That service, as it's written does just one thing. It scans for a device and when it finds one it broadcasts the BluetoothDevice (which is a Parcelable). Then the service stops scanning. This scanning code could just as easily be in an application. But the key is that the scanning shuts down and the BluetoothDevice is passed via intent to some other component.
A good thing to keep in mind too, is that when you use BLE your application is talking to a service already. So defining a new service to wrap the BLE connection is completely redundant (technically speaking). Having multiple activities to bind to a service to talk to one device ... possible, but not without its complications. The number of edge cases you'll run into makes the effort much more work than just having your activity talk to the device directly.
Hope that helps.
Cheers.
Related
Where I'm Currently At:
I would like to be able to run Bluetooth in my app in the background on android. I have read various guides and understand the idea of creating an intent service (something like android.app.IntentService and extending it, overwriting the onHandleIntent with your desired behaviour) however, I don't understand how that would interract with my existing behaviour? So for example, I currently call:
...
var bluetoothManager = utils.ad.getApplicationContext().getSystemService(android.content.Context.BLUETOOTH_SERVICE);
adapter = bluetoothManager.getAdapter();
adapter.startLeScan(Bluetooth._scanCallback)
...
(this is in JavaScript, using the nativescript runtime, so don't worry about it looking a bit wierd.)
Where I'm trying to get to:
I would like to being able to scan for and reconnect to paired devices in the background and recieve (store in SQLite) GATT Characteristic updates.
Question:
So how do I create this functionality in the type of service that can be run in the background as described above?
The Bluetooth LE Gatt APIs are built upon Android's Binder mechanism, which means it will only work during the app process is alive. You must make sure your app process isn't killed by the system. The easiest way to do that is to have a foreground service running (not an intent service). The only important thing is that the foreground service is alive and running, your service class itself doesn't have to do anything. But I guess the easiest way is to put all your BLE code inside that service. See https://developer.android.com/guide/components/services.html#Foreground.
I am a google glass developer.(and I am Chinese student...poor English)
I have to get bluetooth information in background, keeping update, show it on my google glass, but I can't keep my bluetooth service running when I switch my activities.(because every activity should show the latest bluetooth information.)
I want to know :
how can I let my service keep live when I switch different activities?
What you need is to bind the running service to the upcoming activity.
Binding is essentially making the activity start the service if it is not started already or get the running instance if it is already running,
Read more here.
I am working on an android project that requires communication against a BLE device.
as for now I am quite done - however I have one thing I cant solve -
I want to use a service to coomunicate against the BLE device and communicate
with thata service only by sending and recieving broadcasts.
my question is - for some reason when I try to connect to the device inside the service
by making the service extend LeScancallbak finding the device and connecting to it takes much longer and also the BLE GATT server is null (since the gattcallback is never called) however if I bind the service to activity and implement that LeScancallbak in the activity its a metter of acouple of milliseconds -
Did anyone also had the same problem or possibly have an answer to that strange behavior?
I want to use only the service to communicate against the bluetooth device since I want to stay connected to the device even when the application UI is not running (i.e. leave a background service) plus it looks more logical that connecting every activity to that service upon changing screens.
In case anyone have a better way to achieve that, I wil be happy to hear about it.
BLE has a lot of issues on Android, and implementing a service like you want will be difficult. I would recommend integrating the BLEService library produced by Ratio. The source is available on GitHub: https://github.com/RatioLabs/BLEService
To put things simply, I'm writing a video chat application that's supposed to connect say, two Android phones. So far, I've managed to negotiate interactions between clients, until the point I've reached the part where I'm supposed to do the streaming of video (and later audio) data between the clients.
The problem is as follows:
I am trying to implement a service that will, once a person has decided to contact someone, be started from a ChatActivity, and that will negotiate streaming between the two clients, making the sockets and the data going between them completely independent of the events going on within the ChatActivity, except for the moment the conversation is over, where the activity is terminated for good, and with it the service.
However, my concern comes from the point that if the service terminates the sockets mid-conversation, I have the problem of having to renegotiate streaming between client and client.
As is probably obvious, my knowledge of android services is limited, at best, and any advice on the subject is welcome
My questions are:
Is it doable to create a service that will, bar unexpected crashes due to outside influences, keep such a connection active and running regardless of how many times the activity that displays the video from the streaming (ChatActivity) is destroyed and created?
Should I be going with a bound service or a started service for this, or some hybrid of the two?
If I were to somehow create a pair usable stream of video data from the service, one via internet connection other via camera, would I be able to send them back to the activity, and keep reconnecting them to the components, regardless of how many times they get destroyed and created during the lifecycle?
Despite my efforts, I haven't managed to find any examples of anything similar, if anyone has come across code that does some similar socket/service juggling, I'd be most grateful for directions.
Is it doable to create a service that will, bar unexpected crashes due to outside influences, keep such a connection active and running regardless of how many times the activity that displays the video from the streaming (ChatActivity) is destroyed and created?
The Service lifecycle, if started via startService(), is independent of the lifecycle of any of the activities. Activities can come and go, but a service can stick around for a while.
Should I be going with a bound service or a started service for this, or some hybrid of the two?
You will need to use startService() if you intend for your Service to run without any activities around.
If I were to somehow create a pair usable stream of video data from the service, one via internet connection other via camera, would I be able to send them back to the activity, and keep reconnecting them to the components, regardless of how many times they get destroyed and created during the lifecycle?
That's impossible for me to answer, without a complete description of what "a pair usable stream of video data" means.
That being said, you will probably want to consider an event bus like Square's Otto or greenrobot's EventBus, as they both have support for the UI layer receiving events on the fly (e.g., service just establishes communications) and retrieving on demand the last-sent event (e.g., activity needs to reconnect to the last stream).
I am trying to develop an application which will require a service to
run in the background. I am relatively new to android programming,
and after reading many posts, blogs, how-to's and books on creating
and managing services, I am still pretty confused about which model I
should try to use.
First, let me present (in general) the application requirements: I
need an application which will spawn a background process (service?)
which will connect to a bluetooth device. The bluetooth device is
designed to deliver data to the android device. The issue is that the
data could come in at any moment, so the bluetooth connection has to
stay active. Note that the application is a VERY SPECIFIC app and is
NOT intended for public use. I do understand the arguments for not
having background apps running all the time, but please understand
that this is a very specific application for a very specific client.
Now, in general, I think the program flow would be to start the
application (and launch a UI activity). Then I need to configure and
connect to the bluetooth device. At this point, the user should be
able to do other things - make phone calls, check their email, etc.,
while the bluetooth connection is still active and potentially
receiving data. If data comes in, a notification is fired, etc.
So here are my questions and concerns:
If I start an app (which spawns a UI activity and ultimately my
bluetooth connection service) but the app is killed, apparently, the
service handling the bluetooth connection is killed as well. How can
I keep that alive? I read that Service.setForeground() was
depricated, but even if I were to set it to the foreground, if the app
is killed, the service is killed as well. I need to have it run in
the background with as high of a priority as possible (again, I do
understand that this is considered "bad form", but this is a specific
app and this functionality has been requested by the client).
If I started the app (and the service, etc.), but the user, say,
answers a phone call, the app is put into the background. However,
let's say the user goes back to the home screen and starts a DIFFERENT
instance of the app, i.e., he doesn't hold down the home key to select
the already running app from the task manager but starts a completely
new one. If the service handling the bluetooth connection is still
running, how will this new instance behave? i.e., how can I get it to
connect to the bluetooth service which is ALREADY running in the FIRST
instance of the app instead of this new instance? Do I have to use
some form of a Remote service instead of a local service? This is
where I'm a little confused by things as it seems remote services and
defining an AIDL seems to create a lot of extra overhead, and since
I'm already creating a lot of overhead with the service running in the
background all the time, I want to keep that as small as possible.
How can I insure I am connecting to the same service already running?
1)
The service does not depend on an Activity. You can have it running on the background until you call stopSelf().
You can have a BroadcastReceiver that listens to the android.intent.action.BOOT_COMPLETED so your service is started when the phone is turned on.
2)
Your Activity should bind to the service. And get the info from it.
Check this question.