iOS Need help with a UITextField method *help*

iJustinCabral

macrumors member
Original poster
Jul 8, 2012
58
0
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

Code:
 - (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

macrumors member
Mar 27, 2012
95
0
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

macrumors G3
Nov 26, 2007
8,579
4,019
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

macrumors member
Original poster
Jul 8, 2012
58
0
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

macrumors 68030
Jan 19, 2006
2,761
0
Sydney
You could also test the the Length of the string.

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

chown33

Moderator
Staff member
Aug 9, 2009
8,562
4,635
inter-prandial
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.
 

ArtOfWarfare

macrumors G3
Nov 26, 2007
8,579
4,019
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

macrumors 68030
Jan 19, 2006
2,761
0
Sydney
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
 

chown33

Moderator
Staff member
Aug 9, 2009
8,562
4,635
inter-prandial
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

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
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:

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.