phonegap, Strophe.js and xmpp pubsub push notifications when app is offline - javascript

What is the best way to be notified via push notification mechanisms when an update is published to a pubsub node (openfire server) and the xmpp mobile client app is offline? Should the app launch in the background say every 30 minutes without user knowing it (How would I achieve that)?
I'm building a Jquery mobile app and want to use phonegap to package it for iOS, android and maybe other devices.
Edit1: I think it should be something like C2DM or APNS. But how do I send a message from openfire server to C2DM/APNS when a particular user receives a message.
Edit2: How an XMPP server (e.g. openfire) would know whether to send the Push notification to the APNS or C2DM (because one user could have an Android or IOS device or both but the xmpp server doesn't know that)? If I'm asking the wrong questions, please correct me?
Thanks!

Natively, an XMPP server doesn't know anything about those protocols so it cannot push to them. You could create a plugin to push via some other means, but I think it would be simpler if you can get your client to connect every so often and get it's offline messages.

Related

How can I send notifications from my Java server to my react-native client in realtime?

I would like to send messages from my Java server to my react-native clients.
I don't know exactly how to solve this. Should the server establish a connection to all clients via the IP addresses of the clients and send the message and then close the connection again? (Sounds the most sensible to me.)
I think that would be better than if the clients connected to the server and the connection should always be maintained. After all, it should run with high performance.
Basically, it doesn't make much sense for my system that the clients connect to the server, since only the server knows when and whether it is sending a message.
I've already tried working with websockets. However, it didn't seem to work without requests from clients.
The difficulty is to find a method that works with Java on the server side and JavaScript on the client side and that the connection is made from the server to the clients and not from the clients to the server. In addition, the transmission should work in real time.
Is that feasible? Are there any better ways? How can I do it?
I hope you can help me.
Greetings. Martin
The basic function of the system
There are multiple cloud based messaging platforms. One of them is Firebase from Google which is free (I guess). Check this out here. https://firebase.google.com/docs/cloud-messaging
You will find multiple tutorials to configure and use it in your react-native and Java server.
Architectural overview: https://firebase.google.com/docs/cloud-messaging/fcm-architecture
Another solution is writing your own logic using the WebSockets.
Lifecycle of message: https://firebase.google.com/docs/cloud-messaging/fcm-architecture#lifecycle_flow

How to create a real time notification system if I have a rails backend and clients which run on Angular.js?

One simple way to do this would be to have the client poll the server every 10 seconds or so, but I don't think that's the best way to go about it.
I don't want to broadcast notifications to all clients, but only to 1 client at a time.
The internet is loaded with articles on how to do this but I can't figure out which one is more appropriate for my problem.
https://github.com/websocket-rails/websocket-rails
https://github.com/ryanb/private_pub
Consider using a hosted pub/sub broker like Pusher or Realtime (the company I work for) and focus on developing your app and not managing the required real-time infrastructure.
From your Rails backend you would send the messages through the REST API and use the websocket-based JavaScript library to receive them on browser clients (subscribe).
For private messages simply subscribe each user to their own private channel (maybe using their user id).

Express web sockets and a central server

I'm creating an app where the server and the clients will run on the same local network. Is it possible to use web sockets, or rather more specifically, socket.io to have one central server and many clients that are running native apps
? The way I understand socket.io to work is that the clients read the web-pages that are served from the server but what happens when your clients become tablet devices running native apps instead of web pages in a browser?
The scenario I'm working with at the minute will have one central server containing a MEAN app and the clients (iPads) will make GET requests to the data available on the server. However, I'd also like there to be real-time functionality so if someone triggers a POST request on their iPad, the server acknowledges it and displays it in the server's client-side. The iPad apps will (ideally) be running native phonegap applications rather than accessing 192.168.1.1:9000 from their browser.
Is this technically possible to connect to the socket server from the native apps or would the devices have to send POST requests to a central server that's constantly listening for new 'messages'? I'm totally new to the whole real-time stuff so I'm just trying to wrap my head around it all.
Apologies if this isn't totally clear, it's a bit hard to describe with just text but I think you get the idea?
Correct me if I am wrong.
You have multiple iPads running native app. They send a POST request to your node JS server which is running in a computer in the same local network. Whenever the server receives a request from app, you want to display that a request has been received in your computer screen.
If my assumptions about the scenario is correct, then it is fairly easy to do. Here are the steps to do it.
Create a small webpage (front end). Load socket IO in the front end page like this -
<script type="text/javascript" src="YOUR_SERVER_IP/socket.io/socket.io.js"></script>
Then connect to server using var socket = io(). This should trigger connection event in your backend.
Handle all POST request from apps normally. Nothing special. Just add a small snippet in between. socket.emit('new_request', request_data). This sends new_request event to front end.
Handle the new_request in your front end using socket.on('new_request', function(request_data) { ... });. That's it. No need to add anything to your native app for realtime update.
The second step would be a little complicated as it is necessary to make socket variable available inside all POST requests. Since you chose node.js, I don't think you need any help with that.
Not totally clear on your project, but I'll try to give you some pointers.
An effective way to send data between native apps and a server is using a REST server. REST is based on HTTP requests and allows you to modify data on the server, which can connect to your database. The data returned is typically either JSON or XML formatted. See here for a brief intro: http://www.infoq.com/articles/rest-introduction
Android/iOS/etc have built in APIs for making HTTP requests. Your native app would send a request to the server, parse the response, and update your native UI accordingly. The same server can be used from a website using jQuery ajax HTTP requests.
Express.js is more suited to serving web pages and includes things like templating. Look into "restify" (see here: mcavage.me/node-restify/) if you just want to have a REST server that handles requests. Both run on top of node.js (nodejs.org).
As far as real-time communication, if you're developing for iOS look into APNS (Apple Push Notification Service). Apple maintains a persistent connection, and by going through their servers you can easily send messages to your app. The equivalent of this on Android is GCM (Google Cloud Messaging).
You can also do sockets directly if that's easier for you. Be careful with maintaining an open socket on a mobile device though, it can be a huge battery drain. Here's a library for connecting ObjC to Socket.IO using websockets, it may be useful for you: https://github.com/pkyeck/socket.IO-objc
Hope that helps!
To answer your question, it is definitely possible. Socket.io would serve as the central server that can essentially emit messages to all of the client. You can also make Socket.io listen for the messages from any of the clients and serve the emitted message to the rest of the clients.
Here's an example of how socket.io can be used. Simply clone, npm install, and run using 'node app.js'
All you have to do is to provide a valid server address when you connect your socket from the iPad clients:
var socket = io.connect( 'http://my.external.nodejs.server' );
Let us know if you need help with actual sending/receiving of socket events.
It is possible to connect to Websockets from your apps.
If you are using PhoneGap then you need a pluging that gives support to websockets in your app (the client) and then use websocket like normal way using Javascript see this.
If your app is native iOS look into this it could help you.
The primary use of the Sockets in your case is to be a bidirectional "pipe" between an app and server. There is no need of server sending the whole web-page to the native app. All what you need is to send some data from server to the client(app) in response to POST (or GET) request and then using this data on client side to update client's UI in real-time. If you are going to use moderate amount of devices (say tens of them), you may have connected all of them to the server permanently keeping individual socket connection open for every individual link server-to-app. Thus you may deliver data and update client's state in real time.
In fact web browsers also employ sockets to communicate to web servers. However as in general case there is no control on amount of concurrent clients in Internet, for the sake of limited networking resources conservation, servers do not keep sockets open for a long time, closing it just after the web-page was sent to client (or timeout has expired). That's how HTTP protocol works on the low level. The server waiting for the HTTP clients (browsers) by listening the 80 port, responding them by sending the whole web page content, then closing the connection and keep waiting for another requests on the same port.
In your case it's basically a good idea to use socket.io as it's a uniform implementation of sockets (ok WebSockets) on both client and server side. The good starting point is here

Can you connect client to client via web sockets without touching the server?

I don't quite know how to search this in google:
"client to client websocket connections"
"browser to browser websockets"
"websockets without a server"
Haha, is there a way for someone on a webpage in the browser to communicate directly to another person on a web page in the browser, without touching the server?
I am very familiar with socket.io, but that requires all clients emit messages to the server, which can broadcast them to the other connected clients. I am not familiar with the details of web sockets though, so maybe there's a way to communicate without sending messages through the server.
Is this possible? I just want to know the scope of web socket functionality, the limits you can take them too, etc.
Not Web Sockets, but four years later and now we've got browser-to-browser communication!
http://www.webrtc.org/
There are JS libraries built around it to make it easier (e.g. https://simplewebrtc.com/). However, it does still require a server to orchestrate connections.
I know this question is ancient, but it showed up in Google when I searched so it likely will for others!
This is not possible, you have to have the server in the middle.
For an application to accept connections, it has to have a server port open and listening for incoming requests. You cannot have a server socket exposed from a browser. I dont know if you can expose a server socket from within an applet. But even if you could, you would need to know the IP address of the other client for establishing a peer to peer connection.
Well, technically when you broadcast, the client emits to the server, the server broadcasts to everyone. I don't think with the current architecture of the web peer to peer connections like this is possible.
But it is possible that a client send a message to server specifying another client ID, and the server sending it to the other clients using sessions.
The moment you have a client listening for websockets (which you have to do in other to communicate), it becomes a server.

Instant Message on browser

Introduction: I want to develop the chat client that user can chat on the browser and I use the protocol call xmpp. Because of HTML5 web socket not yet available I try flash xmlsocket instead.
Problem: I cannot connect to the server via browser. I'm not sure why, but I think that it is the problem of the server configuration.
Question: Which is the best jabber server suitable for this job?
Most probably this is a permission issue. Either that or you've just configured the wrong host/port to connect to. Flash is not allowed to connect to other hosts than the one it was gotten from itself. You have to explicitely allow flash connections on the receiving side of the request (so on the chat server that you are connecting to). Google for crossdomain.xml to get more info.
ejabberd sounds like a suitable option for you. ejabberd is xmpp server written in erlang and is used quite widely. Many of the well known web based im services like www.meebo.com etc are known to be running on ejabberd. It allows you to install other transports which would let you enable talking to users of other protocol like yahoo, msn, icq etc.
You can also have a look at the xiff action script library by ignite realtime. It is an xmpp client library in action script. If you use this library you would just need to implement the ui components.
Hum... flash is ok, but you'd be better of using something like BOSH, which is basically an HTTP layer over XMPP.
Ejabberd would be a good server, as it supports BOSH, I don't know about OpenFire or Tigase (but I'd say they do). Other servers should be looked at carefully because they don't seem to have a "dynamic" community.
You will need a lot of Javascript, and for that, I can recommend StropheJS, which is probably the very best library out there today.
We have created a MUC (Multi-user chat room) client called Aristochat that works in the browser recently at Superfeedr. You can find the code on Github and an example here.

Categories