Matthew Price

iBeacon Delegates Not Being Called

There are a lot of glamorous iBeacon problems out there. This post doesn’t contain any of them. Instead, this is a post about two embarrassingly simple errors and how I fixed them.

Your CLLocationManager Must Be Recreated When You Return from Backgrounding

I read the documentation for CLLocationManager and its delegate methods, implemented them, and then thought I was done. Unfortunately, hidden away in the documentation for a related class, CLRegion, is something important (emphasis mine):

If the app is not running when a boundary crossing occurs, the system launches the app into the background to handle it. Upon launch, your app must configure new location manager and delegate objects to receive the notification. The notification is sent to your delegate’s locationManager:didEnterRegion: method.

My application was launching in the background correctly, but I wasn’t configuring a new location manager and delegate objects whenever the application launched. It’s a quick fix, and it makes sense in retrospect, but that note isn’t where I would expect to find it in the documentation.

CLRegion Doesn’t Notify When Individual Beacons Change

A CLRegion can contain zero or more beacons using the same UUID. While the didEnterRegion delegate method is called as soon as it spots a single beacon, the didExitRegion method is only called when there are no more beacons in range that match the region’s UUID. Don’t confuse didExitRegion with didExitBeaconRange (which doesn’t exist) or you’ll wear a hole in your floor running back and forth between rooms trying to figure out why your app is never notified.1

If you need to detect when you’ve left the range of one particular beacon, you need to actively scan for beacons (battery intensive) or give each beacon a different UUID so you can create and monitor multiple CLRegion’s.

  1. Hat tip to James Barrow for helping me figure this out. I had an idea for how I thought things should work in my head, and it took James to bring me back to reality.

Fresh Starts and Resolutions

January will be over in just a few days, so now is a good time to remind everyone that New Years isn’t the only time you can take steps towards changing your life. There’s a science behind successful resolutions, and it doesn’t require you to wait for a new year. Any milestone of time will work: a new semester, month, week, or even your birthday.

Don’t start out this year with a handful of lofty resolutions that you’ve already failed. Instead, cherry-pick one or two you know you can accomplish and start working on them at the beginning of next week, February 1st. The confidence boost you’ll get from succeeding will help you slowly build up to more difficult goals as the year progresses.

Merry Christmas

Christmas Card 2014

Merry Christmas, everyone! I hope you have a wonderful holiday season, however you choose to celebrate it.

You Don’t Pass or Fail at Being a Person

Nick Bradbury, in a great article comparing programming to life:

I realized that the people in charge are as clueless as the rest of us. Like our software, our society just kind of happened over the years and it’s always on the verge of coming tumbling down. Nobody really knows what they’re doing or what they’re talking about.

There’s no magical moment you grow up, understand everything, and become “good” at life. We can become better at the things we’ve experienced, but we’re effectively a kid again whenever something new and scary comes our way.

There’s a passage I love from Neil Gaiman’s The Ocean at the End of the Lane:

Grown-ups don’t look like grown-ups on the inside either. Outside, they’re big and thoughtless and they always know what they’re doing. Inside, they look just like they always have. Like they did when they were your age. Truth is, there aren’t any grown-ups. Not one, in the whole wide world.

We’re all just stumbling around in our own way, learning as we go, and yet somehow humans have managed to survive for the last 200,000 years. I always find that comforting whenever I’m worried about making the wrong decision. To quote The Ocean again, “You don’t pass or fail at being a person, dear.” Just do the best you can.

Waiting for the Best Solution

The Amazon Fire TV and Xbox One have started implementing voice control, and it’s likely we’ll see future Apple TV upgrades that offer the same.1 But why did it take us so long to make input less awkward? Were we so focused on the best solution that we forgot to look for better solutions that would suffice in the meantime?

We have a wonderful iOS Remote application for controlling the Apple TV but no quick way to open it. Even if our iPhone is within arm’s reach we still need to unlock it, find and open the Remote app, wait for it to load, select the Apple TV, and wait for it to connect before we can start navigating.

Earlier this month I tweeted:

The iOS Remote app should display a notification on your lock screen whenever a linked AppleTV is waiting for keyboard input.

How long would it take to build a solution that opens Remote and connects to your Apple TV when you tap on a notification? It’s not perfect, and it doesn’t cover every situation, but it would have temporarily eased our pain over the last five years.2

I’m not in any position to question Apple’s decisions—they’ve had unequivocal success without my input—but the rest of us could use this as a reminder. The next time you’re brainstorming, try not to toss aside all the imperfect solutions you come up with along the way. Maybe one of them is a simple solution you could implement now while continuing to work on the holy grail.

  1. WWDC 2014 kicks off next week, but the Apple TV’s release schedule isn’t consistent and there are ever-circulating rumors of bigger changes coming this Fall.

  2. iTunes Remote was released in 2008, and iOS has had push notifications since 2009.

Golang: Missing or Incomplete Socket Messages

I recently ran into a puzzling error while working with Go socket connections. When performing a read operation, incoming messages would periodically arrive incomplete or not at all. The fix turned out to be easy, but the problem wasn’t immediately obvious to me.

Almost every Go server implementation is built on top of the io.Reader interface. Go also provides us bufio.Reader, which implements buffering for an io.Reader object. It’s common to run into the following pattern for reading bytes from a connection:

data, err := bufio.NewReader(conn).ReadBytes('\r')
if err != nil {
    // Handle error
}

But we rarely need to read just one message from a socket connection. To continuously wait for new messages, we can enclose our code in a for loop and hand off processing to another goroutine. If we’re feeling clever, we can reduce memory usage and processing time by using a pointer to pass off our data:

for {
    data, err := bufio.NewReader(conn).ReadBytes('\r')
    if err != nil {
        // Handle error
    }

    go processData(&data)
}

Everything looks good so far, but this code actually introduces a big problem that you might not notice during testing: we’re creating a new bufio.Reader, and underlying buffer, on every iteration. Since the buffer is not persistent across iterations, any messages received before the new Reader is created will be lost.

The proper way to write this code is to create a new Reader outside of the for loop. You can then call its read methods like normal on each loop iteration:

reader := bufio.NewReader(conn)

for {
    data, err := reader.ReadBytes('\r')
    if err != nil {
        // Handle error
    }

    go processData(&data)
}