iOS Need help with a UITextField method *help*

[iJustinCabral]

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]

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]

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]

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]

You could also test the the Length of the string.

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

 

[Duncan C]

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]

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]

ahhh I see. I'll change it up to do that, thanks a bunch.

 

[ArtOfWarfare]

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]

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]

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]

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.