Based on the post at http://beekn.net/2014/03/apple-ios-7-1-launches-major-ibeacon-improvement/, I just re-ran my own tests on detection time for my Chinese iBeacons. In 7.0, I was seeing backgrounded apps getting notified of beacon region entry/exits within 2-3 minutes on average. With 7.1, I’m seeing this reduced to 30-40 seconds.
I need to do more testing to remove sample error, but this is a huge improvement. Let’s hope it’s had no resulting effect on battery life.
In the ongoing effort to improve my beta book An introduction to UIKit dynamics, I’ve been experimenting with a new effect, UIView shattering:
This is a general effect, that can blow up any view hierarchy at any point within it. I’m still fine tuning it (sharp eyed people will notice some of the view vanishes oddly in the final animation), but hope to have it in the book shortly. It’s a fun demonstration of linking dynamics with custom effects (the combined gravity and spin0, custom actions (to ensure we know when items have left the screen), and custom dynamic items (to enable direct animation of CALayer instances).
I’ve been working on a new iBook-based introduction to UIKit Dynamics. It’s an introduction to the core concepts, and includes a variety of recipes for physics effects, such as:
It’s still in development, but I’d love to hear feedback on the current draft.
After yesterday’s post about my cheap Chinese iBeacons, I received some more documentation from the eBay seller, and some excellent information from Rhys Jones of Bookry.com. Between them and my own fiddling, I can now compile a more comprehensive list of services:
- First, to prevent the devices from disconnecting you after a short window, write 0×47 to characteristic 0xFFF1.
- To activate the device’s little blue LED, write 0×01 to 0×1802.
- The battery service is available as normal at 0x180F.
For the following, you’ll need to prefix the password you’ve set onto the values written. It’s three bytes, and the default is 0×666666.
- To set the proximity UUID, write the password followed by your choices to 0xFFF2
- To set the major identifier, write the password plus a short to 0xFFF3
- To set the minor identifier, write the password plus a short to 0xFFF3
- To set the power value, write the password plus a byte in the range 0xC5-0×80 to 0xFFF4. I’m not sure what the differences between this power and the later Tx power flags are.
- To change the password, write the old password, plus three bytes of a new password, to 0xFFF6.
- To set the broadcast rate, write the password plus a value in the range 0×01-0×64 to 0xFFF7. The value changes in 100ms increments.
- To change the transmission power, write the password plus the two’s-complement of your new power (in dB) to 0x2A07.
When you terminate your connection, the device will restart with the new values. Don’t forget, whilst you’re connected, the device will not broadcast the beacon signal. With these, you should be able to configure your beacons exactly as you want.
After a bit more digging into my Shenzhen Ankhmaway iBeacons – those of the 3 second disconnect – I think I’ve discovered how to prevent the disconnections from central devices. Characteristic 0xFFF1 of service 0xFFF seems to be the keep-alive. Writing the value 0×47 keeps the device from terminating the connection, and the value is reset to 0×01 on disconnection. I’ve not successfully written anything else to this characteristic – other values just terminate my connection. Perhaps this is a basic form of non-password security?