add new row to a uiTableView - ios

Question

I am trying to add anew row to a UITableView. The user enters data in a UITextField on a UIViewController and the control goes back to the original UITableView. What method writes to the table when new row is added. i seem to have tried everything. nothing seems to work.
The code from the comment below is:
tableItems = [NSMutableArray arrayWithObjects:#"Persian", #"Rag Doll", #"Siamese", #"Scottish Fold", #"British short hair", nil];
[self.tableView reloadData];
}
-(void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
if([segue.identifier isEqualToString:#"AddSegue"])
{
UINavigationController *nav = segue.destinationViewController;
AddItemViewController *aivc = [nav.viewControllers objectAtIndex:0];
aivc.TVC = self;
}
}

Answer 1

If you are storing the new row data in an array (for example) which is accessed by the UITableView then just reload the table as following:
[self.tableview reloadData];

Answer 2

I've updated your question with the code that you provided in your comment to another answer.
Bottom line, you don't tell us where your exception is being generated, nor what the exception is. You need to narrow that down if you expect us to help. Also, I'm not sure what to conclude from the fact that you suggest that the exception is being caused after the UITextField is entered and you're returning to the previous controller, but you didn't show us that code, but rather you showed us the code for segueing to the AddItemViewController. Are you getting the error when you first segue, or when you try to pop/dismiss to get back to the view controller with the UITableView?
With those fairly significant questions notwithstanding, I'd suggest two things:
First, make sure you're adding robust checking of your results, to prevent exceptions from happening. For example, a common problem is that one retrieves a value from a property or a NSArray, but for one reason or another, it's not the type of object that the code assumes it was (and requires it to be). In this case, you're assuming that the destinationViewController is a UINavigationController and furthermore, you're assuming that the first element in its viewControllers array is a AddItemViewController. You know your code, and perhaps you are confident of this fact, but the fact that you're getting an exception means that you probably need more robust error checking.
Therefore, I would suggest that you including NSAssert statements that will verify this fact. Using your prepareForSegue as an example, I might suggest altering it thusly:
-(void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
if([segue.identifier isEqualToString:#"AddSegue"])
{
UINavigationController *nav = segue.destinationViewController;
NSAssert([nav isKindOfClass:[UINavigationController class]], #"destinationViewController is not a UINavigationController");
AddItemViewController *aivc = nav.viewControllers[0];
NSAssert([aivc isKindOfClass:[AddItemViewController class]], #"destinationViewController.viewControllers[0] is not a AddItemViewController");
aivc.TVC = self;
}
}
The NSAssert statements are good ways of testing values during testing to make sure that the objects you return are truly of the Class you thought they were. These NSAssert clauses are only used for errors that you're testing for during development, but should never occur in the production application. If your code makes implicit assumptions about what's being returned from a method, you can use NSAssert to validate those assumptions while you're debugging your app.
Now, I have no reason to know whether the values of nav or aivc are your problem, but this is an example of the sort of checking your code should be doing. It's simply a good practice (especially if you're struggling to find an exception), to make sure that the object you've retrieved is the correct type, upon which the rest of your code depends.
I have an ulterior motive here. Your code implies that you're navigating to a view controller that is, itself, embedded in its own navigation controller. You never said as much in your narrative, so these NSAssert statements simply verify this fact.
Second, if all of your robust verification of objects doesn't catch the problem, you must therefore identify the source of the exception yourself. Frequently you can decipher this by looking at the stack trace in the "Debug Navigator" or by reading the error in the console in Xcode. But, another (underappreciated, IMHO) tool, is exception breakpoints which can find the exact line of code that is causing the exception. If I'm encountering any exceptions, I'll routinely add an exception breakpoint on "All" exceptions. That way, if I'm running the program through my debugger, if it encounters an exception, it will stop the code at the offending line, greatly simplifying the process of identifying the source of the problem. It doesn't always work perfectly, but it frequently finds the source of the exception more quickly than other techniques.