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."
Related
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.
I have a peripheral (using CSR1010's) that only is able to connect to the iPhone if it advertises with Gap settings "Bondable Mode". For my application, I don't want the phone to bond to the device, but do still want to pair (have a secure connection).
If I put the server in non-bondable mode, the iPhone drops the connection immediately after pairing is authorized without any action on the peripheral (i.e. it's the iPhone disconnecting).
According to the spec, non-bondable mode only means that regardless of how the connection is established (with/without pairing), the devices should not bond (retain that secure connection after this connection). I'm wondering if the iPhone actually supports this (spec says it's mandatory to support it).
No, that behavior you mention started to happen in iOS 9. Before that it worked fine. It's not standard behaviour but that's what apple does...
What do you want to achieve anyway? Using pairing without bonding does not add any security at all almost, since ble pairing can easily be decrypted.
I think it is not the issue of whether iPhone support the non-bond-able or not, it is the different device can choose the best security level for itself.
which means each device can choose the high security mode(which request peer device also need high security), or choose the lower one(which means he could not connect to higher security node). Regarding to your concern, if iPhone also use the non-bondble mode, that means it is meaning less for the high security level since even low security level device can interact with iPhone.
or we can say iPhone can support the mode that without pairing but does no employ it.
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.
I am making an app that requires consistent wifi connection. The problem is that when the wifi is off and I turn on the app nothing happens, even though I have activated the UIRequiresPersistentWiFi flag. Also when the screen locks, and I go to the app after unlocking, it also can't use the wifi. The only solution that I have found for this problem is the activation of UIRequiresPersistentWiFi, which clearly doesn't work in my app, or I am not doing it right. So does anyone have any idea what could be wrong?
UIRequiresPersistentWiFi doesn't force the device to connect to WiFi when the app is launched, it only specifies that an existing WiFi connection should be kept open for the duration your app is running. The default behaviour is for iOS to drop its WiFi connection after 30 minutes to conserve battery life.
See the documentation for more detail.
I am working on a major product release for my company. We are designing a new device that we would like to integrate into an iOS app. (FYI, we have recently been accepted into the Apple MFi program so we are past that step.)
What we desire is to create a hardware/software eco-system where our users can start our iPad app (yes, it is specific to the iPad and the not iPhone or iPod Touch devices) and the application will automatically discover and link up with any close-proximity hardware that we've developed.
This means that I will need to implement some form of device connection process on both the iPad and within the hardware.
Is there any way to code automatic connectivity to a Bluetooth device from within an iOS application?
I am aware of the Core Bluetooth Framework which has this capability, however, it only works with the new iPhone 4S. That's not an option.
I've also researched about the External Accessory Framework, which can be used to connect to external devices whether they are connected via the iPod port or Bluetooth. This is an option but, if my understanding is correct, our hardware must already be paired with iPad before the iOS software can connect to it. This is less than preferable because although many of our devices may not be in immediate vicinity at one point in time, our customers could potentially own 100's devices that they may desire to connect to with our software.
What are my reasonable options or alternatives? The end goal is to provide a very easy means for our users to be able to connect to our devices, from within our software, on an iPad.
NOTE: I MUST NOT jailbreak the iPad or break any Apple TOS agreements.
UPDATE (3-7-2012) I saw today that the 'New iPad' (as it is being officially called) will be Bluetooth 4.0 capable. I assume this means that this iPad device will be able to use the Core Bluetooth Framework. This doesn't immediately solve my problem because we do want remain compatible with at least the "last generation" iPad device, but this is worth pointing out for others who may be looking for such an answer.
You cannot connect an iOS device to a bluetooth device without pairing first. It is purposely built that way by Apple to reduce the likelihood that someone could connect a bluetooth device without the user knowing about it. If pairing each device is unacceptable (and it sounds like it is), and you don't want to develop a dongle, the only remaining path I can see is to make your devices capable of relaying data between them like a mesh network. That way the user would only have to pair with a single device, and that paired unit would relay communications between the other devices and the iPad.
One of your alternatives would be going WiFi (AdHoc or Infrastructure) with Bonjour. For example you would be able to detect the device nearby (if it is maintaining it's own AdHoc then by SSID; if it's in infrastructure network then by service being announced). One big drawback would be that you couldn't connect directly (from app) to the device's network - user would have to do it manually.
As for BT: big drawback is lack of a serial protocol (not implemented in iPhone/iPod/iPad).