0

My project has a few view controllers, let's say A and B. In A I have a UITableView. When a row is selected, I pass the row number and cell text to view B, then pushViewController B.

In view B, when hitting the 'done' button I make changes to the underlying data (right now a Singleton array) and then pop back to view A. In view A viewDidAppear, I reload the UITableView to see the new data.

Is this the best way to do it? Or should I be reloading the UITableView when the 'done' button is hit? If so, how do I reload a Table in view A from within view B?

Thanks.

wayneh
  • 4,393
  • 9
  • 35
  • 70
  • `reloadData` is really bad from an UX standpoint. Use the insertRowsAtIndexPaths:withRowAnimation:, deleteRowsAtIndexPaths:withRowAnimation: etc, avoiding issues with the scroll position and selection. – Marcelo Alves Jan 20 '12 at 18:46

4 Answers4

2

It is better to reload the data directly when you hit the "Done" button. You can do that by a Notification Center. Please check this link for more details about Notification Center.

Community
  • 1
  • 1
antf
  • 3,162
  • 2
  • 26
  • 33
  • Worked perfectly! A follow-up: Where should the 'remove notification' be? I assume in viewDidUnload in the main view? – wayneh Jan 20 '12 at 18:41
  • In theory the remove should be when you no more need to be listening anymore. So this depends on your needs but generally since you need to listen as long as the app is running then the remove should be when the app (or that particular view) is quitting. One choice could be `viewDidUnload` and another could be `dealloc`. This depends on exactly when you want the remove to happen. – antf Jan 20 '12 at 18:47
0

ViewController "A" should certainly be responsible for deciding to reload the table data. I would consider putting that into the "viewWillAppear" method of ViewController A. That way the table is reloaded before being displayed to prevent and "flickering".

picciano
  • 22,341
  • 9
  • 69
  • 82
0

There is nothing very wrong about this, except that your table will be reloaded every time it's viewDidAppear is called, which may not be very good depending upon the size of the table. The best way would be to use @protocol and make a quick delegate design pattern, though this might seem unnecessary headache if you are not used to it. You can also use NSNotifications, although I would not insist using it in this case, as there are not many observers listening to the event.

aqs
  • 5,632
  • 3
  • 24
  • 24
0

Instead of using NSNotification. You can assign view A to be view B's delegate which is a much cleaner design pattern.

So in view A it would look like

ViewB *b = [[ViewB alloc] init];
b.delegate = self;

and the in viewB when you are done making modification u call 

[delegate updateTable];

where in updateTable is a @required method in the delegate declaration and since its required viewA will need to implement it if it says it conforms to that delegation.

Also this method will be called before you pop the viewB out.

AJ.
  • 174
  • 1
  • 12