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?
Related
I want to have my application receive notifications without forcing the user to be logged in or authenticated. Thank you for your time!
Well, I'm using OneSignal to send notificaitions to the users of my Android app and it's working fine. Moreover, it uses FCM as its base. So, that shouldn't be a problem too. You can segment users thet way you want and send notifications to one or many - upto you. It's all for free and very easy to set up the basics of it. It's here: OneSignal
You can probably use Socket IO for your case to send messages from one device to another.
There are many good to have Socket IO frameworks which can consider for your requirement
Signal R in Android
SignalR is a new library used to add real-time web functionality to your applications. Signal R uses technology such as
web sockets
Event Source,
forever frame
long polling
Signal R is capable of selecting the best from those four technology depending on your internet connection and your application stability.
Signal R is used in application such as
Chatting application
Stock market application
Real-time gaming
Native Socket.IO
Socket.IO provides an event-oriented API that works across all networks, devices and browsers. Its incredibly robust (works even behind corporate proxies!) and highly performant, which is very suitable for multiplayer games or realtime communication.
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 have an idea for an iPhone app that will make billions of dollars for me, and help me take over the world. I am currently designing the architecture of the application. I had originally assumed that I would need to create and host a database that would allow users to upload their data and share it with other, targeted, users. But I thought it would be better if the users could send their data directly to each other without having it stored in a database. However, I haven't been able to find anything that would suggest this is possible.
Is it possible to send data between iPhones that are not in close proximity (bluetooth) and not on a LAN? For instance...User #1, who is in Tennessee, creates some information and hits "Send to others" and it sends that information directly to User #2, who is in Arizona, and User #3, who is in Maine. Could the text messaging functionality be hacked to do that?
(I realize that the phones belonging to Users #2 and #3 would have to be on, and running the app that would receive the data)
I am new to mobile development, and I am still getting used to the functionality of mobile devices so, I am certain this is a dumb question. But, it is worth asking because, if it can be done, this would dramatically change the architecture (and maintenance costs) of this application.
Thanks, in advance, for whatever advice/pointers you can give.
This is something handled by using the publish - subscribe pattern. You may want to look into a plug 'n play service such as pubnub. That will let you do just that. Phones that should be receiving each other's messages will have listeners set up on the same pubnub channel, and will receive a notification when any of the other phones publish to that channel. Something like pubnub has a pretty simple API/SDK that you can use to get a prototype up and running pretty quickly (and for free, at least at first).
User #1's app sends the message to your server. You server does an APNS push to the phones of users #2, and #3. They don't even need to be running the app.
No need to mark this correct or up-vote it, but I will take a high-paying job in the new world order.
Amazon has an application service called Simple Queue Service (Amazon SQS) which Allows you to create queue's with messages in them tat app's can subscribe to.
To quote their page:
Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly
scalable, hosted queue for storing messages as they travel between
computers. By using Amazon SQS, developers can simply move data
between distributed components of their applications that perform
different tasks, without losing messages or requiring each component
to be always available. Amazon SQS makes it easy to build an automated
workflow, working in close conjunction with the Amazon Elastic Compute
Cloud (Amazon EC2) and the other AWS infrastructure web services.
Amazon SQS works by exposing Amazon’s web-scale messaging
infrastructure as a web service. Any computer on the Internet can add
or read messages without any installed software or special firewall
configurations. Components of applications using Amazon SQS can run
independently, and do not need to be on the same network, developed
with the same technologies, or running at the same time.
They have an iOS API to integrate it into your app, and it is free for up to 100,000 messages per month and then $0.01 per 10,000 messages after that.
More info here:
http://aws.amazon.com/sqs/
Is it possible to send data between iPhones that are not in close
proximity (bluetooth) and not on a LAN?
The two devices obviously need some kind of connectivity.
For instance...User #1, who is in Tennessee, creates some information
and hits "Send to others" and it sends that information directly to
User #2, who is in Arizona, and User #3, who is in Maine. Could the
text messaging functionality be hacked to do that?
The problems here are:
helping each device discover the correct address for the others, and...
ensuring that the devices can reach each other.
Mobile devices are constantly moving around on the network and changing their IP addresses as they go. As you're driving to work, your device may have Internet access through it's 3G connection, except for those times when you're driving through a tunnel and don't have any connectivity at all. Once you enter your building, a wifi connection becomes available, so the device switches to that. But your company's network has a firewall that blocks incoming connections, and it's impossible to know in advance which IP address you'll get from the DHCP server at any given time anyway. The same is true for the folks in Arizona and Maine and wherever else.
A server, on the other hand, is usually located at an address that's both easy to discover (thanks to the Domain Name System), easy to reach, and almost always available. For those reasons, it's common to have mobile devices communicate with each other by going through an intermediate server.
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.