iOS How to have user create class instance

[Abrexas]

Hey guys,
I really feel like I am drawing a blank over something very obvious, but I've been stuck for some time.

Say I have a class:

#import <Foundation/Foundation.h>

@interface Person : NSObject
{
     NSString *name;
     NSInteger *age;
     NSInteger *weight;
}
@end

With appropriate getters and setters. Now hardcoding a "person" is hella simple. But I need the user to be able to create new instances of the person class. I feel like this would be easier in java since I have a better understanding of constructors in java.
How I assume it would go, is that I could have the user fill in various text fields of the desired input, and then on button click fill a constructor with said data. But I don't see where I will [alloc] the data.

By just using the getters and setter I can do this easily, as long as I have already hard coded the initiation of the class.
IE:

Person *Mike = [[Person alloc]init];

And then filling the rest via button click and such.

Can someone tell me how to let the user create the whole thing?
Thanks

 

[dejo]

I would make an init method that takes values for your three instance variables. As in: initWithName:age:weight:

 

[ArtOfWarfare]

You would allocate and init the new instance inside of the method that gets called by the button press. I'd suggest then adding it to a collection like an NSMutableArray or something so you can refer to it elsewhere. IE:

(IBAction) createClicked:(UIButton *)button {
    Person *p = [[Person alloc] init];
    p.name = nameField.text;
    // Other properties get set here...
    [peopleArray addObject:p];
}

dejo's suggestion to use an init method that takes initial values is also a good one, as that is, after all, the purpose of an init method...

Quick aside: is it actually necessary to call an init after every alloc? It seems to me that alloc aught to initialize the allocated memory to some sort of blank state and that calling an init with no arguments aught to be a waste of a call? Does the compiler get rid of this waste of a call for you, or am I mistaken in thinking it's a waste?

 

[Duncan C]

You would allocate and init the new instance inside of the method that gets called by the button press. I'd suggest then adding it to a collection like an NSMutableArray or something so you can refer to it elsewhere. IE:

(IBAction) createClicked:(UIButton *)button {
    Person *p = [[Person alloc] init];
    p.name = nameField.text;
    // Other properties get set here...
    [peopleArray addObject:p];
}

dejo's suggestion to use an init method that takes initial values is also a good one, as that is, after all, the purpose of an init method...

Quick aside: is it actually necessary to call an init after every alloc? It seems to me that alloc aught to initialize the allocated memory to some sort of blank state and that calling an init with no arguments aught to be a waste of a call? Does the compiler get rid of this waste of a call for you, or am I mistaken in thinking it's a waste?

Objective C uses 2 step object creation. Alloc simply allocates the memory for the object, but does NO initialization. Allocating an object but not initializing it leaves it in an undefined state. Do not do that.

To the OP, alloc/init is the equivalent of constructors in Java or C++.

As the other poster suggested, you simply need to add logic in your button action that creates a new object, saves it somewhere like an array, and presents it to the user. The details depend on what these objects mean to the user. The details depend on what the objects are and how you represent them in your UI.

A user interface that manages a table view and has a "+" (add) button creates new model objects in response to the user clicking the "+" button, adds those objects to the data model, and then updates the table view to display the new model contents.

 

[dejo]

Quick aside: is it actually necessary to call an init after every alloc?

Yes, it is.

It seems to me that alloc aught to initialize the allocated memory to some sort of blank state and that calling an init with no arguments aught to be a waste of a call?

It's not a waste. Initializing the allocated memory is init's job; hence, the name. alloc is pretty much the same regardless of the class; whereas init can vary depending on the class of instance it is working with. This two-step approach also allows you to define a number of init "vectors" for your class, such as UIView's initWithFrame: and initWithCoder:.

 

[Abrexas]

Thank you all for the feedback. My problem with doing it in the button pressed method is that every time I click the button it would create a new Person *p.
I am storing multiple people into an array, and when I tried doing this it didn't work. Even if the first button press and the second button press had different information like name and such, since the class variable name was always p, the array would just fill multiple times with the latest declaration of p. Am I doing something wrong or do I need to go about it in a different way?

 

[dejo]

My problem with doing it in the button pressed method is that every time I click the button it would create a new Person *p.

That's what you want, right? Press button to create a new person => new Person created.

I am storing multiple people into an array, and when I tried doing this it didn't work. Even if the first button press and the second button press had different information like name and such, since the class variable name was always p, the array would just fill multiple times with the latest declaration of p. Am I doing something wrong or do I need to go about it in a different way?

Without seeing your code, we can't tell if you're doing something wrong. Show us the entire button press method, as well as any code that adds your Person to your array.

 

[Abrexas]

I didn't take the time to test it with a button. I did something more on the lines of

Person *p = [[Person alloc]init];
p.firstName = @"Steve";

NSMutableArray *testArray = [[NSMutableAray alloc] init];
[testArray addObject:p];

p.fiestName = @"Greg";

[testArray addObject:p];

NSLog(@"@%",testArray);

And the result of that being {Greg, Greg}

Note: this isn't actual code. My program uses a lot more variables, but this is a simplified version of the problem I am having.

 

[Duncan C]

I didn't take the time to test it with a button. I did something more on the lines of

Person *p = [[Person alloc]init];
p.firstName = @"Steve";

NSMutableArray *testArray = [[NSMutableAray alloc] init];
[testArray addObject:p];

p.fiestName = @"Greg";

[testArray addObject:p];

NSLog(@"@%",testArray);

And the result of that being {Greg, Greg}

Note: this isn't actual code. My program uses a lot more variables, but this is a simplified version of the problem I am having.

Look at what your code does. You create a person object and set it's first name to "Steve". Then you create an array and add that object.

Then you change the first name of that person object to "Greg" and add it again. You now have 2 pointers to the same person object in your array, and you've replaced the first name with "Greg". So your array now contains 2 pointers to the same object, with a first name of Greg.

Your code should look like this instead:

NSMutableArray *testArray = [NSMutableArray arrayWithCapacity: 4];

Person *personA, *personB, *personC, *personD;

personA = [[Person alloc]init];
personA.firstName = @"Bob";
[testArray addObject: personA];

personB = [[Person alloc]init];
personB.firstName = @"Carol";
[testArray addObject: personB];

personC = [[Person alloc]init];
personC.firstName = @"Ted";
[testArray addObject: personC];

personD = [[Person alloc]init];
personD.firstName = @"Alice";
[testArray addObject: personD];

NSLog(@"@%",testArray);

(Code cleaned up to use all 4 temp variables personA - personD)

Note that you should add a method description to your person object that looks something like this:

- (NSString *) description;
{
   NSString *result = [NSString stringWithFormat: @"first name = %@, last name = %@, ssn = %@", 
   self.firstName, self.lastName, self.ssn];
}

If you do that, logging an array of person objects will invoke the description method of each Person in the array.

(Note that you'll have to change the code above to log the real properties in your Person object. I used firstName, lastName, and ssn as an example.)


In the first block of code above I used 4 different variables, personA through PersonD, for clarity. I could just have easily used the same variable, aPerson, and overridden it with a new object after adding each object to the array:

Person *aPerson;

aPerson = [[Person alloc]init];
aPerson.firstName = @"Bob";
[testArray addObject: aPerson];

//Replace the old person object with a newly allocated one:
aPerson = [[Person alloc]init];
aPerson.firstName = @"Bob";
[testArray addObject: aPerson];

NSLog(@"@%",testArray);

 

[Abrexas]

Person *aPerson;

aPerson = [[Person alloc]init];
aPerson.firstName = @"Bob";
[testArray addObject: aPerson];

//Replace the old person object with a newly allocated one:
aPerson = [[Person alloc]init];
aPerson.firstName = @"Bob";
[testArray addObject: aPerson];

NSLog(@"@%",testArray);

Exactly what I meant by drawing a blank about something obvious haha. Thank you!
Unfortunately I am doing homework on my windows partition so I cannot go check my code out. I know that I am later comparing things to my arrow of object, and having multiple objects may pose a problem when doing so. However I might have made my code to compare the contents of the objects int he array, int hat case your method would work fine.
If there a way that you know of to dynamically create a new instance of the class with an original name?

Either way, thank you very much for the input!

 

[dejo]

If there a way that you know of to dynamically create a new instance of the class with an original name?

How about something like?:

aPerson = [[Person alloc] initWithName:nameField.text];

(You'll have to create the initWithName: method.)

 

[Abrexas]

How about something like?:

aPerson = [[Person alloc] initWithName:nameField.text];

(You'll have to create the initWithName: method.)

With doing that it seems I would still be adding "aPerson" to the array. Or is there a way to make a method that changes the instances name?

I got around to testing the previous method and it works flawlessly with my code. So thank you all! Still curious for learnings sake on the whole original name thing, but the problem is solved!

Thanks!!
- Steven French

 

[dejo]

With doing that it seems I would still be adding "aPerson" to the array. Or is there a way to make a method that changes the instances name?

I'm not sure I understand. Why do you want to change the instance's name?

 

[Abrexas]

I no longer need to. I thought I did before because I had completely overlooked re-allocating before. Now I am just curious to see if it is possible.

 

[Duncan C]

With doing that it seems I would still be adding "aPerson" to the array. Or is there a way to make a method that changes the instances name?

I got around to testing the previous method and it works flawlessly with my code. So thank you all! Still curious for learnings sake on the whole original name thing, but the problem is solved!

Thanks!!
- Steven French

You have a conceptual misunderstanding. A local variable or instance variable for an object is a pointer to an object of that type. You can store any object of that type there. That variable is not a unique ID of an object that always points to the same object

Person *aPerson;

aPerson = [[Person alloc] init]; //Creates a person object 

//Do something with with aPerson 
aPerson = [[Person alloc] init]; //Creates a NEW person object

Don't think of the variable name as the "original name" of the object. It's not. Think of a variable as a slip of paper with somebody's phone number written on it (in pencil). Erase the number and write a different number on it. It's still the same piece of paper (variable) but not it points to a different person.

 

[Abrexas]

Yes I understand this now. That was the obvious detail that I was asking over before ^_^
I had just been using in my code, id's that mean something about the class so that it was easier for me to see what was going on. As I mentioned, I understand how to do what needs to be done now because of your posts. I was just curious still for no reason.

Again, thanks for the help! ^_^

 

[iphonedude2008]

Yes, it is.


It's not a waste. Initializing the allocated memory is init's job; hence, the name. alloc is pretty much the same regardless of the class; whereas init can vary depending on the class of instance it is working with. This two-step approach also allows you to define a number of init "vectors" for your class, such as UIView's initWithFrame: and initWithCoder:.

If it is a direct subclass of nsobject then yes it is a waste of time. Nsobject's init method looks like this

- (id) init 
{
return self;
}

so it is not doing anything.
Other wise you should call init

 

[dejo]

If it is a direct subclass of nsobject then yes it is a waste of time. Nsobject's init method looks like this

- (id) init
{
return self;
}

so it is not doing anything.
Other wise you should call init

Sure, that may be, but it is a good habit to get into anyways. And besides, perhaps the compiler is able to detect this situation and handle accordingly to avoid unnecessary methods call.

 

[Duncan C]

If it is a direct subclass of nsobject then yes it is a waste of time. Nsobject's init method looks like this

- (id) init 
{
return self;
}

so it is not doing anything.
Other wise you should call init

Hold on a minute. NSObject includes private instance variables like retainCount that must be initialized. The set of NSObject methods and NSObject protocol methods is pretty rich. There may be other private instance variables we are unaware of, even for NSObject.

I bet even NSObject's init method does more than return self. It bet it zeros out other memory, and might even do other housekeeping for the runtime.

If your object is a direct SUBCLASS of NSObject, then YOUR instance variables need to be zeroed out.

In any case, your contract with Objective C says that you should initialize every object after allocating it. Failure to do so may result in undefined behavior.

 

[ArtOfWarfare]

Hold on a minute. NSObject includes private instance variables like retainCount that must be initialized. The set of NSObject methods and NSObject protocol methods is pretty rich. There may be other private instance variables we are unaware of, even for NSObject.

I bet even NSObject's init method does more than return self. It bet it zeros out other memory, and might even do other housekeeping for the runtime.

If your object is a direct SUBCLASS of NSObject, then YOUR instance variables need to be zeroed out.

In any case, your contract with Objective C says that you should initialize every object after allocating it. Failure to do so may result in undefined behavior.

Even if that were the current behavior, it's a private implementation and so subject to change between SDK editions (or wherever NSObject is implemented.)

 

[chown33]

I bet even NSObject's init method does more than return self. It bet it zeros out other memory, and might even do other housekeeping for the runtime.

If your object is a direct SUBCLASS of NSObject, then YOUR instance variables need to be zeroed out.

The +alloc method is guaranteed to return a zeroed object. Check the reference docs.

In any case, your contract with Objective C says that you should initialize every object after allocating it. Failure to do so may result in undefined behavior.

This is the correct reason. I believe it still holds.

 

[Duncan C]

The +alloc method is guaranteed to return a zeroed object. Check the reference docs.

Well what do you know. You're right. Thanks for pointing that out.

The simple fact is, Objective C uses a 2 part object creation, and bad things may happen if you don't initialize an object.

Worse, it might appear to work today, and in some future release of the OS, or on older versions, or different hardware, it might not work.