I am new to android and would like to seek for advice regarding to GCM as questions below:
For the third party server, is it free to use any programming language as long as follow exactly the request format to GCM server? Is there any example to refer for using asp.net?
For the non collapsed message, GCM discard all msg if exceed 100. The maximum number 100 is for total message of the only one device OR total of pending message in the third party server?
For collapsed message so called send-to-sync, If exceed this number GCM will only keep 4 collapse keys, with no guarantees about which ones they will be. I don't really got it, can anyone further explain to me with some examples?
For the time to live, it takes advantage of concept "now" or "never", the "never" is it alerting to trigger another attempt to send the same message again?
Currently I am testing the GCM with the demo sample from here, I experienced unstable of message receiving on emulator with 2.3.3v. In other words, the message could be never reached, or delay up to 15 minutes/more, or received immediately sometimes as well. Even I tried out on jumpnote and chrome to phone apps, that is same case. Can anyone share the experiences or solutions?
Is there anyway third party to get know the results when the message arrived targeted device?
To complete the registration, the Android application sends the registration ID to the application server. This process is via GCM or our personal components like web service or POST?
For the canonical ID, how does third party server get the ID of the last registration requested by application.
Much appreciate for any reply. Thanks.
Related
We're building an application server which will be used to send push notifications to android and ios clients via GCM connection server. Our plan is to use HTTP interface to connect with GCM as we only want downstream messaging. could you please tell me what is the performance of GCM for HTTP interface? I'm looking for some kind of performance data like how many push notifications messages per second GCM can support? I checked GCM site but couldn't find this. Please help to guide from where i can get such data?
as per the official Google answer
The rate limit exception code indicates that you are sending messages from a backend server too frequently. To ensure a stable service, there is a per minute / per device app upper limit on the number of messages that can be sent from a backend server. This limit is set high so most well behaving apps should not be affected, all apps should however be prepared to receive this error code.
They do not specify the "actual limit" but they do say This limit is set high so most well behaving apps should not be affected so as long as you re not spamming a single device like crazy you should be ok with whatever you send at it.
However please note that you can get throttled and have the messages be delayed
I am finding difficulty to know about in-App messaging.
And how to do it.
I have the following things in my mind,
in-App messaging:
Is an idea to receive contents from a server only the app is alive on screen.
This is possible only the app is active.
App should make a call to server and needs to receive contents.
Push messages
Is an idea to receive contents from a server even though the app is not active.
This is possible at any time, we can notify users while our app is closed and running also.
App do not need to make a call.
But the app should have code implemented to receive push notifications.
We can use GCM for Android and Push Notification for iOS.
Am i right with my understandings ?
If i am not and i missed something , please give your hand to take me out of this confusion.
Thanks,
When I think of in-app messaging, to me it means that you're sending a message from one part of your app to another. "Sending a message" is a very generic term that can be accomplished in a number of different ways. Among others:
Sending a broadcast to a message receiver. You'll need to call sendBroadcast to a BroadcastReceiver.
You can pass a Handler to another component and it can post messages to your handler where they're processed
You can use a third party library such as the open source "otto" library
You can build your own version using the observer pattern.
For push messages, your understanding seems about right. However, look at this post for details on the last item, "We can use GCM for Android and Push Notification for iOS".
You are right, though I would change the term in-App Messaging to Pull Messages, since you are referring to the app pulling messages from the server, while in-App Messaging implies that the application is sending the messages.
You points are mostly correct, though Pull Messages does not require the app to be in the foreground (on screen) - a part of your app can run in the background and fetch messages from the server. This is more doable on Android, since iOS limits the operation an app can do in the background.
Another point that should be added to your list is that Push messages also have the advantage of conserving battery life.
In-App Messaging can also be viewed from another standpoint. AT&T has an API for In-App messaging that allows you to send SMS cross carrier. The API can be found here. along with others. From this you can imagine the ability to message from within an app, say a game or a social app and retrieve responses. There are examples for all the platforms you have added as tags. It might be good for you to look this over as it can expand your understanding of the concept in a different direction than the other answers, Somewhere in all of these you will find what you are looking for.
I planning the application pushes a newsletter to all registered users.
Number of users is approximately 200,000 ~ 300,000.
I'm caring about the traffic issue with google c2dm server.
Can I request to c2dm server in a loop with large number of users using HttpURLConnection?
Will I banned?
I heard something about in this case I must use http 1.1 protocol with keepAlive set true.
C2DM does have quotas, both on the messages per device and total number of messages. you can find the details here:
http://code.google.com/android/c2dm/quotas.html
as it says, 200k is the default limit but you can request a larger quota. i've done this at a company and it was no problem, but i can't say for sure how helpful they will be to the average developer.
as far as i know, there's no quota on the rate that you send them. you can send them as fast as the google servers will accept your requests.
I planning the application pushes a newsletter to all registered
users.
you should make sure you aren't trying to push a payload through C2DM. that's clearly a misuse of the service. C2DM must be used to wake up the device only. in your case, the message itself should be "hey device there's a new newsletter on the server, go get it". assuming that's happening but a few times a day at most, it will be within the accepted use for C2DM.
So I have a strange problem, my app has C2DM setup and and it works for the most part, however there is quite a few people who never get registered. So the flow is as follows. On login, we make the registration request, when we get the response on that it submits the registration id to my back-end server and stores it in the database. For some reason I can see that some people logged in just fine, but I never received the registration id on the server, any ideas? I haven't be able to reproduce this my self, but it is affecting a lot of people using my app. Any suggestions on how I can make this more reliable? Because when the C2DM does not work they tend to not stay and use my application.
Any help or advice would be much appreciated.
What do you do on the client side if the registration fails? It could fail for a number of reasons. It'd probably be a good idea to send the status to your backend in failure cases so you can track that. Personally, The most common failures I see are due to not having a logged in google account or having background data turned off in settings.
Could the users in question be on unsupported (pre 2.2) devices?
C2DM in intended for android devices running Android 2.2(API 8) or higher that also have the Market application installed. However, you are not limited to deploying your applications through Market.
Also make sure you make the C2DM registration at very beginning of app start say splash screen. As the C2DM to register and obtain the REG_ID take about 3-4 sec depending upon the network connection.
Also make sure the devices that it is having problem that you reported might be showing the ACCOUNT MISSING:: OR ERROR IN REG_ID when C2DM registration works
I have implemented Android In-App purchase based off of the Dungeons example. The dungeons example however did not cater for applications that required communication with a remote server before content could be delivered. I edited the code to allow this.
The Developer Documentation has this to say about remote server content delivery
Keep in mind, you must send a confirmation when you receive transaction information from Android Market (step 8 in figure 2). If you don't send a confirmation message, Android Market will continue sending IN_APP_NOTIFY messages for the transactions you have not confirmed. As a best practice, you should not send a CONFIRM_NOTIFICATIONS request for a purchased item until you have delivered the item to the user. This way, if your application crashes or something else prevents your application from delivering the product, your application will still receive an IN_APP_NOTIFY broadcast intent from Android Market indicating that you need to deliver the product. Also, as a best practice, your application must be able to handle IN_APP_NOTIFY messages that contain multiple orders.
My Implementation follows this and does not send a CONFIRM_NOTIFICATION until i am happy that my server has unlocked the content. However I have noticed that if i do not send hte CONFIRM_NOTIFICATION (this could be possible if the network drops or my server is down)then i do not continue to receive IN_APP_NOTIFY intents as stated in the documentation.
Has anyone experienced this before? Is there any solution? are the docs not up-to date?