In my Android app I have a service that is started via AlarmManager. I want to have an activity that will display some progress/status info for this service. Since I already have 90% of the code done, and the service is working fine as-is, I'm wondering what is the easiest way (if possible) to just have the service report progress info to the activity, only if the activity is running.
I saw "binding" but I think that might only work if I want to start the service from my activity and bind to it. Possibly a broadcast receiver?
I would like to be able to report status updates fairly often, maybe even several per second in some cases, so I don't want to do something like use PreferenceManager.
Does my service and activity run in the same application scope? If so, maybe I can create a singleton static object to share status info? The status info can just be a string, that is all I really need.
You can use a Broadcast to "emit" data from your Service. Then in your Activity have a BroadcastReceiver for this same event. When no Activities are running that respond to that broadcast then nothing will receive them.
Related
I have an app with 2 services :
MessagingService extends FirebaseMessagingService
and
InstanceIDService extends FirebaseInstanceIdService
There are declared in the AndroidManifest.xml file.
The problem is that when my app's process is forced close itself, the services are also killed.
I'd like them not to be killed. I've heard about the START_STICKY flag for the Service class, but I can't override the onStartCommand() method in these services so as to return this flag...
To answer to the comments, I didn't find any "solution" to my problem because it's not a problem. If the user wants to close my app, he has the right to.
Since my onMessageReceived() method belongs to my MessagingService in my app, if the app is force-closed by the user, neither the app nor the service will restart.
As Weishi Zeng said in the comments, the "settings force close" stops all about my app including the services, so the notification is received by the Google Play services but my app isn't here to see it. Then the onMessageReceived() method is not executed.
However the service is not closed with the "swipe close".
Eventually, I didn't want to find any workaround since this would be contradicting the user choice.
See here.
I want to create a service that runs in the background,
service upload files to a server .
meanwhile you can close the app .
the service continues to work ,
at the end and, if the app is open must update the UI of the app .
as you update the UI of the app if it's open ?
I have to make a check of the type : if app open ui update ?and how to do this ?
Use an event bus, such as greenrobot's EventBus or LocalBroadcastManager. The service can post a message to the bus, announcing any state changes. The activity — if it exists — can subscribe for messages from the bus and update the UI upon receipt of this state-change message.
I have sample apps demonstrating this for greenrobot's EventBus and for LocalBroadcastManager. I also have one for Square's Otto, though it is a bit more complicated due to threading issues.
I have an application where I want to upload some data as soon as the wifi is turned-on even if the application is not running. I think this can be done using android background services. Please help me uploading the data using background services when the app is not running or suggest me some other way to achieve this.
Thanks in advance!!
To be more eloborate, implement following
Create a Started service (service which is started using startService() instead of bindService().
Implement onStartCommand() callback of this service. In this callback method check if there is any data to be uploaded (if this data is created by an activity, it is wise to use a DB table to queue the data to be uploaded and service picks up data from that DB). Check WIFI connectivity and if available upload the data.
Now you need to trigger this service whenever WIFI is available. Here you 2 ways to imeplemnt
Method 1 : register in your application manifest file to be notified of WIFI connectivity changes refer this link . registered broadcast receiver would be called when WIFI state changes. from the broadcast receiver start your service if WIFI is available
Method 2 : using AlarmManager launch you service periodically (say every 10 minutes). refer this link. This method would be beneficial if data to be uploaded gets generated once in a while.
Hope this is helpful. Let me know if you have any questions.
You must use an unbounded service, who is completely independent for the activity (for more details check this ). After starting service monitor your internet connection using ConnectivityManager. Use this like example. Have Fun.
My main app starts 2 services Input-service and Save-service. My Input-service is generating input which i am able to show in my Main app and my both services are starting successfully. I am facing problem in calling one service from another. Means how can i send data of Input-service to Save-service. Is there any example which shows communication between two services. Or can anyone help me regarding this.
Why not use BroadcastReceivers? Register them in onCreate, de-register in onDestroy and send data through intents ...
Fellow struggling programmers,
I've consulted all the documentation concerning c2dm but am still looking for some advice. Do I need to implement a service within my application to listen for the Intents created when the google server pushes them to the device?
http://android-developers.blogspot.com/2010/05/android-cloud-to-device-messaging.html
https://developers.google.com/android/c2dm/
The documentation states it will wake up the app when the Intent is received by having the correct Intent filters and permissions in the app manifest. But how is that possible when the app isn't even loaded into memory? How does the OS know where to go?
Seems to me like I need to have a background service with those permissions which will then start my app when a notification is received.
Anyone have some insight on this idea?
perhaps someone who has implemented a background service using c2dm
or found it to be unneeded.
Intent filters do not require an application or service to be started. When the OS sees that an event has occurred that you have registered an Intent filter for, it will launch the Intent that the Intent filter is attached to as indicated in your manifest.
In general, you don't need a service. It depends on what kind of reaction you need to a message. If you want to start an activity - feel free to do so straight from the C2DM message receiver.
By the way, the C2DM intents are not service intents. They're receiver intents. A service cannot catch them even if it wants. On the API level, you can't fire an intent per se - you have call startActivity(), or start/bindService(), or sendBroadcast(). Depending on the API called, the system will match the intent against activities, or services, or receivers.
I've implemented C2DM. In my case, I do have a service - but that's only because the reaction to a C2DM message in my app is a UI-less HTTP request that may take some time. This seems a rather common pattern in the grand scheme of things - a C2DM is only a trigger, it only tells an app that new data await at the back-end. In this scenario, a service would quietly query the back-end for the said new data and process them. That's my case. But it does not have to be this way.
A receiver alone is not a good vehicle for HTTP because receiver objects are transient - once an intent is delivered, Android assumes that the receiver is done and discards it. After that happens, the app's process has no running objects and is subject for shutdown anytime. A service, on the other hands, once started, runs until it's explicitly done (stopService() is called). That tells Android that the app is doing something, please don't terminate. A running service is not a rock solid guarantee that the app won't be shut down in case of a low memory condition, but it's better than nothing.
Technically speaking, your app is running even if the only thing running is a broadcast receiver. Android will start the app (the process, not the main activity) when a C2DM message arrives. The user won't know unless you flash some UI. It's up to you which other components of the app to invoke from the receiver.