I have created an iOS VOIP app. The reason behind creating a VOIP app was to make my application run in background. Well that is working fine. I am also connected to a host through TCP/IP.
The problem here is when the OS is restarting the wifi radio automatically at some interval, which results in a disconnection. Then I have to reconnect.
Can anyone help me to understand what exactly is causing this behaviour?
There are a few things this could be. Firstly, are you running iOS 8? there have been some reported wifi issues with it. Just google iOS 8 wifi issues to see how many people are having similar issues.
Secondly, it's not too irregular for your wifi network to shuffle you around, so it could be either your wifi router itself, or the iPhone. I would probably try using manual ip allocation instead of DHCP on your router as a test.
Thirdly, your software obviously needs to be set up to handle dropouts etc - dropouts and package less etc are fairly common parts of any networking.
Related
How does the Speedify app switch between cellular and WiFi programmatically within the app?
With the Speedify app on, I "prioritized Cellular", ran a speed test, which showed the WiFi symbol on the whole time.
Then checked my cellular usage, and sure enough 111 MB was used even though wifi was never off.
I have read through NEVPNManager docs, which is used in the app, but can't seem to find anything. Perhaps SCNetworkConfiguration is used?
A possible solution is to use a static IP but don't put in any router IP as described here
https://discussions.apple.com/thread/6448960
I think this can be achieved in code using Apple NetService framework
As for now, I'm using multi peer connectivity between iOS devices communication in same network. Facing major problem in connectivity, its getting disconnected often. So would like to move different approach.
Someone pls suggest me to achieve this in some other concepts.
You can solve your problem programmatically by detecting dropped connections and attempting to reconnect whenever a connection is unexpectedly lost. Some other considerations are:
Multipeer connectivity will not work when the app is running in the background
Multipeer connectivity tends to become unreliable if you are trying to maintain a connection between 6+ devices
If you are determined to find a replacement for Multipeer Connectivity, then we'd need to know more about what you're trying to accomplish. If you're trying to make a game, for example, I might suggest Google Play Game Services. You could also look into WebRTC.
I'm working on an embedded device that will communicate with (WiFi-only) iPads over WiFi. However, these devices are not connected to the internet. They are simply connecting to a specific port, which is constantly relaying certain information. The iPad connects to the Access Point, receives an IP Address from DHCP, and can now reach the desired
What I'm seeing is frequent disconnects, or interruptions in the connection.
My suspicion is that iPad's inability to connect to captive.apple.com/library/test/success.html is causing it to either re-scan for WiFi networks or in some other way momentarily disrupt the connection.
Is there a way to disable this behavior, or ensure that an iPad remains connected to the intended WiFi, even in the absence of an Internet connection? Either through a setting on the iPad, or a configuration setting on the embedded router/Access Point?
If you don't mind breaking backwards compatibility with older iOS devices (iOS 3, for example), I'm told (by someone in DTS, IIRC) that you can send a DHCP advertisement without a router advertisement field, and iOS will do the right thing. I have not tried this personally, though.
You might also try using the CaptiveNetwork framework (deprecated in iOS 9 with no replacement) to claim control over the SSID, and the just never report success or failure. I'm not sure if that would work or not, but it is worth a shot.
My company is developing an iPhone accessory that requires a relatively high connectivity rate to the phone. Due to MFi limitations (USB 2 communications in HOST mode fair only around 100KBps), we're looking at hosting a WiFi ad-hoc network on our accessory, and connecting to that network with the iPhone's WiFi.
This could really work out great in many regards, except we can't seem to find an (Apple-approved) way to programmatically switch the iPhone's WiFi connectivity. Ideally the app would automatically connect to the accessory's network when visible, and then re-connect to the user's preferred network when not visible/needed.
We are aware of the MobileWiFi framework, which fits the technical bill, but won't pass Apple's approval process.
Can anybody suggest a way to achieve our goal? Perhaps there is a system model view that can be called up to allow the user to switch WiFi networks without directly using private APIs?
Creative solutions welcome!
Hate to say it, there's really no way to do it. I can think of two easy workarounds.
1. Make it available on Cydia for jailbroken devices. AirServer just did this.
2. Less elegant, have UIAlertView with a switch over to the wifi pane of the Settings app that is shown when the peripheral is connected and disconnected. A lot like the location settings prompt.
3. Make an Android app!
Apple, you're a pain in the ass.
Sorry to be the bearer of bad news, but the definite answer is no. The main problem with your approach wouldn't even be Apple's approval process, but the inability to access the Internet while connected to your device. iPhone doesn't even try using cellular data when connected to wifi, being that wifi connected to the Internet or not.
You could file a bug report requesting these features and pray Apple hears you which will probably never happen in this case.
I would suggest going bluetooth, but if usb is not fast enough for you, guess that's not an option either.
That pretty much puts you back to square one and going usb. Or distributing your app via Cydia.
I write an app that requires a persistent WiFi connection, and to facilitate that connection being as persistent as possible, I have UIRequiresPersistentWifi set to yes in my Info.plist, and I recommend leaving the app 'open' when the user presses the the hold button.
However, on iPod touches (I have a 2G one and a 4G one for testing) running iOS 4.2.1, the device seems to shut down the WiFi connection much earlier after the device is put to sleep than it did on earlier iOS versions. I think it's on the order of 60 seconds.
I don't believe Apple has made any firm commitments on how it handles powering down network connections, but I was under the impression it was longer, intended to be longer, and it was something we could rely on. Does anyone have any input on this?
It appears after some reading/research, it looks like Apple's philosophy is that the WiFi network shouldn't be relied upon: "Note: Note that even when UIRequiresPersistentWiFi has a value of true, it has no effect when the device is idle (that is, screen-locked). The application is considered inactive, and although it may function on some levels, it has no Wi-Fi connection." - (from the iOS Application Programming Guide).
I'm guessing I'm seeing the different behavior on an iPhone because, also, in the iOS Application Programming Guide - "Connect to the network using the Wi-Fi radios whenever possible. Wi-Fi uses less power and is preferred over the cellular radios."