I have had a pack of four jaalee beacon stickers delivered and I'm having a problem getting them 'woken up'.
According to the website, you have to tap the beacons two or three times. I've tried this a few times but still no cigar, I can't detect them using various bluetooth sniffers.
I'm wondering if I'm tapping them too hard, too soft.
Also found a Jalee app which asks me to press a button on the stickers, no button is visible but I pressed for a few seconds and one of the four stickers 'beeped' once... but the app failed to pair with it. I couldn't get the sticker to beep again.
This was a cheap alternative to Estimote stickers I ordered but which never arrived. So far, beacon sticker technology doesn't seem to be 'there'.
The beacon stickers I have need a few things to happen to be enabled.
1) Download the Jaalee app, I'm not sure it was available when my stickers first arrived. This is the correct app for iPhone for the kind of stickers I have.
App store link for Jaalee thinnest smart tracker... app
2) Open the app and select a kind of activity to which the beacon is to be enabled (they are trying to ape Estimote I believe). I chose the magnifying glass.
3) On the following dialog select + to add a new sticker.
4) Squeeze the beacon sticker firmly in the centre for several seconds until it beeps.
5) Hold it close enough to the phone/mobile device running the app to enable the app to pair with the beacon and enable it.
At this point the Jaalee beacon should be detectable with a standard Bluetooth sniffer app such as 'LightBlue'
Firmly tap the beacon on a table and it should beep. You may need to turn it over a tap the other side. They need a firm tap.
Once woken up it will be available to connect to and reconfigure. If left it will go back to sleep after about a minute.
I've seen claims on the net that the newly released iOS 7.1's iBeacon support.
Specifically:
The system is supposed to still notify your app about
didEnterRegion/didExitRegion events, even if the user explicitly
kills your app.
didEnterRegion/didExitRegion notifications are
supposed to be faster from the background and/or with the device
locked.
I have not been able to confirm either of these claims with my own testing. In fact, I seem to be less likely to get didEnterRegion/didExitRegion notifications from a locked device. (more accurately I seem to get didEnterRegion notices, but not didExitRegion notices). That could be because Apple made me remove my BLE background mode entries in my info.plist - I'm not completely sure. I'm still trying to sort this out.
I had trouble setting up my tests at first, but I have witnessed background region entry callbacks after killing an app in iOS 7.1 on both iPhone 4s and iPhone 5s models. See comments below for testing details and instructions to reproduce.
I have also done tests on background detection times on an iPhone 4S, and I still see delays of 15 minutes on iOS 7.1. My full test results and methodology are described here.
Finally, I have also done some tests on the fluctuations on the "accuracy" (distance in meters) measurement on the same device before and after the upgrade to iOS 7.1. I do not see an obvious difference in the noise on the estimate. The graphs below show results before and after the upgrade, with an iBeacon 0.5 meters away for 60 seconds then moved to 3 meters away for 60 seconds. In both cases, the transmitter was a properly calibrated iPhone 4S w/ iOS 7.1 and the receiver was an iPhone 5S.
iOS 7.0.6 Estimated distance
iOS 7.1 Estimated distance
As has been mentioned in several articles circulating around the internet, beacon sensing is available even when you swipe your app away from the multi-tasking view. However in my experiments, a region enter/exit event doesn't call the didDetermineState: directly (Probably because I hadn't been using the AppDelegate to initiate any beacon sensing but instead triggering monitoring based on UI events). Instead if you have registered for Background Location Updates, your AppDelegate's didFinishLaunchingWithOptions: method would get called with the value for key UIApplicationLaunchOptionsLocationKey in the parameter launchOptions set.
You can do a simple check like this to test if this is indeed a location update that has bought your app into the background to perform some task.
if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])
You can then either register your monitored regions again or start ranging immediately.
P.S. CLLocationManager retains your previously monitoredRegions on app restore but without starting monitoring again using the same UUID and identity, you would not get the enter/exit region event in CLLocationManagerDelegate (which had brought your back up to life)
David has done some wonderful work on this, so I'm writing this cautiously... but I'm seeing something quite different from him in my tests.
I'm using two phones: an iPhone 4S running iOS 7.1 (11D167) and an iPhone 5S running iOS 7.0.6 (11B651). My iBeacons are manufactured and sold by Bluecats (www.bluecats.com), although I'm not yet using their SDK (ie. I'm just using CoreLocation) and I don't think the manufacturer makes much difference.
I'm getting response times of around 1-2 seconds on both devices when the app is running in the foreground and also when running in the background. The only difference is when I remove the app from the app switcher: iOS 7.0.6 never responds (or perhaps will do in 15 minutes), but iOS 7.1 responds in roughly the same time. When I say "respond", I mean that the CLLocationManager's locationManager:didDetermineState:forRegion: delegate is called by iOS.
I'm testing by actually wandering around my office with phones in hand, so I'm physically moving in and out of range. Strangely (?), in my early testing, where I was sitting at my desk and simulating moving in and out of range by removing and reinserting batteries, I was seeing much slower response times. Perhaps this is part of the difference?
In my testing I have seen the presence of a beacon go un-noticed by an app for up to 15 minutes, but I found something that's interesting. I'm using RedBearLabs mini BTLE sensors as ibeacons and their app to program the beacons, http://redbearlab.com/ibeacon/ (http://redbearlab.com/s/MiniBeacon_v1.zip), seems to have an something in it that immediately starts a scan / update of beacons. If I start a beacon up, and in my app it goes unnoticed, by starting then quitting the MiniBeacon app my app immediately notifies me that there are new beacons. This is the same result when entering or exiting. Their app uses CBCentralManager, which my app doesn't, so maybe a mixture between CBCentralManager and CLBeaconRegion is the way to go? I imagine CLBeaconRegion starts / restarts the bluetooth radio, so maybe that is the reason for this. Just taking a stab at it in hopes that someone with a more complete understanding can help resolve this.
Thanks
My testing also reproduces 15 mins to start scanning when my app is in background mode on iOS7.1.1. Just a bit curious, I have seen quite many youtube videos from different companies showing the app has been waken from background mode as soon as they approach their beacons. Is it sales trick?
I did everything verbatim on this sample (How do I discover a Chromecast device using Android?).
The chromecast icon turns to white on indicating there are devices available.
When I pressed it, the application unfortunately stops.
What can be going wrong? The only step so far I want to achieve is list all available devices.
Cheers!
I am trying to develop a simple calendar app with a live tile but in battery saver mode the background agent won't run and I can't have the live tile updated with the current day and day of week.
I noticed that the Calendar (1st party app) does not suffer from this problem even in Battery Saver mode.
Does it get special attention / capabilities being a first party app or there is some trick that I don't know (yet)?
The built-in (or system) apps are not restrained in the same way that 3rd party apps are. There are many examples of this on Windows Phone but two visible ones are...
The calendar app updating its Live Tile even when Battery Saver is turned on (which you noted).
The People Hub Live Tile which has many small tiles which rotate in sequence - as developers, we don't have access to that Live Tile Template.
The Photos Hub Live Tile displays photos using a panning animation - also not available to developers.
As there is no 'fix' if your PeriodicTask doesn't run as expected, you'll simply have to update the tile when your app runs as well as checking the status of the PeriodicTask each time.
I'm doing a phone app with some animations and they look really clunky on the emulator. I don't have a phone yet so this is the only way I can test my app.
Sometimes the animations start late (up to a second after user input) and the they are almost always very jagged. Far from the smooth fades and transitions that I've seen on the interwebs. I'm not using anything hairy - just basic rotations and opacity fades on one or two elements.
Does anyone else see this in the emulator? If not, i guess I have a bug somewhere. If so, is there a work around? Should I bump the priority of the xde.exe in process explorer? Other?
Thanks!
This may be a consequence of gpu detection no working on your system.
You can verify this by checking if you can see the frame rate counters.
Jeff Wilcox – Frame rate counters in Windows Phone
Note the emulator system requirements here also.
Setup and System Requirements for Windows Phone Emulator