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.
Related
If you had to open a resource from a database in a web browser on another computer, using an Apple tablet app as a remote control, how would you implement such a feature? This is basically what WhatsApp Web does, so it should be technically possible. But how would you go about it?
I'm assuming that you mean a situation where the app modifies something on the server, and the browser then updates automatically to reflect this. If you mean something like the iOS Remote app, then you may have to use another method (and you may not be able to do it from the browser).
To do this you'll have to have a server that both the iOS app and the browser are connected to. When the app does something, it updates the server, e.g. by submitting an HTTP request to a REST API. The server then updates the database.
Now you have to get the browser to update, and there are two ways of going about this. One is by polling the server periodically, using AJAX to update parts of the page dynamically without refreshing the whole page. This works, but there's a lot of overhead and it can be a drain on a laptop battery.
The better, but slightly more difficult to setup, alternative is to use WebSockets. WebSockets allow for two-way communication between server and client, and the connection stays open until one party closes it (or it times out after a long time). The client can submit information to or pull information from the server as before, but the server can also push information to the client without the client having to request it. This would typically be how games, chat clients, etc. can operate nearly in real time.
Setting this up isn't necessarily that difficult, but it's a very broad, open-ended topic that's beyond the scope of just iOS development. Beyond the iOS app and the web client, you'll also need a backend that's capable of using sockets. Node.js is a popular JavaScript-based backend for this sort of application; there are numerous others out there as well. You'll have to do your own research to determine what's right for you.
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.
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 looking for ways where my RESTful web service can let my iPad app know to update its cached data when the server's data has been updated. The server is running on Tomcat & Apache Jersey.
Is this doable? And not using Apple Push Notification (APN)?
There are essentially two options: heartbeat check from the app to the server (on a timer) or something that keeps the line of communication open, such as web sockets. Here is an open source web socket for iOS, but I have not personally experimented with it:
http://code.google.com/p/unitt/wiki/UnittWebSocketClient
I'm not sure why you want to avoid APN, but this really sounds like what it's made for.
If you want to update only when your app is running, there are other options (straight forward polling comes to mind), but if you want the user to be notified even when the application isn't running, there isn't really any other Apple approved way to do it.
Can reverse the design around and make your device a client and pull data from a REST service at a regular interval?? With all the support one gets from REST, it might be helpful to know you will have complete control of when data is being pulled by the device from server and exactly the data that might goto device.
I'm curious to know your thoughts, Thanks.
I'll be building a web-syncing iOS application soon, and we're going to use RestKit. Take a look, it might be a big help.
I'm trying to make an iOS 5 app that features real-time things coming from the server. It will only use these whilst the app is running.
To make it real-time without polling I have been evaluating two design routes:
Creating a socket from the app to the server, and exchanging information via streams.
Pros: Relatively simple and would not involve a 3rd party.
Cons: Battery life drain.
For an overview of how this might work, check
out this excellent tutorial:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
Using standard HTTP to communicate with the server, and with each request from the app let the server know what they are viewing. If something new is available for user, send an Apple Push Notification (with no visible alert) to let app know it can go and download new thing.
Pros: Not opening up a new TCP connection, so battery life not drained unnecessarily.
Cons: Feels like a poor hack.
The official docs on APNs http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
I think a socket would be the way to go, but before I commit to it I wanted a second opinion, as this is the first time I've made anything like this!
Sockets would be my choice. I do not know how time critical your application is, but sockets might perform better as APNs if realtime is a must.
Does it really need to be "full real time"? From my point of view i would prefer http since it is already well integrated into the iOS SDK. Its easy to understand, maintain and implement and plenty of documentation is on the web. So maybe a http poll every minute or so will be enough (depending on the app and the number of users). Please consider firewalls too! Traffic to unknown ports maybe denied due to firewall policies of provider or local wifi. So if you really need realtime connectivity I guess you have to use sockets.