Android: Should I use BroadcastReceiver vs Messenger vs BindService vs Handler - android

I know this look like tons of question around SO. But it's not (although I can also be wrong).
I have a long running Service (running in a separate thread using blutooth socket pooling for data in a OBD2 adapter every 5 seconds).
This Service is running in the same process and is a Foreground Service.
The user start this Service through an Activity. It then connect to the Bluetooth device and start pooling and saving data to a SQLiteDataBase.
The user can then minimize the activity and do other stuff.
When he returns (if ever, he can stop the service through a notification area button) to the application it checks if the Service is running and if so, it starts another Activity which show the data that is being pulled from the OBD2.
My question is, between this visualization Activity and the Service should I use and by this I mean the recommended or the right one:
LocalBroadcast? This is actually what I am using. Every time the service pull some data, it sends a broadcast with the data everytime it was pulled. Then in the onReceive method call runOnUiThread to update the respective View.
Messenger? As far as I know (never used it) I should send a Messenger from the Activity to the Service (much like a Handler) and in the Service it should send the Messages with the data pulled. But from this I would get a RemoteObjectException if the Activity was destroyed (like I said, the user could just minimized the activity and then it got GCed). So, I would probably need a way of sending the Messenger to the Service every time the Activity gets created and check if it's ok to use the messenger form the Service every time (if that's even possible, I've never used this).
BindService? Should I bind to the service when I open the Activity and then get the data directly from methods in the Service? But this would probably mean I would have another thread in the Activity gets this data from the Service every time, right?
Handler? (for a moment now I realize don't know the difference between Messenger and Handler, should it be that "use Messenger when Service runs in another process and Handler otherwise)
I've seen/read a lot of answers here in SO and through the web in general.
But in the end I don't see a ultimate answer for my case. But I'm sorry if this is just because I couldn't figure it out.
Thanks in advance!
EDIT: forgot to mention, I would rather make use only support libraries and android framework stuff, I'm still learning Android and I want to understand what's happening within its own classes.

Related

use startService() repeatedly over time to send commands to started service

I'm developing an app that communicates with an embedded device via BLE (Bluetooth Low Energy). The app allows the user to send commands via an activity. Meanwhile the app needs to send location data in the background. The location data must be sent constantly, even if the activity is closed and opened multiple times over the day.
I cannot separate the continues location updates from the command requests. Because all BLE transmissions must be synchronized by one queue to prevent simultaneous transmissions which would cause package loss.
After reading the official guide (https://developer.android.com/guide/components/services#Basics), my first idea was to use a foreground service because the service must not be terminated when the activity is closed. That works fine for sending the location data. However, for sending the commands I have to communicate with the service after it has been started. I read that it's not recommended to use both startService() and bindService() but instead to decide for one way. As far as I understood a bound service can be destroyed when the referencing context (the activity in my case) is destroyed. So I guess binding to the service is not an option for me.
Another approach to talk to a started service is to send commands using broadcasts and receiving them in the service (sending commands from Activity to Service in android).
But I think there must be a better solution that I miss. What came to my mind is simply calling startService() every time I want to send a Bluetooth command. I guess that would work. But is it good practice? Effectively, I would call startService() dozens of times during a typical use case before calling stopService().
Oh wow... I read through the whole guide but overlooked this sentence in the method documentation:
startService()
Every call to this method will result in a corresponding call to the target service's onStartCommand(Intent, int, int) method, with the intent given here. This provides a convenient way to submit jobs to a service without having to bind and call on to its interface.
https://developer.android.com/reference/android/content/Context#startService(android.content.Intent)
Hope it helps in case that someone stumbles across it..
You don't have to bind the service to anything. It's enough to start it and then make sure you call startForeground on it. That will keep your process running without being killed by the system. You don't have to place your BLE code in the service class but can have it wherever you want.

Using Service for long network connection

Right now I have a server running on a desktop. I want to be able to start up my app, hit a button to start collecting data from this server, and only stop once I hit to button again. The user should always be grabbing data from this server after hitting the button, even if the app isn't active. So far I've considered setting up a Service or using Threads by themself.
A Service sounds exactly like what I need, but I've been told it isn't meant to sustain a long network connection. I poked through the BluetoothChat sample application and it didn't use a Service. Would a Service be the right thing to use then, or should I implement it with threads like the sample application does? The only reason I need a long connection is to listen for any error reports from the server. The other network stuff only happens when the user is directly using the app. I will have to use threads anyways because a Service runs in the same thread as the activity that calls it, but I guess my main question is whether I should scrap the Service part. Right now I have a basic Service set up that can handle messages sent to it and it seems really easy to use. The documentation on it is just all over the place, there needs to be a section saying "If you want to do X, then this is suggested!"
A Service runs on the UI thread, but an IntentService runs in its own thread.
It's ambiguous to say that the "app" isn't active. If you're running a Service, it's always active. An IntentService is active as long as it has finished the work in its onHandleIntent() method. None of the activities of the app may be active, which means that the app is in the background.
Other than that, I'd need to know more about what you're trying to do. In general, it's better to collect data in cycles rather than trying to keep the connection open constantly. For example, what do you do when the device loses connection to the Internet?

Where I should use Service , AsyncTask and Broadcast Receiver?

I'm in little bit confusion where in what case I need to use application components like Service, asyncTask and Broadcast Receiver.
Can any one explain what the exact difference between these there and where I need to use these components?
AsyncTask is a friendly way to create a new thread that performs some work asynchronusly.
A Broadcast Receiver is something like an Event Handler for system events. It can run in
background and perform an action when something happens, like turning the phone off or turning wifi on..
A Service is just an app that works in background (like a daemon) and serves information to an app or just performs tasks.
Sorry for my English, I try to let me understand but it is not my mother tongue
I will get straight to where I have applied these three in my projects so far:
1.Service:Something you want to perform in the background without any user interaction.For instance fetching location data continuously or sending some data continuously to your server.You can also use services to perform tasks every few time units.For example sending ten minute background updates.
2.AsyncTask:Making a new thread of execution.Best use I have encountered so far is calling a web service..I did the following using an AsyncTask for web service calls
1.Display Progress bar in onPreExecute()
2.Perform my web service calls in doInBackground(Params...)
3.In onPostExecute(Result) update the UI or do some other stuff with the response from the web service.
3.BroadCastRecievers are like global recievers for your app.They can listen for both System events like a phone restart or a custom event within your app.I used them for starting a service when the phone was restarted,which stopped when we switched off the phone.
Let me explain with a usecase, so you understand it better -
AsyncTask - Want to get something from the server, or post something to the server? If we do so on the main thread, the user won't be able to interact with the app. So Asynctask is used, and it performs the network activity in a different thread.
Service - Want to manage something in the background? Like get the users' location every 10 minutes or 1 hour, or alert the user when he is crossing a particular area based on the location. The Service makes the app run even when the app is not opened (the user might be doing something else, or the phone is locked, the Service still runs in the background).
Broadcast Receiver - Assume, you are tracking location and storing locally (when the internet is down). Not when the internet is up, you want to send all of them. So you register with the OS, that you want to listen for that specific event, and you get control.
Or when you want the server to know that the device is restarted, then we just have to implement it.
Clear?
A service and its local memory-variables are loaded into memory and is always running
A BroadCast receiver is only garanteed to be in memory and running while processing an event.
A Broadcastreceiver can be removed from memory by the operating system if the memory is low.
"Service" is a component which runs in the background, without interacting with the user. Every developer can create new Services in his application. Services support true multitasking for Android, as they can run in their own process.
"AsyncTask" encapsulates the creation of Threads and Handlers. An AsyncTask is started via the execute() method.the execute() method calls the doInBackground() and the onPostExecute() method.
Mostly main purpose to download something without user interaction.
"Broadcast receiver" is a class which extends BroadcastReceiver and which is registered as a receiver in an Android Application via the AndroidManifest.xml file(or via code).you can register a BroadcastReceiver dynamically via the Context.registerReceiver() method.
The class BroadcastReceiver defines the onReceive() method. Only during this method your BroadcastReceiver object will be valid, afterwards the Android system can recycle the
BroadcastReceiver.

Background Service in Android - Need Help

I need some help or suggestions regarding Background services.
Well I want to achieve this. I have an application with Some Views that application also has a Background Service that always keeps on running.
In my views there is a Button whenever I press that button, that button passes some files to the Background Service and my Background service upload that file onto some server.
I am done with the uploading process. Now I want to know that how can I make a Background Service that always keeps on running and on my tapping of the button it sends a file to the Service.
I am new in Background service implementation.
Please guide Friends with some tutorials, suggestions or guidelines.
Thanks a bunch
You've probably already read some of the Android Service documentation, but I suggest studying it further and looking at the Local Service Sample if you have not done so already:
http://developer.android.com/reference/android/app/Service.html
It sounds like you have already got your Service up and running, and I think the actual problem you are trying to solve now is how to communicate data from your Activity to your Service. When your Activity is bound with a Service that's part of the same application, that service is in the same process and runs on the same main UI thread, so once you get the IBinder object from the Service after binding with it, you can simply directly call the functions in that Service from your Activity. Similarly, you can pass your Service a handler object from your Activity so that the service can send messages or post Runnables to your Activity. Communication with a local Service is therefore quite simple.
So if you take a look at the Local Service Sample in the link above, you will see a section in the code where we get a reference to the Service once binding has completed:
mBoundService = ((LocalService.LocalBinder)service).getService();
After that point, it's possible to directly call methods on that Service that's in the same application. For example, you could have a method called sendFile in your Service. In your Activity, you might do something like:
mBoundService.sendFile( myStuffObject );
There are quite a number of questions on Stack Overflow regarding communicating between an Activity and a Service, and I think you'd find it beneficial to search and read these.
A standard Android service will do just fine in this case.
It will continue running in the background untill its work is finished or until you ask it to stop.
There is a topic on the android dev site explaining services in detail.
you should go for android Service that is used for Background operation . Inside the service your have use TimerTask which will be checking the Queue for every x sec and when any items present in the Queue it will pull the item and upload it to the server.
here is the link for Android Service..
http://developer.android.com/reference/android/app/Service.html
Link fro Queue.http://developer.android.com/reference/java/util/Queue.html

What to use: service or threads

I am developing an android app which fetches/uploads data from/to the web service every n minutes. This upload/download is only done when the app is running. But this might change in future.
I dont update the UI when the new data is downloaded. The UI is only updated if the user is on the current screen(app have multiple activities)
My question is what is the best approach to this problem.
I dont think service is the right approach as it sounds like an overkill(in the present scenario). AlarmManager could be an option.
Running threads inside a service be an option ..something like this .
Any pointers/suggestions would be great.
Thanks
I am using AsyncTask in my activity to ask .net web service some information and it works and easy to use.
AsyncTask enables proper and easy use of the UI thread. This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers.
Well, in this case, since the app would already be running during the time, either would work great, but a service can be called from anywhere within the application so this is where I would use the service over the thread.
If you want to create the thread to only be used in lets say Main.java, then thread would work fine, these are the only things that I can see really making ANY difference at all, they're really pretty close, and in this case neither gives a distinct "correct" answer, but I would choose Service
I think all approaches you noted would work ok. Personally I'd go with this:
Use AlarmManager to wake download service. Start it when Activity is shown, stop it when activity hidden.
Download service should be short lived: start it to do the upload/download and then shut it down.
If download service does get some new data, it sends a Broadcast which Activity listens to.
Just broadcast a message after your upload/download is done, and then have a receiver start the service and then have that service stop itself. And you are done.
This should be done if you dont plan on polling the server for new information or anything. Primarily this kind of approach would be for onetime update, interpret, finish. And wait until the next update. Which primarily for most cases is streaming.. but depends on what you are getting.

Categories

Resources