Develop Reference

Receive update from server with mobile framework

I'm trying to make a mobile application and I found ionic framework which seems cool.
It seems that REST is a common way to do things and I don't understand one thing with this protocol. How does the server notify that he has data to send. If we have a text application, how does the server notify the application (without push notification, or maybe they're mandatory ?) that another client sent you a message ?
It seems like REST is only good for the requests coming from the client. Does it means that I have to send request for update every X milliseconds to have a responsive application ? Do I have to use websockets for such purpose ? I also saw Comet, is it a good way to use rest ?

The REST architecture doesn't really address "Publication/Subscription" (pub/sub) paradigms. It's much more coarse than that.
The major issues with pub/sub are technical, especially today. In a fully connected internet where everything is online at known locations all the time, then the basic REST architecture just works. Simply, the roles of Client and Server swap back and forth (i.e. the Server becomes a Client when it needs to send an notification).
But that's not the real world.
The real world is while we have a lot of connected devices, we do not have a lot of known locations. Your phone moves around all the time, and who knows what IP address it's at at any one time. DNS doesn't help because your phone is likely not registered under any particular known name. Then there's infrastructure issues where the vast majority of clients are locked away to where they can send messages, but can not receive them, even if we did know who and where they were.
So, REST doesn't explore that area simply because it typically violates a few key attributes.
One is that the URL goes away. Since we don't know where or who you are, we can't get to you by name. So, one way folks get around it is through long lived connections. Your client hooks up to the server and retains its connection so that the server can talk back. But this is an implicitly stateful connection. REST drives towards statelessness, and is effectively connectionless at the architecture level.
So, in that environment, REST is not an appropriate architecture, since the mechanics can not support some of the fundamental precepts.

Active MQ security and scalability

I've currently setup an Android and iOS app to use ActiveMQ MQTT for my message relays. It all works fine but I have the following questions that I would be grateful if anyone could help with:
1) As I understand, all clients need to keep an open TCP connection to the MQ server (for obvious reasons) and subscribe to topics and when a topic is published, the subscribed clients get a notification. If the number of clients is in the millions, it would mean millions of active open TCP connections. What are the ramifications of such number of open connections to a server? Is there a better way to handle the situation? Would you recommend instead to connect say once a minute or so, query for the "State of the world" (i.e. the latest unread messages) and disconnecting the clients? or am I being paranoid and millions of open TCP connections is fine?
2) On the subject of security, I understand that I can use SSL which is great but I still don't understand how to prevent a third party from subscribing to all topics (or even individual topics)? As far as I understand, clients need to connect to a server and subscribe to a topic but what would prevent a third party application from doing the same? How would I prevent such a thing and make sure that only clients from my app are able to connect and subscribe to their own topics?
Many thanks in advance for your help,

If you do reconnect , you will need to make sure your clients create durable subscriptions. If not, you miss out on anything that was published between connections. This can also be a scalability issue that you will need to consider. With millions of connections you will want to consider using a cluster, or some sort of topology that supports load balancing, regardless of approach you take. Constantly reconnecting clients can cause unexpected overhead as well as the Broker(s) attempt to keep up with everything that is coming and going. A big part of your decision will be based on your hardware as well as with any server.
This only scratches the surface of topologies, but here is a good starting point.
Edit: Added information to try to address your concerns on millions of connections that I meant to add the first go.
You can set up role based security via authentication plug-ins within ActiveMQ. Each role/group can be set up with a pattern using wild cards to allow access to a specific topic tree.
See this page for more details on setting this up.
Here is another site with good information that should answer your questions on how to and how it works.

How Does WhatsApp overcome the GCM Push notifications delay?

I am trying to use GCM service, Every thing is OK except of the long delay that GCM push notification or deliver payload... some times it take to my App 5 minutes receive notification or payload.
I need Immediate delivering...
I know about the roles of GCM, that wait until the other device got online, but in my case I hold two devices and they are online, but I got Delayed notifications!
How does WhatsApp(as example of app that uses GCM) overcome this problem.. and send Immediately?
[ i.e (message of the type: typing, online - last seen) cannot be delayed...]
the GCM Delayed Push is known problem : this issue
my question is: How other app that use GCM overcome this issue

The big players
Lets focus on WhatsApp from a scale point of view. Their scale is global and one of the largest in terms of the market share. For players like these it becomes necessary to provide a consistent and smooth user experience no matter what the circumstances are. This means that the "small fish developers" like us are left with pre-defined rules by the big fish companies. Sometimes, it is the implementation that is challenging enough that a lot of the small time developers have to do with whatever is available.
I would like to take WhatsApp's Push Notification as an example to illustrate the above.
First of all, we must stop associating Push notification with Google's services(i.e, Google Play Services) exclusively. Would a device without Google Play services won't receive Push notifications? No, of course it can -- try focusing on the core mechanism of a push notification
How do Push Notifications work - Sockets!
Contrary to a protocol like HTTP which assumes a client-server architecture and is a uni-directional protocol(server can't initiate communication by itself), a plain socket enables communication bi-directionally.
You want to implement your own File transfer protocol over socket? You can!
You want to implement your own Chatting protocol over socket? You can!
You want to implement your own Push notifications protocol over socket? You can!
A socket is the canvas of communication over a network. You can pretty much do anything. Personally we have developed a custom request-response protocol in our organization.
Multiple implementations
Don't stick with default GCM/FCM notification messages protocol or implementation. You can deploy a mechanism to maintain a persistent socket connection with the device and can listen to whatever the server wants to push.
WhatsApp uses both GCM/FCM as well as their proprietary XMPP server implementation for Push notifications
WhatsApp(and several other Apps) rely upon GCM/FCM(as option 1 - the default) as it is present as a system App on lot of devices and therefore holds a special status where it is very less likely to be killed unlike a normal App.
For devices that do not have play services, your custom socket connection is relied upon. It may be that FCM is preferred over socket when the former is available but those are upto you to manage.
From WhatsApp's latest build(2.19.203):
Notice that the relevant permission for FCM is present.
Suspected socket implementation: https://android.stackexchange.com/questions/43970/how-is-whatsapp-able-to-receive-messages-when-not-in-use
XMPP based Push Notifications
From, https://www.quora.com/Does-WhatsApp-use-GCM-to-exchange-messages
No, whatsapp doesn't use GCM[NOT entirely true]. It uses a modified version of XMPP
called FunXMPP instead. It changes the XML keywords in message frames
to save bandwidth as it's users aka mostly mobile network users,
doesn't have a good internet connection. The replacements can be found
here: mgp25/Chat-API (I am not the author though)
They have even asked for whitelisting of any port(custom) in use by them.
So, WhatsApp does it. Facebook does it. Google does it. A lot of these companies do this. You can do it as well(to an extent) using Ejjaberd, Openfire or some other technology and having a proper client side implementation for the same.
Chinese ROMs
Some chinese ROMs have taken it even further and radically changed the way the memory and processes are managed in Android. As an example, in Oppo if the Application doesn't have Auto Start turned on, it will not let you do anything once your App is killed. No hopes of any experience whatsoever except hoping that the user will open the App again. In these cases, these OEMs have whitelisted WhatsApp, Facebook, Google and other players selectively. So, who suffers?
Us. Period.

When sending your notification you could set the priority-parameter to "high".
From the docs:
By default, messages are sent with normal priority. Normal priority optimizes the client app's battery consumption, and should be used unless immediate delivery is required. For messages with normal priority, the app may receive the message with unspecified delay.
When a message is sent with high priority, it is sent immediately, and the app can wake a sleeping device and open a network connection to your server.
I know this answer comes late, nevertheless if you are still facing this issue (or anyone else) please tell me if it helps.

Periodical website parsing consumes high data downloading. Should I migrate my logic to a server? How?

First of all, sorry for my bad English.
I've made an Android app which seems to work fine. Its mission is to connect to a website and parse it to see if there is new data. In that case, it creates a notification.
The data in the website is modified approximately once a day, but at a random hour. And I want to know it as soon as possible.
My app connects to the website every 20 minutes to check for new info, but I realized that it involves a high data consuption on 3G. I've thought that the parsing could be done in a server, and the mobile would just recive a c2dm push.
My problem: I've no idea about servers. I've seen some prices and.. Do I have to expend that high quantity of money in a 800$ server? Are there any cheaper option for my simple app?
Thank you everyone!

As you have seen, doing the parsing on the device can be troublesome with data use and also potential network access issues (what if you don't have a connection at the time you try to search?). Doing this work on a server with a more reliable internet connection is a good idea. You will be using Google Cloud Messaging (GCM) not C2DM which is deprecated. You don't need to buy special hardware to host a server, and if it's only for your use, an always-on desktop computer could do the work for you. Since you'll be using push, you don't even need a static IP address (or a domain name) for the server, since the device will never 'phone home', since you just need a notification when things change.
I would first start by opening a port on my desktop computer and try to get the device to talk to your machine via your LAN.
Hope this helps.

Is a live internet connection required for push notification?

This maybe a silly question, but I need confirmation and I have no one else to ask.
I am trying to understand the implications of implementing my own push notification for android mobile devices. This requires a continuous TCP connection to a server, though most of the time it will be idle.
My assumption is that, even when idle, for the server to be able to push data to the client through the TCP connection, an active internet connection will always be required, and if the connection is disrupted (i.e. the user switches the connection off) this push will no longer be possible.
Is this assumption correct ?

I'd say yes, it's correct indeed. How would you communicate without a live internet connection?
Afaik, Android C2DM handles this by queueing up the push requests when the user does not have a live net connection and sending them down to the user when the connection gets back up. You could implement a similar behavior in your solution's server side.

Answer is YES
To understand the best way then any-other about C2DM, You just should go through this Google Project C2DM
They have provided complete documentation required to Understand the work and mechanism of C2DM and provided completed Examples too.
I have one another favourite tutorial for the same is : Vogella's
You just need to give a good time to read this thing and implement..
Happy Coding :)

You are right. C2DM maintains a open socket (with Market or Gmail app), which it uses to identify your device.
And ofcourse, you will need Wifi or a cellular network to receive the push notifications.