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
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 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).
I'am developing something like a Push Notification SDK, when users integrate the SDK to their application, the SDK create a Service and receive Notifications through a TCP connection.
Now here is the question: Assume that many applications will use the SDK on the some android device, all of the application need to receive their own notifications, if we create TCP connection in each Service, it will cost too much resources and battery power, so I want to use a main Service(maybe the first Service start by SDK) to set up TCP connection, the other Services reuse the connection by some kind of IPC. But I don't known what kind of techniques is best to use.
Is there anyone who can give some advice?
thanks~
Finally I solved the problem this way:
Make a public Service(android:export="true") to set up TCP connection to the server, when the APP starts, first check if the public Service exists, if not, call startService(). Then call bindService() in the APP. To communication with the public Service, use a Messenger class:
http://developer.android.com/guide/components/bound-services.html#Messenger
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 developing an application which utilizes a custom network protocol over TCP. Several tasks within the application use different activities however each activity requires the networking enabled (since each activity has to send/receive some custom packets over the network).
So my idea is basically to
At application start - create a service to handle networking ( I read somewhere that I should do the networking in another thread in this service to prevent ANR)
When a new activity is run, it binds to that service. During that time it sends/receives data from the service. When the activity ends, it unbinds from the service.
I would like to know if this makes sense.
Also, I understand that I can send data to the service (to send over the network) using the aidl interface, but how would I receive data from the service? Polling through the aidl seems to be the only way I can think of - which means I would need another thread in each of my activities to prevent ANR. Surely there is some better way.
I appreciate your help and am open to suggestions.
Actually I've been reading more and am beginning to look at callback methods in the sample code provided here. After reading it more thoroughly I have a better understanding of the services and AIDL.