I have a service that listens to a socket. When receiving certain input it is to create an activity. When receiving other input, it is to kill this activity. I have struggled for a while to make the service communicate with the activity through AIDL (http://developer.android.com/guide/developing/tools/aidl.html), but this seems to not be effective. I think AIDL is only effective when the process that is to be talked to is a service, not when it is an activity? I would love some directions or suggestions on how to solve my problem.
Cheers,
I have a service that listens to a
socket. When receiving certain input
it is to create an activity.
Please make this configurable. Services should not be starting activities except in very unusual circumstances (e.g., the socket is a SIP connection and you are creating a VOIP client). Popping up an activity interrupts the user in whatever they are doing.
When receiving other input, it is to
kill this activity.
The only scenario I have seen where this is a valid pattern is dismissing the in-call screen when the other party hangs up the line. If you are creating a VOIP client, your proposed pattern should be OK, but otherwise, please reconsider having the activity vanish in the middle of the user using it.
I think AIDL is only effective when
the process that is to be talked to is
a service, not when it is an activity?
No, it works in the reverse direction too, but usually only if the activity is the one starting the service and binding to it. More importantly, AIDL is only for cross-process communication.
I would love some directions or
suggestions on how to solve my
problem.
You have not really provided enough information on the nature of the communication to give you a thorough answer. What, exactly, is the service trying to tell the activity? Is the activity also trying to communicate with the service?
The recommended pattern for ongoing communication from an activity to a service is to use the local binding pattern. You will find an example of this in your SDK samples, and you can find one here as well.
The service then has options for communicating back to the client: via a callback (e.g., the Handler in the answer supplied by Mr. Smiljanić) or via broadcast Intents. In the case of the callback, the activity would need to bind to the service in order to get access to an API to provide the callback object. The service would then hold onto that object and call methods on it during key events.
If your service is doing its primary work on a background thread, you will need to ensure that your UI operations get performed on the UI thread. The Handler is one approach to that.
Related
I'm developing an app that communicates with an embedded device via BLE (Bluetooth Low Energy). The app allows the user to send commands via an activity. Meanwhile the app needs to send location data in the background. The location data must be sent constantly, even if the activity is closed and opened multiple times over the day.
I cannot separate the continues location updates from the command requests. Because all BLE transmissions must be synchronized by one queue to prevent simultaneous transmissions which would cause package loss.
After reading the official guide (https://developer.android.com/guide/components/services#Basics), my first idea was to use a foreground service because the service must not be terminated when the activity is closed. That works fine for sending the location data. However, for sending the commands I have to communicate with the service after it has been started. I read that it's not recommended to use both startService() and bindService() but instead to decide for one way. As far as I understood a bound service can be destroyed when the referencing context (the activity in my case) is destroyed. So I guess binding to the service is not an option for me.
Another approach to talk to a started service is to send commands using broadcasts and receiving them in the service (sending commands from Activity to Service in android).
But I think there must be a better solution that I miss. What came to my mind is simply calling startService() every time I want to send a Bluetooth command. I guess that would work. But is it good practice? Effectively, I would call startService() dozens of times during a typical use case before calling stopService().
Oh wow... I read through the whole guide but overlooked this sentence in the method documentation:
startService()
Every call to this method will result in a corresponding call to the target service's onStartCommand(Intent, int, int) method, with the intent given here. This provides a convenient way to submit jobs to a service without having to bind and call on to its interface.
https://developer.android.com/reference/android/content/Context#startService(android.content.Intent)
Hope it helps in case that someone stumbles across it..
You don't have to bind the service to anything. It's enough to start it and then make sure you call startForeground on it. That will keep your process running without being killed by the system. You don't have to place your BLE code in the service class but can have it wherever you want.
I've looked at all the IPC mechanisms in android and none seem to do what quite I'm looking for, perhaps there's a better way...
I have a service that's starting up, and it needs to get information from another service or activity in an entirely different 2nd application.
startActivityForResult is what I'm looking for, but that's not available from a service, only an activity.
I'd really prefer to get the information from the 2nd app's activity, but I'm happy to get it from the 2nd app's service.
But the part I'm really interested in, is making the synchronous call from the service and have it wait for a response.
I can send a broadcast intent from the service to the 2nd app's service, but then there's no tie back when the 2nd app's service sends a broadcast intent back with the answer I want.
Is there any way to do something like this from a service?
Is there any way to do something like this from a service?
The calls made to a Binder from a bound service are synchronous. The documentation discusses bound services, with a separate page on the AIDL you will need since the services are in different applications.
Personally, I would rewrite the first service to not need the synchronous call.
I have two problems:
I know that for connection activity and remote-service I have to use AIDL.
I tried this and it's work but I can find only one way connections example. In simple words - reading something from service (by activity). But I need solve for sending some data to activity (by or from service). It's so important because the service have to send some information to activity immediatly after some its events (obtain data from the net).
Is it way to bring to front again closed application (activity) from the remote service?
Any suggestions would be greatly appreciated.
Regards
Artik
It's so important because the service have to send some information to activity immediatly after some its events (obtain data from the net).
You can use AIDL for two-way communication. You would need to expose not only the service interface, but a callback interface, via AIDL, with the client having the .Stub of the callback and supplying an instance of it in a parameter to a method on the service interface. This gets a bit complex -- here are a pair of sample apps from my book that demonstrate the technique:
Service
Client
Is it way to bring to front again closed application (activity) from the remote service?
Your service can call startActivity(), but generally that is a bad idea. The user may be in the middle of doing something else, when all of a sudden your activity pops into the foreground. Occasionally, the user may deem your activity to be more important, but not always. Consider using a Notification instead, to let the user know that there is something in your app that needs the user's attention.
First, create a private resultreceiver variable in your service. Then create a method to set this resultreceiver via a connected activity. Then use AIDL to pass on a resultreceiver to the running service from the activity via the method you just made. Then in the service use resultreceiver.send if the resultreceiver is not null.
A few examples to get you started
http://lalit3686.blogspot.com/2012/06/how-to-update-activity-from-service.html?m=1
http://chrisrisner.com/31-Days-of-Android--Day-28–Intents-Part-3--Service-Intents
I'm new to Android development, i'm trying to port an IOS app to Android. Basically my App need to communicate with a server in real time with socket IO. It connect to the server and then handle the various message until the server finish to process the request.
In my IOS app i use a Singleton pattern to send the requests to my websocket server, and i use the same instance to delegate the server response.
In Android i was going to use the same pattern, with a callback object in my activity to redirect the user after getting a server response.
I need my app to keep the socket connection open until we got the right status from the server, even if the app goes in background.
Some people recommend using Service with Broadcast receiver instead of Singleton. Is it the best thing to do in my case ?
Using a Service is exactly what I have done for very similar purposes (doing socket communication for Bluetooth and TCP/IP applications) and think you'll certainly want to be using a Service if the communication should continue even when the user has closed the application.
A Service is essentially a means to run code on the UI thread (but of course you can then start off other threads within it) but without a user interface, unlike an Activity which has a UI associated with it.
If you were to try to do this in a static singleton class as you propose as an alternative, then I think the problem would be that you wouldn't have very good control over the lifecycle of it. If the user navigates away from the application, then my understanding is that it's up to the framework when it chooses to remove the process and all the static objects along with it. For this reason, if you have singleton classes populated with data and you exit your application and then later come back to the application, you may or may not find that the 'old' singleton instances are still around. For this reason, in my application (which uses a very large amount of global state) I've resorted to holding my singletons' actual instances in an extension of the .Application class, to (hopefully) better control their lifecycle.
With a Service you have a well-defined lifecycle with appropriate lifecycle callbacks (onCreate(), onDestroy(), etc.) just as you do with an Activity.
Yes, definitely use a Service. From the docs:
A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user
While using a singleton might work for a while, your application would be prone to being killed by the operating system when it goes into the background unless you have a Service. If you're more comfortable with the singleton pattern, you could implement it in a singleton and then just tie it to a Service simply to maintain its lifecycle, but that seems more of a mess than it's worth. Note that you shouldn't do network operations on the UI thread and by default a Service runs on the UI thread. You'll need to spin up another thread to do your work.
I don't see anything in your post that demands a BroadcastReceiver, though perhaps there may be some network related broadcast intents that might be useful like android.net.ConnectivityManager.CONNECTIVITY_ACTION.
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.