A web application acts as a backend to process request coming from the iPhone. To send messages to iPhone from web application while processing a request(e.g., for payment), I want to send messages to iPhone when something interesting happens on the server or else if everything is successful, sending them transaction details. Which one is better to use PushSharp or SignalR? Does they both serve the same purpose? Either way, enlighten me on this topic. Its confusing to me.
SignalR is a great way to send real time information to a web client, essentially having server-side code push information to the client and call client-side code (i.e. javascript) in realtime.
PushSharp is a great way to send push notifications to native mobile apps. For iOS, this means using Apple's infrastructure. It also means that the message will be shown as a notification in the iPhone and not just inside the browser.
Essentially, if the iPhone request you mention is coming from a native app, try PushSharp. If it's a web app running in a browser, use SignalR.
PushSharp appears to leverage the native messaging for each platform. Azure Notification Hubs provide native messaging similar to what PushSharp appears to do. The native messaging platforms scale out very well, but do not give you direct access between client/server code, and messages can be delayed in some cases up to minutes. Messaging like this works really well when you want to send messages to millions of devices. Example: all users who want an alert when their favorite sports team wins a game - not time sensitive to the minute.
If you want your push message to be strictly between your server-side code and your client-side code, SignalR can achieve that. SignalR also has a .Net implementation, so it isn't just for javascript/web pages. SignalR is will leverage approaches like web sockets / long polling / etc. If you are sending a response to tell your client that a query has finished, or that a message was received, and it doesn't help to have that message arrive minutes later... SignalR may be a better approach.
Related
Currently building a mobile application that ideally would have functionality that allows one user to "nudge" another user, pretty much the equivalent to a Facebook "poke." For the sake of building quickly, we'd like to use as many third-party libraries/services as possible. So far we were looking into using pusher and expo, but to be totally honest, we are a bit confused as to how to architecture this.
From what I understand, the front-end (ios app) would subscribe (open a socket) to a specific channel/server and the server would then send messages to the client(s) that subscribed whenever necessary. How this works with users being subscribed to every other user they are friends with, I don't understand. What's the proper way to architecture this?
I also read that on the front end, when a user doesn't have the ios application open you can't have any websockets open to the server, so how does that work?
Additionally, how does one bundle notifications??
Really confused with this, any help would be greatly appreciated.
Chris
Well, push notifications now mostly are implemented with Firebase. This is a service inside most of mobiles, so you only need use these libraries to implement your client application.
From the server, you only need to consume a rest api of Firebase.
Now there are permissions to allow mobile applications receive push notifications in background. You do not need to implement a socket or websocket, that is a feature of Firebase.
Read more about this.
https://medium.com/google-cloud/push-notification-for-react-native-bef05ea4d1d0
https://dzone.com/articles/how-to-add-push-notifications-on-firebase-cloud-me
I just wonder why and for what kind of application or case we need the Socket.IO.
I am the iOS developer of a known open source project socket.IO-objc
Usually, we need HTTP or HTTPS to communicate with server. The socket aims to conduct real time communication (It should always keep a live HTTP connection.)
Libraries like socket.IO are needed when we need real-time in our app. Let me explain this in little more detail. Let's assume that you are developing a game, which is multiplayer and 2 or more users can play that simultaneously. Then, in that case, you won't be making HTTP or HTTPS calls because of many reasons and one of them is that their packet size is large and other is that these calls are very slow. In such scenarios we use libraries like sockets to send and receive data to and from the server. Sockets are really fast and are capable of sending only those data packets which are needed. Using HTTP programming you can never create any multiplayer game or any app which will be interacting with a server on a realtime basis.
Let's take another example. Let's assume that you are working on a chat application. When user A is typing something then user B should know that A is typing (similar to gtalk of facebook messenger). If you will use HTTP calls at that point of time then "B" will never be able to see the actual status of the other person because of the delay. So what we can use is sockets so that when user A is typing anything then his device will send only one data packet which will just notify the server that he is typing and will be delivered to user B, this process is really fast (almost realtime) and will reduce the data transfer also.
I'm working on chat application using socket.io also. So it seems to replacing everythings with socket.io. This is making me in doubt and curiousness. I totally agree with real-time app like chat suits for socket.io. However there is round-trip communication (such as user login) that's more suitable for HTTP.
Socket.io uses web socket to pass data among users who are all connected to a web server. With web socket, there is no negotiation protocols and connection remain open as long as users concerned are registering for service with the web server. As pointed out also, the payload is significantly less than http/https protocol.
Socket.IO is a JavaScript library for realtime web applications. It enables realtime, bi-directional communication between web clients and server. It has two parts: a client-side library that runs in the browser, and a server-side library for node.js. Both components have a nearly identical API.
I am a Ruby on Rails developer and I have a question about iOS development.
How do iPhone applications typically interact with a server?
For example, let's say you wish to send GPS coords from the iPhone to the server to be stored or processed. How is that typically done? Is it through a typical server API (like JSON)?
Sorry for such a basic question.
EDIT: Thanks for the answers below. Now, how about pushing data from the server to the iPhone app (without a request). How is that done?
The communication format is usually XML or JSON via HTTP call, but it depends on your data you wish to communicate between server and app. You may use socket connection.
Typically, every client and server exchange information via public API's.
in iOS, we prefer, RESTful webservices that deliver JSON. (There are other options also, but we prefer this)
I'd say that the best way to ensure delivery of data to the app from the server depends on whether you know the app is running or not. Push notification can deliver payload data, albeit in small quantities, to the app and it does not matter whether it's currently running or not. It's a big subject but thats a good start.
I want to build a instant messaging application using Ruby on Rails but I'm confused about the implementation.
How is a IM application (like the one on Facebook) usually implemented? I think we can use a push server (server pushes to client) or polling (client asks the server), but is there any other ways? And what are the corresponding advantages of these two approaches? Which one is usually more efficient and less demanding?
Thanks in advance.
Polling: In case of Polling, browser makes the request to server at a regular interval to check for updates. It will increase your server load.
Server Sent Events: server sent events.
Server-Sent Events have been designed from the ground up to be efficient. When communicating using SSEs, a server can push data to your app whenever it wants, without the need to make an initial request.
WebSockets: WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol.
For IM best suited is websocket, as using websocket you can do bi-directional communication.
A similar example of IM using websocket is Applozic chat SDK. It Uses web sockets for Real Time Messaging.
I don't know specifically how Facebook implements their IM service, but most web-based IM clients use either a push server or a Jabber client. Jabber is good if you want the users to be able to communicate with the service through their own IM client, and not just through the web frontend; push is good if you're doing something interesting with the received messages on the server-side. Polling isn't used anywhere near as widely nowadays. It requires the same JavaScript support as server push, but is much more resource-intensive for your server.
For getting started with push, I would recommend looking into Faye or Juggernaut.
If you're interested in Jabber options, check out the JavaScript Jabber Client Library.
I have registered with RIM for the push notification evaluation. But i cant find good sources for implementing push notifications. There are some samples in the sdk but i couldnt find out a way to implement them. So, i am looking for a good tutorial where i could find step by step implementation of push notification services...
RIM's samples for the server side involve setting up a web application container (e.g. Tomcat), setting up a backend database, and then building their Spring-based application. This sample web app handles things like device registration, content subscription, etc. and features a portal to manage everything.
The bare minimum that is required, though, is to send a WAP Push message which is just an HTTP POST to their Push Service servers. Here is a thread from the BlackBerry Support Forums that describes how to use their low-level PAP API to construct this message. Pay attention in particular to the messages by the user mdicesare.
There's also another SO question that has some tips.