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.
Related
We have developed a Google Action with Dialogflow that responds to personalized requests from users and performs some tasks that require a certain amount of time, usually several minutes.
Our goal is to announce the result of the tasks using the "Broadcast" feature of Google Assistant, but we can't find a way to send the command to Google Assistant.
Our agent receives the user's request and launches a Java application that executes the task, so it is the Java application that must communicate with Google Assistant when the process is finished.
From the Java application we can communicate with the agent using Dialogflow RPC API, but not with Google Assistant.
Is there any way to send the request to Google Assistant from the Java app? or... since we can communicate with our Google Action Agent... how could we send the request through the agent?
In other words, could the agent communicate with google assistant to use any of its features, for example, "Broadcast ..."?
We have checked Google Assistant SDK as alternative, but we are confused about it.
Please, excuse me for my bad English.
Any help would be appreciated. Thanks!
The "Broadcast" feature is not available to user-developed Actions, and probably not a good scheme to use in any event - if users will need to wait for a while for an answer, they probably don't want the answer suddenly announced when they're not expecting it.
Actions are typically meant to be conversational, rather than taking a while to reply with the answer, which is why there is a 5 second limit on how long the fulfillment has to do processing. If you do need to take a while, you have a few options available to you:
First is that you can use some other method outside of the Assistant to deliver the answer - possibly using something like Firebase Cloud Messaging or sending email to the user.
Similarly, you might be able to use notifications. In this scenario, your Java program would send a notification through the Assistant to the user when the information is available and store the result. The user can then activate the notification to continue the conversation and get the result. This has the advantage that the answer isn't just blurted out, possibly when the user isn't ready for it, but does have a downside that speakers don't (yet) support notifications.
You can also look into using a Media Response to set up a way for you to poll for new messages periodically. Under this scheme, you would fire off the Java program which would get the result and then store this in a way your fulfillment server can access. In your reply to the user saying you're working on the results, you would include a Media Response for some audio that plays for, say, 15 seconds. When the audio finishes, your Action will be called again and you can check to see if the result is available. If so, you send the result and continue or end the conversation. Otherwise, just send a Media Response.
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 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.
I created a service or application (whatever you call it ;)) which use Location and SMS REST API which are provided by Telecom. I hope that i do not have to explain what that APIs do, but first is obtaining a mobile phone location and second one is sending SMS to mobile phone.
I was wondering which, mainly in telecommunication way, parameters are used to describe parameters which are important for those APIs. I think it will be :
-response time, maintain services under heavy load, service delay, maybe CAPS (Call per second).
That's why i would like to ask, what more it can be tested with those APIs...to combine with the requirements of the telecom
If you use "REST API" it means that you use high level API and talk with the network through gateways which take off most problems.
But if you talk with SMSC or USSDC directly via SMPP, then the rule number one is "send acknowledge packets(responds) as soon as possible", or it will resend you SMS again. USSDС will hold signal link till you send answer to client. And so on. But it isn't your case... you use gateways that keep network in safety.
Location services are not so capricious.
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.