Chapter 8. Advanced Tutorial – iBeacon Museum

So far throughout this book, you've learned about discovering beacons, determining the range of beacons, and even picking up and utilizing their presence when our app is running in the background. The aim of this chapter is to consolidate your knowledge into an app, which is as close to a real-world example as we can get.

In this chapter, we will not bring in any new iBeacon knowledge, but we will really get to grips with everything we learned throughout the book with an all-encompassing tutorial.

Our museum app allows users to wander around the exhibitions, and as they draw closer to the displays within each exhibition hall, they're given a more in-depth description of the context of what's on display.

Unlike in previous chapters, we will not use crude examples and try and mimic the kind of choices you'd make when considering user experience in a real-world app. A great example of this is that we'll ask for location permission by explaining to...

Our exhibitions

Our iBeacon museum is made up of three exhibitions. Each exhibition contains three displays, which we'll refer to as exhibits.

Our entire museum will use the 1A285B28-EA1B-43F5-984A-CE5D2ED463CE UUID. We'll be using major values to identify the exhibitions and the minor values to identify the exhibits beneath them as shown in the following figure:

iBeacon museum exhibits

Because researching, collating, and even designing beautiful exhibit views is way beyond the scope of our app, what we'll be doing instead is using UIWebView to display our exhibit information. This way, we can concentrate on what's important for our app.

Other than skimming over the designs and using predefined, responsively-designed web views for our exhibit content, our app is pretty much a fully functioning real-world example. You can take the code base on this app and reuse it in a commercial application if you wish, and of course, you have my consent to do so. I'd love to see your commercial applications...

The museum map

Our museum is made up of an atrium and three exhibition halls in a lovely hexagon design as shown in the following figure:

The museum map

The main entrance of our museum takes the visitor into the atrium. Once there, they can visit any of our three exhibitions, but always have to come back through the atrium. We'll assume that if the user isn't within 5 meters of any beacon, then they're probably in the atrium and we'll let them know what else they can visit in our museum.

Our app structure

Our app is split into three views, which are automatically presented completely. There's no real navigation system to the application, the app navigation is controlled by where the user's feet take them.

The permission view

The first view halts the users' access to the app until the app can determine that the location services are switched on for use by the app and that the user has given permission for the app to use their location.

Without location information, our app is useless, but rather than just assuming that we have it like we have in all of our other tutorials, we'll actually give users the reason why we need it and give them a much nicer user experience.

The atrium view

The atrium view gives our user more information about the museum and a summary of the exhibits within. We'll be presenting the user with the atrium view when they're no closer than 5 meters to any exhibit beacon. When they're closer than that, we'll always present the user with an exhibit view.

The...

The supporting website

In order to skip the design phase of this app and really concentrate on the iBeacon related functionality, I've provided the view and map content in a separate responsive website.

Most of the content of our app will be delivered as responsive web pages presented in UIWebViews from http://museum.ibeacon.university/.

Our companion site also uses real-time socket connections so that you can actually see which exhibit you're currently visiting in real time from any browser as shown in the following figure:

iBeacon museum current visitors

Tracking our user's journey

The role of the supporting website is to track our user's journey but also to return the content associated to the beacon that they are nearest to. In order to do both and effectively track our user, we need to follow a strict order of calls to our service. We'll do this by maintaining a browser session in a hidden UIWebView, which belongs to our main view controller. Consider the following steps to track our user...

Our app design

Our app is going to be essentially a single view application with all of our functionalities being placed offscreen when it's not in use but still present within the view and ultimately owned by the view controller.

This is a nice and easy way to ensure that UIWebView, which is maintaining our session with the server, is always in memory, and so that we're not getting a new identity with the server every time, the view is released by our application.

The following figure gives a much clearer indication of how our app is designed:

Views hidden until required

Building the application

Now that we've fully explained our app and all of its features, let's build it!

Creating the project

Follow these steps to create the project:

1. Start by firing up Xcode and choosing a single view application from the templates when prompted.

2. Enter the following options for your new project:

   • Product Name: iBeacon Museum

   • Organization Name: Learning iBeacon

   • Product Identifier: com.learningibeacon

   • Devices: iPhone

3. Before we begin coding, let's start by setting our project properties. Open up the project properties by clicking on the top-level project in Project Navigator, and then under Deployment Info ensure that you turn on the Hide status bar option. Also ensure that our iPhone app can only be displayed in portrait mode by ensuring that only Portrait is checked in the Device Orientation option.

4. We're going to be displaying a lot of Wikipedia content in our app so it makes sense to hide any other text when it's just content on the screen. Open the Info tab of our Properties...

Time to test

This really has been a huge tutorial and so there's a good chance that you might have missed a step. If something doesn't work quite like you expected it to, then go through each step again and download the completed source code from the companion site to compare it with your own to see what you might have missed.

Use the companion OS X app to act as your beacons and don't forget to open a separate browser window for http://museum.ibeacon.university/ to see your progress (as well as others) on the web too.

Finally, feel free to amend, adapt, and refactor any of the code or feel free to catch me on Twitter if you have any questions about this tutorial (@craiggilchrist).

Summary

This chapter really was just to reinforce everything you've learned throughout this book. The final chapter looks at some security issues surrounding iBeacon and also what the future holds for the technology.

As far as coding goes, this was the final tutorial in the book. I hope you've really got to grips with the amazing potential of this technology and you are well armed with all the coding skills you need to build amazing proximity-powered applications.

In the next chapter, we'll discuss some of the security aspects of deploying iBeacon solutions including spoofing, hacking, and overcoming user fears with good user experience.