My app uses the Android XML-RPC project to communicate with a server. After the connection is established the app needs to keep the connection alive by sending a message to the server every xx second. The app also contains multiple Activities that need to send and receive messages using the connection.
What's the proper way to implement this?
Using a IntentService and BroadcastReceiver?
Or just a Thread?
This looks like a perfect job for a Service started by the AlarmManager.
Your service in its onStart method will get whatever information you need for connection (like token, username, ...) from the preferences for instance. You can trigger the service start by using the AlarmManager sending on a regular basis an intent to start the service.
Another option would be to have a service started in the background, running a thread that does the communication each X seconds (use a sleep(delay) between calls.
Related
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 coded an IntentService where I send a command line. Is related to an activity where I'm trying to program a Console. The activity's purpose is to do a 'command prompt' where I can send and receive to/from the server.
The Service's action is:
COnnect to the server
Send command line
Get response
Retrieve response to user
The main problem is that every time I send a command line, the Service has to reconnect to the server. (Cause every time I'm starting the whole Service)How can I avoid this step?
I would like to "keep alive" the service waiting for a command line to send, without the need of reconnect every time I execute its action.
Is there any way to do it action-responsive? I mean, I start the service and every time I set its action (setAction) and put the line I want (putExtra). Then I have to start the service again?
Good night. Tomorrow I'll be back :)
Thanks in advance!
Due to its "one shot" design, using an IntentService isn't a good approach IMO.
If you don't want to start the service each time you send a command, then I'd suggest you 'bind' to a standard Service (see Bound Services). If you bind to the Service in your Activity's onResume() method and unbind in onPause() your Activity will be able to directly call methods in the Service.
You will, of course, have to create your own worker Thread in your Service to handle any work involving your network connection however. If you want any tips on how to do that, look at the source code for IntentService - it's fairly straight-forward.
Don't use an IntentService. Per the documentation:
the service is started as needed, handles each Intent in turn using a worker thread, and stops itself when it runs out of work.
Instead, you should consider using a normal Service (calling stopSelf()) when you want to stop the service (and your connection to the server). Or, if you'd like the connection to the server to have the same lifecycle as the activity, you can create a bound service: it will start when your activity binds to it and then stop when the last activity is unbound.
I've an application with several activities bounded with a service.
The service open, in an asynctask, a socket connection and start listening (while(true)) the incoming message from a socket server.
the question is: how to send a callback to the several activities that a message is arrived?
thanks in advance
Are you binding the activities to the service with onBind()? If so, why? onBind() usually isn't necessary.
As far as I can tell, you're listening for incoming messages from a server. Have you investigated using Google Cloud Messaging?
The activities don't have to be bound to the Service. It will remain running until something shuts it down. You can run an AsyncTask on it, but you might even want to use your own background HandlerThread.
In any event, to communicate back to the activities, use a LocalBroadcastReceiver and send broadcast Intents from the Service.
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.
I'm developing a MMS-like app on the advanced interphone for the airport using private network. I receive the messages from the specific server using socket. If the user log on the message system, the user should always receive the messages until he logout.
My idea to solve such issue is as follows:
By using one local service as a Manager service, this service will receive the command from the UI,and one remote service to maintain the connection with the server.
When the local service receive the different cmd from UI, it will check the UserState stored in a Application sub-class, then send the required information to the remote service.
The remote service will generate different message-packets to send to the server.
While the receiving procedure is like: After the remote service receiving and parsing different messages(such as sms,address list of contacts), it send necessary strings, file URI or object to the local service, and the local service send the info to the activity.
I don't know whether this idea will work well. For I need a Role like Manager to handle different sending cmd and receving messages and a consistent connection, what the structure should my app be like?
use one local service as a Manager service,this service will receive the command from the UI,and one remote service to maintain the connection with the server.
No. Use one local service, period. A second service adds no value; a remote service makes your app worse, not better, by wasting RAM, CPU, and battery for no benefit.
can you tell me an method how to make the connection service is always running?
You cannot have a service running "always". If you use startService() and startForeground(), it will be the least likely to be automatically terminated. However, the user can elect to force-stop your app or use a task killer if they so choose.
For in service document, local service can be killed more easily than a remote service(running in its own process) by the system.
That is incorrect.