Subclassing

That's step 1. Step 2 is you'd need to give your secondViewController an actual instance of FirstViewController (or firstViewController, or whatever the real class is).

Importing the @interface of a class simply tells the importing code what the structure of the imported class is. That is, it tells the importer what the names of the instance variables are, what the methods are, etc. It doesn't actually create an instance anywhere.

Remember, a class is just a factory for creating instances that have the same characteristics (same instance variable names, same methods). You don't make a milkshake by putting a cow into a blender. The cow makes milk, which is what goes into the blender. The cow is a milk factory. A cow is also a calf factory, but the calf instances can be male or female, so not every instance produced is another milk factory. And if you want to make chevre or pecorino, you need a completely different factory (goat or sheep).

 

If your app needs a single set of data shared by different controllers, then Step 1 of the design is to decide where the single set of shared data will reside.

If you put the shared data in one of your controllers, then you also have to arrange for that data to be made available to (shared with) all the other controllers.

If you put the shared data in a single common place, such as the application object, then any of the controllers can get it, without you needing to make the controllers share the data.

This type of design (a single repository for shared data) is a common pattern. It applies in many cases, regardless of what kind of view or view controller is being used. It's called the Singleton pattern, and it's specifically mentioned and described in the "Cocoa Design Patterns" heading of the Cocoa Fundamentals Guide:
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/

Depending on what the shared data actually is, another possible place to store the shared data is in the application's NSUserDefaults object. See the class reference doc.

In any case, you need to think about the design of the app before writing code for any classes. Think about what's shared and what's not. Where shared things will reside. Where unshared things will reside. Draw simple block diagrams showing relationships of where things are stored, which things can access them, etc. It doesn't need to be complicated, and you don't need a fancy drawing app. Paper and pencil suffices.

 

[1]
Try factoring out your networking code into a custom model class. Your view controller is just responsible for instantiating this model; the model is responsible for handling the download and parsing:

Code:

- (void)viewDidLoad
{
    [super viewDidLoad];
    
    if (myModel == nil)
    {
        myModel = [[FirstModel] alloc] init];
    }
}

[2]
Be careful with the synchronous download APIs. Try incorporating asynchronous NSURLConnections to download your information from the server.

[3]
Try having your child view controller declare a read-write property for a model object that it needs to display its data. Then, have the parent view controller set this property to the right data when the child view controller is about to be displayed.

 

As a general-purpose place to put shared variables, NSUserDefaults is a poor choice. That's just hammering a square peg into a round hole.

That's why you need to think about the design before thinking about how to implement a design. In other words, step 1 is creating a design. Step 2 is implementing it. You don't choose NSUserDefaults or some other class until step 2.

When you do it backwards, then the first choice you make is NSUserDefaults, and you then cobble together a design around its strengths and weaknesses. If what you're trying to do happens to be a bad fit for NSUserDefaults, then you will spend more time and effort trying to make it fit than if you just started over from scratch.

If you have a good clear design, it should be obvious whether to use NSUserDefaults or not. Without a clear design, you can't possibly make a sensible choice of how to implement it.

I'll use another analogy: if you're making a video short story, do you start by shooting actors in on-location scenes? Or do you start with an idea of the story you want to tell, then write a script, then decide which actors and locations to use? Even with a script, actors, and locations chose, are you ready to shoot yet? Not likely: you have to decide which shots are closeup, which are distant, from what point of view, what time of day, whether you need a dolly and crane operator, etc. When you do it backwards, you end up with nothing but a bunch of meaningless crane and dolly shots, of incongruous actors saying meaningless dialog.