0

I want to know how the same reference of an object of a particular class can be accessed inside two different Xibs.

I understand that by creating an object reference for the class inside each xib creates different objects. Even when using AppDelegate its creating different objects. What I want to achieve is that referenced object inside both the xibs should be the same (so that I can use the object as the datasource of two different table views for instance.)

Rakesh
  • 3,370
  • 2
  • 23
  • 41
  • 2
    It sounds like you want to use an *external object* in your nibs. Look at the accepted answer to this question: http://stackoverflow.com/questions/6950674/how-to-use-a-common-target-object-to-handle-actions-outlets-of-multiple-views – rob mayoff Aug 08 '12 at 09:19
  • 1
    @rob - Yes. Thats the solution i was looking for. Thanks a lot. But only problem is I don't know where to find the external/proxy object. I cant find it in my object library. Im using Xcode 4.2. – Rakesh Aug 09 '12 at 07:49
  • [This image](http://cfile29.uf.tistory.com/image/142011464DA3ACEE0C6E64) shows you what the External Object looks like in the object library. I found the image here: http://musart.tistory.com/49 – rob mayoff Aug 09 '12 at 08:04
  • Try typing “external” in the search box under the object library. – rob mayoff Aug 09 '12 at 08:05
  • 1
    its not there in Xcode 4.2. Which version are you referring to? – Rakesh Aug 09 '12 at 08:28
  • You probably need to upgrade. The latest public version is 4.4.1. – rob mayoff Aug 09 '12 at 08:51

3 Answers3

2

Only create the object once, and put it somewhere you can get to it from both classes. For instance, you could create the object as a property of your application delegate. Then add

AppDelegate *app = [[UIApplication sharedApplication] delegate];

to your classes (after importing AppDelegate.h) and access the object with app.objectName.

Dustin
  • 6,783
  • 4
  • 36
  • 53
  • but i guess i still cant use this as an object inside my xib. Creating an AppDelegate Object inside my two different xibs would still return me two different AppDelegate objects with two different iVars. – Rakesh Aug 08 '12 at 03:30
  • Using [NSApp delegate] (in cocoa)inside the code and accessing the AppDelegate object returns the same object every time like you said. But when I create an AppDelegate object inside each of the xib and make each of them my application's delegate it returns different objects. – Rakesh Aug 08 '12 at 03:59
  • Then don't make a new `AppDelegate` object; the code above just creates a pointer to the existing application delegate. If that's all you have in your code then you won't create another one (if that's even possible). – Dustin Aug 08 '12 at 12:09
  • @Dustin-Thats what even I thought but when i take the AppDelegate object inside the xib, instead of this object pointing to the current delegate of NSApplication, its makes this new object as the delegate. Some thing like the following code is happening i guess: `AppDelegate *appD = [AppDelegate alloc] init];` `[NSApp setDelegate:appD];` – Rakesh Aug 09 '12 at 07:45
2

The other answer will work but it's a bad design.

You should stick to the tell don't ask rule. Give your objects the dataSource you want them to use, do not have them asking for a dataSource, which is actually a nasty global.

The other issue is your understanding of nibs. They store an object graph, when a nib is loaded the graph is un archived and each object in it is instantiated. If you have two of the same objects in the graph then you will end up with two instances not two references to one instance. It is the same for when you drag out multiple views, you end up with multiple instances of UIView (and subclasses) which is exactly what you would expect.

It's well worth the effort in learning the boundaries between what you can/can't do in a nib and what you have to do in code and how they all fit together.

Paul.s
  • 38,494
  • 5
  • 70
  • 88
  • You're right that this is better design. Props for actually sticking around and explaining it rather than giving an easy solution. – Dustin Aug 08 '12 at 12:14
  • @Dustin I've just noticed the comment by robmayoff under the actual question has the best option and I didn't even know how to do that so that's pretty cool – Paul.s Aug 08 '12 at 12:15
  • @Dustin - thinking about it further, it has fairly limited use cases. UIViewController automatically deals with loading nibs so you would have to reimplement this work and then with storyboarding you get even further away from being able to use this. But for stand alone xibs it could be cool although I think it would be just as easy to call set a property after loading a nib than constructing a dictionary with the correct keys etc. – Paul.s Aug 08 '12 at 13:22
  • I'm still not getting it completely. Can you guys take a look at this question that i posted: http://stackoverflow.com/questions/11666917/changes-not-reflected-across-view-when-using-binding-in-cocoa – Rakesh Aug 09 '12 at 07:33
  • Right now I'm populating two table views in two different xibs by declaring an array in `AppDelegate` and then getting `AppDelegate` object ( `[NSApp delegate]` ) in each of my datasource objects to access the array. Is there any other way I can do this? – Rakesh Aug 09 '12 at 07:38
1

Interesting !
Try using singleton approach, check out this link http://www.duckrowing.com/2010/05/21/using-the-singleton-pattern-in-objective-c/
Using this approach, you can create an instance which will be available throughout the application life cycle

Piyush
  • 188
  • 8
  • As previously stated this is a pretty lousy way of solving this problem. – Paul.s Aug 10 '12 at 09:54
  • 1
    No offense @Paul.s, but why would this be wrong design ? You have an instance which can be used for sharing of data, and well Core Data can be used for persistence. – Piyush Aug 11 '12 at 22:23
  • 2
    It's terrible for testing. It's just a global variable which is generally bad. It increases the coupling in your code, making it more brittle. It makes your code less reusable. Singletons do have their uses but this is a bad use case for them. – Paul.s Aug 12 '12 at 00:40