At the request of a new Fortune Global 500 (South Korea-based) customer, with whom we have recently signed an enterprise-wide license with premium support for MigratoryData WebSocket Server, we have developed a new MigratoryData API for building Android apps able to push notifications to end users even when the mobile device is in “sleep” mode.
MigratoryData WebSocket Server is certainly most appreciated and in demand for its ability to reliably distribute real-time data to a large number of web clients.
However, our customers want to leverage the high scalability and the enterprise features of MigratoryData WebSocket Server and use it to distribute real-time data to mobile clients too – not only to mobile web browsers but also to native mobile applications.
As a result, we’ve extended our client API for JavaScript, used to build pure real-time web applications accessible from any standard browser, to mobile technologies. In this way, we’ve developed client APIs for Android (Java), Windows Mobile (.NET Compact Framework), iOS (Objective-C), and BlackBerry (Java ME).
The new MigratoryData Android Push Notification API enhances the existing MigratoryData API for Android with the ability to push notifications even when the mobile device is in “sleep” mode.
A push notification is similar to an SMS notification. However, the push notifications can be sent at almost no cost, the delivery is instant and guaranteed.
The new API implements all the features of the MigratoryData Client APIs, including:
- Encrypted SSL/TLS Connectivity
- Load Balancing and Fault Tolerance
- Guaranteed Message Delivery
- Entitlement
Also important to note is that this API connects end users directly to the MigratoryData server using a persistent TCP connection (even in sleep mode) and without using the Google GCM (“Google Cloud Messaging”) service. Thus, data is delivered directly and securely to mobile users, without the need to pass through a third-party service.
The API will be available shortly via our download portal but if you want to try it sooner, just let us know.
P.S. I promised some new benchmarks for MigratoryData WebSocket Server version 4.0 but of course premium customer support is MigratoryData’s top priority. I hope to be able to perform the new benchmark tests shortly.
Scalable Realtime Messaging 
It sounds like the MigratoryData system is making great advancements in high performance WebSocket infrastructure. I have a question regarding the push notification design, and the ability to push a notification to a device in “sleep” mode:
What is the impact (if any) to battery consumption on the device?
Thanks for your question, Robert.
Of course, keeping a socket permanently open (and exchanging at minimum some heartbeats) has a certain impact on the battery consumption. However, we ran a number of battery life tests and the results are good.
So far, we’ve done battery life tests with guaranteed message delivery, rapid detection of a connection failure, and immediate recovery (reconnection to another MigratoryData server of the cluster). This is the most demanding scenario in terms of battery consumption.
Different quality of service levels will be shortly added to the API to further improve the battery life. Then, we will perform rigorous battery benchmark tests and I will share the results on this blog.
Does your WebSocket Server run on Windows Server? If yes, does it utilize WCF?
MigratoryData WebSocket Server is written in pure Java. So, no, it does not use WCF, and yes, it does run on Windows, Linux, Solaris and potentially on any platform with support for Oracle (Sun) JRE 1.6.
Which solution will scale faster (horizontally, from 100 users to 1000 users, for instance) in your opinion: send information through PUSH notifications or send information through websockets? Does MigratoryData have in mind some thing to allow the both notification methods or, at least, to switch between them?
Hi Jose,
Push notifications use HTTP streaming along a single persistent TCP connection like WebSockets use. For each message pushed by the MigratoryData server, HTTP streaming adds a few bytes overhead compared to WebSocket communication. But this difference is negligible concerning scalability.
Finally, our client libraries automatically select the best transport available for a client either WebSockets or HTTP streaming or other transports.
Thanks,
Mihai
Can I use the WebSocket in the localisation (android)