I'm working on the Android version of an application I first created on iPhone and this application requires to send (if it's as successful as its iPhone version) up to millions of push notifications to users daily.
I naively thought the Android platform had a push notifications service as its sibling so I decided to look at this feature at the end of development and now here i am!
I searched stackoverflow for answers about this feature (issue ?) and found several options (thanks guys!) BUT did any of you guys was able to achieve such a feature with such a volume?
Here's the options I found :
Google's C2DM Framework : my first issue is that it's for Android 2.2 + only but I may consider it if there wasn't this 200.000 notifications a day quota; did any of you guys requested more quota from Google ?
MQTT : this solution looks good and the sample code provided by Anton Lopyrev is helpful (and Dale Lane blog posts are a good read); this is the option I'm using right now but I have no idea about how it may react with thousand of users (I also have trouble with the server (mosquitto) OR the service (I don't know yet) and I am not able to receive notifications sometimes with 2 users :p)
XMPP : it looks like the best option (yet ?) but I haven't tried it yet; did any of you guys use this solution ?
I've read about Xtify or Urban Airship but none of these commercial solutions may help (volume or cost).
Thanks for any tips!
Edit : my goal is to be able to send up to 5,000,000 notifications a day
200K is the development quota, we'll be happy to grant you more if you need it. Android 2.2+ represents >80% of Android devices in the field today. We typically turn these requests around pretty quickly.
http://developer.android.com/resources/dashboard/platform-versions.html
All I would mention is that XMPP can be pretty verbose, you might want to look at MQTT if you want to keep your network usage low as it is very efficient.
If you are trying to send many million notification or presence packets, SoapBox Server 2012 is capable of sending over 100k message per second on a single server as well as concurrently connect more than 250k users.
Our 8th generation platform has been designed for non instant messaging use cases, such as Remote Device Monitoring (RDM), Cloud Message Bus, Software Defined Networking (SDN).
You can download a free trial of our XMPP Server and XMPP SDK at our website.
Update: according their blog post Notifo Will Be shutting Down. But that blog post is already more than a year ago and I believe they are still up and running
Also I would like to point you out to notifo which is pretty cool. I don't know about if they have a quota at all, but I guess you should sent them a message, which generally gets responded within a day.
Base on my investigation, if you want to use C2DM,the google framework must be installed in your android device. If you have google play, that implies google framework is installed.
Related
I noticed that Google C2DM quota is limited to 200000 messages per day. This makes me thinking that it should be used for very simple use cases. Now I understand why IM services like skype or others have a service always running on the background. Does a library exist to manage a persistent connection to the server? I have tried XMPP with Smack api but even if it is very good for desktop stable connections, it is not so suitable for mobile ones (that have many problems). I would prefer a simpler one specific for mobile applications. Does it exist?
Thanks
What are you trying to do here? Google C2DM quota is a soft-limit. If needed, you can email them and perhaps agree on some sort of business deal with them.
If you are looking for push-like experience, you can check out Urban Airship. They made their version of service that works on the Android devices without C2DM support.
I would recommend checking out Deacon. There is Android specific code and it runs as a service in the background with a connection to your server.
This is an edit of a question I asked about a week ago.
I'm working on an Android app which communicates with the users' home PCs to control some 3rd-party PVR software running on the PCs. The model is as follows...
Android app < - wifi/3g -> Windows Service <- localhost -> 3rd-party PVR software
The Windows Service is written by me (C# .NET) and acts as a proxy between the Android app and the PVR software.
What I'd like to do is use C2DM to notify users of various things - one example is if one family member sets a TV show to record, a C2DM message is sent to other family members' devices so everybody is up to date.
I now seem to have 3 possible options for how to proceed. The Windows Service is a key player in the system so plays a part in them all but I don't know what the best approach is.
Use the Windows Service as the C2DM 3rd-party app server. Downside - I need to embed my C2DM credentials into the software and there will be potentially 100s of servers around the world requesting authentication tokens (not sure if Google would allow that).
I have a hosted web server I could use which allows PHP/MySQL. The Windows Server would simply act as a relay but my PHP experience is minimal and I can't find any comprehensive PHP examples for C2DM.
Use Google App Engine (again with the Windows Service as a relay). The problem is I don't know if Google are happy with GAE being used as a C2DM app server although I've seen a few mentions of it.
I've basically Google'd until my head hurts and keep coming back to the same tutorials and partial code examples. I know how C2DM works and actually have option 1 working in my dev environment but it doesn't seem like a good option to go public with.
So (trying to keep my question as objective as possible)...working on the principle that option 1 is not a good idea, are there any reasonably comprehensive PHP examples out there for a C2DM app server or, alternatively, does anyone know definitively if GAE is an acceptable approach?
With C2DM you can target the device that the message goes. So in you example the one that sets the TV show sends a message to the Windows Service to notify each one of the other users.
You can do that with 1 C2DM server
UPDATE
I whould go with the 3rd server.But of what i can tell you are not sure about the structure. Shared now GAE later maybe finally ec2. What can you actualy do is to create a CNAME that points to the server of choice.(less hard coded). I don't think that GAE cannot be used for C2DM. It's a simple server with http requests.
I have developed a simple two player chess game in android to be played using Bluetooth. I want to extend it by making it possible to be played through internet. whenever a player makes a move, the move should be transferred to the other player via internet.
How to make this possible?
I have heard of C2DM mechanism.Does that suites the scenario i described and is it reliable?
Thanks:)
Yes, C2DM is ideally suited to this type of game. This is what I am using for my own game (http://www.chesspresso.net) which is a correspondence chess client for android.
Things to consider when using C2DM:
You don't send the info to the devices, you notify the devices that a move has been made. You don't use C2DM to transfer data, you use it to notify that something has changed.
Its available for 2.2+ Android, which is the majority of devices. But if you wanted to support older devices you'd have to consider an alternative. I am using polling for older devices.
You have to request for developer access, then once your app is ready you have to request production status. If you don't do this you'll hit the developer status quota very quickly once its released! They are very generous with production quota, but you have to explain what you're using it for and it also can take a few weeks to get accepted!
Your users will have to have a google account that is authorised, otherswise C2DM won't work. Most users will have an account associated with their device, but some don't so this means that you'll possibly want to validate for the presence of an account to notify the user.
Its reliable, but every now and again a device will have to wait for the message. Sometimes a few minutes. Usually its instant.
Hope that helps!
UPDATE:
C2DM has now been deprecated, and replaced by Google's GCM.
Also, I strongly suggest looking at other options as tying yourself down to a Google specific API means you won't be able to support external marketplaces. For alternatives, I am currently evaluating Amazon SNS and I will also be looking at Urban Airship. There are possibly other alternatives I have not considered evaluating yet.
UPDATE:
Evaluation update of non google based push notifications:
Amazon SNS is just not a project for this task and Urban Airship for the vast majority of apps is too expensive. Unfortunately all the other alternatives are all very expensive also, especially if your app (like mine) relies heavily on push.
A good way of doing that is using a simple direct TCP connection between the peers.
If you're new to socket programming on Java, try this:
All About Sockets
Another option is to use some sort of IM as a communication medium for app. For eg. Use Asmack to connect to XMPP Im like GTalk. Prompt user to create an account there, for your game.
And use it to send and receive commands via IM. This way you won't need to setup your mediating server.
This works if user knows who he is playing with. To collect the user data and let them search for available players, you still need to setup a server. IRC chat room may be an option to avoid this also.
GTalk was just an example. You can use any IM or IRC also.
C2DM it's not design to transfer informations, even if they are small like "horse in b4" or things like this. It's designed to inform the device of something, maybe a newer version of a document or more articles on a website.. Stuff like this.. It's not designed to communicate device to device. And also it may be not fast enough for a real time chess play.
You should look for a more traditional way of communicate via internet or to search for some libraries (I'm pretty sure that something exists..) that will help you.
IMHO, C2DM is exactly the kind of thing you would want for a chess game; to be notified when the oppo has made his turn (which may be minutes /hours / days later ?). I have discussed my game with a few google android devs and they've stated that C2DM is ideal for this. You'll need to go via a centralised server though (well, not essential but very advisable) as there may be issues with resync'ing game state etc. Worried about "hitting the limit" ? Well, for a start my c2dm acct is restricted to "just" 100,000 messages per day. I guess you're buying the drinks if you hit that !!
Chess is often played by email. You could do that.
Of course, any centralized/federated messaging system will work.
What might be better for your use is to add a jabber client to the application and have the program generate an account name that is used for automated messaging. You could host the jabber server or generate the accounts on a free provider.
Google App Engine if you know Python or Java.
Alternatively there are two web app API styles in wide use today: SOAP XML and RESTful web services.
If you know RoR I would recommend using JSON/REST, because you can just use Phusion Passenger with Apache to deploy your app. Free, extremely easy, and makes your server very reliable.
You could, and I only mention this because my friends do this all the time, use twitter as a server between the games.
I also found a lib called mages which looks quite promising.
Good luck.
I did this for my online 2D rpg: http://developingthedream.blogspot.com
Basically, use a middle-man server to co-ordinate data between all your clients.
You simply open a socket and communicate with the middle server and it takes care of passing on the information to any other connected clients.
I wouldn't recommend C2DM because of the message limit, and because the latency is still to big. Using your own server you can optimize it, plus you'll be the only one using the service so your data will be delivered faster.
I think that C2DM is not right way for playing chess because there is no warranty that messages will be delivered. You need more reliable way for data transfer
Can anyone give me a comparison for android push notification services.
Mainly I want to compare these services.
MQTT - http://mqtt.org/
XTIFY - http://xtify.com/
Mobile Push - https://labs.ericsson.com/apis/mobile-push/
Google's C2DM server
These are partially apples and oranges, however you can get the same push notification effect with varying degrees of difficulty. Full Disclosure I currently use Xtify in my Android app to great success. I'll try not to be biased, but I did choose it for a reason.
MQTT is a wire protocol which specializes in low overhead and queue tolerance. You will need to implement (or find open source) server-side and client-side programs to use MQTT, which will require a fair amount of development time. Java's not great (unlike C) in my opinion at dealing with low level abstractions like network I/O. Benefits resulting from speed/reliability will depend on how good your implementation is.
Xtify is a mature 3rd party push service with some cool features like geo-notifications, timed alerts, statistics, etc. Big benefit to you is that your overhead is low, and it will just work (no time spent debugging low level code). There are several APIs for creating and configuring notifications, pushing, and getting information. Integration of the Xtify SDK into your app will take some time, but I found their support to be very responsive. Xtify announced they will be supporting C2DM in the future.
Mobile Push is another 3rd party push offering by Ericsson which has SMS capabilities (Xtify does not). They have a web API for sending pushes but you do have to write the code to handle the notification once it's received in the app. Another thing to note is that it doesn't look like this project is still under active development. The last version was released in September 2010.
C2DM Is a google offering which is still technically in labs (active development) but is looking like it will be the suggested method to send pushes to Androids in the future. This is pretty barebones push and requires you to handle the notification once it's received like the other 3rd parties. A key discriminator is that only Android OS's 2.2 and above can be reached by C2DM.
Summary
In terms of getting not locked into a product, either Xtify or Mobile Push seem to be pretty good. You can always rewrite web API's but switching to a new solution after writing your own protocol specific interfaces will be harder.
In terms of features Xtify wins out, plus if you ever decide to convert your app to iPhone or Blackberry, it's the same interface.
In terms of simplicity probably Mobile Push is the winner, but again, I would be wary of building production code around out of development or orphaned APIs.
Good Luck! Hope this helps.
I'm currently writing an Android application that should be able to receive push notifications from another application hosted in Google's App Engine.
Since I can't use sockets in GAE, I though maybe using XMPP over GTalk server would solve my problem. But that way the Android Application would be connected to the users Gtalk account and thus showing the user as being online, when in reality the user is not.
Any way of achieving this kind of communication without showing the user as being online, and without asking the user to create a separate account?
Or any free push notification alternatives?
EDIT:
I'm targeting 1.5+ Android devices so C2DM isn't an option.
Thanks!
May be you can use the channel API: Building real-time web apps with App Engine and the Feed API
Not sure about the exact requirement of your app, but.. perhaps C2DM can be an alternative?
http://code.google.com/android/c2dm
I've found the PubNub service (http://www.pubnub.com/).
It enables push notifications through API's on several platforms (PHP, Ruby, JavaScript, Java, ...).
It's a paid service, but provides a free daily quota.
Although it's not the ideal solution to my problem, it'll have to suffice until some Channel API documentation comes out.
Thanks to all of you!
Why are you shying away from HTTP/JSON? Might be useful to know why you discounted the obvious solution...