iPad + Universal (iPhone + iPad) Apps

Project Options

In fact, the only real difference is in our .plist file. If we right-click on the project, and choose Options, we’ll see that the Devices setting is set to iPad:

By changing Devices setting to iPad, the dialogue also gives options specific to the device.

Interface Builder and iPad Views

Editing iPad .xib files in Interface Builder (IB), is exactly like editing iPhone .xib files, except the designer is much larger. Double-click on the Hello_iPadViewController.xib and it’ll open up in IB:

Let’s add a label to the view, and save it:

We don’t need any Outlets or Actions, but adding them is the same process as it is for the iPhone—you open the Assistant Editor, and Control-drag from the control to the .h file.

Running an iPad App

Now let’s build and run our iPad app. If we look at the Project menu > iPhone Simulator Target, it’s set to Default, but since we’ve set the Device to be an iPad in the .plist file, the iOS Simulator will open up and simulate the iPad, which looks nearly the same as the iPhone Simulator, except for the size:

That’s it! We’ve built our first MonoTouch iPad application!

iPad Icons

iPad application icons are specified in the Info.plist file, just like iPhone application icons are. The only difference is the size needed for them. The following table lists the icons and sizes needed for iPad applications:

To add these icons, follow the same procedure we did for the Hello, iPhone application: right-click on the project and choose Add : Add Files.

To configure these icons, either double-click on the Info.plist file in the Project Navigator, or double-click on the project and choose iPhone Application in the Options dialog.

iPad Default Loading Screens

Specifying a loading screen in iPad is conceptually the same as with iPhone apps, you just move your properly named and sized images into the project root, and iOS will automatically show them during application launch. However, things are slightly more complicated in iPad apps because instead of two images (as there are for the iPhone), you can optionally specify up to four; one for each orientation.

Additionally, unlike the iPhone, the status bar is viewable when an iPad application launches, which means that you must take into account that 20 pixels at the top of the screen are already occupied. This is also dependent on orientation, because the status bar is always at the top. So, if the iPad is in portrait mode, the loading image needs to be 768x1004 pixels, and if in landscape, it needs to be 1024x748 pixels.

The following table lists the types of iPad loading images, as well as their sizes (width x height) and orientations. The images are listed in order of precedence; images further down the list take precedent over images higher in the list:

Unless you want to have different images for each orientation, you only need to supply a Default~ipad.png image if your application only supports portrait mode. If your app only supports landscape orientation, you only need the Default-Landscape~ipad.png image. If you support both landscape and portrait orientation, then you should supply at least these two images. This significantly reduces the amount of images you must create, since supplying one for every orientation is typically overkill.

For more information about loading images, see the Apple documentation on Custom Icon and Image Creation Guidelines.

OK, now that we’ve covered iPad applications, let’s take a look at how to build apps that target both the iPhone and iPad.

Universal Project Template

Let’s create a new solution, this time we’ll choose C# : MonoTouch : Universal : MonoTouch Single View Application – Universal:

Let’s name the project Hello_Universal.

If you take a look at the project structure created from this template, you’ll notice something a little different. There is one view controller, but two associated .xib files:

public override bool FinishedLaunching (UIApplication app, NSDictionary options)
{
       // create a new window instance based on the screen size
       window = new UIWindow (UIScreen.MainScreen.Bounds);

       if (UIDevice.CurrentDevice.UserInterfaceIdiom == UIUserInterfaceIdiom.Phone) {
              viewController = new Hello_UniversalViewController
                  ("Hello_UniversalViewController_iPhone", null);
       } else {
              viewController = new Hello_UniversalViewController
                  ("Hello_UniversalViewController_iPad", null);
       }
       window.RootViewController = viewController;
       window.MakeKeyAndVisible ();      
       return true;
}

if (UIDevice.CurrentDevice.UserInterfaceIdiom == UIUserInterfaceIdiom.Phone) { …

if (UIDevice.CurrentDevice.UserInterfaceIdiom == UIUserInterfaceIdiom.Phone) {
       viewController = new Hello_UniversalViewController
             ("Hello_UniversalViewController_iPhone", null);
} else {
       viewController = new Hello_UniversalViewController
             ("Hello_UniversalViewController_iPad", null);
}

public Hello_UniversalViewController (string nibName, NSBundle bundle) : base (nibName, bundle)

Creating the User Interface

So far, so good, but let’s actually put this in action. First, let’s open the Hello_UniversalViewController_iPad.xib file in Xcode and add a couple of labels and a button:

We’re going to update the bottom label with some text when the button is clicked, so make sure it’s fairly wide, so that the text doesn’t get truncated.

Next, we’ll do the same thing with the Hello_UniversalViewController_iPhone.xib file:

Again, be sure to make the bottom label fairly wide so the text doesn’t get truncated.

Sharing Outlets and Actions Across Multiple Views

So now we have two views that share the same controller, but how do we create Outlets and Actions that work across the two views? Well, it turns out that this is very similar to how Actions are shared.

Let’s first create our Outlets. Open up the iPhone view and the corresponding shared controller .h file in Xcode and Control-drag to create the following outlets:

• btnClickMe
• lblOutput

The btnClickMe outlet should be wired to the button, and the lblOutput should be wired to the lower label. When we’re done we should have something like this:

Our .h file should have the following Outlet code:

@property (nonatomic, retain) IBOutlet UIButton *btnClickMe;
@property (nonatomic, retain) IBOutlet UILabel *lblOutput;

Next, let’s open up the iPad view. This time, we’re going to Control-drag to the existing Outlets that we created when the iPhone view was open:

Now our Outlets are shared across the two .xib files. Let’s save our work and switch back over to MonoDevelop. We can now use the same Outlets in the same ways, whether the app is running on an iPhone or an iPad. Let’s modify our Hello_UniversalViewController class’s ViewDidLoad method to see this in action:

public override void ViewDidLoad ()
{
    base.ViewDidLoad ();
    this.btnClickMe.TouchUpInside += (sender, e) => {
        this.lblOutput.Text = "Clicked @ " +
            DateTime.Now.ToShortTimeString();
    };
}

Now, when we run it and click the button, we should see something like this:

Notice that the iPhone simulator launches by default. We can force the application to run in the iPad simulator by selecting iPad Simulator 4.3 from the Project > iPhone Simulator Target menu. When we run the application now, it will launch in the iPad simulator, and when we click the button, the code will run just as it did when we used the iPhone simulator:

Complex Universal Applications

The approach we’ve used so far, where a single controller manages two different views based on the device, works fine for simple screens in which there are the same Outlets, Actions and user interactions between the iPhone screen and the iPad screen, but this is a rare occurrence in the real world. Typically, iPad apps and iPhone apps differ substantially in terms of UI and user interaction (referred to as User eXperience [UX] when taken together).

For example, consider the following two different interfaces for the same app on different devices:

In this case, we’d want to have two different controllers because the Outlets would be different. This is obviously a contrived UI, but you can imagine that in some applications the UI is drastically different between devices.

To load a different controller depending on the device, the first thing that we should do is to declare a generic UIViewController in our AppDelegate class, rather than a specific one (say homeScreen_iPad or homeScreen_iPhone):

public partial class AppDelegate : UIApplicationDelegate
{
    // class-level declarations
    UIWindow window;
    UIViewController homeScreen;
    …
}

Then, in the FinishedLaunching method, when we determine which device is in use, we load the appropriate controller, and then set that controller as our root:

if (UIDevice.CurrentDevice.UserInterfaceIdiom == UIUserInterfaceIdiom.Phone) {
    homeScreen = new Screens.HomeScreen_iPhone();
} else {
    homeScreen = new Screens.HomeScreen_iPad();
}
window.RootViewController = homeScreen;

Now, when we run the application, the correct controller for the device will be shown.