So in a change from the past, I've opted to have a public beta with Code Collector Pro 1.3. This has the benefit of me getting a much wider beta tester pool and users getting the latest and greatest sooner (albeit a bit buggier). So what is new in 1.3? Well first I'm going to talk about what has gone:

No more Tiger support

If you are using Tiger than CCP 1.2.4 is the last release you'll be able to run until you upgrade to Leopard. After spending months developing Lighthouse Keeper as a Leopard only app I started to appreciate how much code I didn't have to write compared to Tiger. The less code I have to write, the more I can focus on cool stuff and the less bugs there are in general.

No more Code Collector Lite

Code Collector Lite is being replaced by a more flexible trial in CCP. Now obviously this will annoy some people, but the fact is that Lite was the unloved brother of CCP. It didn't receive any updates and just caused the code base to be more complicated as I had to remove a lot of stuff.

Now my hope is that 30 snippets and 5 groups will be enough for most users who only want to use Code Collector occasionally. You will gain all the features of pro except for the sharing (which is now disabled in the trial). For those who need more snippets then €20 is honestly not all that much.

---

Now that you know of the two major potentially negative (but in the long term extremely positive) changes, what is new in CCP 1.3?

Snippet search panel

Since it's launch, CCP has been the best way to organise your code snippets on the Mac. And since version 1.2 it has been the best way to share your snippets with the world. Unfortunately the missing part of the trinity has been using your snippet. There have been various ways to get snippets out of CCP and into your code. Dragging snippets from CCP to your documents, selecting a snippet and copying it or using the menu item to search for and copy a snippet to your clipboard. Unfortunately none of these are elegant.

So to solve this problem I've replaced the search menu item with a search panel which is more less buggy, more powerful and provides a seamless workflow. Now you can bring up the search panel using a global hotkey (customisable of course), start typing to search for snippets, press up or down to select the snippet and then hit return to insert it into the front-most app. Your hands never need to leave the keyboard.

Languages without bundles

One of the biggest support issues with CCP has been users getting confused over how to add languages. To rectify this I've completely redesigned how languages work in CCP. You can now add a language without the need for a TextMate bundle, though you will still need a bundle in order to have syntax colouring.

Download bundles within CCP

And to make getting those bundles easier, CCP 1.3 lets you download them from within the application. When choosing a bundle for a language, click on the segmented control to view the repository and then click Install to download it.

Drag & drop files into your library

One of the biggest requests has been the ability to drag a code file into CCP to add snippets. Well with 1.3 your request has been fulfilled. You can drag code files onto your library to create snippets from them. Even better, CCP will use any bundles you have associated with language to try and guess the language of the snippet based on the file extension.

---

There are also some other smaller improvements and bug fixes, such as language and licence names updating across the app and the ability set the background colour of the code view. So if you want to try out the latest and greatest version of Code Collector then download it now. (If you haven't already got CCP 1.2 on your system then you'll need to install it first, there's a few bugs that have been pointed out to me between releasing and writing this that cause a launch on a clean machine to fail).

WARNING: As always, this is beta software and so it contains bugs. Always make a backup of your library before trying it out (found at ~/Library/Application Support/Code_Collector).

Comments (0)

---

Almost every programmer has been there. You've created a beautifully architected application with each class fitting perfectly into well defined boundaries. Then you hit a snag, you need to pollute your nice clean architecture and destroy one of those boundaries to get something to work (or face a huge amount of code to get it to fit in with your existing system).

I hit this problem with Lighthouse Keeper and found a rather nice solution to it. When talking to Lighthouse I have a single "smart" class that deals with all API calls, which then creates a bunch of "dumb" data objects that handle storage and saving (eg Tickets, Milestones, Projects, etc). These data objects contain integer ids when they need to reference other types of data object, and the "smart" controller class has methods to make perform the task of linking these together if I need them (eg getting all the milestones in a certain project).¹

But of course this approach leads to issues, the biggest of which I found was sorting. Cocoa provides a very nice class for sorting called NSSortDescriptor. You set a key, whether it is ascending or descending and optionally a selector to call on the object to compare them. Now, when sorting tickets by milestones or users, you want to sort by the milestone name or the user's name not their id. The problem is, there is no way to move from a ticket to a milestone with key value coding the way I've set things up.

So I'm stuck with a dilemma. I can either pollute my nice cleanly architected code by letting tickets know about other objects, or I can keep my clean architecture but write my own sorting code (but due to the way table views work it is a bit more complicated than that). Well thankfully, I found a way to both have my cake and eat it and it involved categories.

By creating a category on my tickets class, I could add methods that referenced other objects, while having my actual ticket class be completely and utterly oblivious to the other objects. I could now create a simple KVC to sort my tickets "milestone.name". As always, it's frustrating how incredibly simple and obvious a solution seems once you've found it, but I'm surprised that nobody seems to have posted about this before.

1. For those interested, I chose not to link directly between objects for several reasons. It makes it easier to fail gracefully if the related object doesn't exist. It's also simpler when creating and updating objects. And it also makes it simpler to manage moving both ways as I don't need objects to know and manage their children and children to know their parents

Comments (0)

---

Page 1 of 1 pages