Is there a way to automatically tie a UITextField

Question

I'm building up a view controller where I'm adding a bunch of UITextFields to my view programmatically. I want to pre-populate the textfields with some text that I'm loading from CoreData, but allow the user to go in and change that text if they want. I then need to go back and save that new text back to CoreData again, as well as perform calculations using the new value. The saving and loading itself isn't a problem, but I'm looking for a good way to track what the user has changed.

In the past, I've done this with the .tag property of the UITextField and the textFieldDidEndEditing: delegate method. The problem is I'm going to have dozens of textfields in this view - enough so that I can't really remember what .tag belongs to what variable in my model. Having to go back to look up what tag I assigned when I created it is going to be a pain, and the whole thing feels really error prone. Additionally, I'm going to be creating the textfields in multiple different loops, so getting a unique tag for each textfield when I create it will be difficult (maybe impossible?).

What I'm looking for is a way to "tie" the UITextField to a variable in my model when I create it and just know from that point on, whenever the user updates that textfield, the value I specify in my model will be instantly updated to be used in future calculations, and saving back to CoreData when the user leaves the screen. Is there a way to do this?

EDIT 1: Another thing to note is that my model itself is kinda complex. I have several different custom NSObject subclasses that are all holding different pieces of my data. Some of the objects have properties that are themselves other custom objects. I also have dictionaries where the values will be instances of some of the custom objects.

As an example, I might have these objects:

• MySmallObject1, which has properties name,size, and value (all NSStrings)
• MySmallObject2, which has properties date and cost (an NSDate and an NSNumber)
• MyBigObject, which has properties box1 and box2 (which are MySmallObject1 and MySmallObject2 instances, respectively)
• theDict, which is an NSDictionary instance that has MyBigObjects as values

So when I am building my textfields, I might actually be going down a tree that would look something like:

for (NSString *key in [theDict allKeys])
{
    UITextField *txt = [[UITextField alloc] initWithFrame:...];
    txt.text = [[(MyBigObject *)[theDict objectForKey:key] box1] name];
    [self.view addSubview:txt];
}

In this case, I need to know when the user changes the text in any of the txt and update the appropriate value through the tree.

EDIT 2: While trying to implement @Till's suggestion in the comments, I started reading a tutorial on pointers in C. It seems like this is the way I need to go, but I'm struggling to get the & and * from the C world to play nicely with the NSObject subclasses I mention in my last EDIT from the Objective-C world. To get @Till's suggestion to work, I think I need to somehow store the memory location of my value up that complicated object tree. So my code block from the last EDIT would become:

.h
@property (nonatomic, strong) NSMutableDictionary *tagDict;

.m
for (NSString *key in [theDict allKeys])
{
    UITextField *txt = [[UITextField alloc] initWithFrame:...];
    txt.text = [[(MyBigObject *)[theDict objectForKey:key] box1] name];
    txt.tag = globalCounter;
    [tagDict addObject:[[(MyBigObject *)[theDict objectForKey:key] box1] name] forKey:[NSString stringWithFormat:@"%d",globalCounter]];
    globalCounter ++;
    [self.view addSubview:txt];
}

Where globalCounter is an int that I'm incrementing every time I put something into tagDict so I can keep it unique. I guess in this case I could just simply be using an NSArray and it would work just as well, and probably look a little cleaner. My plan is to use tagDict in my testFieldDidEndEditing like:

- (void) textFieldDidEndEditing:(UITextField *)textField
{
    *[tagDict objectForKey:[NSString stringWithFormat:@"%d",textField.tag]] = textField.txt;
}

This throws an error for Assigning to 'id' from incompatible type 'NSString *'. I'm not really sure what that means. Is there a way I can use a "dereferencing operator" to change the value of the item I am pointing to in my dictionary?

throws an error Address expression must be an lvalue or a function designator. I'm still a little fuzzy on how this pointer stuff would work in the Objective C world, and I think there's something I'm not fully understanding.

Answer 1

You could use your original approach with the .tag , but use typedefs.

typedef enum TFTypes {
    TFModalType1,
    TFModalType2,
    TFModalType3,
    TFModalType4,
    TFModalType5,
    ...
} TFType;

Answer 2

You can use UITextField+blocks it may be less entangled. And it will be much easier if objects have similar interface or implement one protocol with method like setText: .

Answer 3

I ended up doing largely what I think @Till was trying to suggest. I added an NSMutableArray *tieArray and an int tieCounter as @properties to my view controller. My code for building the UITextFields from the first code block in my OP is now:

for (NSString *key in [theDict allKeys])
{
    UITextField *txt = [[UITextField alloc] initWithFrame:...];
    txt.text = [[(MyBigObject *)[theDict objectForKey:key] box1] name];
    [self.view addSubview:txt];

    txt.tag = self.tieCounter;
    self.tieCounter ++;
    [self.tieArray addObject:[[(MyBigObject *)[theDict objectForKey:key] box1] name]];
}

Then in my textFieldDidEndEditing

- (void) textFieldDidEndEditing:(UITextField *)textField
{
    if ([tieArray objectAtIndex:textField.tag] isKindOfClass:[NSMutableString class]])
    {
        [(NSMutableString *)[tieArray objectAtIndex:textField.tag] setString:textField.text];
    }
    else if (//...More conditions to set other variable types with the syntax as needed)
}

Note that for this to work, all the properties of MySmallObject1 and MySmallObject2 need to be covered by a isKindOfClass: check, and the actual syntax will vary a little depending on what class that property is.

I haven't been able to test this yet (and my app probably won't be in a testable state for quite some time), but it makes sense to me, and it's not throwing any errors or warnings. If I have problems with it when I actually run it I'll update here.