iOS 9.2.1: iBeacon region monitoring bug - iphone

I deployed the same iBeacon region monitoring code in 7 devices. One of them, iPhone 6 running iOS 9.2.1, is regularly failing to detect beacon states (inside, outside, etc..).
I tried with and without SIM card and when the SIM card is inserted it gives better results. However, when compared to an iPhone 6 running iOS 9.2.3 and one running iOS 9.2.1 it gives worst results (the latter two iPhone's always detect the region).
Have you experienced the same in this version of iOS (iOS 9.2.1)?
Is this an known official Apple bug?
My theory behind this:
iBeacon region monitoring uses iPhone location, iPhone location can be
improved using Wi-Fi and phone signal and possibly also accelerometer
and gyroscope data.
iOS could be using these in combination withe the Bluetooth data to
"tune" the beacon ranging thread (in other words if a significant
location happens then the background monitoring frequency will be
increased). Hence if this tuning is depending on the SIM card
information there could be a version of iOS where they put a stronger
dependency on the SIM card presence leading to what I am observing.

Related

Motion & Fitness on iPhone 5/5C

From what I know iPhone 5/5C do not have the motion processor like 5S and newer phones have, but when I request the motion permission the default alert with Allow and Don't allow still appears, even if I check before if the motion is available for device with MotionManager.isDeviceMotionAvailable. I would expect the alert not to appear for 5 and 5C.
What am I doing wrong here? Does 5 and 5C actually support motion?
No, you are getting this wrong; isDeviceMotionAvailable detects the presence of a gyroscope and an accelerometer. It's actually available since iOS 4, which came out way before the M7 motion coprocessor inside the iPhone 5s.
From Apple Documentation:
The device-motion service is available if a device has both an accelerometer and a gyroscope.
As #the4kman said the device motion is available through accelerometer and a gyroscope.
But what I actually meant and needed in this case is the user's activity, which is available through the M7 processor that is installed on 5S and newer and to check if that is available on a device I did CMMotionActivityManager.isActivityAvailable()

iBeacon - iOS Region Monitoring and Region Advertising simultaneously

I am trying to use
[self.peripheralManager startAdvertising:self.myBeaconData];
to advertise UUID and beacon’s identifying information and also monitoring same UUID with different minor and major using
[self.locationManager startMonitoringForRegion:self.myBeaconRegion];
but I am not able to fulfill this requirement of using same Device(iPhone) as receiver as well as broadcaster(advertiser)
Can anyone help me to create a iPhone Device to behave as a Broadcaster(Advertise an UUID, for example "A77A1B68-49A7-4DBF-914C-760D07FBB87B") and at same time behave as Receiver to Monitor same region for other beacon having same UUID "A77A1B68-49A7-4DBF-914C-760D07FBB87B".
Currently you cannot broadcast an iBeacon and simultaneously monitor for iBeacons. This is current as of iOS 7 and iOS 8 Beta 4. This is not likely to change any time soon. This is also why all tutorials show 2 apps and 2 devices usually.

CoreBluetooth - iPhone advertising in background mode

I am working on an iPhone and Mac OS X application, which allows you to lock and unlock your Mac via proximity. Means if you the signal strength is under a determined threshold or the connection gets lost it shall lock the mac.
I am working with Apples CoreBluetooth framework for BTLE, using the iPhone as a peripheral and the Mac as a central. So far so good. It also works very well but when I send the app to the background on the iPhone the advertising seems to change. The iPhone still advertises but without the service profile and characteristics, I use in the app.
Although this is not a problem when the iPhone is still in the range of the Mac, because it's still connected and the characteristics are not used in the central, it becomes a problem after moving the iPhone out of the range. As expected the Mac locks and starts discovering to reconnect the iPhone and unlock if succeeded.
But in this discovery, I use the specified service profile and the characteristics to only get devices running my app and to identify the one for unlocking.
I tried a workaround by discovering without a service profile and identifying the correct device via its UUID, which I saved when I started to use this iPhone for locking and unlocking. This workaround also works in a small scope, because when I turn off the Bluetooth on the iPhone and turn it on again, it gets another UUID. That's a constraint I could live with, but it also changes the UUID after a few hours and then the unlocking does not work.
Maybe someone already worked on an app like that and know how to fix such a problem? Or you know a static value which I can use to identify the device?
So it seems, like usual, Apple has some weird and unique things going on in their framework. When you advertise from an iOS device (such as your iPhone), there are two "storage areas" for the advertisements -- a normal one that any device that is scanning can see, and an "overflow" one that can only be seen by iOS devices that are specifically scanning for it. When your app advertises in the background, all services UUIDs that you advertise go into this overflow area unfortunately, so it looks like only other iOS devices can see it -- and not your Mac. From the CBPeripheralManager docs:
Any service universally unique identifiers (UUIDs) contained in the
value of the CBAdvertisementDataServiceUUIDsKey key that do not fit in
the allotted space are added to a special “overflow” area; they can be
discovered only by an iOS device that is explicitly scanning for them.
While your app is in the background, the local name is not advertised
and all service UUIDs are placed in the overflow area.

Using Old iPhone 3G for testing, remove the sim card?

I just got an old iPhone 3G for testing. It doesn't have a plan attached to it, but I just put in the sim card and it said it will take a while to activate.
When everyone has test devices, do you just leave the sim card out? What about when testing location based services that need to find cell towers? What do we do in situations like this? I don't want to pay for service.
You won't get anything out of the cell towers without a valid SIM card. I use my wife's old iPhone 3G for testing, and it still has the old AT&T sim card, but of course there is no service because that sim card is not on our account anymore. I always leave it in Airplane mode.
The main thing I'm verifying with the physical device is performance, UI responsiveness, and memory issues that present no problems in the simulator, but choke on this old device. The iPhone 3G is great to have on hand as a minimum baseline for that stuff.
The location-based stuff you should be able to mock up without needing any "real" data. Do a google search for "iphone" "mock location" and see what that turns up.
This looks promising:
http://rssv2.blogspot.com/2010/03/mocking-core-location.html
You don't want to have to develop with real, live data until you are in the beta stage anyways. Using real, live data during development is a huge hassle, not easily repeatable, and very time consuming. And this makes it impossible to write effective integration tests.
The iPhone has a GPS receiver, you don't need cell towers they just help speed up the process of acquiring the GPS satellites and finding your location. WiFi service will do the same thing but is not required. With no cell data and no wifi it can take several minutes to acquire GPS satellites, download ephemeris from the satellites and get a good location, but it works.
I use a 3G running 3.1.3 with no sim card for 3.1.3 testing and it works fine even for using location services, but I have wifi here.
I also use a CoreLocation simulator which allows me to simulate and repeat motion scenarios without going anywhere, it can simulate acquisition time, varying horizontal accuracy and motion. The simulator is available on github.

iPhone Simulator providing location results

I am using iOS SDK 4.2 and followed this tutorial: http://mobileorchard.com/hello-there-a-corelocation-tutorial/, and got some GPS logs happening on the console using both iPhone and iPad.
Then I ran it on the simulator to test other features and the CoreLocation logs were hitting the locationManager:didFailWithError: method which is fair because the MacBookPro (OSX 10.6.6) has no GPS functionality... or so I thought.
This morning I tested it on the iPad again at work instead of at home and now testing on the iPhone simulator without any device connected the simulator is providing my location results of my office (No I don't work in Cupertino) and the horizontal accuracy is varying between 45-56m each time and only giving two samples at most (presumably because my notebook isn't moving).
Now I have fully closed XCode and the simulator and deleted the app from the simulator and performed a clean and rebuild and still getting my current coordinate. I can also replicate it without internet access incase the simulator was being tricky with some sort of GeoIP.
Where is the simulator getting my location from?
I thought perhaps maybe the simulator stored some GPS location data when I used the iPad this morning but with no device connected and clean starting everything it is providing varying results eg +/- 0.000001 of a degree variations.
From your MacBook's IP address or, if it's on WiFi, the stored location of your WiFi network. Since it's so accurate for you, it's the WiFi, since the IP address method generally narrows it only to a city, or at best, part of a city.
Skyhook provides geolocation information for most of the WiFi networks in the US and some other parts of the world, info that Apple subscribes to.
Edited to add
Apparently Apple ditched Skyhook last April and now uses its own database, but the system is the same. Much like Google got in hot water for in Germany, someone drives around with a computer looking for WiFi networks and recording their location.