Every major software company has a collection of internal tools to help them develop their software. These are either off-the-shelf apps like Photoshop, or they are so specialised that they have to be custom written in-house by a team of specialists, often by a dedicated department.
Right now I’m in a similar situation myself: We need a dedicated tool to create the data structure for future reference apps. Specifically we need a simple input mask that makes my iPhone App understand what data I’d like to display without having to tweak a text file.
I can’t quite believe that I have successfully written such a tool for precisely this purpose. Best of all, I did this almost without any code using Cocoa Bindings. Aptly titled PatchBay, this app allows us to create a Core Data store file which I can pick up in iOS and display on the iPhone.
Let me tell you how it came to be, why it’s useful for us and how gobsmacked I am that this has become a reality.
When you’ve written one iOS app, you’d think it would be relatively easy to just copy that project, change a few details and create a new app in a matter of minutes. Well it’s not like that at all. You can of course copy and paste portions of code, but there are too many internal values in an app that govern its behaviour. There’s no “template” as such that you could easily customise to give you a head start on your next app. Every time you start, you start more or less from scratch.
In our case, we want to make several other reference apps, just like the 7 that are on the App Store right now. All of them have a certain look and feel, the same functionality, and all that’s really different is the data and separation into groups (say all Columbo episodes in one app, and all Poirot Novels and episodes in another as an example).
Until now we’ve had to hand-write all those titles in a file in text which our apps then display. Each item has a unique value which can track if a user has seen an episode and give links to more information. The time consuming bit is to copy and paste all that data so that the app can understand what we want it to do. It looks like this:
"tvShow2.1-title" = "Etude in Black"; "tvShow2.1-airdate" = "17/09/1972"; "tvShow2.1-imdburl" = "http://www.imdb.com/title/tt0068398/"; "tvShow2.1-wikiurl" = "http://en.wikipedia.org/wiki/List_of_Columbo_episodes#Season_2"; "tvShow2.1-image" = "season2.jpg"; "tvShow2.2-title" = "The Greenhouse Jungle"; "tvShow2.2-airdate" = "15/10/1972"; "tvShow2.2-imdburl" = "http://www.imdb.com/title/tt0068401/"; "tvShow2.2-wikiurl" = "http://en.wikipedia.org/wiki/List_of_Columbo_episodes#Season_2"; "tvShow2.2-image" = "season2.jpg";
That times 267. And of course if you miss as much as a semicolon everything stops working. You get the picture. It messes with your head after a few hours of working with it.
All this data can then be accessed by some other funky part of my code which I won’t get into right now. My point is it’s time consuming to do this, prone to errors, it’s difficult to edit and maintain, and from an artistic point of view just not very elegant.
What we really needed is a clever editing tool that let’s us add data in groups, and save everything as one file which we can give to the iOS App, and if we want to make a change it should be fun and easy. A simple text editor – as you can imagine – is not the solution.
Core Data is the answer
Over the last few weeks I’ve rediscovered Core Data, something that Apple recommend to use for storing data in iOS and Mac applications. They also say that “it’s not an entry level technology” – something I can confirm first hand: having looked into it last year for several weeks, my brain just never understood the slightest thing about it. Thinking that some things are not meant to be understood, I tried to avoid Core Data for something as simple as what I wanted to do.
Had it not been for Simon Allardice and the way he explained it in one of his excellent courses at Lynda.com I would still be clueless! Thanks again, Simon 😉
Now that I understand Core Data I must admit I actually enjoy using it – but it does add a level of complexity to beginning developers that has a touch of mystery and mind-blowing-ness.
Once I understood the technology, the next step was to create a simple input mask for our data – which would be too tedious to do in iOS (even on the iPad)… so I had to look into creating a Mac App for this purpose. I had never done that before either. Even though the development tool is the same (Xcode), implementing a user interface is quite different – and not something I was planning on adding to my skill set any time soon.
But it turns out that Mac Apps can do something rather magical, something that iOS Apps can only dream of. Something as tasty as…
Cocoa Bindings
This chocolaty sounding ingredient is a way to connect user interface elements (like a button or a text field) directly to Core Data, thereby eliminating the need for code. I didn’t know this, but discovering it came as a huge help. Imagine the possibilities!
So I devised a simple input mask for all the elements we need:
- episode title
- wiki link
- IMDb link
- etc, etc
The resulting SQLite file can then be imported and opened in my custom iOS App and display the data just the way we like it. It’s genius – and a huge time saver! Here’s what it looks like:
The principle was great, but of course there were – as always – a few minor problems I couldn’t quite figure out at first: Core Data can save things like a string or a date, but we also needed the ability to save pictures, as well as a unique index which can identify what the user has seen or watched. I didn’t want to hack in a file name, or manually add an incrementor value. Surely there had to be a more elegant way to do this. But how?
It took a bit of digging, reading complex developer manuals, and quite a bit of coffee – I even acquired a new Kindle DX for this purpose to read those manuals in the bright Florida sun. It wasn’t easy, but over the last few weeks I’ve put the pieces of the puzzle together:
Pictures can be dragged into something called an “Image Well” and saved as plain data – which my iOS app can re-convert into an image. And lucky for me the unique identifier is already being taken care of automatically by Core Data and is called an objectID – it’s a property I can access and never have to worry about.
I don’t want to bore you with technical details here, but this little helper app is quite a breakthrough for me. It’s more powerful and complex than anything I had imagined I would write for a while. I guess spending some uninterrupted time on this project really paid off.
Right now my head is filled with funky sounding things like
- NSValueTransformer
- Fetch Request and Fetched Results Controller
- Persistent Store Coordinator
- Predicates and Sort Descriptors
- Managed Object Context and the NSManagedObjectModel
I’ve documented all this and more over on my other site The WP Guru in the iOS Development Section.
Final Thoughts
To my own surprise I actually enjoy doing all these things. It’s like an extremely complex puzzle for me, an adventure game in which several small things need to be figured out to make a bigger project come together. I never thought I was such a geek!
This time last year iOS Development was an exercise in frustration for me; right now I’m confident that when the next puzzle comes along it’ll be an interesting challenge to figure out, and not something that’ll make me want to throw away the toys.
We’re currently testing PatchBay internally but I’m confident that the next app will most likely be created using my own development tool.