Hone Tools

In fall a friend and me were working on an application called Alarm which was released recently. The application was made as part of Hone toolset and we were one of the teams that got early access as means of external evaluation and bringing in real world feedback during development process. In this blog post I’ll write about this experience.

Hone is iOS and OS X toolset that allows storing and retrieving various parameters as well as providing easy way to change them live, as your application is running. It’s composed of the framework that is embedded to the application itself and OS X application that is used as front end for tweaking parameters. Additionally, there’s web component that centralizes parameters so you can even tweak them as the application is already published, without requiring rebuild.

Framework

Being developer, let’s first take a look at the framework. It’s very lightweight and works in two layers. The simplest of the two is very similar to NSUserDefaults - you ask Hone for value and it returns it. You can optionally specify default value in case the value you ask for doesn’t yet exist. For example:

let floatValue = HNE.CGFloatWithHoneIdentifier("SomeFloatValueKey")
let intValue = HNE.NSIntegerWithHoneIdentifier("SomeIntegerValueKey")
let stringValue = NSString(honeIdentifier: "SomeStringValueKey")

All of these methods accept second parameter with default value. As you can see it’s trivial to use. But it’s static - it only reads value when you tell it so. In order to respond, you need to use another layer that’s built on top of key values. It’s conceptually similar to key value binding but works on both, iOS and OS X, whereas KVB is only available on OS X. With this API, you can simply bind a key to a property of an object and whenever the underlying value changes, the property on the object is updated. Example:

HNE.bindUIColorIdentifier("MyNiceBackgroundColor", object: self.view, keyPath: "backgroundColor")

I find the binding API take care of most of the needs. But in some cases, you need to perform more complex steps upon one or more of the values changes. For these instances you can observe changes and react as needed. This API is very similar to KVO, albeit offering much nicer way of dealing with changes:

HNE.watchIdentifiers(["MyValue1", "MyValue2"], object: self, block: { object, identifiers in
    self.tableView.reloadData()
})

Toolset

In addition to providing framework, Hone is also composed of OS X counterpart application which reads all of your settings and provides nice user interface for changing them. If you implemented dynamic handling (and there’s really no reason why you wouldn’t), any changes you perform in Hone app, will be instantly indicated in the UI of your application be it on simulator or actual device (or of course OS X application running on your computer). The two don’t even have to run on the same computer, the devices just need to be on the same WiFi network.

Furthermore, the changes can be sent to Hone website in order to have them distributed to all of your customers, without requiring rebuild, they just need to have internet connection of some sort. Hone framework will check for any changes when your application starts and will download them if needed. From then on, internet connection is not required. Of course, default values are always present, so the application is useful even without any internet connection.

We didn’t use web component much during development, but the idea is intriguing.

Workflow

This brings me to workflow. The developer is the one that needs to “open up” or expose parameters to Hone. As demonstrated above, the API is very simple, so typically you need to bind couple values in viewDidLoad and be done with it. But you also need to prepare Hone configuration files where parameters are described and their default values set.

There are two ways of adding the values to Hone - you can use Hone OS X application or edit configuration files directly. At the time I used Hone, I found it easiest to edit source files - they use YAML syntax and I found them perfectly readable. Additionally, as Hone configuration files are using text format, they play very nice with versioning system - git, subversion or whichever one you use. After you describe the values, Hone OS X application will automatically detect them and allow you to change. From here on, you can easily tweak parameters without having to restart your application which is a huge time saver.

Not only that, being so simple to use, the developer can only prepare rough UI, leave various parameters open to Hone and have designer tweak them in order to create the perfect user experience. And if more are needed, they can easily be added as it goes. Think colors, corner radiuses, widths, animations etc etc.

In fact, that’s how Alarm was developed; we simply concentrated on core functionality and exposed parameters where we estimated need for, then simply used some default values. Designers were then responsible for tweaking and making sure all views play nicely.

Conclusion

I find Hone interesting for several reasons: it allows quicker development times, concentrating on core functionality and bringing otherwise long and costly polishing phase to client/developer side. Further more, adapting to dynamic changes by mere clicking and updating values in Hone OS X application, it can also shorten polishing phase considerably. I can easily see great value for such a tool for smaller or emerging businesses or design studios wanting to get their own application but fearing development costs - they can outsource developers in order to get functional application without fear of additional charges for polishing phase. Similarly, on developer side, using tool as Hone makes it more viable to have outside developer polish the app to perfection.

Hone is currently in beta on hone.tools. Alarm has been released now and is available on the App Store. You may also want to read Alarm release blog post. It explains how you can use Hone tools to tweak Alarm visuals, so go ahead, give it a go and see it for yourself. Alarm source code is currently not available, but it will be open sourced in the future.



Want to reach us? Fill in the contact form, or poke us on Twitter.