The core value of this group is to bring developers up to speed with BB technology, concentrating on BB10.Exploring efficiency, beauty and power BlackBerry provides to its users by designing Apps that can be used globally and that improves developers life as it improves community life.
Eddystone Lighthouse by Vilhelm Melbye (1824–1882) Attributed to (Sotheby’s London, 07 May 2009, lot 54) [Public domain], via Wikimedia Commons
Written by: John Murray
Introduction Eddystone is probably the most famous lighthouse in the British Isles, built on a small and very dangerous rock 13 miles south west of Plymouth, it has been protecting shipping and sailors since 1698.
It’s fitting then that Google chose “Eddystone” as the name of its recently published Eddystone Beacon Specification as an alternative to the older and more established Apple, iBeacon specification.
Having blogged extensively and written a variety of resources for developers such as code samples and Cordova Plugins allowing BlackBerry 10 and other platforms to interact with beacons it seemed to me that it should be relatively simple to demonstrate that BlackBerry 10 was also capable of supporting Eddystone Beacons in applications.
This is the story of this challenge. If you want to skip forward the code sample that demonstrates how to use Eddystone in BlackBerry 10 applications can be found here; it’s an extension of an earlier code sample: WheresMyBeacon, that I wrote.
What is Eddystone Anyway? I’m not going to repeat the details of the specification, which you can find here; rather let’s, first compare Eddystone with the Apple iBeacon.
An Apple iBeacon frame is carried in a standard Bluetooth Low Energy Advertising frame. In particular it’s embedded in the Manufacturer’s Field, and specifically it’s contained in the Apple proprietary Manufacturing Data itself. It contains 4 elements: a unique identifier in the form of a UUID and two integer fields (Major and Minor numbers) and an indication of the calibrated transmitted power measured in dBm at 1m from the iBeacon. The power measurement allows you to estimate distances since you know the measured power received in the receiving device.
On BlackBerry 10 and Android you can directly detect these advertising frames and have your application act upon them. On iOS direct access to the specific iBeacon form of frame is forbidden and all aspects of iBeacon detection are handled through the Location APIs.
Eddystone uses the same Bluetooth Low Energy Advertising frame as iBeacon; however, rather than use the Manufacturer’s Field it embeds its payload in a standard Service Description field using an Eddystone service UUID that has the 16-bit value of 0xFEAA. Rather than simply advertising a single form of field, as iBeacon does, it transmits a sequence of three message types:
A UID message – this is similar to an iBeacon in that it contains two fields used to uniquely identify the beacon:
A TLM message – this contains telemetry data about the beacon with information like its temperature and battery voltage.
There seems to be no requirement to transmit all three types. TLM messages seem to be always transmitted but fairly infrequently whilst you may choose to transmit only UID or URL messages, or perhaps both depending on the application.
The URL message is a useful extension over iBeacon allowing a beacon to advertise a URL that can be detected and linked to. The TLM message is useful to determine when the battery needs replacing.
Getting My Hands on a Real Eddystone Beacon The next step in any investigation like this is to acquire some hardware; namely an Eddystone Beacon. Luckily I’ve got a number of Estimote beacons lying around and these nice people at Estimote had just published a new set of firmware for their beacons that would upgrade them to be Eddystone-capable! Nice!
The upgrade over the air was quite simple to perform and I soon had an Eddystone Beacon advertising quite happily – here’s what I saw for the UID type message:
It all looked good as per the specification and it was quite easy to parse this data in the BlackBerry 10 application.
I did the same thing for the URL and TLM frames and modified the application’s UI to display the content in a simple manner.
Here’s a screenshot from the application of the Eddystone Beacon UID frame. You can see the
Namespace and Instance Id fields as well as the calibrated power reported in dBm and the path loss in dB, which can be mapped to distance.
Here’s a screenshot from the application of the Eddystone Beacon URL frame. You can see I’ve programmed the beacon with the URL http://www.blackberry.com. Notice that this frame also reports the calibrated power reported in dBm and the path loss in dB, which can be mapped to distance.
Here’s a screenshot from the application of the Eddystone Beacon TLM frame. I’ve broken out the battery voltage that shows a healthy 3.15 Volts and the beacon temperature that is running quite cool at 28.5 C. I haven’t displayed the various other fields and leave that as an exercise for the reader.
Summary One of Google’s objectives for Eddystone was that it:
Works well with Android and iOS Bluetooth developer APIs
I think I’ve successfully demonstrated that it works well with BlackBerry 10 Bluetooth developer APIs as well!
I’ve released v2.2.0 of the WheresMyBeacon application containing the features described in this article and so you can download, review and reuse the full source code – you can find the URL in the “Resources” section below. I hope this has been interesting and will help set you on your way developing real-world event driven Bluetooth applications for Blackberry 10.
Please feel free to contact me, @jcmrim, via Twitter if you need any help on anything Bluetooth Smart.
Last week, Chad filled you with all the goodies about Ionic and Angular Material. As you can see, both Ionic and Angular Material are both rated quite well and allow you to develop a cross platform solution easily and efficiently. Just to re-iterate what Chad had said already, we have been evaluating and comparing the frameworks in certain areas such as whether the framework support cross platforms, the popularity of the framework, theme support, performance and scalability to various screen resolutions and so on. We just wanted to share our findings with the broader development community and here they are.
Since you have already seen facts about Ionic and Angular Material, I will focus on Sencha Touch and JQuery Mobile this week.
Both of these frameworks take the “write less, do more” mantra to the next level. Instead of writing unique applications for each mobile device or OS, these frameworks allow you to design a cross platform application that will work on all popular smartphones, tablets and desktop platforms.
Let’s take a look at these two frameworks in detail.
Cross Platform Cross platform support is probably the most important factor that you need to consider when you are choosing a framework for your app development. Why cross platform? It is simply because you get a greater reach to the variety of different devices, you will increase the revenue stream, you can support the BYOD or the COPE programs that some of the enterprises are offering.
Ability to theme
Ability to scale Scaling to various screen resolutions is another important factor when it comes to cross platform development. There are many devices with various screen resolutions and it is important that your application needs to scale well.
Overall Performance Another important factor because this affects your application’s user experience. Four things to consider when it comes to performance.
Hello y’all, greetings from wintery Cape Town! I thought I would follow on from Ed’s BES12 v12.2 : What’s New for Enterprise Developers blog post and introduce you a bit more to the new BlackBerry Secure Connect Plus transport that is available now for use after upgrading your BES12 to v12.2.
A short history of BlackBerry Enterprise Server (BES) connectivity
I know I may be showing my age here but I remember a time before BES had a Mobile Data Service (MDS) component. Before the addition of MDS we were strictly speaking about email and calendar redirection from the corporate messaging system to the mobile device. Of course the mobile device in those days was little more than a dressed up two-way pager, not the snazzy all-touch glass slabs most people carry nowadays.
With more capable screens and devices came the desire to consume corporate content other than text based emails and calendar entries. Access to the intranet was on our sights and with the introduction of BES for Exchange v3.5/v3.6 and BES for Domino v2.1 we added a new component, Mobile Data Service (MDS), which everybody that is familiar with the BES architecture now knows as MDS. MDS, you understand, was a giant leap forward in the realm of enterprise connectivity!
Alas due to device, network and other limitations we were looking at a very limited, if functional, cousin of web browsing into the intranet that we came to appreciate from desktop browsers. Some of you will remember the, then state-of-the-art, Wireless Mark-up Language (WML) as a mobile friendly subset of HTML. Some may shudder at the memory… :)
With the introduction of BES v5.0 the MDS component was renamed to MDS Connection Service and formally recognised as your TCP proxy for BlackBerry devices to communicate with your intranet applications.
In 2013 with BES10 we also added the BlackBerry Communication Proxy (BCP) which adds the same TCP proxy functionality for Android and iOS devices (note the alphabetic order). And now we are happy to release the BlackBerry Secure Connect Plus (BSCP) component as part of the v12.2 upgrade to BES12. BSCP provides a new secure communication transport for applications on the device.
What is BlackBerry Secure Connect Plus?
Figure 1 – BES12 Device Management components
The BlackBerry Secure Connect Plus component that was added to BES12 v12.2 provides a secure IP tunnel for the supported devices into corporate’s network. What are the supported devices you ask? At the moment BSCP is supported as a transport for BlackBerry 10 devices, Samsung KNOX devices activated against BES12 (currently KNOX v2.4 is required) and Android for Work (Android OS v5.1 or higher) also activated devices against BES12 naturally.
Once BSCP is installed as part of the v12.2 upgrade for BES12 and enable for the supported users, the device will create a secure tunnel between itself and the BSCP component on the BES12 instance. That means the device has an internal/private IP address which is used for all application needs on that device.
What are the benefits of BlackBerry Secure Connect Plus?
The BES transports prior to BSCP acted essentially as a TCP proxy and as such were limited to TCP traffic. BSCP takes this further and provides secure behind the firewall connectivity and does so by providing a true IP interface for developers to use on the device. Now the device when it establishes the secure tunnel gets an internal IP address assigned which is used for all applications that need to communicate via BES12 with enterprise network resources. This opens up potentially a whole new field of enterprise applications that previously were hard to imagine without elaborate workarounds.
One of the possibilities is that BSCP enabled devices can now make use of UDP as a protocol, provided that a STUN server is available and configured to allow the NAT’ing of the UDP traffic between the device and BES12. With that VoIP applications, media streaming and other applications that make use of UDP can become a reality and that securely in the context of the Enterprise. And the best from a developer’s perspective is that this is transparent!
Architecture and Signalling Overview
Figure 2 – BSCP signalling
Let’s have a look at the signaling. Once the BES12 and the device have determined that BSCP is the best available connection method, meaning that no corporate Wi-Fi or BES12 VPN profile are available, then the device will send a request via a TLS connection through the BlackBerry Infrastructure that an IP tunnel should be established. BES12 receives this request through it’s connection to the BlackBerry Infrastructure on port 3101.
After the request has been received the device and BES12 use the TURN protocol to negotiate the tunnel parameters. For the communication one tunnel is established and use for all the apps from within the work perimeter to the Enterprise resources.
Be sure to checkout to check out the Administration section of the BES12 v12.2 support site and stay in touch with your BES administrator to find out when you can make use of this new feature of BES12!