I have no idea why it’s there, and why it and *only* it is there, but that was the file that created the problem.

However, it turns out that under Snow Leopard you can no longer search for a document of type x – a search for .storedata turns up zilch. Tiger’s Spotlight app, which I liked an awful lot, has been folded into the general folder search – no more grouping of results (which was useful), no more search by predicate of ‘find me something of the same type as the document I’ve just dragged here’ which Sherlock used to do. Dear Apple: why are we getting less functionality???

So I’ve found one zombie file, but have no idea whether I can find and zap all of them.

Onwards and upwards. And now to make a bloody tree controller work when every single tutorial I find is giving me something that throws exceptions left, right, and centre.

This includes Apple’s own, so I’m not singling anyone out, I am just *so tired* of not even being able to RTFM because there IS no FM that describes how to make the code work in simple steps, and Apple seems to be changing everything around and mixing it up and while I’ve specified in my app delegate that I want my app to store its data in SQLite format, I have no idea what .storedata IS.

What was my crime?

I created an application with a Core Data model. I compiled the application, found it didn’t work, made some changes, including to the Core Data model, recompiled it, and got The managed object model version used to open the persistent store is incompatible with the one that was used to create the persistent store.

I have created dozens of Core Data applications. I have changed the models in them hundreds of times… in Xcode 2.5. And every time, when I’ve used ‘build-and-run’ I was presented with a new persistent store that WORKED.

This is the behaviour I expect. I’m developing an application. Once you build the finished thing, writing a permanent store and forcing developers to maintain version control and backwards compatibility is a good thing. During the build-and-run phase, it’s a very stupid behaviour. I am not creating precious, valuable data… *I am developing an application*.

So, I’m not the first person to run into this problem.

The documentation here talks about the different types of data stores and their advantages… without mentioning where you might set them.

You’re just automagically supposed to intuit. And yes, I *have* tried to read TFM as much as I was able to download it, and I *have* looked at each and every promising possible setting I could find, but I was not able to identify where to tell Xcode which kind of data store to use.

Marcus S. Zarra in his comprehensive book on Core Data…

… is just as silent. There’s not even an entry for sqllite in the index, and while he, too, tells you which storage formats you might choose, he omits telling you HOW TO FUCKING CHOOSE THEM.

I admit defeat on this one. I cannot, no matter how far I look and root around on my hard drive and search for anything associated with my damn application find the place where the data has been written. This is very very bad news, because I use Core Data a lot and I have created and run and experimented with *a lot* of Core Data apps, all of which appear to have written invisible, undeletable data SOMEWHERE on my hard drive, files which I cannot find, cannot delete, and which seems destined to hang around forever.

So this is a FAIL on several levels:

- there’s no visible or documented way of declaring the store type when you start creating your application
- your application’s data is not (despite assurances to the contrary) stored in an accessible space
- there is no way of clearing out that store and doing a clean rebuild during development (‘This is not compatible: overwrite data store’ would do just fine, thank you)
- the application’s data store hangs around even when the application is deleted; it persists when you create a new project with the same name that allegedly stores its files in a different location
- the documentation sucks. It completely absolutely utterly sucks.

I don’t know where to go from here. The sensible way forward would be to NOT run any new Core Data projects until I know where the fucking data is stored because this is creating invisible, unfindable files on my hard drive. I feel that I have gotten as far as I can – I’ve looked at the damn thing, I’ve read the documentation, I’ve searched my hard drive, I’ve rooted around in books, I’ve opened all packages (which doesn’t explain why creating a NEW project with the same name leads to the same error as before) – the long and short is that I CANNOT find the data, I CANNOT work this out, and I am completely baffled where to go for help since the hivemind of the Internet hasn’t given me any workable solution, either.

I expected to encounter this type of problem sooner or later, but if the app I’m trying to program is the equivalent of a novel, I didn’t expect to stumble over ‘It was’.

This is supposed to be a hobby. It’s supposed to be fun. And those people for whom programming form part of their livelyhood don’t deserve having to spend hours batting their heads against walls over very simple things, either.

I am deeply disappointed at Apple and am rapidly losing trust in their Cocoa development team, because this is a failure on several levels – design, preferences, documentation.

And I’m not imagining things. CocoaDevCentral says quite clearly The data store is defined in the -managedObjectContext method, which is generated automatically when you create the project. My managedObjectContext method contains no such line as
url = [NSURL fileURLWithPath: [applicationSupportFolder stringByAppendingPathComponent: @"BlogDemo.xml"]]; ... if ([coordinator addPersistentStoreWithType: NSXMLStoreType configuration: nil URL: url options: nil error: &error]) ...

Part of that code is spread around other functions, but this means that the help I can get is not valid for the auto-generated code I am working with – as far as I can read my code it a) ought to create an XML store (addPersistentStoreWithType:NSXMLStoreType) in a ‘Outline_Test’ directory ([libraryURL URLByAppendingPathComponent:@"Outline_Test"]).

There is no such folder. There’s a Outline_Test-aebwvrtqgkvjspduholxgeckmgki folder – I am *so* impressed that Xcode4 is creating monster folders like this for every project I run – and that there’s nothing in the code that would indicate to me that this is going to be created. There’s also no .xml file that I can find anywhere.

I really truly *do* give up. And hope that someone, somewhere on this planet with more patience and more magical ability will work this out and put the solution somewhere I can find it. In the meantime, unless I want to give up programming for good, I have to resign myself to creating zombie files on my hard drive, and that makes me absolutely utterly FURIOUS.

I needed Richard Wentk’s excellent book (entitled simply Cocoa) to find them.

They are interwoven with the Developer documentation. That’s the documentation you can only access when you’re online, remember?

If you’re not accessing it from a browser but from inside Xcode, and browse the Mac OS X Core Library, you find that it contains a lot of examples, which can be downloaded and opened.

(And I am *so not impressed* that half the links have been updated and are getting redirected to the main page so that the samples aren’t easily accessible after all.)

I liked the old way – where you could download documentation and samples in a version that would be guaranteed to run on your computer/version of Xcode – much better. If I hadn’t happened to glance at the right page in the book – and who in their right mind reads up on how to use documentation – I would have missed this feature for some time yet.

So now I’ve downloaded sample code for the things that interest me most – including NSCollectionView – and can start, dodgy internet connection or not, but argh. Life shouldn’t be so difficult!

typedef enum { Domestic, Water, Land, Display } EnclosureType;

If you’re using something like this purely in one small area of your application, that’s fine, but the main problem I see is that you’re hardcoding values – which sounds like a bad idea, even if you have a file where you declare all of these things globally.

Err, that’s the voice of experience. There’s nothing worse than wading through hundreds of possible location – even with good search capabilities – to find that you’ve originally used a different collective term for aquariums, terrariums and bird cages. And when your Zoo expands and you’re having walk-in enclosures housing birds and monkeys, good luck finding this typedef and all the places where you were counting on having only four types.

My understanding – and I’m happy to be corrected – is that it’s better to either create an object/CoreData entity, or to make encode such lists through the preference files (and I’m rather shaky on that part.)

Which brings me to the second typedef: struct.

typedef enum { Domestic, Water, Land, Display } EnclosureType;

struct Enclosure_ {
int enclosureID;
char *enclosureLabel;
float xLength, yLength, depth, height;
EnclosureType enclosureType;
} Enclosure;


There are two things going on here – one is definiting the structure as containing all the variables listed, the other is the naming conventions. Enclosure is a type, which is defined as a struct [which happens to be called Enclosure_]. This – according to to Trent/McCormac p. 195 – allows referring to the struct inside itself, but don’t ask me how it works or why anyone would want to.

You can set values in a manner similar as you would for an object:

Enclosure elephantEnclosure;
elephantEnclosure.enclosureLabel = "African Elephants";


This still looks _exactly_ like an object to me, and I have absolutely utterly NO idea why and when, in OOP, one would define a struct like this and when one would create an object. I would guess that structs have smaller footprints than objects… but when are they appropriate?

I then went and deleted most of the iPhone stuff, leaving the system version that I’m running and the latest; which saved me about 4GB back.

(As usual, things are complicated. I’m not working on the latest system version; or the latest version of Xcode. And right now most of the materials I have refer to Tiger/Xcode 2.5; with the later ones optimised for Xcode 3.2… Xcode 4 is a different beast, and I’m havinng to learn it all over again.)

Xcode 4 does not come with documentation. None, zero, zilch, nothing. It also doesn’t come with more than three examples.

This is so lousy that I don’t have words for the lousyness of this arrangement.

I don’t have a permanent fast unmetered internet connection. I can read e-mails and open most webpages most of the time, but if I want broadband access I need to leave the house. Comes of living in the middle of nowhere where companies look your location up on their computer systems and go ‘well, ahem, that super-duper-broadband offer? Not something we can put into your house. Sorry.’

I don’t mind, most of the time – I have mobile broadband and an iPhone that serve my needs, and access to more internet if I need it, but an application of this complexity that comes without any documentation whatsoever is LOUSY. And with Tiger I had the difficulty that online examples were updated _to exclude running on my computer_.

This isn’t just a problem because I’m inconvenienced. It’s an accessibility problem – people who cannot afford to buy new computers, people who cannot afford broadband (and everybody who lives in an area where paying for fast broadband *is not an option*) are excluded. Yes, most developers probably will have the latest, fastest gear – if you’re a commercial developer that’s a must – but by setting the hurdle at a computer with the latest or almost-latest OS and unlimited broadband access, development is artificially limited to wealthy people.

And that’s not cool, and deserves to be pointed out.
A optional download of documentation and examples would go a very long way.

Xcode 4 is definitely the future. The thing I hate most is that everything is happening in one window – I want my floating palettes in Interface Builder back; I *hate* the all-in-one arrangement. I don’t like working full-screen at the best of times, and I want to be able to move palettes and inspectors out of the way. I like the new Core Data editor a lot; I like – from the little I’ve seen – the quick help and other editor features.

Code Snippets are made of win. (Even more win would be the ability to organise that library other than by name, but for someone like me who makes typos and forgets syntax, the ability to just drag my for and while and switch statements is wonderful.)

I’m not looking forward to this. I have to relearn so many things – how to create interfaces, and while I might not have been a very successful programmer, many of the things that *did* learn now have to be unlearnt and reaquired… without the body of books and tutorials to look things up if I can’t work it out on my own.

This means I need to relearn some things, I need to tackle the basics again, and I am refamiliarising myself with the examples.

So imagine the wonderful surprise I got when I realised that most of Apple’s examples… *need the OS 10.4 SDK kit installed to run*.

Yep, you read that right. Snow Leopard’s Development tools don’t come with their own set of fully working example applications.

I am not impressed.

Am even less impressed by 2409 Errors stopping TextEdit from running.

No, really. I did not make up that number, 2409 fatal errors in an example that went with _Apple’s own software examples_. Really, folks. You can do better than that.

has a very long list of Cocoa (OS X/iPhone) books. It’s an exceedingly comprehensive list; many of these are books I hadn’t even heard of and wouldn’t have known how to look for them. Some of them just stand on their own, some have brief reviews, but if you want a bookshelf to browse, this is hands-down the best I have seen.

Major areas where encapsulation plays a role:

• Model/View/Controller
• Objects
• Accessor Methods
• Data Encapsulation

Data Encapsulation

is the easiest to explain. Don’t use finalPrice=basePrice + 17.5% in your application. If the VAT rate changes, you’ll have to hunt down every instance, and you’ll miss them, and in five years you might no longer know where that ’15%’ figure came from.
Define – and since VAT is something you’ll use in a number of contexts, this should be a global variable – float valueAddedTax=20% (float? syntax? I need to look this up) and use finalPrice=basePrice + valueAddedTax. This means you only need to change the value in one single place *and* your code will be more readable. Double Win.

are reasonably straightforward: instead of reading the value of an object directly, you knock on the door and ask the object to provide its value or to set itself to an new value. Each data object (with a few exceptions, but most) has a getter and a setter method. (I’ll talk about them another time, they’re a little more complex than I’m making out here – in Objective C 2.0 they can be automatically synthesized, and using the code below can create problems). The getter returns an object of the same type as the object you queried: if you want to know the value of an ImageTitle NSString, you call its - (NSString *) imageTitle; method. If you want to set an object to a value, you would pass it a string and call its - (void) setImageTitle: (NSString*) title; method. This means that you could, for instance, restrict access: a -(int) salary; method might want to check whether the user is allowed to view that information (stupid example, but I’m lacking a better one right now), whereas a setter can check whether a value fulfills certain conditions (checking whether a proposed password contains numbers) before proceeding.

Object classes have a public interface – the bit where you can see their instance variables, their outlets and action methods, and their methods. [I sincerely hope that's all]. (This is the .h file.)They also have an implementation (in the .m file): and as long as you return the expected values, it doesn’t matter by which route you arrive there.

The Virtual Zoo should include a ‘calculate my route’ button, where visitors can say how they want to spend their day. The idealRoute class will contain a - (void) calculateIdealRoute: (NSArray*) desiredStops; method that takes an array of places a visitor wants to see and calculates a route through the zoo based on that information. There are dozens of ways that the input can be calculated – the user might just click on a map, or choose from dropdown menus, or answer a number of questions (such as how much time they have and whether they’ll want icecream or hot food at lunchtimes) – and dozens of ways of calculating a perfect path. This does not matter as long as the class takes the input – however it was derrived – and spits out a result (whatever form that result takes and however it was calculated).
You can start with a simple implementation – you can start, in fact, with a manual list of input if you want to test the calculation or with an unordered list of ‘first go to a, then go to b’ if you want to test the input mechanism. The aplication as a whole will continue to work. This means that you will be able to make _a lot_ of changes to an application before breaking it.

The MVC model is one of the central tenets of Cocoa programming, and for good reasons. A good Cocoa application separates the Model layer (data) from the View (the way it is displayed) and the Controller (the layer that handles how the two interact. This means that you can, again, separate them. Apart from the usual benefits of being able to reuse code and switch out individual bits and test them in isolation it also means that you can perform manipulations of data without displaying it. You can search for a certain string in a bunch of files and display the lines that contains the search string, and only load and display the file if the user clicks on it. Furthermore, adding different interface controls becomes a trivial matter: if you decide you don’t just want a ‘list animals’ menu item but that you want to provide a button, too, you connect the button (‘outlet’) to the controller’s ‘list animals’ method (‘action’) and bingo.

So how does this work in reality? One piece of functionality I want to add to the Virtual zoo is that any time I load a picture – in any location – I want to automatically add Copyright © Virtual Zoo 2011.

And here’s the first point of encapsulation: you don’t want to add Copyright © Virtual Zoo 2011 – you want to add NSString * copyrightMessage which, in turn, is composed from @"Copyright ©" + copyrightHolder + copyrightYear. Maybe you’ll open a branch, the Virtual Deerpark, or Zoos all over the world love your application and want to buy it, so you need to give them the opportunity to read copyrightHolder from a preference file.

Next step.
Conceptually, there are two ways of achieving this goal: one would be to _add_ the text to the image, save the new image, and use the result in the display (admit it – probably the first thing you thought of, definitely the first thing *I* thought of); while the other is to _display_ the copyright notice on top of the image in a separate view layer. The master encapsulator will choose the second version: the first one creates new data to be stored (your picture store will double, and there are *a lot* of animals in the zoo) while the second recreates a result from original objects only when needed. In general, you need very good reasons *to* store results; recalculating them according to stored rules tends – for most applications – to be not measurably slower, and saves disk space and memory. I’m taking Apple’s word for the performance aspect, but storing data several times is a bad move:

Adding text to an image is final, and if, next year, you decide that you don’t like the result (or if your company expands and you’re now the Virtual Zoo and Botanical Garden), the first method leaves you with the task of redoing all images again. (This, however, would be another example of encapsulating: you’d do the image manipulation without actually displaying the results, just as a background batch conversion.)

So when would you want to create the image-with-notice as opposed to just displaying the notice on top of the image? Any time you want to export an image out of the application. Why would you do that? Even if you have no idea, you can create an ‘exportableImage’ class that returns the flattened image. You don’t need to know who is going to ask for that image; just that you’ll provide one. And you can start with a simple method (position copyrightMessage automatically in bright green in the bottom righthand corner). Once you’ve finished all other programming tasks, or if the appearance bothers you, you can modify it: turn copyrightMessage into an NSAttributedString that the user can change, for instance, until it’s readable. Or offer the ability to drag the message around so it can appear anywhere on the image. Or maybe you want to add a sophisticated ‘invisible’ key signature to the image. Doesn’t matter: all you need to do is modify the exportableImage class accordingly. As long as the code itself works and - (id) exportableImage; returns an image, you’re golden.

Maybe I am doing the authors of the ‘here are seemingly random pieces and you’ll make sense of them at the end’ resources a disservice: maybe their brains *do* work like that. Maybe it *is* possible for them to learn how to do one example and then turn it into something else. Maybe they would feel the same frustration in reverse if they had to start programming my way, with high-level concepts working down to the nitty-gritty of message sending.

Since most of my problems seem to have stemmed from encountering materials that do not cater to my learning style, maybe the greatest danger here is to assume that everybody learns like I do; that my explanations and my journey through the programming process are _better_ than what has gone before, instead of merely radically different to most. If everybody adopted _my_ model, people who don’t learn like me will feel just the same frustration and bang their heads against their own walls.

I can’t promise I’ll stop ranting about the people who make programming needlessly difficult or who discourage would-be learners by telling them that this is the one and only way, that everybody learns to program like this (and if you can’t learn it this way, you’re either not working hard enough or you’ve got no talent and ought to find another hobby). That assumption – my way or the highway – is, at best, based on ignorance of learning styles and of the fact that there *is* another way to approach programming, and at worst exclusive and elitist, but I would serve the cause – making programming easier – badly if I comitted the same error in the opposite direction and made anyone else feel stupid for not learning the way *I* do.

I’ve spent more than a year banging my head against various walls, being told that progamming is insanely difficult, and being made to feel stupid for not getting it. The only reasons I haven’t given up were that a) I have an application I want to realise, b) I am bloody stubborn, and c) I *know* that I’m a good application developer, just not – as yet – a good _Cocoa_ Application developer.

In that process of trying to learn and banging my head against walls, I’ve vented my frustrations frequently, and I am *still* frustrated at the fact that despite the maturity of Cocoa (and Nextstep before it) the only book that seems to vaguely cater to my learning style was published in 2010 and, as a beginner, all the resources I’ve encountered made learning to program – a topic that’s complex and not without pitfalls – twice as hard and far more frustrating than it needs to be. I feel I can be forgiven for venting my frustrations but – in the light of understanding the root cause of my difficulties – I need to ensure that I move forward in a positive manner.

Gosh, this post includes a lot of banging my head against walls, but that’s what it felt like – everywhere I turned, I encountered oblique code, bits that didn’t make sense, and a complete lack of explanations that would help me to design my own applications. I could probably find other words, but this phrase expresses my frustrations very well. I shall attempt to use it less in the future.

This morning I had another ‘I could have had this easier’ moment that makes me want to scream with frustration: I reached ‘Adding Behaviour to a Cocoa Program‘ in Apple’s Cocoa Fundamentals Guide.

This section covers the question of what programmers are trying to do, and answers it in a conceptually different form: Instead of incorporating library code into your program [as you would in a procedural C application], you incorporate your program code into the framework.

Well, duh. If this had been the first thing I had encountered I could have saved myself a lot of frustration and scrambling about. It’s on page 351-of-699 in the ebook edition, and comes after the substantial ‘Cocoa Objects’ section in that guide, and while I’ve managed to puzzle together much of what this section actually _says_, we’re back with Not RocketScience: this is the fundamental underpinning that I need in order to understand how applications work and what a programmer _does_.

Writing a Cocoa Application is conceptually completely different from old-school programming; it’s also a process that’s resonating a lot more with my learning style (I’m a Gestalt learner rather than procedural), and while I haven’t worked through the whole section yet, I’m already having moments of ‘oh, so *that’s* what’s going on’.

And ok, it’s hiding in plain sight – the guide IS called ‘Fundamentals’ and if you take time to read it, you’ll reach this bit – but only after wading through a lot confusing things that will go over your head and make you reach for introductory texts.

I’ll go as far as to say that without understanding _ad abstractum_ how a Cocoa application works and what it does, nobody should attempt to write one. (The problem is that it’s possible to write perfectly reasonable applications without this knowledge – Cocoa makes it easy to just plug in stuff into the framework, and countless tutorials encourage the habit, but you’ll only get so far, and either screw up or put together something that’s suboptimal. My goal is to write a _good_ application, not just one that works, sort of.)

What I’m proposing is that would-be developers should engage with the theory first – understand what this framework is and what it does that they’re hanging functions upon – before doing the actual writing-of-functions. What have you learnt from following a ‘My First App’ tutorial? That’s it’s very easy to write an application if you know what you’re doing and that Apple gives you a lot of features for free. That’s good and reassuring to know… but it doesn’t actually _help_ in learning how to program.

Most experienced Mac users will already know most of this stuff: they know how an application works, they know how users interact with them, they know the common controls, they know – because they have seen them – many common functionalities, like the built-in text handling capabilities.

Using a Gestalt approach means that you take an in-depth look at what a Mac application is from the point of view of the computer, and where it has hooks you can hang your custom code and custom functionality on.

And THEN you delve into learning how to actually do this, but that shall be the subject of another post.

Having tried the procedural approach, where you learn stuff from the bottom up and put it together (I never got that far, I was missing far too many fundamental concepts) I am now attempting to try the Gestalt approach: first, get the overview and understand what I’m doing, then understand the concepts of individual aspects, then delve into the mechanics of those bits.

So, my first step right now is to understand how a Cocoa application works from a programming point of view. Next, I’ll work out application design – how *do* you put all those various things together? This will involve an in-depth understanding of design patterns – how objects get passed from one part of the application to another, which class is responsible for keeping track of information, how user input is processed. And last but not least, there will be function design, which involved Objective C syntax and how to deal with all potential user events and what the relevant bits of the Cocoa framework actually do and how I make use of them/override them.

At the end of that, I should have a working application that’s also well-designed.

I’m posting this as a mainstream post instead of merely as code snippets because I want to talk about the _conceptual_ side of text-in-Cocoa. Apple might have a long and detailed guide but, as usual, it helps me to work these things out myself.

Firstly, _storing_ text is relatively simple and has low overheads. Text files are small compared to image files, video, music, and whatever.
_Displaying_ text, on the other hand, takes up a fair amount of computing power, because in a modern OS the text is transformed into glyphs – vector files that determine the shape of each letter – and then displayed. Back in the day of bitmap display fonts, the overheads were lower (and the displays much uglier).

Text handling falls into three broad categories:

• Manipulating text strings (including storage)
• Text Attributes
• Displaying Text

An NSTextView created in Interface Builder has a NSTextContainer (the rectangular area text is displayed in), an NSTextStorage object and an NSLayoutManager created automatically. Understanding their basic functionality is the basis for deciding when (or whether) to subclass them (eg, when you want your text container non-rectangular.).

I’m mentioning this because it helped me to understand how the various things I mention below fit into the grander scheme.

Text is stored as a string of characters, encoded by one of several methods (UTF8 being the most common). For the most part, it will be of type NSString (and subtypes), and when you’re handling text in files that’s usually what you will use.
NSTextStorage forms – as mentioned – part of an NSTextView; Apple refers to it as the storage layer: it contains an NSMutableAttributedString (and is, in fact, a subclass of NSString and thus responds to its many methods which allow the manipulation of text strings: you can find the length, break a sentence into words, insert one string into another, etc etc.

Attributed text has several functions. One is to aid the reader directly – they might have a preference for serif or sansserif fonts, might need a large text size or a particular colour combination to improve their reading experience. The other is to emphasize parts of a text (bolding or red for negative numbers) or otherwise structure it. (italics for thoughts, particular formatting to indicate code as opposed to explanatory text).

For a more detailed overview of setting font attributes, see Setting Font Attributes

I came across a chance mentioning of NSLayoutManager, which – until today – I had not even heard of. (The two books I have at hand right now – Trent/McCormack and Clair – don’t mention it explicitly. Fun.) Apple’s Documentation has plenty of details, and it turns out that as soon as you scratch the surface, text handling is wondrous and fascinating and far more complicated than it looks. (This post relies heavily on Apple’s explanation.)

• NSTextStorage (a subclass of NSMutableAttributedString: holds text attributes such as style etc)
• NSTextContainermodels the geometric layout on the page

NSTextView (or another NSView-type object) provides the view in which the text is displayed; I am not entirely certain where NSTextContainer (the rectangular display area) fits into this; an NSTextView (see above) seems to be a cluster of things.
In a scrollable view, the size of the display area can be larger than the size of the window (text view, etc).

NSLayoutManager (according to this article on subclassing it is the class that creates and returns the accessory view containing these common controls [eg the 'ruler' you can show in so many Mac Apps, which in turn allows for, well, layout control: justification and tabstops and styles.])