CoreData
I just think that declaring a variable name 3 times is just cumbersome for "default" behavior. I mean for non default behavior it makes perfect sense. Say somebody want to implement their own special getter or setters.
It is cumbersome. Unfortunately, that's how Obj-C works. It's not particularly different than other programming languages of it's era that are C derivatives (e.g., C++). More modern programming languages (C#, Java) have a single file containing the full interface and implementation, while yet other programming languages are completely dynamically message based (Smalltalk, Ruby, Python). Get over it - it's the price to play in the game.
You're making it worse than it is by not exactly demonstrating a complete understanding of WHAT you're trying to accomplish.
a) The member variable in the class definition defines a member variable. It doesn't have to have a property associated with it, it's just part of an object's data.
b) The property statement in the @interface section declares an EXTERNAL interface for getter/setter methods on a member variable (or with readonly, only a getter is created). One key thing you're missing is that you don't have to have a member variable with the same name declared separately. If you have a "property int bob;" and no bob member is in the class, one is created for you, for free.
c) The @synthesize statement in the @implementaton section creates 2 methods (again, 1 if readonly is used) to implement the getter and setter.
You don't need the @synthesize either, as long as you implement the getter and setter methods yourself. Using bob as the example, @synthesize bob; becomes the equivalent of:
Code:
-(int) bob
{
return bob;
}
-(void) setBob:(int)anInt
{
bob = anInt;
}
d) The final ones (in dealloc) are caused by your own use of retain as a property modifier. You chose to retain the instances, hence you created the problem so you should clean it up. Perhaps you don't have a very clear understanding of memory management in Obj-C?
If this confuses you, read the documentation. If you need to have someone explain it to you, then go into iTunes U and download the Stanford iPhone programming courses. They're very good.
The next question is that district should be a collection or an array. One "Badger" can contain several districts. How would I go about this?
I don't know. Answer these questions:
- Does order matter?
- Does the list of districts change over time?
- Are all districts equivalent (i.e., instances of the same class)?
Surely you must already know the answer to these since it feels like you're porting an application. Read the Collections guide and pick one that matches your needs.
I will need samples of well written classes
They're available on the developer website, provided by Apple. Start reading the documentation, it will help.
People here are good about answering questions, but nobody here is going to write your code for you. If you don't understand HOW Obj-C works (which I don't think you do yet), you will struggle with everything iOS related - they are two sides of the same coin. Slow down, take some time to learn WHY you're writing that code instead of just copy/paste (as I said, the Stanford courses are very good) and come back with a question that demonstrates some understanding. When you run into a roadblock, we'll help you get past it.
Ron C
