Question

I’m a starting iOS developer and I would like to get the idea of NSMutableArray.
Specifically, I want to pass NSString value from one VC to NSMutableArray, belonging to another view controller. I also want that NSMutableArray to populate UITableView on its view. Any ideas how to do this?
For example, I have this action that the user triggers from within 1st view

- (IBAction)addToFav:(id)sender {  
}

And I want to pass a value of NSString myBookString to the NSMutableArray array in the 2nd view.
The task is fairly simple, but I can’t quite understand why you can’t pass the values to NSMutableArray outside this - (void)insertObject:(id)anObject atIndex:(NSUInteger)index method mentioned in Apple’s reference docs.
Thanks in advance!

EDIT: My views are different VC belonging to UITabBar and to UINavigationController at the same time

Answer 1

You need a communication between two controllers. There are several solutions. Pick one of the following. I recommend delegate.

From http://www.hollance.com/

When you have two objects A and B, say two view controllers, that you want to make talk to each other, you can choose from the following options:

NSNotificationCenter.

• This is anonymous one-to-many communication. Object A posts a notification to the NSNotificationCenter, which then distributes it to any other objects listening for that notification, including Object B. A and B do not have to know anything about each other, so this is a very loose coupling. Maybe a little too loose…

KVO (Key-Value Observing).

• One object observes the properties of another. This is a very tight
  coupling, because Object B is now peeking directly into Object A. The
  advantage of KVO is that Object A doesn’t have to be aware of this at
  all, and therefore does not need to send out any notifications — the
  KVO mechanism takes care of this behind the scenes.

Direct pointers.

• Object A has a pointer to Object B and directly sends it messages
  when something of interest happens. This is the tightest coupling
  possible because A and B cannot function without each other. In the
  case of view controllers you generally want to avoid this.

Delegates

• Object B is a delegate of Object A. In this scenario, Object A does
  not know anything about Object B. It just knows that some object
  performs the role of its delegate and it will happily send messages
  to that delegate, but it doesn’t know — or care — that this is Object
  B. The delegate pattern is often the preferred way to communicate
  between view controllers, but it takes some work to set up.

Blocks.

• Essentially the same approach as delegates, except that Object B now
  gives Object A one or more blocks (closures) to be executed when
  certain events take place. There is no formal delegate protocol and
  the only thing that Object A sees of Object B is the blocks it is
  given.