Notifications for mobile devices are way too complicated to get to work.
There is APN for iOS devices and GCM for Android devices—that means supporting two separate stacks just to send the same notification. GCM for iOS is the new kid on the block, but it doesn't really solve any problems: the interface for sending a notification to iOS is still different from sending one to Android.
Notifications are anything but client agnostic. But that's not the only problem.
On the client-side the code to receive notifications is insanely complicated. Oh, you can figure it out—but should you really have to set up three different services and blindly copy-paste some code from a tutorial to get to receive your first notification?
There is no low-barrier-of-entry way to receive notifications. There is no simple on-notification-do-this abstraction.
First step is building an interface for notifications that works no matter the client. Send one request, any number of recipients, and it just works.
The Unified Interface is live in a free prototype, and you are encouraged to try it out!
Check out the Unified Interface!What is a registration id? A token? A notification key?
Do you actually care, or do you just want to receive notifications?
I bet you don't care. This project will abstract away all of the internal keys used, and let you identify users by the handles you already use in your system.
Currently in development …The client-side code for receiving notifications is needlessly complicated.
This project will provide neat abstractions for easily registering and updating registration IDs and listening to notifications.
Being able to do this with less than 4 abstractions, and hopefully without always-identical configuration code would be top notch.
This project should support at least Android and iOS.
Currently in development …