Samsung and the Physical Web Get CloseBy

Samsung has announced support for Physical Web URL detection in its Samsung Internet browser – the default for Samsung devices.

Called CloseBy, the support allows users to activate an extension to their browser which will then deliver a notification when they’re “close by” to a Physical Web beacon. Tapping on the notice, the user is taken to a Web page within the Samsung Internet browser.

The Physical Web is an open source standard for broadcasting a URL from a Bluetooth LE beacon, Wi-Fi direct or other hardware.

Challenges Ahead

CloseBy is still in beta and is reporting its share of glitches. These will be worked out.

But for brands, retailers and developers there’s increasingly a larger challenge in how to effectively managing the end user experience.

Fragmentation is a potential problem. When coupled with the fact that Physical Web has been designed primarily with a “lean-forward” consumer in mind, this is creating a challenge in consumer education.

Simply put:

  • If you want to make sure that most of your users (say, visitors to your store) can be made aware of and “see” a Physical Web URL, some sort of visual prompt is required
  • This is caused by an inability to actively notify users that there is a URL nearby. In theory, your Physical Web URL will appear 100% of the time in the notification tray (although there are serious enough issues with this as well). But getting users to check their notification tray requires some sort of physical world prompt (a sign, say).
  • Google Nearby attempts to solve this by “surfacing” notices. How this happens is opaque.
  • To solve for these challenges, a retailer or location should provide signage or prompts. Just like consumers needed to learn the purpose and use of QR Codes, the theory is that they’ll also learn about Physical Web URLs.

But with the Samsung launch, we now have another series of steps a consumer needs to take to “see” a Physical Web URL.

So how do you resolve the different types of education needed for different devices? It seems unbearable to think of a Physical Web sign with different activation instructions for 3-4 different device types!

(We haven’t even discussed iOS where Physical Web is available through notification widgets for Google Chrome!).

Change is Good. Change is Bad.

Further complicating issues is that there are changes happening with little education of the ‘beacon industry’ and developers.

A stellar comment by “mjanke67” on GitHub captures the heart of the issue:

I would suggest that until that level of Physical Web adoption occurs, users simply won’t drop their drawers (ed: notification tray) to check for scanned Nearby objects. Ultimately, the Physical Web adoption may never grow because it has been setup for future and not current levels of adoption. To address this – it is key that users retain their ability to view Nearby Notifications in both the Status Bar and Lock screen. To ensure that users don’t get offended by too many notifications, disable their display within the Lock Screen by default but give them the ability to enable notifications on the Lock Screen if they so desire. This same control (or another) could be used to enable display of an icon within the Status Bar when a notification has been added to the drawer. With this level of control in place, interested users can be shown or taught how to get notified by Physical Web objects. Disinterested users will leave Status Bar and Lock Screen notifications disabled (their default state) and will be unaffected.

Another key point that I would raise is that Nearby Notifications did exist within the original deployment of Nearby within Google Play Services (GPS) and were removed without warning after my company and others built product around the Nearby featureset. Removing original service features without discussion or warning is (choosing my words carefully) – very very uncool.

This last point is worth noting: features may change without warning.

And while many of them might be in the end service of users, or in the end service of providing a balance between users and developers/locations, it can be disconcerting (or a show stopper) to plan an entire roll-out only to have the use case itself change in a significant way before (or during) launch.

So, sure, all of these tweaks and improvement are good – but they often come with a lack of explanation and non-existent access to meaningful interaction data.

Samsung Gets Closer?

So, Samsung now supports Physical Web URL detection. It joins Opera (which I think was first to the party) but clearly represents a far more substantive audience.

But there are a few things left unclear – and maybe anyone testing the beta version can chime in with a comment below.

  • Is CloseBy like Google Nearby in how it “surfaces” notifications? Their post and screen shots seem to show a lock screen notice.
  • If it does display a lock screen notice, is this a 100% reliable notification?

In other words, at what step does the following screen appear in a user’s journey?

 

Second, Samsung mentions a server:

Upon receiving a URL from the Physical Web object, your phone sends that up to our servers in order to find the title of the page and determine whether to show it.

Can we assume that this is simply a way to parse a URLs metadata in order to display a notice? Where does this content come from? How do the fields on a web page match over to the notice that the user sees?

And are these notices consistent with how other Physical Web detection works, or will developers need to create different metatags for different systems?

Beacon Next

It’s an exciting time for the beacon industry. The Physical Web, Samsung CloseBy and Google Nearby are giving options across devices for the delivery of messages to users.

To fully take advantage of beacons, the next step would be to lead a user to download a beacon-capable app. Within an app, a developer can more finely control and measure the impact of proximity on an end user.

So, this part of the “funnel” is important and Samsung’s entry is a welcome development.

But the large beacon ‘ecosystem’ is leading to a fast-changing and fragmented set of user experiences which will create new challenges in how we educate consumers and how we prompt them in physical spaces.

Share Your Thoughts – Have You Tested CloseBy?

Join our e-mail list for more on iBeacons, Eddystone, Physical Web and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Have you tested Samsung Internet? What has your experience been? How well does it handle notifications and consumer on-boarding? And how well do you think we’ll be able to manage consumer interactions and education?

Drop a comment below, or pop me a note on Twitter.

 

Advertisements

Google, Beacons and the Black Box

When Google launched its response to the Apple iBeacon standard, it established itself as best-in-class for the field. But as it worked to integrate different initiatives within the company, it has left some notable gaps that hinder the development of effective user experiences.

It can be hard enough to understand all of the competing terms and standards. Sorting out whether your beacon should broadcast Eddystone, Physical Web or iBeacon signals is confusing enough.

But ending the process with a “black box” around your analytics makes it difficult to achieve what Google intends: useful end user experiences.

Background to Beacons

Before Google, all the hype was built around Apple’s iBeacon. The media (and developer community) often conflated software and hardware protocols. There was a perception that Apple was delivering ads based on proximity. Overall, there was both confusion over what iBeacon is or isn’t, and where Apple intended to take it.

Bluetooth Beacons First, it’s good to remember that beacons are all built on the same standard: Bluetooth LE. This is a protocol by Bluetooth for a low energy signal. The proximity standard is one of those protocols. This standard can be ‘interpreted’ in a number of different ways. Basically, Bluetooth provides a method for sending a radio signal in which a packet of data is included. How you use that packet is up to you.

iBeacon When Apple first launched its own standard for how the ‘packet’ should be encoded, it created confusion. iBeacon encompassed the standard for broadcasting, but it also came to include (at least in the popular imagination) the software tools for iOS developers, and the beacon itself (by being allowed manufacturers to use the iBeacon symbol).

Since its launch of iBeacon, Apple has done – well, nothing. Ahead of last year’s developer conference, they announced plans to integrate iBeacon with its iAd platform, giving brands the opportunity to deliver content to beacons without the need for an app.

But Apple pulled the plug on its iAd platform, and iBeacon (and the Apple approach to Bluetooth proximity) remained unchanged for yet another year.

Decoding Beacons the Google Way

Along came Google. When it launched its Eddystone standard, the press hailed it as an iBeacon competitor. And narrowly defined, it was. But this masked a much wider ecosystem. Google support for beacons was both more robust and more confusing.

It’s helpful to begin with understanding a few of the terms that apply in the Google ‘universe’ of beacons:

Physical Web This was the first unofficial entry from “Google” into the world of beacons. And I use the term in quotes because Physical Web is an open source standard which at first seemed loosely coupled with the company. Spearheaded by Scott Jenson, it is a standard protocol for broadcasting a URL in a beacon broadcast.

Browsers and operating systems which support “listening” for this URL can then display a web page.

Since its launch, Physical Web has expanded to include a number of methods (such as Wi-Fi Direct and SSDP) that can act as alternatives to physical beacons for broadcasting a URL.

Eddystone This was, perhaps, the true “Google response” to Apple iBeacon – “a protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages.” The protocol is for an open format beacon.

It picked up where iBeacon stopped and addressed some of the key concerns with the Apple standard. By offering three different broadcast protocols, it allowed:

  • Secure broadcasts through Eddystone-EID (a companion framework) so that only authorized devices can ‘see’ your beacon
  • Additional flexibility within the broadcast packet, giving manufacturers some ‘room to maneuver’ compared to the Apple standard
  • Better support for beacon monitoring and management through Eddystone-TLM

Google Nearby Finally, Eddystone was launched with support for Google Nearby. This allows you to register your beacons with Google and present a notice to user’s phones, even if they don’t have an app.

And it’s on this last item that things get interesting. Because without the need for an app, you can now engage with users in a new way – by directing them to an app download page, or to an https web page of your choosing.

Google is Not One Thing

So Google launched Eddystone. It launches beacon support through Google Nearby. And it launches a collision of standards.

Let’s say you want to support iBeacon and “Google”. So you put out beacons that broadcast the Physical Web, iBeacon, and maybe AltBeacon because you have an app that uses it.

You register iBeacon with Google Nearby (huh? Yeah. You can even register an iBeacon to Google Nearby).

Now, your end user might be getting multiple notices – one via Google Nearby, one through your app, and one for Physical Web.

This confusion stems, in part, because different units within Google are developing in parallel – whether the Nearby team or Chrome.

Over time, Google started to coordinate all of these efforts, and has done a brilliant job iterating and improving the user experience. Now, your phone will sort out the Physical Web and Nearby signals and start to sift through them to avoid confusion.

Meanwhile, as a developer, brand or retailer, you’ll still need to sort out the differences between the 100s of Android phones – but that’s the pain of entry into the Android world. (With Samsung recently announcing its CloseBy standard, at least we’re seeing a relative match-up to the Nearby approach).

The Silent Notification

OK, so you’re still probably a bit confused. You’re not alone.

So let’s simplify things a bit:

  • You can now send a beacon notice even if your end user doesn’t have an app
  • This notice can link (via Physical Web, Google Nearby or…soon, Samsung CloseBy) to a web page or app download
  • This notice is silent. Which means the user needs to know to take an action (swiping down, for example, for the notification tray) to see your notice.

Users with Bluetooth on and widgets activated will always be able to see a silent notice. The Physical Web will always show in the notice tray if, for example, you’ve activated the Chrome widget on your iPhone.

But the notification is “silent”.

Except when it’s not.

Because with Google Nearby there’s a catch:

Android users near that device or beacon will see the message in the Nearby section of Google Settings, the Nearby Quick Settings tile will light up on supported devices, and messages that perform well will be raised as notifications.

And there’s the rub: “messages that perform well“.

Because – well, there’s no way to know.

The Data Gap

There’s a problem: Google doesn’t want to spam end users with unwanted messages. According to Google, their data clearly shows that inappropriate messages will ‘turn off’ end users. We can imply that this could lead to turning Bluetooth off, or otherwise disabling Physical Web or Google Nearby.

We get it. So, as a developer, you want to do your best – to test, say, multiple messages. To look at the data and tweak your messages so that it gets better. To improve your performance so that Google will ‘un-toggle’ your notices and present more of them to your end users.

But you’re fighting a battle with one hand tied behind your back:

  • You don’t know how many total devices were eligible for your message
  • You don’t know how many users “pulled down” and therefore don’t know what your hit rate is with a specific message
  • You might not have a good handle on how much physical foot traffic you get near your beacon

All you know is that 50 people (say) opened your page. You don’t know how many of those were from a “pull down”, how many were from a “raised notification”, or how many people even saw your message in the first place.

And to make matters even more difficult, there’s no way to test any of this in your development environment. You can’t easily “reset” your test phone so that it acts like a naive user. Google interprets development and production the same way via Nearby.

We’re working in the dark.

And there’s no easy answer.

Is There a Solution?

With Google I/O approaching in May, I half suspect that Google will monetize Nearby – letting you pay to raise your notification in a more consistent way. Maybe they’ll connect up to Google Analytics or Firebase Analytics.

But even if they don’t there’s no easy way for Google to solve this black box issue without raising a host of other issues.

For example, if you were to give a total count of ‘eligible devices’ wouldn’t this open up the chance to snoop on foot traffic and device counts? Couldn’t you then place a beacon inside a competitor store and use this data to snoop on their location foot traffic data?

But to start, developers and Nearby users should at least be provided with some simple tools to help them improve the end user experience. Some baseline data would be a start:

  • When you launch a Nearby campaign with beacons, what is the starting percentage of users who will see your “raised” notification?
  • What is the maximum value this will go up to?
  • Can Nearby provide the capability of A/B testing messages and report back on which message included a “boost” to raised notifications?
  • Can we get access to “percentage of raised notifications” even if it doesn’t give us numbers?

Providing a better method for toggling Nearby beacons to “development” along with better instructions on how to treat a development phone as a naive user would also be a big improvement.

Google is doing it right – they’re making sure that users aren’t spammed, that we don’t see a backlash to beacons, and that the different notices are ‘streamed’ effectively from the different protocols.

But to get to the next step, Google should provide developers with some sort of feedback to help them improve the effectiveness of messages. This type of two-way partnership will be key to the continued uptake of beacons.

Share Your Thoughts

Join our e-mail list for more on iBeacons, Eddystone, Physical Web and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

How do you assess the effectiveness of Nearby or Physical Web projects? How do you assess the data? What would you like to see Google provide (data or other tools) to help improve the end user experience? Drop a comment below, or pop me a note on Twitter.

 

 

 

 

BeaconControl: Open Source Beacon Management

Launching this week, BeaconControl is an open source platform for managing proximity experiences using Bluetooth LE beacons.

It promises to help extend the stack of tools available to developers, organizations and brands and allow for more seamless integration with existing systems.

“The platform eliminates the need to focus on low level issues such as hardware integration, security and beacon deployment,” Marley Fabisiewicz, Founder of BeaconControl, tells me.

His Warsaw software agency Upnext has developed BeaconControl. The open source platform includes a suite of software tools which includes:

  • SDKs for iOS and Android
  • An open source Web management tools based on Ruby on Rails (with a RESTful API), and
  • A free mobile app for beacon deployment and set up.

The company is partnering with Kontakt.io to provide the first “deep integration” with the physical beacon itself.

This allows developers and organizations to physically configure a Kontakt beacon and have that configuration link to the BeaconControl dashboard.

Why Beacon Management is Needed

When Apple launched support for Bluetooth LE proximity detection through its iBeacon specification (and accompanying iOS developer tools), brands and organizations often struggled to both understand and implement beacons into their mobile experiences:

  • You needed beacons. Most of the beacons on the market came with back-end management systems. Some of those systems were required if you wanted to use that vendor’s beacon. Gimbal was an early example of a beacon company whose back-end system (while rich and robust) was what you were really buying when you bought one of their beacons.
  • You could use third-party management systems. If you chose beacons that didn’t require that you use their management systems you could turn to one of the dozens of start-ups offering proximity management platforms.
  • You could choose to build your own proximity management system. This could be a costly proposition. It came with the added challenge that the technology was relatively new, support for Android was still in its early days, and best practices for user experiences were yet to be established.

With Google announcing more robust support for proximity and beacon detection and putting their weight behind the Physical Web (through the open source Eddystone protocol), the management of beacons has become even more complex.

And while Google itself now offers a degree beacon fleet management services and basic tools for delivering content, a developer or business still needs to think about how their beacon infrastructure will support the end user experience across a myriad of devices – from Android phones to Apple Watch.

Building an Open Source Beacon Management Community

BeaconControl hopes to help accelerate the proximity industry by making its tools available under an open source license, and to encourage developers and engineers to support its development.

Fabisiewicz tells me that developer involvement will help build momentum for BeaconControl:

We have already entered great partnerships with the Silicon Allee campus in Berlin and the NewLab in New York City to develop sustainable, “technology enabled workspaces” based on BeaconControl. We are in talks with various startups and corporations who have expressed interest in BeaconControl. But at the moment we would love to see developers start using the platform and contribute to the movement.

Developers can check out the BeaconControl code on GitHub and contribute to improving the web-side management dashboard.

For the more technically-minded, Fabisiewicz explains the architecture:

The core stack is Ruby on Rails and that’s how it will stay in the future as we deeply believe in Ruby on Rails.

In terms of mobile integration we are already providing iOS SDK and Android SDK is coming soon, so the mobile mobile landscape is currently covered.

Beacon Control is designed with Service Oriented Architecture in mind, so that any technology stack can integrate it and use it through the REST APIs. Depending on community feedback, we will consider developing wrappers in other languages.

What Does It Mean for Businesses?

For organizations looking to deploy beacons, you need more than just a device. You need a way to manage the interactions that go with a beacon.

You can choose a beacon provider who has accompanying dashboard and management tools, but risk vendor lock-in. Or you can work with a “platform” (from Urban Airship to any of the dozens of proximity providers who specialize in the field).

These approaches have pros and cons: from cost efficiency and speed-to-market, to being able to rely on vendors whose sole purpose is often thinking about and developing for proximity.

But if you have the resources, or if you have the need to integrate proximity campaigns into existing systems, developing your own beacon solution has often seemed a viable approach.

Now, you’ll have the option of using an open source library to get your project started.

Developers Unite!

If it can involve a larger group of developers, BeaconControl could potentially become an emerging standard for proximity management.

With a new generation of sensors and beacons on the horizon, this open source approach can give the industry a leg-up on its ability to respond to technical change.

Its founder tells me that:

We are at the very beginning of proximity technology and we think that BeaconControl can evolve into a platform that supports various types of sensors in the future. Currently Mesh beacons are a very interesting technology, they can turn the current generation of location-broadcasting beacons into a two-way, Net-connected network. Generally we think that proximity technology has the potential to change the world, but it will take time and a lot of effort like with mobile payments.

BeaconControl might also be a sign of things to come. As the industry shakes out, more companies may choose to open source parts of their technology in order to focus on other areas: consulting, analytics or infrastructure management.

For Upnext, BeaconControl is the perfect fit for an agency that focuses on innovation and mobile experiences.

As Fabisiewicz tells me, BeaconControl opens up a range of possibilities for his company:

First and foremost, we are aiming to create a community that builds the physical web and the IOT. We are trying to give innovators and technologists a headstart with our platform. We will eventually make money by consulting with companies to integrate BeaconControl into their applications. We are also thinking of marketplace (like an app strore) for BeaconControl where the entire community can distribute their add-ons for BeaconControl and monetize them.

BeaconControl will help to kickstart new forms of innovation in the proximity industry and will attract developers who are inspired by working together to create new standards and best practices. It represents a milestone on the beacon industry and is, perhaps, a sign of things to come.

Share Your Thoughts

Join our e-mail list for more on iBeacons, Eddystone and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

Is BeaconControl what you were waiting for? How do you think an open source proximity management platform will impact the industry? Will start-ups who sell proprietary solutions need to consider their own open source strategies? Drop a comment below, or pop me a note on Twitter.

Google Loves Apple (In a World of Beacons)


 

The launch of Eddystone by Google has, at long last, addressed a challenge in creating proximity experiences with beacons. Namely, that the software tools for beacon detection and interaction were less robust for Android development than for Apple devices.

The media narrative, as always, paints the move by Google as a showdown between Eddystone and iBeacon.

Mashable calls Eddystone a rival, Ars Technica announces that iBeacon needs to move over because Eddystone is a fighter, and Tech Republic concludes that it has clear advantages in the showdown with Apple.

Now, you can’t blame the media. It makes good copy.

If Google launched some kind of self-driving toilet paper the media would call it a rival to the iPad, siphoning off valuable screen time from its arch enemy in Cupertino.

And while there’s a broader truth to the Apple v Google narrative (which I’ll get to in a minute), the truth is that the move by Google has made life easier for brands, retailers, developers and device manufacturing companies.

What Your Clients Need to Know

If you work in mobile development you’ll know that the last thing your clients need to hear is that there’s yet more fragmentation – between Android devices, between Apple and Android.

The good news is that, at the simplest level, Google’s announcement of the Eddystone beacon format (and the accompanying development tools) means that we can now create beacon experiences for both Android and Apple devices in a way that assures a higher level of confidences that the experiences will be on par.

Better yet, Eddystone has added a few tricks to how beacons work that will benefit both Apple and Android apps. These tricks include the ability to embed beacon management functions inside your app (instead of needing to rely on some type of admin app or cloud beacon), a promise of increased beacon security, and the ability to link beacons natively to web URLs.

By launching an open specification and leveraging the capacity of beacons to interleave multiple signals, brands, retailers and venues can get the best of both worlds:

  • Android apps that respond as fluidly to beacons as Apple apps
  • Access to new beacon features across both platforms
  • No need to buy new beacons – especially if your hardware provider is one of Google’s preferred manufacturers (and we note that almost all of them are our own!). Just update your firmware and you’re good to go.

There’s No App For That

The second part of the media narrative about Eddystone is its capacity to deliver a URL in place of a unique identifier. The promise is that on Android, you’ll be able to deliver messages without an app.

Part of this promise will be reliant on what Google releases with Android M so it’s too early to judge how deep this promise will go. We’ve long speculated that the secret war horse for Google will be Chrome – a trojan horse on Apple devices that could conceivably contain beacon detection and help Google bypass the gatekeepers in Cupertino.

Regardless, the capability of reaching consumers without an app isn’t confined to Google.

Apple has been using Passbook to trigger beacon interactions and will be extending this through Offers, a new iAd “wrapper” on Apple Wallet. We assume that this will allow brands to target iAds based on location and allow the delivery of Wallet Offers (similar to Apple passes) which embed beacon detection (as previously available).

So while it’s a compelling value proposition – the ability to bypass apps entirely, it’s not confined to Google.

Who Owns The Experience?

It’s when we look beyond the beacon that the Google v Apple narrative starts to make a bit more sense.

Both Apple and Google give you tools to register your “place”. Both want to help you map your indoor location. Both want to provide “contextual experiences” through Siri, Google Now, and search.

And both want to serve ads:

  • Google wants to use all the data it can get to serve better (and more) ads across more platforms (including iOS)
  • Apple wants to generally keep the data anonymous but still wants to make money through its iAd platform.

Apple’s main focus is the user experience, and we can expect to see more and more tools to integrate beacons into payments, Apple Wallet, in-home connectivity, and location-based context. Google’s main focus is giving users better and better free tools and applications but in the larger service of ad revenue.

Neither approach is bad for brands or venues. But each provides strategic pros and cons – from sharing your data about your customers with Google through the lack of access to individual user data on the Apple platform.

But these trade-offs and decisions have nothing to do with the beacon. The choice to integrate that beacon, to make Google aware of its presence, to integrate it with Google Now (with the benefit of “app-less” consumer interactions but with the cost of providing Google data about your customers) are strategic ones.

As a retailer, you’re faced with the same questions you’ve already struggled with: who owns the data about what happens in your store, and are the trade-offs worth it?

But, again, those questions have nothing to do with the base function of the beacon, and are supplemental decisions about how far you want to go with Eddystone.

For now, it’s enough to know that beacons just got better, and users of both Apple and Android devices will benefit from the innovation.

Share Your Thoughts

Join our e-mail list for more on iBeacons and BLE. Join the conversation on Twitter, or connect with me on LinkedIn.

What do you think? Google has clearly done Apple one better with Eddystone. But is it really a “threat”? How will you use Eddystone?

Tutorial: Making a Smarter iBeacon Detector on iOS Using PubNub | Guest Post

Apple has been using BLE on its devices since the iPhone 4S. Because of that great head start, using your iPhone to detect beacons is much easier than on any other platform! In fact, Apple’s iBeacon protocol was the first to take advantage of the great qualities of BLE communication.

In our previous tutorials, we walked through an overview of beacon technology and how to build an iBeacon emitter.

In this tutorial, we will make a smarter iBeacon detector (ie. observer)!

Using PubNub and iBeacon, we can create two-way communication while still keeping the low energy asset of beacons! You’ll want to read a little bit on how we plan on doing this, this article will give you a high-level explanation on how our app is supposed to function. This weird, but simple setup increases the capabilities of iBeacons greatly!

We will first look into how to turn your iPhone into an iBeacon in Swift, and we will build the PubNub structure over it!

What are we waiting for? Let’s build amazing apps! This article is inspired by this example app so feel free to use some of its available source code.

 

 

Using your iPhone to detect iBeacons

In the scope of this tutorial, we will build a minimal app on which you can build upon and improve. As a result, we won’t really get into building the user interface. We want to keep it clean and simple.

Setting up your View Controller

First things first, let’s import our libraries.

[snippet id=”368″]

That’s all we’ll need for this.

The variables you’ll need in your view controller are as follows. We’ll talk more about them later on.

[snippet id=”369″]

For the sake of simplicity, we will have most of our application in the viewDidLoad() method. It’s up to you to arrange it as you wish.

[snippet id=”370″]

The first thing we need to do here is create a region element. The beacon region element defines how the proximity to a beacon or a set of beacon should or will look like. What this means in our example is that we are defining beacon regions that have our specified UUID. As a result, when we will detect beacons, we will only detect those with this particular UUID. We could have just as well initiated our region with a UUID, major and minor which would have limited our detection to beacons which satisfy all 3 conditions.

The next step is to create a location manager instance. The location manager is the element that will allow us to use the iPhone’s hardware to start detecting beacons. We will need to set a delegate which will call the location manager’s methods when certain events will be triggered. We set our view controller as the delegate. Don’t forget:

class YourViewController: UIViewController, CLLocationManagerDelegate {

For iOS 8 or more, it is necessary for the app to request the user’s authorization to use location tools. This line usually will not suffice. You have to manually add a couple lines in the info.plist file which is located in the “Supporting Files” directory. If you right click on it and open it as “Source Code”, you want to make sure you add these lines inside the “<dict>” markup.

[snippet id=”371″]

When the user first starts the app, a pop up dialog box will ask the user to authorize location services along with the string we just defined.

We can finally start monitoring for our beacon region!

For now on, our view controller will be waiting for the following events:

  • didStartMonitoringForRegioin
  • monitoringDidFailForRegion
  • didEnterRegion
  • didExitRegion

We will only implement one of those methods:

[snippet id=”372″]

When we started monitoring for regions, we are only subscribing to entering and leaving a region events. In the scope of our app, we need more information. Remember, we want our iPhone to connect to PubNub when we get close enough to a beacon. To save some energy, we will start to range beacons only when we enter a region of interest.

This will trigger a didRangeBeacons:inRegion: method much more frequently than the didEnterRegion method. It will be called as soon as the distance to the beacon changes.

[snippet id=”373″]

Alright! I hope we cleared out the logic for using Apple’s tools to detect our iBeacons. The next step here is to make our iPhone compatible with our smarter emitting beacon. If we want to establish a two-way communication with the beacon, we want to subscribe to the same PubNub channel as soon as we get close enough (you can think that “Near” distance suffice, here we will require to get at “Immediate” distance to start the communication).

Making your iBeacon Smarter with PubNub

Getting Started

The first thing you will need is the pubnub library for iOS.

We are going to use cocoa pods. If you don’t use it yet, you’re missing out. Easy installation and starter’s guide here.

In your project’s root directory

[snippet id=”374″]

Your podfile should look like:

platform :ios, “8.0”
target “YourProject” do
pod ‘PubNub’, ‘3.7.2’
end
target “YourProjectTests” do
end

You can make sure you are using the latest version of pubnub here.

Now you just need to type

$ pod install

Close Xcode, and open the YourProject.xcworkspace .

That wasn’t too hard right? It’s not quite over though.

Use Objective-C libraries in Swift

The pubnub library is written in Objective-C, but we are coding in swift. All you need to do now is to build a bridging header. Create a new Objective-C header in your project called YourProject-Bridging-Header.h for good practice, and type:

[snippet id=”375″]

Now in your project’s configuration panel, go to build settings and scroll down to the “Swift Compiler – Code Generation” section. Set the “install Objective-C Bridging Header” to Yes and in “Objective-C Bridging Header” type the path from your project’s root directory to your bridging header. It’ll be something like “YourProject/YourProject-Bridging-Header.h”


 

All set? Let’s roll.

Initializing PubNub

For the sake of simplicity, we will code our PubNub behaviour on the same view controller.

We will need to add 3 variables to our class:

[snippet id=”376″]

When a user connects to PubNub, he is identified with the content of this PNConfig object. For the scope of this tutorial, we will use demo keys. Get yours here!

In the viewDidLoad method, we will also start PubNub. Add these lines and don’t forget to set your class as a PNDelegate:

[snippet id=”377″]

Awesome! We are connected to PubNub!

We want to use the data advertised by the beacon to subscribe to the beacon’s channel.

Subscribing to the PubNub channel

We need to add a couple line to our didRangeBeacons method in order to subscribe once we get at “Immediate” distance from the beacon:

[snippet id=”378″]

That’s it. We just need to make sure we did not already subscribe to the channel.

[snippet id=”379″]

On the beacon’s side, our subscription event should trigger the beacon to send a message on the channel. We need to implement the method which will be called whenever a message is sent on the channel.

[snippet id=”380″]

Alright! We just received the message! We are good to go. It’s up to you to figure out what you want to do with it.

Finally, when we exit a region, we will want to stop all of these processes:

[snippet id=”381″]

With just a few lines of code, you just created a two-way communication with a beacon while still having a low energy consumption! How great is that? We hope you liked this article.

Next, we’ll build an iBeacon emitter.

Resources

Guest Authors 

Norvan Sahiner and Sunny Gleason wrote this tutorial series on behalf of PubNub, a platform that allows you to build and scale realtime apps for connected devices.

Tutorial: Making a Smarter iBeacon Emitter on iOS with Swift with PubNub | Guest Post

Apple has been using BLE on its devices since the iPhone 4S. Because of that great head start, the iPhone is easier to turn into a beacon than any other platform. In fact, Apple’s iBeacon protocol was the first to take advantage of the great qualities of BLE communication.

In our other tutorials, we walked through an overview of beacon technology and how to build an iBeacon listener (detector).

In this tutorial, we will make a smarter iBeacon emitter! Using PubNub and iBeacon, we can create two-way communication while still keeping the low energy asset of beacons! You’ll want to read a little bit on how we plan on doing this, this article will give you a high-level explanation on how our app is supposed to function. This weird, but simple setup increases the capabilities of iBeacons greatly!

We will first look into how to turn your iPhone into an iBeacon in Swift, and we will build the PubNub structure over it!

What are we waiting for? Let’s build amazing apps! This article is inspired by this example app so feel free to use some of its available source code.

Using your iPhone as an iBeacon

We won’t get into doing the user interface here, we really just want to focus using the iBeacon capabilities of your phone.

Setting up your View Controller

First things first, let’s import our libraries.

[snippet id=”382″]

That’s all we’ll need for this.

Inside our view controller class, we’ll have variables representing the UUID, the major and the minor of our advertised signal.

[snippet id=”383″]

You can chose any uuid or major and minor as long as the uuid is the same as the one you inserted in the app detecting your iBeacon signal.

Start advertising the iBeacon in a region

You need to create a CoreBluetooth peripheral manager which will control the advertising of your data. Don’t forget to set your View controller as a CBPeripheralManagerDelegate.

To simplify our app, we will start our peripheral manager when the view loads.

The first thing we want to do is build a beacon region. This will create an object defining the data you want to advertise: uuid, major, minor.

The next step is to create a peripheral manager instance. The peripheral manager is the element that will allow us to use the iPhone’s hardware to start acting as a beacon. We will need to set a delegate which will call the peripheral manager’s methods when certain events will be triggered. We set our view controller as the delegate. Don’t forget:

class YourViewController: UIViewController, CBPeripheralManagerDelegate {

For iOS 8 or more, it is necessary for the app to request the user’s authorization to use location tools. This line usually will not suffice. You have to manually add a couple lines in the info.plist file which is located in the “Supporting Files” directory. If you right click on it and open it as “Source Code”, you want to make sure you add these lines inside the “<dict>” markup.

[snippet id=”385″]

When the user first starts the app, a pop up dialog box will ask the user to authorize location services along with the string we just defined.

[snippet id=”386″]

Alright, so we generated a dictionary containing the data we want to advertise in the proper format. The region object holds the important data. The measured power argument represents the RSSI power of our emitting device from a meter away. Remember, inside the advertised data, one byte represents this value which is used by the receiver to estimate how far the beacon is. By entering nil, this will return the default RSSI value of your device. That’s probably what you’ll want to do 99% of the time.

Finally we start our CBPeripheralManager. Since we set our View Controller as the delegate, as soon as the manager starts, the peripheralManagerDidUpdateState:peripheral: method of the delegate object (i.e. our view controller) will be called.

[snippet id=”387″]

When the method is called with a powered on state, we can start advertising our data. Its up to you to decide how your app will behave for other states.

And that’s all it takes. Easy, right? Just a couple lines and we can start advertising our data! Beautiful.

The next thing we want to do is make our app magical. That’s where PubNub comes it.

Making your iBeacon smarter with PubNub

Getting Started

The first thing you will need is the pubnub library for iOS.

We are going to use cocoa pods. If you don’t use it yet, you’re missing out. Easy installation and starter’s guide here

In your project’s root directory:

[snippet id=”388″]

Your podfile should look like:

platform :ios, “8.0”
target “YourProject” do
pod ‘PubNub’, ‘3.7.2’
end
target “YourProjectTests” do
end

You can make sure you are using the latest version of pubnub here.

Now you just need to type

$ pod install

Close Xcode, and open the YourProject.xcworkspace .

That wasn’t too hard right? It’s not quite over though.

Use Objective-C libraries in Swift

The pubnub library is written in Objective-C, but we are coding in swift. All you need to do now is to build a bridging header. Create a new Objective-C header in your project called YourProject-Bridging-Header.h for good practice, and type:

[snippet id=”389″]

Now in your project’s configuration panel, go to build settings and scroll down to the “Swift Compiler – Code Generation” section. Set the “install Objective-C Bridging Header” to Yes and in “Objective-C Bridging Header” type the path from your project’s root directory to your bridging header. It’ll be something like “YourProject/YourProject-Bridging-Header.h”

All set? Let’s roll.

Initializing PubNub

For the sake of simplicity, we will code our PubNub behaviour on the same view controller.

We will need to add 2 variables to our class:

[snippet id=”392″]

When a user connects to PubNub, he is identified with the content of this PNConfig object. For the scope of this tutorial, we will use demo keys. Get yours here!

In the viewDidLoad method, we will also start PubNub. Add these lines and don’t forget to set your class as a PNDelegate:

[snippet id=”390″]

We are all set. All we need to do is to define the methods that will be called when events occur on the channel.

There is a long list of methods being triggered for various events, you’ll find it here. We’ll only implement one for our app.

[snippet id=”391″]

When someone joins the channel, the method is triggered and we send a message to the channel that the end user will receive! The message can be any object in the form of a JSON. Here we just send a string, but you could configure the message to have a receiver variable so that only the user who just subscribed receives it.

That’s it! Our iPhone acts like a beacon that emits information to join the PubNub channel. When the customer is close enough to the iBeacon, his phone will subscribe to the advertised PubNub channel. Our beacon is listening for presence events to the channel and immediately sends a message on the channel for the user to see!

Beautiful. Hope you like it. There is so much more you can do with so little code.

Resources

Guest Authors 

Norvan Sahiner and Sunny Gleason wrote this tutorial series on behalf of PubNub, a platform that allows you to build and scale realtime apps for connected devices.

Tutorial: Using Beacon and iBeacon Technologies on Your iPhone / iPad with PubNub | Guest Post

iBeacon has been quite a buzzword since the release of iOS 7 when Apple enabled all their iPhones since the 4S with this new BLE technology.

The iBeacon is simply a protocol that takes advantage of the new Bluetooth Low Energy technologies. It has been easy for companies, aside from Apple, to emulate similar protocols such as estimote or AltBeacon. As a result, we thought iBeacon and PubNub could fit together in some pretty cool ways.

In this article, we will explain how the iBeacon protocol works by taking a closer look at how the emitted data is actually structured. We will move onto how to use the iOS sdk to detect and emit beacons. Finally we will try to see if we can use other protocols on iOS devices.

 

iBeacon Detecto
iBeacon Emitter

 

What an iBeacon’s Advertisement Looks Like

According to the Bluetooth v4 specification, a beacon advertises a data package called the Scan Response Data.

This Data can be up to 31 bytes. If we create a smaller scan response, the remaining bytes will be filled with as many 0s.

The scan response is divided into what are called AD structures. They are sequences of bytes of various size, with a predefined structure that goes as follows:

  • The first byte represents the number of bytes left to the end of the AD structure. This allows a receiver of this structure to know when it ends and when a new AD structure starts.
  • The second byte is the ID of an AD structure type.
  • The rest of the bytes are data that is structured in a predefined way depending on what AD type was defined by the previous byte.

That’s all there is to it. Just a succession of AD structures.

Most beacon protocols have only 2 AD structures, which are as follows.

The first one has 3 bytes:

  • The first byte will be: 0x02 because we only count the following bytes.
  • The second byte is: 0x01 which indicates we have a “Flag” AD type.
  • The last byte represents theses flags. These flags express whether the emitting device is, in “Limited Discoverable Mode”, “General Discoverable Mode”, etc… The byte is computed the following way:

The 5 flags are represented by the first 5 bits of a byte. The value of these bits defines whether the flag is ON or OFF. The binary number is then written as a hexadecimal value which will be advertised. An example may clear things up:

bit 0 OFF LE Limited Discoverable Mode
bit 1 ON LE General Discoverable Mode
bit 2 OFF BR/EDR Supported
bit 3 ON Simultaneous LE and BR/EDR to same Device Capable (controller)
bit 4 ON Simultaneous LE and BR/EDR to same Device Capable (host)

The resulting binary value hence becomes: b00011010 Converted into a hex, we get: 0x1A

That’s all there is to the first AD structure! Let’s look into the second one, which contains most of the information we need!

 

image00

 

The second structure can be of a different size according to the protocol. Let’s look at the detected scan response emitted by an iPhone.

  • First byte is 0x1A (26 in hexadecimal).
  • The next byte is always 0xFF which means we have a “Manufacturer Specific” type of AD structure.
  • As a result, the 2 following bytes represent the company identifier as defined on bluetooth.org. For an iOS device, the manufacturer is “Apple Inc.” whose company ID is 76. In hexadecimal value, this is equal 0x004C. The ID, written as little endian, takes up 2 bytes. Here it will be 0x04C 0x00 in this order.
  • The rest is Manufacturer specific data.

For the iBeacon protocol, the 2 first bytes of the manufacturer specific data are always 0x02 0x15. The next 16 bytes are a UUID representing the advertiser’s organizational unit and the 4 following bytes are going to be the major and the minor. They are 2 bytes long numbers.

There is a final byte at the end of the data structure called the TX Power, which represents the device’s signal reference intensity a meter away from it. This value is held into a single byte which is the two’s complement of the signal’s intensity in dB.

Computing the distance to a Beacon

When a scan response is detected by a device, it also determines the intensity of the received signal. Hence the iBeacon protocol uses the reference value held in the TX Power byte and compares it to the intensity of the signal effectively received. This allows iBeacons to compute an estimation of the distance to the emitting beacon. This is a great quality of iBeacons, but note that the intensity of the signal depends vastly on existing obstacles or simply on the geometry of the room. As a result Apple does not recommend to use iBeacons to determine precise locations.

The algorithm used to compute the distance is not open-source, although others have tried to emulate matching ones.

How to Use Apple’s SDK for iBeacon

Emitting or detecting iBeacon data is organized around iBeacon regions.

 

image01

These regions are instantiated with optional initial values such as the UUID, major or minor. In the case of detecting an iBeacon, this region object defines what type of beacon scan response should be detected. For example, if you provide a UUID, only the beacons with matching UUIDs will be detected, regardless of the major and minor. If you also provide these values, you’ll detect only beacons matching all three of these values.

When emitting an iBeacon signal, the region object based on the values of the UUID, major and minor generates the data structure to be advertised.

As you may have guessed, this makes the iOS SDK very simple to use! For more detailed examples, check out our beacon emitter and beacon detector tutorials.

However, it also makes things much more difficult when you are trying to use a protocol different from iBeacon! Let’s look into that immediately.

Using Apple’s SDK for AltBeacon or Estimote

We have seen how complicated the scan response can be, and how Apple simplified the SDK so that we just need to enter the UUID, major and minor to set it up. However, with other beacon protocols, the scan response has a different structure which Apple makes hard for us to tweak.

Detecting other beacons

When detecting iBeacons, the locationManager:didRangeBeacons:InRegion: method is called on the event of a detected signal. However, this is very specific to iBeacons. When detecting another BLE signal, you must not use a CLLocationManager instance, but a CBPeripheralManager which detects ANY BLE advertisement EXCEPT iBeacons, which will be blocked.

The callback that will be triggered upon detection is centralManager:didDiscoverPeripheral:advertisementData:RSSI: . The advertisement data that is returned is a dictionary holding 2 objects; one for each data structure of the scan response. Here is a sample response from an AltBeacon.

{
kCBAdvDataIsConnectable = 0;
kCBAdvDataManufacturerData = <1801beac 0cf052c2 97ca407c 84f8b62a ac4e9020 00090006 c5>;
}

The top element represents the first, three bytes long, “Flag” data structure. The second one represents the manufacturer specific data following the bytes describing the size and type of the data structure.

This is good news for us, and means we can detect any beacon information!

Emitting another beacon

We have found things are much trickier when it comes to advertising custom beacon scan responses. We can try to build an NSDictionnary similar to the one detected and try to advertise it using the startAdvertising method.

However the advertisement data keys available for detection are limited to only CBAdvertisementDataLocalNameKey and CBAdvertisementDataServiceUUIDsKey when it comes to advertising the data. It is Apple’s way of preventing us from building manufacturer specific data outside of the iBeacon protocol.

So there you have it! We went through apple’s iBeacon protocol, looked at how we could detect other beacons and apple’s restrictions to advertising data. We have some working examples and tutorials to build an iBeacon app on Swift – check out our beacon emitter and beacon detector tutorials, which allow you to get the best out of iBeacons by establishing a two-way communication which beacons aren’t usually capable of. The reason why we think it’s great is that we use PubNub to enhance beacons’ capabilities while still keeping their low energy consumption asset! Sweet, right?

Resources

Guest Authors 

Norvan Sahiner and Sunny Gleason wrote this tutorial series on behalf of PubNub, a platform that allows you to build and scale realtime apps for connected devices.