I implemented a chat application in Android with websockets. However when the user closes the application, the websocket connection to the server is lost and no new messages can be received.
I am essentially lost and do not know where else to turn, how can I setup the service in the app to stay connected to the server as the user logs in as well as after the app has been stopped?
As we're all aware, continuous background code execution is not feasible on Android; different ROMs will man-handle your background services without any guarantees (e.g. START_STICKY will not get your service restarted on some devices), so we need to do the best we can with the code that is reliably executed.
In this situation, you have a websocket server delivering continous information to your client. When your app is in the background, it may miss out on some data. When your app returns to the foreground, your information may be out of sync, so you need to synchronize again with your server, and then reconnect to your websocket.
In my chat app I achieve this by checking whether my websocket service is running onResume in an activity which is a superclass of all the activities that I want to have access chatting data (i.e. not login/registration activities). If the service is not running, I synchronize my data by pulling the changes from an endpoint and then restarting the service. This way, even if the service is killed in the background I will still get the latest data and real-time experience once the app returns to the foreground.
Related
I'm developing a similar app to Telegram or WhatsApp, I need to keep a persistent socket connection to a server (I know this is a resource intensive job and I am sure GCM is not going to help in this case, I can't change the architecture at the moment).
First of all I tried writing a Service but since the service is running in the same process as the app's main thread, whenever the app is closed, then the service is restarted. (I have returned START_STICKY on onStartCommand()).
After that I am begining to think I would have to develope an independent service and use AIDL to interact with my app.
I'd appreciate if you could help me with this problem.
Users can always kill your app if they want to. If you've marked your Service as STICKY, Android will simply restart it for you. In this case you will need to recognize that your app has been restarted and recreate the persistent socket connection. There is nothing you can do to prevent a user (or Android) from killing your app under certain conditions.
I read the Last Safe Method to be called before killing the application in Android is OnPause.
Suppose I have client running on Android that is a part of location based Client/Server application. I have some design issues:
When I create the main activity I though it is logicall to start a service that connects to the server (running on my computer) and updating it in with the user location.
Now, when the application is active I want to present the user some information. Even if the user paused the activity I want the service keep running in the background and update the server. I also want the server to know when user disconnected.
Now because OnPause is the last safe method guaranteed to be called by the system, I don't know where it's best to notify the server of user disconnection.
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'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 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.