I'm developing an Android application that holds a socket connection open to a message server. I have a set of runnables that spawn their own threads and handle the connection / maintaining the connection. These are invoked from a foreground service. The foreground service is to handle all of the message processing / business logic. This is going to be nothing too complex, it'll involve manipulating XML, trawling through an SQLite DB. The activities will be thin and dumb - passing everything to the foreground service.
I was looking at a tutorial on mindtherobot.com that details building a basic twitter client, with a background service that periodically polls the Twitter API and passes that data to the activity. (I don't want to post an actual link to it as it's showing up on Google atm as being malware infested / harmful). For doing that, it uses a remote service.
Using the remote service means that it touches on AIDL to handle IPC, rather just using binding.
What I'm not sure about is there any need to do this. My service will not be used by any 3rd party application - and from what I've read it is frowned upon to use a remote service unless it's strictly needed (as it doubles on overheads).
In the future, I may want to add widgets to display notifications that have come from the foreground service - would this change anything wrt remote services?
The standard pattern for this is to use:
Handler to fire a periodic Intent
BroadcastReceiver to listen for said intent. When it wakes up, poll the server and store any new data
ContentProvider to provide the data to the Activity
Be sure not to fire the periodic Intent too often, otherwise you'll drain the battery.
Then again, you could instead make a server that pushes the data over C2DM.
Related
I have an desktop application that receives data via websocket (server) and an android client websocket sending data (PC input can be controlled via android). Both also do the other job (sending/receiving) but pretty rarely. I want the client to run as a foreground service, so I can send data like clipboard from android and receive e.g. music (artist, etc.) from server.
My question: how can I build a foreground service that holds the websocket open while also maintaining fast (20 requests per second) communication with the activity, including callback? I used a Singleton (Kotlin object) before but with the foreground service that sounds even worse than with the activity open. I don't seek a coded solution here, just a plan on how i can pull this off.
Thanks in advance and sry for the bad english.
I think you should try to use Bound service - the Activity binds to the service as described here https://developer.android.com/guide/components/bound-services
I'm making an app that will collect data using a sensor, only when the device is on. This program will mainly run from the notification bar. Most of the posts about using sensors in the background seem to suggest using Service but I've read that IntentServices are the way to go if handling a long task. So I was wondering which one would be best to use?
It sounds more like you would need a Service, as you will have a long-running operation (monitoring the sensors) which will pause (but not destroy) during some periods when the monitoring will not be required.
Using a Service will also allow your app's activities to bind to it, and show something like live updates. What you however need to be aware of is that if you would like to do something periodic in your Service then you will need to handle the scheduling and threading (if necessary, depending on the amount of processing required) yourself.
You could for example use an IntentService if you wanted to send the collected data to a remote server, as this will nicely kick off a worker thread for you to perform the (slow) network request on.
I'm developing this dating app that allows users to browse profiles downloaded from a server.
But I'm not sure what kind of thread or service I should be using to do the uploading to and downloading from the server.
It has to be a service that runs in the background that first connects to the server via a socket and then waits for commands from user input (from the UI thread).
I read about the Service and IntentService classes.
IntentService seems to be appropriate except that it is destroyed once it has finished its job and returned a result to the calling thread. I need it to keep listening for requests.
I could start a new service each time but that means I would have to reconnect to the server with each request (let's say each time I browse a profile). That doesn't seem right.
Can anyone tell me what is the best approach for this purpose?
If you are asking about how to make the client send download/upload requests outside UI thread, then you could try using AsyncHttpClient. I've been using that in almost every application I developed, and it is highly reliable.
But if you want to send data from server to the client (in other words, client keep listening for any incoming data), I recommend you to use GCM. Here is a step-by-step tutorial of implementing GCM in Android device.
I have a few applications that connect to a network service in order to call a few messages. As the communication with this network service is planned to change, I was thinking to implement a service that will deal with the communication with the network service, and the applications will just send intents or messages to this service. My idea is to have this service standalone, started after boot up, so it needs to be started service. It will connect to the network service and will wait for commands from the applications. So far, I found that Messenger is nearest to what I need, but I think it can only work as a bound service.
Is there already something I can use for my case?
If not, then am I correct that I would need to:
implement a started service
use HandlerThread to handle the input messages - my preferred way is to use intents, but so far I don't know how to do it
So as pskink pointed out, the way to go is using Messenger.
I used com.example.android.apis.app.MessengerService (from Android SDK samples) as an example of such service.
The service is started on reception of ACTION_BOOT_COMPLETED and (on my device with Android 4.2) when the first client tries to bind to the service, the service's onCreate and onBind are called. The communication occurs by sending Message objects and I have defined an enum with the supported messages listed (so I am not using AIDL directly).
What would be the best way to implement this. I have an Android app that will use my python server to allow communication between 2 phones in rounds. Rounds mean that they can't talk to each other until a round start and once they send a message they can't send another until the other person responds which will then start a new round.
I was thinking I would use the IntentService but it seems wrong to have the server constantly starting and stopping and I don't won't to have to worry about the issues with asynctask or is that the best way to handle it. How could I have a service that should receive and send messages to the client, seems services are more one way things?
Intent services are nothing more that worker threads that are triggered by intents, execute their actions in a separate thread and then get shut down. They are designed to be started and stopped.
If you need to perform stuff like an http get, or in any case interaction that do not require to stay connected to the server, use intent services and get your activities notified using broadcast events.
If your app needs to stay connected with the server (i.e. permanent tcp connection), the way I'd go for is to have a service (not an intent one) that performs the networking stuff using an asynctask or a more classic thread hosted in the service. You can then make the activity interact with the service using bindToService() .
I'd recommend not to use asynctasks inside an activity. You will risk to loose the server response in case of horizontal / vertical view changes, as oneilse14 stated in his reply.
I highly recommend the IntentService/Broadcast Receiver route. Avoiding the nasty configuration change issues associated with AsyncTask will make your life ten times easier.
As far as i understood your problem is of type worker-queue model Producer-consumer model). Intentservices are meant to do that. You should use services if and only you need to do multithreading. You do can communicate with Activity and Service by using IBinder interface.
Asynctask are just a specialized threads so that you can update your UI easily. But for your case IntentService seems to be best option.
I would use an Alarm, which is scheduled via the AlarmManager, as then it can be set to check if the round has started/turn. It has the advantages of a service but not the horrors of battery drain. It takes a frequency to how often the Alarm should run, which even includes enumerations of time (e.g. 1 hour/day/week).
When the Alarm runs it could poll to see what the current state is and react accordingly. For example a notification could go into the status bar and phone could make an audible noise and vibrate.The benefit of this is that the user does not have to keep the app running as the Alarm will trigger a broadcast receiver.
An example of the Alarm code: http://www.androidcompetencycenter.com/2009/02/android-basics-alarm-service/