PDA

View Full Version : Need help with a UITextField method *help*




iJustinCabral
Aug 20, 2012, 05:45 PM
What I'm trying to do is make it so after they press done on the pop up keyboard, if the text is nil...no object is added to the array, but if its not nil then create the object and add it to the array.

Heres the code I have

- (BOOL)textFieldShouldReturn:(UITextField *)textField
{

if (!self.theList)
{
self.theList = [[NSMutableArray alloc] init];
}

Paper *newItem = [[Paper alloc]init];

newItem.listName = textField.text;

if (newItem.listName == nil)
{
[textField resignFirstResponder];
[self.collectionView reloadData];
}

else {
[self.theList addObject:newItem];

textField.text = nil;

NSLog(@"Count %d",self.theList.count);

[textField resignFirstResponder];

[self.collectionVIew reloadData];

}
return YES;
}



Ides
Aug 20, 2012, 06:10 PM
What's wrong with the code you already have? In order for anyone to help you with something, you have to tell us what's not working.

ArtOfWarfare
Aug 20, 2012, 06:11 PM
Why would the text ever be nill?

You should check if the string equals @"" (an empty string.) Actually, there might even be an NSString method to directly test if it's an empty string...

iJustinCabral
Aug 20, 2012, 06:19 PM
I fixed the problem.


I just made an NSString = @"" and then compared my list object to the string and if it was equal then it wasn't added to the array

MattInOz
Aug 20, 2012, 06:52 PM
You could also test the the Length of the string.


if (textView.text.length !=0)
{
//Do Stuff
}

Duncan C
Aug 20, 2012, 07:45 PM
You could also test the the Length of the string.


if (textView.text.length !=0)
{
//Do Stuff
}


Testing the length is MUCH more efficient than string comparison. String comparison is fairly compute-intensive.

chown33
Aug 20, 2012, 08:33 PM
Testing the length is MUCH more efficient than string comparison. String comparison is fairly compute-intensive.

I would be truly astounded if the string-comparison method doesn't test for length equality before comparing character-sequences.

iJustinCabral
Aug 20, 2012, 09:05 PM
ahhh I see. I'll change it up to do that, thanks a bunch.

ArtOfWarfare
Aug 20, 2012, 10:45 PM
I would be truly astounded if the string-comparison method doesn't test for length equality before comparing character-sequences.

How is length determined? I was under the impression that NSStrings weren't much different from C-strings, which would then mean length is determined by checking each character and seeing if it's a \0 or not... If it's going character by character either way, I don't see why length would be any faster?

MattInOz
Aug 21, 2012, 12:10 AM
How is length determined? I was under the impression that NSStrings weren't much different from C-strings, which would then mean length is determined by checking each character and seeing if it's a \0 or not... If it's going character by character either way, I don't see why length would be any faster?

From the Doc's for NSString
The NSString class has two primitive methods—length and characterAtIndex:—that provide the basis for all other methods in its interface. The length method returns the total number of Unicode characters in the string. characterAtIndex: gives access to each character in the string by index, with index values starting at 0.

As a primative method it seem like it needs to fast and cheap.
Also it seems that all NSObjects maintain an Instance size in Bytes* it would seem like the length of the string in characters would be simple function of the size.

Not to mention that to comparing two strings you need two objects where as length is standalone.

*fun reading
MacDevCentre -inside Objective-c runtime (http://macdevcenter.com/pub/a/mac/2002/05/31/runtime_parttwo.html)

chown33
Aug 21, 2012, 12:21 AM
I was under the impression that NSStrings weren't much different from C-strings, which would then mean length is determined by checking each character and seeing if it's a \0 or not... If it's going character by character either way, I don't see why length would be any faster?

A simple test to check this:
1. Create a string of 10 million characters.
2. Create a 2nd string that's the same 10 million characters plus an 'X'.
3. Create a 3rd string that's the same 10 million characters plus a 'Y'.
3. Perform isEqual: across the three strings.

If the length-first hypothesis is correct, it should be noticeably faster when the lengths differ, and noticeably slower when the lengths are the same. Any sufficiently large value would work, 10 million is just an example.

Duncan C
Aug 21, 2012, 07:19 PM
A simple test to check this:
1. Create a string of 10 million characters.
2. Create a 2nd string that's the same 10 million characters plus an 'X'.
3. Create a 3rd string that's the same 10 million characters plus a 'Y'.
3. Perform isEqual: across the three strings.

If the length-first hypothesis is correct, it should be noticeably faster when the lengths differ, and noticeably slower when the lengths are the same. Any sufficiently large value would work, 10 million is just an example.

It seems to me that relying on the optimizations of a class's isEqual method is silly when there is a very clean way to test for an empty string.

The code:

if ([field.text length] == 0)


uses one of the primitive methods of the class directly to test that the string is empty. ANY other call you do (like isEqual or isEqualToString) at a minimum will have to call the length methods on both the field's text and the blank string you are passing in. If it is a naive implementation, it could be much, much worse.

Finally, checking that the length == 0 is really easy to read and maintain.