Chapter 2. Detecting Beacons – Showing an Advert

In the previous chapter, we introduced you to the amazing possibilities of iBeacon and brought the UUID/major/minor broadcasting triplet to your attention. We also built our first, albeit very simple, app that detected the presence of beacons.

In this chapter, we're going to expand our knowledge and get an in-depth understanding of the broadcasting triplet, and we'll expand on some of the important classes within the Core Location framework.

To help demonstrate the more in-depth concepts, we'll build an app that shows different advertisements depending on the major and minor values of the beacon that it detects. We'll be using the context of an imaginary department store called Matey's. Matey's are currently undergoing iBeacon trials in their flagship London store and at the moment are giving offers on their different-themed restaurants and also on their ladies clothing to users who are using their branded app.

Uses of the UUID/major/minor broadcasting triplet

In the last chapter, we covered the reasons behind the broadcasting triplet; we're going to use the triplet with a more realistic scenario. Let's go over the three values again in some more detail.

UUID – Universally Unique Identifier

The UUID is meant to be unique to your app. It can be spoofed, which we'll cover in Chapter 9, iBeacon Security – Understanding the Risks, but generally, your app would be the only app looking for that UUID.

The UUID identifies a region, which is the maximum broadcast range of a beacon from its center point. Think of a region as a circle of broadcast with the beacon in the middle.

If lots of beacons with the same UUID have overlapping broadcasting ranges, then the region is represented by the broadcasting range of all the beacons combined as shown in the following figure. The combined range of all the beacons with the same UUID becomes the region.

Broadcast range

More specifically, the region is represented by an...

Understanding Core Location

The Core Location framework lets you determine the current location or heading associated with the device. The framework has been around since 2008 and was present in iOS 2.0. Up until the release of iOS 7, the framework was only used for geolocation based on GPS coordinates and so was suitable only for outdoor location.

The framework got a new set of classes and new methods were added to the existing classes to accommodate the beacon-based location functionality. Let's explore a few of these classes in more detail.

The CLBeaconRegion class

Geo-fencing (geofencing) is a feature in a software program that uses the global positioning system (GPS) or radio frequency identification (RFID) to define geographical boundaries. A geofence is a virtual barrier.

The CLBeaconRegion class defines a geofenced boundary identified by a UUID and the collective range of all physical beacons with the same UUID. When a device matching the CLBeaconRegion UUID comes in range, the region...

Creating a CLLocationManager class

The CLLocationManager class is used to track both geolocation and proximity based on beacons. To start tracking beacon regions using the CLLocationManager class, we need to do the following:

1. Create an instance of CLLocationManager.

2. Assign an object conforming to the CLLocationManagerDelegate protocol to the delegate property.

3. Call the appropriate start method to begin the delivery of events.

All location- and heading-related updates are delivered to the associated delegate object, which is a custom object that you provide.

Defining a CLLocationManager class line by line

Consider the following steps to define a CLLocationManager class line by line:

1. Every class that needs to be notified about CLLocationManager events needs to first import the Core Location framework (usually in the header file) as shown:

   #import <CoreLocation/CoreLocation.h>

2. Then, once the framework is imported, the class needs to declare itself as implementing the CLLocationManagerDelegate...

Understanding iBeacon permissions

It's important to understand that apps using the Core Location framework are essentially monitoring location, and therefore, they have to ask the user for their permission. The authorization status of a given application is managed by the system and determined by several factors. Applications must be explicitly authorized to use location services by the user, and the current location services must themselves be enabled for the system. A request for user authorization is displayed automatically when your application first attempts to use location services.

Requesting the location can be a fine balancing act. Asking for permission at a point in an app, when your user wouldn't think it was relevant, makes it more likely that they will decline it. It makes more sense to tell the users why you're requesting their location and why it benefits them before requesting it so as not to scare away your more squeamish users.

Building those kinds of information views isn...

Building the tutorial app

To demonstrate the knowledge gained in this chapter, we're going to build an app for our imaginary department store Matey's. Matey's is trialing iBeacons with their app Matey's offers. People with the app get special offers in store as we explained earlier.

For the app, we're going to start a single view application containing two controllers. The first is the default view controller, which will act as our CLLocationManagerDelegate, the second is a view controller that will be shown modally and shows the details of the offer relating to the beacon we've come into proximity with.

The final thing to consider is that we'll only show each offer once in a session and we can only show an offer if one isn't showing. Shall we begin?

Creating the app

Let's start by firing up Xcode and choosing a new single view application just as we did in the previous chapter. Choose these values for the new project:

• Product Name: Matey's Offers

• Organization Name: Learning iBeacon

• Company...

Summary

Well done on completing your first real iBeacon powered app, which actually differentiates between beacons. In this chapter, we covered the real usage of UUID, major, and minor values. We also got introduced to the Core Location framework including the CLLocationManager class and its important delegate methods. We introduced the CLRegion class and discussed the permissions required when using CLLocationManager.

Finally, we put this all together with offers from our Matey's store.

In the next chapter, we're going to broadcast offers using our iOS device as an iBeacon transmitter.