I am working on some home automation project and I am trying to use my iPhone as "I am home" sensor.
I tried
Reachability API (doesn't work in bg)
CLLocationManager and startMonitoringForRegion (too inconsistent and not accurate at all)
performFetchWithCompletionHandler (not predictable triggering)
Is there a way to notify that I am on a certain network?
I also tried the reverse approach of continuously scanning my lan, but other that seeming stupid it doesn't work and it's not scalable, iPhone goes in low power mode when it's locked and it just sends beacons, aka is not pingable, reachable.
Assuming:
I know the iphone mac address
IP may change over time
I can't access so DHCP logs
I can run a server on a raspberry pi to sniff (I don't like it)
Related
Apologizing in advance, I am no 802.11 expert and this is a long winded question...
I am working on an iOS voip client, we use the Cocoaasyncsocket library for our TCP/UDP connections. The app/iDevice is allowed to roam in/out of wifi coverage (for the purposes of this discussion we will assume the app is using wifi only... no cellular connection). We have the appropriate plist settings for backgroundmode (voip, audio) as well as requiring persistent wifi.
We are having a problem that seems particular to Cisco AP's. With the client app in the foreground and roaming out and in of wifi range, we noticed that eventually the iOS device will eventually not automatically rejoin the network. After a great deal of debug the failure to rejoin was noted to have nothing to do with the app. The failure to re-join can ultimately be reproduced by forcing the AP (via config) to deauthenticate the iDevice three times. After the 1st and 2nd deauthentications, the iDevice readily automatically re-joins. But after the 3rd time, iOS does not automatically rejoin the network.
The network will be rejoined if, for example, the iOS email app is put in the foreground.
We were curious if any other VOIP type apps suffered this problem, and ran an experiment with running FaceTime and Skype on the iOS device.
Skype behaved much like our voip app, after the 3rd deauth the connection was lost. Trying to initiate another call resulted in a message to the effect of "must have an internet connection to make a call".
FaceTime did disconnect on the 3rd deauth and failed to automatically rejoin... however, we were able to re-initiate another FaceTime call which caused iOS to rejoin the network and make the call.
We would like to emulate the FaceTime behavior, but so far do not understand what we should be doing differently. To the best of our knowledge, we are properly closing the open sockets when we get disconnected. Is anyone familiar with this issue and have some insight to offer?
I'm developing an iOS app that connects to a certain type of BLE device, but I'm writing the code in a room that has 20+ such devices sitting around, powered up. I consistently find that in the morning, I can connect to my personal device just fine, but as the day wears on, it becomes impossible to connect to my device, as if the 20+ other devices have woken up somehow and are blocking my signal. No one is using most of these devices; they're just sitting on tables. Is this a known bug? Is Apple working on it?
Are all the devices Advertising?
If they are advertising with say 20ms then it could be difficult to hear all. There are "only" 3 advertising channels to share between all devices. The connection happens on the same channels (the peripheral listens after it's own advertising to hear if someone want to connect).
It has nothing to do with Apple CoreBluetooth. In my experience CoreBluetooth can handle around 20 devices after connection has succeeded and the activity has moved to the traffic channels.
1) Try using a slower advertising interval. This should work okay if your app is in the foreground.
2) Use a BLE sniffer (TI USB dongle is fine) and see if connections fail on protocol level, then it is not CoreBluetooth's fault.
3) Only advertise with fast interval when needed or you really really need a fast discovery.
As a rule of thumb apple needs up to 55 advertisements in background mode to see a device when it's the only one visible. So if you really need around 1.1second discovery then you might need 20ms advertisement interval, else use 100ms or even more (see Apple advertising interval guidelines for the exact number that will optimise discovery)
100ms gives so much more capacity and not too bad discovery.
1-2s gives a much longer battery lifetime and will be found in 1-2 minutes if your app is in the background. This would be quite fine for eyeBeacons in malls or the like while you might want 100-200ms in smaller areas.
I need to connect an iOS device (iDevice) to a WiFi access port but keep using the cellular data connection.
Default behavior is for iOS to set the WiFi connection as the default gateway, routing all internet traffic there. In my case the access point is a black box device supplying a WiFi network to access it's services, but not the internet.
One solution which we have tried, is to make the iDevice the access point (hot spot) and have the black box device connect though it. This is far less desirable as the black box device has no UI. So it is difficult to setup. We have lessened the pain by using Bonjour but still...
Is it possible to make a system call (iOS application) to restore the gateway setting back to the cellular gateway after the iDevice joins a WiFi network?
Would be even better if there is some way to setup the iDevice (IPhone or IPad) to maintain it's cellular gateway after connecting to a WiFi access point.
I am trying to build an app for iOS that can connect to computers running macOS or windows, and control a few stuff on those computers. Another application will be installed on those computers so that the app on iOS can connect to them. But at first I need to discover those computers in the network that has my app installed and running. What is a good way of doing that? I thought about using broadcasting, multicasting or bonjour. Are there any other options? Which one is best for my situation?
I am planning on doing two different applications for macOS and windows, one with objective c and other with c#, so the networking stuff should be available for both of those. Thanks in advance
The simplest option by far would be to use IP/UDP broadcast packets. The application on the computers (running whatever OS) can all sit there listening on a predefined UDP port (e.g. 9999), and when the iOS device wants to 'scan' the network, it will send out an IP/UDP broadcast packet with the destination port of 9999. Upon receiving the broadcast packet(s), the application on the computers can respond since it now knows the IP address of the iOS device, and you can take things from there.
The cleanest way to handle a computer leaving the network is for the application that is running on the computer to communicate this fact to the iOS device since it already knows the IP address of the iOS device. But if keeping a current list of computers is crucial, then some sort of a polling mechanism is unavoidable because the computers may crash for whatever reason without having the chance to send the bye-bye message.
Multicasting can be utilized as follows: computers periodically send IGMP joins for a predefined multicast group (e.g. 224.1.1.1), and iOS device sends the multicast UDP packet destined to 224.1.1.1 when it wants to 'scan' the network. The multicast UDP packet(s) will be received by the computers since they have already joined the multicast group of 224.1.1.1, and then the computers can start communicating with the iOS device now that the IP address is known. However, this seems overly complex, and does not really offer any advantages. The whole point of using multicast is to save bandwidth, but the amount of bandwidth saved will be minuscule. Unless you are going to send the same data in substantial quantities from the iOS device to all the computers, there is simply no reason to go down this path.
As for Bonjour, unfortunately I am unable to comment as I have no experience with it, but I would still vote for simple broadcasting to keep things platform independent... well, at least on the computers side. :)
Is it possible to get GPS information in a mobile device through APIs without having any GPRS connectivity?
Edited
Yes, for example on the Java ME platform or Apple iPhone
Yes; if you are on a device that has GPS hardware in it and software development on the device gives you access to that hardware from your software.
This can be using a built in API for opening a COM port. You then just need to open the port that has the GPS hardware connected to (internal GPS receivers inside the device are often connected to a fixed COM port number) start interpreting the (often) NMEA strings that the GPS receiver is sending out.
Or perhaps the device has more specific GPS related APIs, like the GPS intermediate driver in Windows Mobile 5+ that lets the OS talk to any GPS receiver (either built in, or connected via cable or bluetooth to a COM port) and lets multiple applications concurrently interact with the GPS data.
P.S.
GPS has nothing to do with GPRS per se. You might have gotten that idea because of A-GPS which uses telecom network information and/or a dataconnection (like GPRS, EDGE, UMTS, WLAN, whatever) to download a small file with information about the location of GPS satellites.
This data will then enable your device shorter GPS aquisition times within the time period that this retrieved data is current - often a couple of days to a week I believe - because it does not just need to see what GPS signals it can receive and make sense of that, but it has a lot of prior knowledge about the GPS constellation that should be in orbit in the part of the sky you can see.
GPRS is a two-way data transmission which enables you to access the iternet while the GPS is just a receiver and as peSHIr already mentioned it has nothing to do with GPRS. GPS receiver receives the signals from multiple satellites and calculates the location from time differences.
Anyway... you need GPRS or any other internet connection only if you want to use any web service for reverse geolocation or you want to use google maps or any other location service. But just for receiving (calculating) the coordinates GPS by itself is enough.