Develop Reference

Use foreground service to communicate with network

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

How to listen for new chat messages on Android?

I'm writing a small chat client for android. So the behaviour I want is, that my application is listening in the background for new messages and shows them in the notification area (only the icon of my app). Listening for incoming messages should be a really long term thing - maybe over days after closing the ui thread
My question is: How to do it? Should I have a service with it's own process? should I start an AsyncTask for the Listener? Or are there much better ways to do it? And if I use a new Service Process, do I need to use AIDL?

How to do it?
Have your chat server use GCM to push chat messages to the device.
Should I have a service with it's own process?
No.
First, it would not need to be in its own process.
Second, this would require you keep the service running all of the time, which many users dislike.
Third, this would require you to keep the device powered on all of the time with the WiFi radio powered on all of the time, which users will not appreciate. The exception: if you are running on a device supporting mobile data (e.g., a phone), and you are very very careful, you can maintain an open socket connection to a server while the device is asleep. This is difficult to get working properly.
should I start an AsyncTask for the Listener?
Probably not.
Or are there much better ways to do it?
Have your chat server use GCM to push chat messages to the device.
Or, possibly, change your chat server to work on a queuing model, so you can poll periodically (on a user-configurable interval) to pick up available messages.
And if I use a new Service Process, do I need to use AIDL?
No.

Keeping a XMPP connection alive or (re)connect on activity start up

I'm currently working on an application that uses asmack source to connect to a XMPP Server. This application basically includes all the default messenger attributes (Sending/receiving messages, changing statuses, etc).
At the moment the XMPP connection lives inside the application and isn't in some sort of background service. So now I'm wondering, is it better to keep the connection alive using a service or just keeping the connection alive when my application is actually running. This is taking in consideration that I don't want to stay connected to the XMPP Server the entire time (like days, or anything longer than half an hour) since this places a small but noticeable stress on the server.
So in a way I'm asking if it's better to (re)connect/log-in as soon as my Activity is brought to the foreground/started or is it better to connect once inside a service and just keep this connection alive?(and possibly popping notifications on new incoming messages)
Thanks in advance,

Android Service design - start with activity or only when needed?

I'm an android noob that is looking for some advice on how to properly use a service in Android. I am building an app that will connect to a server on the Internet to get a data stream via TCP. That data then needs to get send out to another device that is connected via a bluetooth serial port. I want this to continue to function in the background while the user looks at a different activity.
The app will be a NTRIP client, which pulls real time RTK correction data from the Internet and sends it to a RTK GPS receiver that I connect to via bluetooth. The data rate will be about 500 bytes/second. The user interface is a single button to connect or disconnect the data stream and some text to show status of the GPS receiver. There are also a few settings that will need to be configured by the user such as the IP/port of the server to connect to and the bluetooth device to communicate with.
I think I need to have the main activity spawn a local service, and then have the service spawn a thread for the TCP stream and another thread for the bluetooth connection. Does this sound right?
What is the best model for the service in this scenario?
-Start(bind) the service every time the activity starts, and have the connect/disconnect button send commands to the service to start/stop the threads. If I go this route, the service will continue to run after the user disconnects and goes to another app. The service would need an inactivity timer to terminate itself.
-Start and stop the service when the user presses the connect/disconnect button. The service only runs when data is moving. If I do this, the activity will need to see if the service is running when the activity starts, in order to know if it should bind to the service or tell the user that the link is disconnected.
Thanks.

I'd go with your second option. Checking if a service is running or not is an easy task and also you won't consume unnecessary processing time which will be better for the battery life.
Just because you can run a service for a long time in the background doesn't necessarily mean that you also should do that. At least not all the time.

As android supports more than one entry point into the app, you could define two entry points in the Manifest.xml.
<category android:name="android.intent.category.LAUNCHER" /> defines, that this class could be started from the launcher. I guess that would work for a service, too. I would do two entry points. One which spawns the activity first and gives the user some configuration control. And another which simply spawns the service.
As you have no control over the lifetime of an activity i would not suggest to do anything which should not be ended by the system. If you have an incoming call your activity would simply die.
If the user starts the service you could create an widget with the button. If the user starts the activity you could start the service and the widget.
And if the user starts the widget, the user decides, what should happen with the service.

I'm not a Java or Android programmer so take what I say with a grain of salt. The normal way to handle blocking IO in Java is to use threads. It sounds like the data flow is unidirectional but for maximum flexibility I would create 3 threads, one for the UI, one for the TCP connection and one for the bluetooth connection. Communication between the UI and two worker threads could be done using shared variables (need to careful about synchronization, race conditions, etc). I would pass the data NTRIP data to the other worker using a multi-threaded queue data structure.
The worker thread for the NTRIP data would be roughly:
while (app running) {
if (connection enabled) {
if (not connected) {
c = connect to remote
}
data = get data from c
queue.put(data)
if (options reconfigured) {
close c
}
}
}
For the bluetooth thread:
while (app runnning) {
data = queue.get()
if (UI settings changed and connected) {
close connection
}
if (not connected) {
c = connect to remote
}
send data over connection
}
In the normal state, both workers are blocking on IO and will be consuming essentially no CPU time. Based on my experience, I would recommend you write your code to handle communication errors. For your code to work well in the real world you have to handle connections closing, hanging, etc. Making it robust will likely be the most time consuming part of the development.

Which background model to run

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.