It is very usual that an iPhone send data to internet server.
But what if a server wants to connect to an iphone?
I have wondered long about it.
For example, like many web-based apps like Facebook, what is the mechanism/algorithm behind, so that when, for example, any updates on your wall can be noticed to you in a real-time manner?
Hope some can understand my query.
Have a look at this Wikpedia article about Push Technology.
Push technology, or server push, describes a style of Internet-based communication where the request for a given transaction is initiated by the publisher or central server. It is contrasted with pull technology, where the request for the transmission of information is initiated by the receiver or client.
Your iPhone could intermittently 'poll' the server, looking for any data it needs to be sent. Say every 5 seconds, or after some trigger - it would call the server and ask for new data.
You could use push technology: i.e. have a continuous http connection open to your server that allows data to be sent both ways. LightStreamer is a product that does this that i've used before. This is the most elegant and efficient solution for streaming data.
You could use iOS push notifications. The server can trigger a push message and target it at a specific device and send your iPhone something...
Push notifications are the way to go with iOS. I have used push notifications through the cloud-based Cocoafish backend server. This is a great solution as you can 'subscribe' mobile devices to a push notifications channel - for example, a channel for friends requests or a channel for chat etc. Its real easy to set up with all the correct certification. There's good set up instructions in the documentation on their site too.
Related
I've just read alot about push notification servers, self-hosted ones as well as cloud. and I am pretty much confused about one aspect.
I need push notifications for my Android/iOS app for more than a million devices using the same app. now there is no free service for that scale and paid services will result in too much monthly fees, so I thought about running my own server with an open source solution. I've checked Many but parse seems to be the best fit. but they say that it uses FCM and I know from google pricing that it is free only for a limited number of registered devices. I thought that hosting my own push server would spare me those fees; but it seems like not; what good is it then ? wouldnt it be better to just use FCM directly ?
Delivering push notifications to Android (with Google Play Services) and iOS will always use FCM or APNS respectively. The reason is that those services are built into the operating system, or built closer to the operating system than regular application can function and get reliability and battery life advantages from that. Both FCM and APNS are completely free and unlimited, although both have quota to protect the services against abuse.
There are many services (such as Parse Push, Airship, OneSignal, etc) that build on top of FCM and APNS to provide higher level messaging operations. But at a lower level these will be using APNS and FCM for the actual delivery of the messages.
That's also what you have to think of when you considering building your own server: what will that server actually do to deliver the messages to the devices? If you're not using FCM/APNS, how do you get the message to the device, especially when the user is not actively using the app?
I am currently writing an iPhone application that sends and receives JSON data from a remote server to essentially display realtime information. Me and my partner started the project using Google App Engine (Python) for the server-side implementation mostly because it was easy to pick up and seemed suitable for our needs at the time. However, we're only just now starting to see the downsides of the framework for realtime iPhone apps - APNS is not at all supported, and neither is the GAE Channels API. So our only option for displaying the realtime server data on our app is to continuously poll the server, which certainly seems like horrible design.
We'll have to port our server-side code to a new framework. My question is, which one do we use? From numerous searches, I still have yet to find a satisfactory answer.
I should mention that I don't necessarily want the server to send push notifications. I just want to be able to push data to clients in real-time, and then manipulate that data on the iPhone client-side code. We're fine with setting up the framework on a local server if we have to.
Since you don't want to be pull data in background (lett alone if it is even possible)will have to use APNS.
But why switch away from google app angine, you could use an APNS provider like Urban Airship wich provide there on API to connect with.
You'r not even the fist to run into this problem: Apple Push Notifications on Google Appengine
Probably the easiest realtime framework you can use for sending data to iOS clients in real-time is PubNub (http://www.pubnub.com). It's reasonably priced, and it scales to anything you can throw at it. In my experience, it has no problem delivering a message to an end client in under .25 milliseconds (regardless of the number of clients it's being sent to).
Their latest version also supports APNS functionality for when you app isn't in the foreground.
https://github.com/pubnub/objective-c/blob/master/iOS/README_FOR_APNS.md
If you want to create your own APNS server (since you are running on App Engine anyway), there are examples of how to do that using App Engine's new Socket API. I've written a demo python AppEngine application that people might find helpful in this regard.
https://github.com/GarettRogers/appengine-apns-gcm
I'm looking for any reference projects or key learning from anyone who has implemented XMPP/Jabber to successfully send notifications to iOS devices (iPhone/iPad).
I'm considering using an XMPP server (OpenFire specifically) to provide a single cross platform mobile push system. C2DM for android has a number of annoying requirements like users having Google accounts. This is what got me started looking at XMPP. I also need to support pushing to iOS devices. I know all about APNS, however I'm wondering if I could use the XMPP server for both Android and iOS platforms (and possibly more like Black Berry).
The things I feel might come up are:
iOS killing any persistent connection to the XMPP server. Will it
auto reconnect?
iOS preventing access to certain ports or protocols.
Anything to be aware of here?
Other gotchas one would only discover
by trying this?
Here you can find the answer to your first question:
when your app goes in background you (the client) close the connection
with the xmpp server. When your app comes back into foreground you
reopen the connection. If your server need to send messages to your
client, it must use push notifications. When the client receives the
notification can (it depends on the user action) go back to
foreground.
(source: iOS Backgrounding & XMPPFramework)
I understand that some applications need to check against a server periodically, but why don't servers let a mobile device know when it's time to update.
For example, let's say you receive an e-mail in gmail. As it stands now, there can be a delay between receiving the e-mail and your device notifying you. I assume this has to do with waiting until the device has checked the gmail server, at which point it sees the new e-mail and notifies the user. It makes more sense to me that when the gmail server receives an e-mail, it should ping (or however the creator wants to implement it) all registered devices to let them know that it's time to update. This way notifications would be synchronized and mobile device could save battery by not having to periodically check a server.
What you are describing is called a "server push". Some mobile applications does use server push. And Google actually have a technology in place to make this easier to implement, named "Cloud to device messaging" (C2DM). It works by having the servers sending a tiny little message, via googles C2DM servers, to the application running on the device, informing it its time for a update. And the device then retrieves the actual update from the original server (not from C2DM).
Its good stuff. It allows the service listening for C2DM manages to wake up the phone and everything. The downside is, the user of the application needs a google account. For android users, this isnt really a downside though.
Except they do, in some cases. In the "Mail, Contacts, Calendars" section of Settings on my iPod, there's a submenu labeled "Fetch New Data", which contains an option to have the mail server or whatever "Push" the data to the iPod. The Fetch aspect, which you can set the schedule for, is for when Push is off or you're syncing with applications that don't support push.
That is how Android does it. It pushes notifications to the device and that api is open to third party developers as well so they can push notifications to their users.
That thing is it is difficult to know the address of a mobile device at any particular time, the I.P address is dynamic, on a server the address is much more stable, so the device knows it will always find Google at google.com but Google has no real way of knowing where to find the device, it wouldn't know where to ping in the first place.
This is where push comes in, there are different implementations but i think they work by having the device maintain a connection to the server, and reestablishing it if its lost.
See http://en.wikipedia.org/wiki/Push_technology
This of course is much harder to implement and maintain then a simple client pull.
I want to write an iOS app that can act as a client and a server to other iPhones over the cellular data network (i.e., without a typical centralized server). The goal is to share series of about 200 short event messages, one at a time, from the iPhone server to multiple iPhone clients by some means of notification. Apple Push Notification service would be fine for such notifications, but there is no need to use it specifically.
I think sending push notifications from one iPhone to another is possible by connecting to gateway.push.apple.com from the serving iPhone as described in the Local and Push Notification Programming Guide, but I can't find anyone else discussing this approach (maybe it's too obvious?).
The reason for all this is an attempt to avoid the overhead of infrastructure. If this isn't feasible, alternatives which minimize or avoid additional hardware are welcome.
Requirements:
Communication must be [strictly] over cellular data network
Wi-Fi isn't available
Bluetooth doesn't have enough range
Unidirectional communication with an iPhone server multicasting to many iPhone clients
No jailbreaking
Ideally the serving phone's battery will be able to handle this without a recharge
Update 5/4/11 2:12 AM EST: Just to be clear, I don't have any particular requirement to use APNs; I thought it may have been feasible in this setup, but from the discussion below, it sounds like that's not the case. However, I'm still interested in any other system that could help me achieve the same end result with some type of message passing or similar form of communication.
Theoretically you should be able to write a iOS app that can connect to the APNS and send notifications to other devices running your applications. However, your main problem will be to actually acquire the 'tokens' of other devices. When you have a centralized server doing the job, its always online and thus, the clients can 'talk' to it via http and register them self (giving their tokens to the server in the process). Thus the server knows the client token and it can use them to send notifications to the clients via APNS.
However this is not possible in the scenario you are talking about. But this is not to say its impossible. May be you could use an email account X, to store all client tokens. Every client will send a email to this account with their token in it. So when a another 'client' want to send a notification to another client, it can find out the token by reffering to the inbox of the email account (you can cache this stuff and optimize it in a zillion ways of course).
But the point is some how a (third party(ex: email service provider)/your own) server that is online 24/7 will be involved in the process.
Let us know how you progress with this. It would be interesting to know.