Recently I departed from the safety of mobile apps to dive into OS X development and Swift. A bit of an adventure!

Motivation

So why was I heading into unknown territory? On a recent Android project we had a recurring problem with a set of 9-patch assets. It was a large project with a tight deadline, and somewhere along the way these particular assets had gone a bit… awry. Our designer’s time was overloaded (it's okay - we have two designers now!) and, with the 9-patch graphics evolving and several resolutions to cater for, we ended up having a series of failed builds. (If you’re curious what a 9-patch is, or how it can make a build fail, have a look here)

Our process for handling 9-patches wound up looking something like this:

1. A designer exports a new 9-patch graphic
2. They commit it to the repo
3. An engineer pulls the changes to integrate them
4. Unfortunately the 9-patches are malformed so the project fails to build! Disaster!
5. The engineer has to revert the designer's commit and ask them to try again. Back to step 1.

The biggest problem occured when our designer left the office at step 2 after a long day's work and we had to wait until the next morning for a fix! The root cause was found and we got back on course, but we realised that designers have no tools available to quickly and easily check the validity of 9-patches before committing them. Large graphic deliveries and tight deadlines are inevitable and mistakes will be made - this is not going away on its own.

So we decided to fix that.

(The 9-patch tooling, that is, not the designers committing to Git - we actually let them do that! Thanks SourceTree…)

Developing a solution

We did our research first of course. We initially thought that the solution to this could be found right at the source: project structuring and tools. But after a thorough investigation by Steve, we have concluded there really is no elegant solution to the problem. Adobe products lack the tools to help with 9-patches and Android’s draw9patch tool was not working as a solution. Tools such as Sketch have a number of 9-patch plugins but they would still need editing afterward. So if you can’t go over, round or under it… make a Quilt.

Our aim with Quilt is to try and help the designer as much as possible. With this in mind we have two strategies to employ - a two pronged attack if you will…

• Active The graphic assets are exported and ready to go. But how do you know they are valid?

  You could download the Android developer tools, open the project, and try to compile it; but that is an awful waste of time and effort. Even if something was found to be wrong, it might be hard to identify. With a dedicated desktop tool you could manually check the assets before committing and see any problems in an easy to read list.

• Passive When all is said and done a 9-patch can either be wrong or it can be right, so there is no way a bad one should end up in the repository. And what do you do when you want to enforce a rule on a repository?

  Git Hooks to the rescue!

  With a git hook installed in your local repository we can alert you that something is wrong and even what that something is. With the desktop tool you could get a more usable display of what is wrong (rather than a nasty command line output) and, hopefully, with a couple of tweaks and another check you can get your commit in easily.

To that end, our new designer Merce has been cutting her teeth in Balsamiq Mockups by creating a way to bring these tools together into a nice, easy to use product, more details on that in part two...