CrazyMusician » 2007

You may have noticed an increasingly large amount of posts from me lately about various Cocoa eccentricies, etc. Well, it is more than just playing around. I’m laying the groundwork for an application called StudioMan (short for Studio Manager), which will aid private music teachers in organizing their student records and scheduling studio time.

Planned features for version 1.0:

Consolidation of student, instructor, and accompanist info in one convenient place
Automatic creation of studio schedules using user-supplied schedules for instructors, students, and accompanists.
Student repertoire listing
Import current students/accompanists into new academic terms
Allows import and export of Address Book (vCard) and iCal (vCal) files, to allow integration with Apple iCal/Address Book

I haven’t yet decided whether I want to make this project Panther-compatible or not. I like the lifecycle-management of Core Data, but it some ways I think it’s more complicated than it needs to be. For now I’ve set up a data model as well as made data-object shells, so hopefully if I start working in one and realize I need to switch to the other, the impact will be minimal. The project will obviously be Universal Binary, as there’s no real need to go Intel-only at this point.

I’ll be setting up a new website for the project shortly, as well as some sort of version control mechanism. I haven’t decided on licensing yet. It will probably be GPL, but I’m not going to make a decision until I do some more research into the matter.

Comments (0)...

Core Data gotcha posted at 7:01 PM

computers

OK. So, here’s the deal. Let’s say I have two entities: Person and Name. Person has relationship name to Name. Person has attributes x,y,z. Name has attributes a,b,c. I have one table set up to show all Persons, with text fields to show the contents. x,y,z show fine in the text boxes, but one of them is supposed to be for the a property of the Name entity that has a relationship with the person entity. So, using common sense, I set the binding key path to name.a.

Nothing.

Any ideas?

Comments (2)...

Objective-C memory management, session 1 posted at 10:05 AM

computers

So, I’m having a bitch of a time with Cocoa releasing objects when I’m not expecting it to. I thought I had it figured out, but apparently I am wrong. Can one of you lovely Cocoa people run me through my code and see what the hell I’m messing up? It’s really getting on my nerves.

//edit: OK, so I have it figured out enought that it won’t crash, anyway, by throwing a few retains in. I wish I could figure out when these objects are getting their release messages, so I could figure out exactly why they’re being prematurely released, and so I know I’m not overdoing the retains and creating memory leaks. Garbage collection much?

Comments (4)...

Comment by Colin:

February 14th, 2007 at 11:24 am

it’s really simple

(1) Anything you alloc do a release or auto release, ex

NSMutableArray *myArray = [[NSMutableArray alloc] init];

[myArray addObject:@"Testing 1"];
[myArray addObject:@"Testing 2"];

//do something with array

[my array release];
//or
NSMutableArray *myArray = [[[NSMutableArray alloc] init] autoRelease];
//or just call auto release anytime on the object
[myArray autorelease];

(2) Anything you alloc in the init or awakeFromNib method of a class you’ll need to release in the dealloc method, also it’s considered good programming to set any pointers to nil, ex and call [super dealloc];

- (void) dealloc
{
nc = nil;
defaults = nil;
lastUniqueId = nil;
[filterPredicateString release];
[currentAssignments release];

[super dealloc];
}

//

Objective-C currently operates on the retain/release principal with reference counting. If you need to keep a object around then do a [object retain] call on it and it’ll keep it in memory. As soon as an objects retain count goes down to 0 it’s deallocated.

Well sometimes memory management can be a bit complicated but it just depends on what your doing. Remember you can always do a NSLog and see what an objects retain count is.

Or you can wait for Leopard and Garbage Collection

Comment by Colin:

February 14th, 2007 at 12:17 pm

Oh I forgot I also use MallocDebug to find memory leaks and ObjectAlloc ( http://www.cocoadev.com/index.pl?ObjectAlloc ) can help you track memory allocations, both are excellent tools

Comment by Nick:

February 14th, 2007 at 2:26 pm

Well, see, I understand the basic concepts behind it… what was happening is that objects were being released without me realizing it, causing crashes.

I’ve been using NSMutableArray *myArray = [NSArray array] to create the initial array with no members, and myArray = [myArray addObject:anObject] to add to it. I ended up needing to put a retain on the original array when I created it, and also needing to put a retain on a NSString that’s a member of the object I’m putting into arrays. The array retain is the one that really confuses me, because I’m seeing no place that the array should be sent a release message.

Comment by Colin:

February 14th, 2007 at 5:11 pm

wait first thing i notice

NSMutableArray *myArray = [NSArray array]

You’d be the first to actually use it that way. The documentation on this method isn’t great because I don’t know how the array is allocated and initialized. The documentation only says “Creates and returns an empty array.” Because of this I’d stray away from this method.

Do it this way

NSMutableArray *anArray = [[NSMutableArray alloc] init];

//do stuff here

[anArray release];

i’ve had absolutely no problem doing it this way and you can always change the init code in the future. In fact every array you create should be created like the above example or be created like

return [NSArray arrayWithObjects: obj1, obj2, nil];

for temporary arrays that are used in methods for things like toolbars, etc…

Chances are if your going to create arrays like that theres a specific reason for doing so and your probably very familiar with NSMutableArray behaviour. Im a little confused why Apple put this method in the documentation this way because it’s nothing but confusing.

I don’t know how much you’ve been working on Cocoa stuff, but trust me you should just get used to alloc] init]’ing everything initially for a while till you know all the behaviours of the classes or the other method has a performance or some speciality need to call it.

There are instances where sometimes Apple isn’t clear on things. For the longest time I thought using NSEnumerators on arrays and modifying them was ok, but it turns out when enumerating through an array NSEnumerator actually does a copy of the object it’s enumerating through which makes modifying objects on the fly with NSEnumerator unsafe and can lead to unpredictable behaviour.

Trust me just do it the nice and easy way first then experiment and merge