I have a BlackBerry app that performs a variety of tasks by accessing various network resources. I have a new requirement for the app that one of these tasks has to connect to the Internet via Bis-B, and if the device isn't able to do Bis-B the app should not allow the user to perform the task in the first place.
The way to connect via Bis-B is to append this to the URL you are trying to access:
;deviceside=false;ConnectionType=mds-public
For devices that are on Bis-B this URL suffix works and the connection is made through Bis-B.
The problem that I'm having is with devices that aren't on Bis-B. I had assumed that if I appended the above to the URL and then attempted to connect, the attempt would fail (and I could then trap it and use that to determine that the device isn't on Bis-B). Unfortunately, what actually happens is that the first one or two attempts succeed, but the second or third attempt fails with "Network could not be detected. Please try again later." After this happens, all subsequent network requests fail with the same message, even the calls that don't use the Bis-B URL suffix. After 10-15 minutes something seems to clear up and then all non-Bis-B network requests start working again.
So I'm naturally puzzled, and I'm looking for some way to reliable detect whether or not a device is on Bis-B. I know that the devices themselves can tell, because the wifi icon in the upper right corner of the BB screen is bright white if the device is on Bis-B and gray when it isn't.
I'm looking for some way to reliable detect whether or not a device is on Bis-B. I know that the devices themselves can tell, because the wifi icon in the upper right corner of the BB screen is bright white if the device is on Bis-B and gray when it isn't.
I have found the blackberry dots indicate whether you are on BIS or not. They will appear next to the 3g/edge indicator if BIS is routing over the cellular network, or they will appear next to the wifi indicator if BIS is routing over wifi.
I'm looking for some way to reliable detect whether or not a device is on Bis-B.
CoverageInfo.getCoverageStatus() returns a bitfield, and one of the bits is CoverageInfo.COVERAGE_BIS_B. My understanding is this bit corresponds to the blackberry dots appearing in the connection status area of the home screen.
Related
I have an iOS app that I had intended on adding a feature which shows WiFi bars to show the user their WiFi signal strength while the app is in full screen. As I have learned recently, it is not possible to include a feature in an iOS app which allows you to show the signal strength of the connected wireless network since Apple does not allow this unless you sign up to register for Apple's NEHotspotHelper and this is not a normal use case for this API.
To work around this issue, is there some way of still showing the user that their WiFi connection isn't good? Could I measure the latency of the connection is some way to show an alert saying the connection is bad? Are there any other symptoms of a poor wireless connection that I could measure to still implement this function in my app?
Is it possible to create an app where the message is automatically sent from one device to another when both the devices are in the same geo-location in predefined range or in the wireless points like Bluetooth?
I think there must be some way to do this. Please let me know if you have any idea about the same.
In peer-peer connection, It is not possible. When the user terminates the app everything goes with it.
But if you connect it with server, you could try to implement the behavior you are looking for with a push notification with content available, which gives you some time awake to download content in the background.
I have encountered a rather strange behavior when trying to implement download functionality on iOS. The download implementation works fine in that it finishes successfully, can run in the background, and file is stored on device. However during a download, I can turn of wifi to let the task switch to and continue on cellular network (or just start the download using cellular). This behaves as aspected. But when I enable wifi again, the download never seem to switch back to using wifi. The device is connected, and the wifi-connection-bars displays at the statusbar. Using rechability functions to check what connection that is available will even return Wifi, but the download seems to be stuck at using cellular.
The way I am detecting this is looking at the Usage stats in the system settings. The cellular data usage will rise in sync with the pending download, and continue to rise until the download is finished (even if wifi is turned on again).
I have tested with both Alamofire and by using NSURLSession and NSURLSessionDownloadTask directly, and they both behaves similarly. I have also seen this behavior in two completely seperate projects, on multiple devices, in iOS 8.4 and 9.1, when the apps are in the foreground or the background, and even AppStore behaves like this when downloading apps!
Has somebody else experienced this?
And if so, did you find any way to gracefully switch tasks back to wifi?
Thanks in advance.
This is normal behavior. Adding a new network interface (e.g. turning Wi-Fi on) doesn't stop existing TCP connections. They will continue until the original network interface goes away.
If you want to pause the request and reconnect when Wi-Fi becomes available, you'll need to call cancelByProducingResumeData: on the task, then create a new request with that resume data to restart the request from where it left off. That new request will go over the currently active network interface, which would typically be the Wi-Fi interface if Wi-Fi is up and running.
Before you stop the existing request, though, I would suggest trying a probe request for something like Google's generate 204 or one of Apple's captive portal detection URLs, to ensure that Wi-Fi really is working.
BACKGROUND
We're trying to use an iOS app running on iPhone/iPad to give WiFi credentials to an embedded device (using an ARM SoC running Linux). The embedded device starts an AP (access point), we instruct the user to connect to this AP and then the user submits their WiFi credentials. After WiFi credentials are received the device drops the AP and connects to the WiFi the user gave credentials for.
Initially, we try to hit a PHP page to get the list of WiFi networks the embedded device can see.
ISSUE
We instruct the user to join XYZ network (in iOS they must background the app, go into settings and switch to our WiFi network). We listen for an app resumed from background notification, check the devices current ESSID (ensure its our AP ESSID) and try to hit a PHP page to receive the list of WiFi networks. Often, this connection fails reports "The internet connection appears to be offline" (or something of that nature).
We currently have a stop gap when this happens telling the user to toggle their WiFi off and then back on (in settings). The device will reconnect to our AP as it's the most recently connected network. This ALWAYS fixes the issue, we've never had to toggle the WiFi twice in order to reach the PHP page on the device. Please tell me any possible way we can avoid having to instruct the user to toggle WiFi and still access PHP pages on the embedded device.
Note: when we're connected to the AP (whether this bug is active or fixed) the device DOES NOT show the WiFi icon in the status bar. We assume this is because the AP doesn't have a viable connection to the internet (can only access pages served by the embedded device). We've been testing on a device that has LTE cellular access, but the error still says "Internet connection appears to be offline".
Obviously we have a DHCP server running on the embedded device.
It's looking like this was caused by an omission in our dhcpd.conf file.
This omission was causing iOS to believe the connection was unviable.
We added the following line and are getting much better results:
option domain-name-servers 10.10.10.1;
I have observed from a wireless packet capture in my home network that anytime my iPhone device switches from asleep to active, and it is not attached to a power source, it sends a DHCP Request. I have validated this behavior with two different iPhones (with different iOS versions). I have also tested an Android device and this does not happen.
Hence this makes me wonder why does an iPhone need to send a DHCP Request, once switched from asleep to active, if the DHCP lease has not expired? In addition, why doesn't this happen in an Android device?
I am pretty sure this is not an issue related to a bug, such as the one reported in
http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address.html
If the device thinks it has an unexpired lease, and the device's network interface has just brought up physical LINK, then that the client should start in the DHCP INIT-REBOOT state (or even INIT state).
Alternatively, if the device thinks it has an unexpired lease, and has kept LINK up continuously since going to sleep, then the client could start in the BOUND state when awaking.
Basically the main reason that the devices react differently is the way they handle the sleep mode (most iOS will disable the wireless interface, whereas in Android it is configurable in the menu).