I'm using the sockets api to communicate with the Apple Push Notification Service, although I'm not confident I'm using it correctly...
I have an initialization function where I establish my connection to APNS. However when is the correct time to call Close() on the connection? Or do I just leave it open and keep reusing it?
Thanks!
Apple specifically request that you don't close the connection with APNS and keep reusing it as long as possible.
Keep your connections with APNs open across multiple notifications; don’t repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day it is ok to use a new connection each day.
(Source)
However, Apple will close the connection if you send them invalid data (such as notifications with invalid device tokens), so your code must be able to detect that and create a new connection when necessary. You should also read error responses from Apple, since those responses will let you know if you should re-send some of the notifications after you re-open the connection.
That's a good answer from Eran but you may also check out java-apns-gae.
It's an open-source Java APNS library that was specifically designed to work (and be used) on Google App Engine.
https://github.com/ZsoltSafrany/java-apns-gae
Related
Im developing an iPhone app with client-server design, the server manage client connection with sockets and keep an array of all the currently connected clients.
This way i get persists connection between client and server, and i can send messages from the server to the clients when ever i need.
My problem is on the client side, the iPhone user. every time the phone get locked the connection is lost so i need to re-connect and re logging again when the user unlock the iPhone.
Is this the way to go? Or am I doing it wrong? please help..
A RESTful protocol may be more suitable for mobile use.
I'm creating an application for a mobile device (Windows Phone 7) that opens a socket on a server.
Should I :-
Open the socket and hold it open for the application lifetime
Open and close on each request
I found this question IPC: Connect for each request or keep socket open? which is related but I wonder if the answer changes given the constraints on a mobile device
It depends.
If you don't need to hold the connection open to receive a message from the server then you may want to close it after you've finished using it.
You may, however, want to keep it open if you're making lots of requests in quick succession and the overhead of opening and closing the connection would cause an unwanted delay.
As a general rule for mobile app development is that you shouldn't use resources (including keeping connections open) for any longer than is absolutely necessary.
It depends on how your OS manages resources. If your app is the only one using the internet connection, then closing the socket could let the OS totally extinguish used network interface, which definitely will reduce power consumption.
Anyway, if you don't need to constantly send or receive something, I'd recommend you to close the socket.
I am using PHP to connect to apns to send some notifications to multiple devices, although the question is more conceptual so it doesn't have to be specific to PHP. I will be sending to about 7000 devices (and growing) all at the same time. My process runs ONCE per day and broadcasts to all devices, so I am not constantly re-opening a connection.
open connection to apple
loop over device tokens
create payload aggregating all devices
end loop
write to socket ONCE with whole payload for 7000 devices
close connection
Can I do like above pseudo-code?
That is a correct approach but you need to check for APN Feedback and remove the "stale" devices. Apple will give you a list of tokens that they think are no longer valid. You should prune your database and never send to those tokens again.
Correct Approach here is,
you can open the connection.
perform as many writes as you like.
just make sure you check the connection status after each write
close the connection.
As each write is considered as a message specific to device, you can write one message at a time. But you can open a connection once and write as many you can.
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.
I'm using apn_on_rails to handle push notifications with my Rails app, but I'm not sure how to see what the response from Apple's servers are (for debugging purposes).
Any ideas how to do that?
There is no response for you to inspect. apn_on_rails uses the "simple" format for communicating with APN over a streaming TCP socket -- if the connection is not severed, you assume success.
A little more here in Apple's docs.