Sometimes I am experiecing a delay while receiving APN , while at other times its working absolutely fine.
I am also connecting to the feedback server at ssl://feedback.sandbox.push.apple.com , but its not showing any data.
What are the possible reasons for the delay?
Thanks
Delay can happen if you've got a bad connection on 3G or Edge (iPhones use those, not wifi, for push unless they're totally unavailable). If the connection is dropped but the device doesn't know it, it'll wait until it does a heartbeat and realizes the connection is closed.
Also, if you're using an iPod Touch, the connection to the push servers will only be maintained while the backlight is on or you're plugged in via USB; otherwise the wifi connection will be dropped when the backlight goes off to save power, and it'll poll for new notifications every half an hour.
Related
We are developing an application where an iPhone should connect to an cc2564 device (Specifically cc2564+msp430f5438), the application should make quick and short connections to send some data. We need reliability in the connection so we need to know if the connection was really successfully or not, and we need a way to connect to the device with assurance.
The iPhone connects correctly to de device most times, it discovers services and works as expected, but sometimes the iphone makes the connection but the callback of discovered services is never called.
We used a sniffer to look at the communication packages and we saw that in those cases the connection package was send but there wasn't any response from the device, the phone tries to retry some version request messages and then stops, as you can see in the image:
The problem seems to be on the device, we are using the SPPLEDemo sample provided by Texas, and the first function that is called when the connection is established is GAP_LE_Evenet_Callback, and when the problem occurs it's never called. We don't know if somewhere inside the GAP API the device receive the connection message.
Is there some way to debug it or to know if the connection message is received by the device when the error occurs?
Is it a problem on the iPhone (unlikely), or is a problem on the device?
You quoted that
..the first function that is called when the connection is established is GAP_LE_Evenet_Callback, and when the problem occurs it's never called..
I'd recommend tweaking (playing) a bit with connection timeouts and Link Supervision Timeouts before consulting the experts who have developed the BLE Device firmware if that is possible for you.
Be assured that whenever a connection is made, the BLE device gets an event (callback) from the BLE stack that the connection has been established.
If that event is not handled the way it should be, then you can conclude that BLE device has some implementation issue.
I'm trying to create an iOS application that sends data over UDP continuously over wifi/3G network.
I have an issue when I launch my app over 3G network after like 10 seconds I get this message :
sendto() : No buffer space available
It's not that a big deal because my app still works well BUT when I quit the app, I guess my buffer stays full because I can't use 3G anymore (I have to wait some time or reboot my phone)
Is there a way to flush this buffer before I quit my app ?
It sounds as if you're hitting the outbound bandwidth limit. If your app does this continuously while in use, isn't that going to make it very expensive for users to run? Most mobile users, I would guess, are on some kind of metered plan where they pay for transferred data.
I would guess that closing the socket normally before exiting should flush it first, since you've requested the data to be sent after all, but sometimes UDP sockets don't try very hard to deliver the data (since they are "lossy"), perhaps that's what's happening in your case too.
acani uses zimt websocket for chat. Can we make it so that when a user closes his phone and puts it in his pocket, he can still receive chat messages from and send location updates to the node.js server? I think this would be nicer than push notifications. Don't you? If not, why should we use push notifications instead or also?
Thanks!
You can't keep a network socket open, unless you are registered for voip/GPS/music playing in the background.
if you register for these, and then don't do them, apple usually reject the app.
the reason you cant keep a network socket open, is that without your app jumping to the foreground when it receives a connection, it cannot respond to network traffic(because if it is not in the foreground its memory content is frozen).
background network traffic kills the battery, as the radios in phones are one of the most energy intensive parts.
with push notifications, apple manage how often they are sent out, so you don't have all of the applications on the phone polling the network every 2 minutes killing the battery, you only have one active network connection, which is intermittent.
I am developing a network application on iPhone that requires internet connection all the time. However, once I login to the server and keep the iPhone idle for a while, the iPhone goes to sleep mode and disconnects my network connection (it logs me out).
If I run the same application on iPhone, while the iPhone is connected to the PC through USB cable, it never loses its network connection.
In the info.plist file I have added these two flags, but does not seem to have any effect.
UIRequiresPersistentWifi -> true
SBUsesNetwork - integer ->3
Am I missing anything? Could you please let me know how can I make sure that the network connection is persistent throughout the life of the application?
In your application delegate ("appDelegate"), disable the idle timer in the +initialize method:
myApp.idleTimerDisabled = YES;
Note that this will keep your iPhone from sleeping while your app is open. This can present issues with battery life.
Another option might be to set up a background thread that opens a small CFStream on a timed basis.
What do you mean by "logs me out" here? At the network level, there is no "logged in" (*). There are only packets. You send them or you don't. So does your server process have some expectation of packets or messages arriving periodically? If it does, then you must send them, and that means that you can't go idle (idleTimerDisabled = YES). If you control the server, it is better to make it less demanding about how often you talk to it. This all happens well above the network layer, however.
UIRequiresPersistentWifi means that the Wifi radio is kept on while you're app is running, even if you don't talk on it. This is important for receiving data. Otherwise you drop off the network and others can't talk to you after about 30 minutes. It should be set in Info.plist, but this is certainly in your app bundle. If it weren't, your app wouldn't launch, so that isn't the problem.
(*) The cell network does have the concept of logged in, but that's not what's causing your problem.
I know that iPhone shuts down its WiFi connection after 30 mins. Is there any way to keep it alive? How about 3G connection? Does it shuts down its 3G connection after 30 mins? Is there any way to keep the 3G connection alive?
Thanks.
Occasionally, even when you're polling something fairly regularly just too keep the connection alive, the iPhone or iPod will feel it's too hot to use the WiFi connection right now. It's probably right, and there's nothing you can do to keep the OS from disconnecting and turning off WiFi, except to pop up a "try again" dialog if you really need a connection for the current operation.
As this posting rates quite high when searching for the WIFI/WLAN iPhone problem - here's the link to the answer: iPhone SDK Internet connection detection