Switching to Jekyll

November 24, 2016

Are we still calling these things blogs? It certainly feels like blogging is an outdated technology these days. The type of thing that Google, Facebook and Medium are trying to kill off entirely. But there are still people in the tech community who are succeeding at doing things the “old internet” way, and I admire that. Building their own website, controlling their own content, and making something to be proud of.

For what it’s worth, I want to keep my blog around for a while. So I’ve decided to switch to Jekyll. I’ve been using Ghost for a year or two now, but I kept running into the same frustrations I had with Wordpress. I’m constantly behind on updates. Changing the layout is difficult because I have to re-learn how theming works, even for a small tweak. I think Jekyll is going to be a better fit for me. It’s not perfect, but it already feels like there’s less tooling standing in the way of writing and maintaining this site.

Anyway, I guess what I’m trying to say is, I apologize if you see a bunch of duplicate RSS items today!

Send data from your Arduino to HomeKit!

November 23, 2016

In my last post I described how to configure Homebridge to control Belkin WeMo switches through HomeKit. This is great, but it’s only part of my home automation story. My previous custom app included temperature and humidity sensors from Arduino Yún devices throughout my apartment. Fortunately it’s (almost) as easy to add these sensors to HomeKit as it is to add WeMo switches.

Arduino Yún

The Arduino Yún was discontinued earlier this year, so I can’t exactly recommend it if you don’t already have your own hardware. But any microcontroller that can serve up JSON will be fine. If you’re using an Arduino, I put one of my sketches here as an example. If you’re a beginner to this stuff and haven’t bought anything yet, remember that you can’t beat Adafruit for selection of parts and great tutorials.

The more powerful devices let you assign a hostname like livingroom.local, but if you’re accessing it through an IP address you should assign a static IP on your router so its address doesn’t change in future. You want your device to output a small chunk of JSON like this:

{
    "temperature": 21.61,
    "humidity": 48.85
}

Invalid output will just crash Homebridge, so use your browser to make sure it’s sending a valid result. When you’re satisfied, install the plugin on the computer running Homebridge:

sudo npm install -g homebridge-httptemperaturehumidity

Now open up ~/.homebridge/config.json and add each of your devices under the accessories section.

"accessories": [
    {
        "accessory": "HttpTemphum",
        "name": "Arduino Yún (Living Room)",
        "url": "http://livingroom.local/arduino/temp",
        "http_method": "GET",
        "humidity": true
    },
    {
        "accessory": "HttpTemphum",
        "name": "Arduino Yún (Bedroom)",
        "url": "http://bedroom.local/arduino/temp",
        "http_method": "GET",
        "humidity": true
    }
]

Restart Homebridge and you should see your sensors in HomeKit!

Unfortunately, there are a few caveats. The iOS Home app is limited in what it can do. There’s no history, and you can’t create an automation or get an alert based on a temperature reading. And the Homebridge plugin is less than perfect. It can take a few seconds to update values, and occasionally it will time out altogether. But I’m hoping both HomeKit and Homebridge continue to get better over time. And it is neat to ask Siri, “what’s the temperature in bedroom?” and get a response.

How to add HomeKit support to your Belkin WeMo switches today

September 18, 2016

iOS 10 was released last week, and comes with a new Home app to control devices that use Apple’s HomeKit protocol. It’s pretty nice, especially combined with Siri and the Apple Watch. But are Belkin WeMo owners out of luck? Earlier this year Belkin announced they had no plans to add HomeKit support (not surprising, since it would require different hardware). Fortunately there’s a solution… Homebridge! It’s completely free, takes 10 minutes to set up, and gives you full HomeKit compatibility for your WeMo devices.

Belkin Wemo Switch

Homebridge is a Node.js server that acts as a bridge between HomeKit and other home automation devices. It’s a pretty great piece of software, and so far (fingers crossed) it’s worked extremely well on my network. I only have WeMo switches at my house, but Homebridge supports hundreds of different devices through its plugin architecture.

The only prerequisite for Homebridge is Node.js and NPM. There’s a guide on Treehouse to install it on your Mac if you don’t already have it. When you’re done, installing Homebridge is simple:

  • Run sudo npm install -g homebridge to install the Homebridge server.
  • Run npm install -g homebridge-platform-wemo to install the Homebridge WeMo plugin.

You’ll also need to create a new file called config.json in your ~/.homebridge folder. Here’s what mine looks like:

{
    "bridge": {
        "name": "Homebridge",
        "username": "CC:22:3D:E3:CE:30",
        "port": 51826,
        "pin": "728-15-728"
    },
    "platforms": [
        {
            "platform": "BelkinWeMo",
            "name": "WeMo Platform",
            "expected_accessories": "4",
            "timeout": "25",
            "no_motion_timer": "60",
            "homekit_safe": "1"
        }
    ]
}

You must change expected_accessories to match the number of WeMo devices on your network, but otherwise there’s not much to configure. Take a look at the WeMo Platform Plugin page for details.

Save your config file and run homebridge from the command line. You’ll see a code to pair with HomeKit. Open the Home app on your phone, tap Add Accessory, and you should see your Homebridge server! Homebridge is sensitive to mistakes in config.json, so if you see any strange errors check it for problems or invalid JSON. Otherwise, once things are working correctly, you can use forever to keep Homebridge always running in the background.

There’s one more step you might want to do if you have an AppleTV 4. You can use your AppleTV as an iCloud HomeKit hub, allowing you to control devices when you’re away from your home wifi network. For this to work you need to turn on two factor authorization for your iCloud account. Think you’ve already done this? It’s likely you have two-step verification enabled, not two-factor authentication. Okay, this is confusing, and Apple doesn’t explain it well at all. But it’s easy to fix. Follow this guide at Six Colors and you’ll be set.

Tab Workroom is in the App Store!

July 06, 2016

I’m excited to announce the first major milestone of my new indie software company, Once Living. Tab Workroom 1.0 for iOS is available on the App Store!

I made Tab Workroom to help practice guitar and build a library of tabs and chords for the songs I love to play. It’s the iOS equivalent of a three ring binder for your songs. Add tabs (there’s a built-in web browser to make finding content easy) and practice them anywhere. Tab Workroom includes a custom CloudKit sync engine to make sure your content is always available on all your devices. And of course, features like fullscreen and autoscroll for practicing your songs.

It’s nice to see Tab Workroom in the App Store, but there’s still a ton left to do! I’m currently working on a macOS companion app, adding iPad support, and continuing to add additional features to help people play and learn new songs. If Tab Workroom is an app for you, don’t hesitate to send feedback about what features you’d like to see.

Download Tab Workroom here for free. Follow @OnceLivingApps or sign up to the mailing list for news on future updates!

Is this the end of iCloud Core Data?

June 17, 2016

Michael Tsai wrote a summary on the apparent deprecation of iCloud Core Data:

Fast forward to WWDC 2016. When installing the Xcode 8 beta, I noticed that all of the symbols related to iCloud Core Data were marked as deprecated in macOS 10.12 and iOS 10, with the comment “Please see the release notes and Core Data documentation.” Strangely, the Core Data release notes and What’s New in macOS 10.12 documents make no mention of this. What’s New in iOS 10 simply says that “Several NSPersistentStoreCoordinator symbols related to ubiquitous content” have been deprecated.

Writing your own CloudKit based syncing solution is hard, but worth it in my opinion.

Four Random and Unrelated Core Data Tips

June 06, 2016

  1. Marcus Zarra is still the undisputed Core Data expert in my book. People who are new to Core Data tend get hung up around its threading model, but if you follow his advice you won’t have any problems. Even if you’re experienced with Core Data, you should watch his talk on the subject at least once. This related talk on networking is worth your time too.

  2. A new feature of iOS 8 is NSBatchUpdateRequest, which solves some of the problems with updating a set of objects that’s too large or slow to fetch into memory. But watch out! I didn’t even think about it at first, but NSBatchUpdateRequest completely bypasses the threading model mentioned above. There are still ways to safely use it, but my recommendation is to simply avoid it unless it’s something you legitimately need.

  3. Another new feature in iOS 9 is Core Data Constraints. Instead of following the fetch and create pattern when inserting data, you can set a constraint on an attribute and Core Data will check for existing objects with the same identifier. Handling conflicts seems messy though. I think I’m going to avoid this feature for now. Maybe I’ll change my mind, though.

  4. When you declare an @NSManaged var in your managed object subclass, normally it can be an Int, Bool, or Double. But not for Core Data primitive accessors! Primitive accessors (not to be confused with primitive types, I’m talking about methods that are a shorthand for primitiveValueForKey: … ) must be declared as an NSNumber. You don’t have to explicitly wrap your value in an NSNumber, you can still assign an Int or Double to your var and Swift will box it up for you. Not a big deal, but something to remember if you find your app crashing.

Announcing Once Living

May 30, 2016

Here’s a small secret I’ve just recently started to tell people about. I’ve been working on a new project this year. It’s a new indie software company I’m starting, called Once Living.

The first product I’m releasing is Tab Workroom, an iOS and OS X app for guitar players to collect tabs and chords. Although Once Living is new, Tab Workroom isn’t. It’s been an occasional side project for almost four years now. I play guitar, not in a serious way, but enough that I have pretty nice collection of tabs that I love playing. I built Tab Workroom to be the best possible way to organize and practice my collection of songs.

Building an app (even a small one) is never easy, but it’s been a lot of fun watching Tab Workroom come together. The folks over at The Iconfactory did a fantastic job on the app icon, and I love seeing it on my homescreen. The future is bright too. I have a lot planned even after the initial iOS release!

Tab Workroom is in private beta and will be available in the App Store soon. If you’re interested in learning more about the launch, sign up for the mailing list and follow @OnceLivingApps on Twitter. I’m excited to show you what I’ve been working on!

Better Segue Identifiers

March 14, 2016

Lately I’ve been thinking about segue identifiers. We all know it’s bad practice to use strings instead of constants for identifiers. All it takes is one spelling mistake or forgetting to update a name, and you have big trouble that’s not visible until runtime. But there’s no getting around this in Xcode, unless you stop using segues altogether (and no, you don’t want to do that).

In my current project (the first where I’ve gone all-in on storyboards and segues) I’ve reached the stage where many view controllers have a non-trivial number of segues. And so I started wondering if maybe there is some sort of safer, Swift-y way of managing identifiers in code. Of course it turns out that @NatashaTheRobot has already thought about this! You can read her post about it right here.

I tweaked her solution a little bit for my own needs. The biggest change is adding segueIdentifierForName(), to check the segue identifier string given in shouldPerformSegueWithIdentifier(). Natasha’s blog has the background, but to start you create a SegueHandlerType protocol:

import UIKit

protocol SegueHandler {
    typealias SegueIdentifier: RawRepresentable
}

extension SegueHandler where Self: UIViewController, SegueIdentifier.RawValue == String {
    
    func performSegueWithIdentifier(segueIdentifier: SegueIdentifier, sender: AnyObject?) {
        performSegueWithIdentifier(segueIdentifier.rawValue, sender: sender)
    }
    
    func segueIdentifierForName(name: String) -> SegueIdentifier {
        guard let identifier = SegueIdentifier(rawValue: name) else { fatalError("Invalid segue `\(name)`.") }
        return identifier
    }
    
    func segueIdentifierForSegue(segue: UIStoryboardSegue) -> SegueIdentifier {
        guard let name = segue.identifier else { fatalError("Segue has empty identifier!") }
        return segueIdentifierForName(name)
    }
}

When you create a segue, make the source view controller implement SegueHandlerType by providing a SegueIdentifier enum with the identifiers you set in Interface Builder. You don’t have to include the segues you’re not dealing with in code, but you should— it’s useful when making changes to see all the segues declared in code.

class LibraryViewController: UITableViewController, SegueHandler {
        
    enum SegueIdentifier: String {
        case OpenFile
        case ChooseFolder
        case OpenSettings
    }
        
    override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
        switch segueIdentifierForSegue(segue) {
        case .OpenFile:
            // prep the destination view controller
        case .ChooseFolder:
            // prep the destination view controller
        case .OpenSettings:
            // prep the destination view controller
        }
    }
        
    override func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
        performSegueWithIdentifier(.OpenTab, sender: nil)
    }    
}

I’ll reiterate: this is ALL @NatashaTheRobot’s solution, just changed a little for my own needs. I can’t take credit for her awesome work!

It’s not 100% foolproof, but I like this way of dealing with segue identifiers. I’m using it in a couple of my projects, and as long as you’re careful to keep your code current with Interface Builder it’s a much cleaner and safer way to work.

Xcode UI Testing Tip

February 03, 2016

You’re using Xcode’s UI Testing framework, right? It’s a fantastic way to prevent bugs and know when refactoring you’re not breaking some dark corner of your app. It’s not always easy though! UI testing is still an early technology in Xcode 7. There are bugs, and asynchronous network calls can lead to frustrating false positives.

Here’s an incredibly easy tip to improve your tests: run them on a device with Network Link Conditioner set to “Very Bad Network.”

Things will time out. Your tests will fail. But that’s okay. You’ll quickly see places where it’s the test that’s at fault, and something timed out before a network operation completed. Some of these you can fix that with this snippet:

func waitUntilVisible(element: XCUIElement, file: String = __FILE__, line: UInt = __LINE__) {
    expectationForPredicate(NSPredicate(format: "exists == 1"), evaluatedWithObject: element, handler: nil)
    waitForExpectationsWithTimeout(30) { (error) in
        guard error != nil else { return }
        let message = "Failed to find \(element) after 30 seconds."
        self.recordFailureWithDescription(message, inFile: file, atLine: line, expected: true)
    }
}

What’s more interesting are the places where it’s not the test. I’ll bet you find some interesting race conditions you wouldn’t normally see, even when using Network Link Conditioner during your own debugging. Enjoy this, it’s not always this easy to find these types of bugs!

iOS 9 Storyboard References

December 16, 2015

With every new release of iOS there are the features everyone talks about, and those that get mentioned at WWDC and promptly forgotten about. It’s the latter that often the most useful in the long run, though.

With iOS 9 one of those features are storyboard references. In short, you can split a storyboard into multiple files while still taking advantage of segues and having a visual reference of how your view controllers are connected. And Xcode makes the refactoring process easy. It’s a five minute deal, even if you’re starting with a big messy storyboard.

No more scrolling through a huge storyboard trying to find the view controller you need. Merge conflicts? Still a pain, but they should happen a lot less.

Etiquette.io

April 15, 2015

My latest project I’d like to introduce you to is Etiquette.io. With the upcoming release of the Apple Watch, we’re going to be encountering all sorts of new, awkward social encounters. Etiquette.io is my attempt to fight rudeness in future technology.

I owe many thanks to the talented Christopher Reineman for the illustrations!

Marcus Zarra’s Core Data Stack

April 08, 2015

There’s an unfortunate but understandable tendency to avoid Core Data in the iOS developer community. Follow the correct patterns though, and Core Data can help you build a reliable, performant data model. And there’s no better person to talk about Core Data than Marcus Zarra. Take a look at his latest article here.