1. Trang chủ >
  2. Công Nghệ Thông Tin >
  3. Quản trị mạng >

iPhone vs. iPod Touch vs iPad?

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (36.44 MB, 500 trang )

CHAPTER 1: Getting Started with MonoTouch

You can also create your interface programmatically by instantiating Cocoa Touch

objects and adding them to your application’s Views (more on Views later).

You cannot, however, create your MonoTouch interface using traditional .NET

technologies such as Silverlight, WPF, or Winforms. You can, however, build games

using Microsoft’s XNA Toolkit that target the Windows 7 phone and port them using the

open-source XNA Touch project (we’ll cover this in Chapter 21). Additionally, there are

indications from the MonoTouch team that Moonlight will be supported at some point in

the future. Time will tell if that bears fruit.

Cocoa Touch uses a rough amalgamation of the Model View Controller (MVC) pattern

that we’ll discuss in Chapter 3.

By utilizing the UIKit, developers can make iOS applications using the same familiar

control set as applications written in Objective-C. However, if you wish to branch

beyond that, you can. MonoTouch also exposes the underlying graphics framework so

that you can create rich 2D and 3D applications that allow you to go well beyond the

UIKit control framework.

How Do I Distribute My Apps?

MonoTouch applications are distributed the exact same way that traditional iOS

applications are distributed, either via the Apple App Store, Enterprise, or ad-hoc


The App Store is an online repository that allows users to pay for applications (if they’re

not free), and download them. It is available from within iTunes, or directly from the

iDevice itself. In order to get a license to distribute via the App Store, you must register

with Apple, and pay $99/year. For more information, go to http://developer.apple.com

and read about their development program.

Enterprise deployment is for those wishing to develop internal applications for a

company and distribute them, for example, to employees, without listing them with the

App Store.

Ad-hoc deployment allows you to deploy to a limited number of devices mainly for the

purpose of testing and development.

What Is the Licensing Model?

Unlike Mono, MonoTouch is not open source—it is a commercial product. That means, if

you want to do anything useful with it, you have to purchase a license to use it.

MonoTouch comes in three flavors and prices:

Professional ($399): A single personal developer license that allows

you to develop applications and distribute them via the Apple AppStore




CHAPTER 1: Getting Started with MonoTouch

Enterprise ($999): A single corporate developer license that allows

you to develop applications and distribute via the App-store, or via

enterprise deployment

Enterprise, 5 Seat ($3,999): The same as the Enterprise license, but

includes 5 seats

Academic ($99): A single personal developer license that only allows

non-commercial distribution via ad-hoc deployment

All three options include a year of free updates.

There is also an evaluation edition that allows you deploy to the simulator only (the

simulator is part of the iOS SDK, which I'll talk about later in this chapter). For the

purposes of most of this book, the evaluation edition of MonoTouch is all you need. If you

wish to try out any of your code on an actual device, you will have to purchase a

licensed copy of MonoTouch.

Are There Any Limitations of MonoTouch?

As powerful as MonoTouch is, it has some limations that the larger .NET Framework does

not. Let’s examine them.

No Just-in-Time (JIT) Compilation

Per Apple’s iOS policy, no application can include code that requires just-in-time (JIT)

compilation. But wait a second, that’s exactly how .NET works, right? This is correct;

however, the MonoTouch framework gets around this limitation by compiling your

application down to a native iOS assembly. This, however, introduces several limitations.

Generics: Generics are instantiated by the JIT compiler at run-time.

However, Mono has an ahead-of-time (AOT) compilation mode that will

generate all the methods and properties for things like List. Other

uses of Generics, such as Generic virtual methods, P/Invokes in

Generic types, and value types that don’t exist in the core library in

Dictionary are not supported (although there is a

workaround for Dictionary).

Dynamic code generation: Because dynamic code generation

depends on the JIT compiler, there is no support for any dynamic

language compilation. This includes System.Reflection.Emit,

Remoting, runtime proxy generation for WCF, JIT’d RegEx, JIT’d

serializers, and the Dynamic Language Runtime.

C# Is Currently the Only Language

Additionally, currently, the only .NET language available for writing MonoTouch

applications is C#.


CHAPTER 1: Getting Started with MonoTouch

More Information

For a full list of limitations and more information, including workarounds, see


Getting Started

In order to get started building MonoTouch applications for the iPhone we’ll need a few


An Intel Mac computer running 10.6 (Snow Leopard) or better

The latest Apple iOS SDK

The current version of Mono

The MonoTouch SDK

An IDE such as MonoDevelop or XCode, or a text editor program

Mac Computer Running Snow Leopard

This is an important and easily missed requirement. While theoretically you could build

most of your application on other platforms, the iOS SDK (and therefore the iOS device

simulator and Interface Builder) are only available for Snow Leopard. Additionally, the

compiler itself uses some low-level magic specific to the Intel Mac machines, so having

one is an absolute must.

MonoTouch is currently working on tools that will allow you to write in Visual Studio via

their MonoTouch Tools for Visual Studio. However, it has yet to be released, and you

will still need a Snow Leopard machine to run the simulator and to compile for the actual


Apple’s iOS SDK

Available at http://developer.apple.com/devcenter/ios, the iOS SDK is a free download,

but you must register with Apple to get access to it. Along the way, Apple may ask you

to pay $99 to get an iOS developer account, which allows you to deploy your

applications, but for the purposes of this tutorial, you just need the SDK. The iOS SDK

includes Interface Builder, the iOS device simulator, Xcode, and a few other things.

After you have installed the iOS SDK, make sure you can launch the iOS Simulator. You

can find the simulator by opening Spotlight and typing “iOS Simulator.”

Mono for OSX

Once you’ve tested out the iOS simulator, install the latest version of Mono for OSX.

Mono can be downloaded from http://mono-project.com/Downloads. Make sure you click




CHAPTER 1: Getting Started with MonoTouch

on the “intel” link, and not the CSDK. Also, install Mono before you install the MonoTouch

SDK. Mono comes in a disk image; double-click the installer package and follow the


MonoTouch SDK

Next, download and install the latest MonoTouch SDK. You can either buy it at the

MonoTouch store, http://monotouch.net/Store, and you’ll receive a link to download, or

you can download an evaluation version from http://monotouch.net/DownloadTrial. If

you purchase MonoTouch, you can deploy your applications to a properly configured

device, but for most of the book, the evaluation version is fine.

Text Editor or Integrated Development Environment

If you want to create MonoTouch applications, all you need are the previous items and a

text editor. You could create all your code files and manually compile using the

command line (terminal window). This would be quite a pain, though, so we’re going to

use an integrated development environment (IDE) to develop our applications.

You have several options for this, but all of our examples in this book will be based on

MonoDevelop. I’ve chosen MonoDevelop for two reasons, first, it’s free, and secondly, it’s

the only IDE that completely integrates MonoTouch.

You can find the MonoDevelop install at http://monodevelop.com/Download.

You can also use Visual Studio to write libraries for use in MonoTouch, but it involves

converting your standard C# class library projects to MonoTouch iOS class library

projects. For more information, and a tool to help automate this, check out:


You can either modify/hack Xcode (installed with the iOS SDK) to use the MonoTouch

libraries and compiler, or you can use MonoDevelop.

If you have installed Mono correctly, MonoDevelop should open up without error.


One of the biggest drawbacks to developing for MonoTouch is that, while there is a wealth

of documentation for developing for the iOS in general, the MonoTouch documentation

itself is lacking. You can access the MonoTouch documentation directly from MonoDevelop

in the Help menu, or you can view it online at http://www.gomono.com/docs/index.aspx. You can also find the .NET documentation online at



CHAPTER 1: Getting Started with MonoTouch

Xcode/iOS Documentation

Probably the single most useful source of documentation for developing MonoTouch

applications is the iOS documentation. It’s all based on the Objective-C API and includes

Objective-C samples, but it should be considered the bible for iOS development.

You can access the iOS documentation either online at http://developer.apple.com, or in

Xcode. To view it in Xcode, open Xcode and choose Developer Documentation in the Help


NOTE: I've included a short Objective-C primer in chapter 21, which deserves a once-over. It will

significantly help to understand the examples in the iOS documentation.

MonoTouch Rosetta Stone

Additionally, Miguel de Icaza (the creator of Mono) keeps a “Rosetta stone” which maps

the MonoTouch API to the underlying iOS API at http://tirania.org/tmp/rosetta.html.


As you learn and develop with MonoTouch, when you get stuck, and you probably will,

there are quite a few resources online to help you work through it:

MonoTouch forums: You can find forums dedicated to MonoTouch

development at http://forums.MonoTouch.net

IRC channel: There is a very active IRC community to be found on the

#MonoTouch channel on the irc.gnome.org and irc.gimp.net servers. The

MonoTouch team themselves are very active on there. You can access

the channel directly from the MonoTouch website at

www.MonoTouch.net/chat, if you’re unfamiliar with IRC.

3rd Party Libraries

There is an active and growing number of open source 3rd party libraries for MonoTouch.

Many of the most popular libraries for Objective-C have been wrapped for native use in

MonoTouch. We’ll cover 3rd party libraries in Chapter 21, but you can also find a current

list at http://wiki.monotouch.net/.


Congratulations, you’ve made it through the first chapter. By now, you should have a

pretty good understanding of MonoTouch’s place in the world, what tools you need to use

it, and where to go for help when you encounter issues. You should also understand the

basic constraints of developing for the iOS. In the next chapter we’ll leverage what

we’ve learned so far to build our first MonoTouch application.






Our First Application

Once you have everything installed from the first chapter, you’re ready to start building

iOS applications. In this chapter, we’re going to build a single-screen “Hello, World”

application specifically for the iPhone/iPod Touch. By the end of this chapter, you’ll be

familiar with:

Creating MonoTouch projects

Using Interface Builder to create screens

Wiring up controls via outlets and creating actions

Handling UI events in code

Deploying to and running applications in the iOS Simulator

Without further ado, let’s get started.

Starting the Example

First, launch MonoDevelop. Your screen should show something similar to following

(Figure 2–1).




CHAPTER 2: Our First Application

Figure 2–1. MonoDevelop

As a standard IDE, it should look pretty familiar. It’s very similar to such environments as

Visual Studio, Eclipse, Visual C# Express, and others.

We’re going to create a new solution in which to put our iPhone project. Solutions are

exactly the same as they are in Visual Studio and, in fact, you can open up solutions you

created in Visual Studio in MonoDevelop. One thing that is different in MonoDevelop,

though, is that you can actually have multiple solutions open in one instance of

MonoDevelop, as illustrated in Figure 2–2.


CHAPTER 2: Our First Application

Figure 2–2. MonoDevelop with multiple solutions open

This is a pretty important feature since, in the Mac OS, you cannot have multiple

instances of an application open without terminal or scripting trickery. So, if you need to

switch between solutions (for example, if you want one open for sample code), you can

simply open more than one at once.

Create a New Solution

So, with all that said, let’s create a new solution. In the menu, go to File  New  Solution.

We want to create an iPhone Window-based Project, as shown in the following figure. Let’s

go ahead and call it Example_HelloWorld_iPhone.




CHAPTER 2: Our First Application

Figure 2–3. MonoDevelop new solution dialogue window

Again, this is very similar to Visual Studio’s dialog for creating new solutions. Click OK,

and you should now have a solution view that looks something like the one in Figure 2–4

(note, I’ve expanded the arrows in the solution view to show all the files and references).

Figure 2–4. The solution window


CHAPTER 2: Our First Application

Examining the Code

Let’s go through these:

References: This folder contains the basic references needed for a MonoTouch

application. The MonoTouch assembly includes everything needed that is specific

to the iOS, including all the wrappers to the Cocoa Touch controls and the core

iOS stuff such as Location, Data, etc. The System.* assemblies are the .NET Base

Class Library and runtime that have been tailored to run on iOS devices.

Main.cs: This is the same as it would be for a console application, a WPF

application, or the like. In here is our static void Main call, which serves as an

entry point for the application. We’ll take a look at this in more detail in a second.

MainWindow.xib & MainWindow.xib.designer.cs: This is analogous to a

Winforms Window, or a WPF Window. The xib file will actually be edited in

Interface Builder (which we’ll examine in just a bit), and the designer.cs file will

hold our properties for that form.

Let’s examine the code in the Main.cs file, as shown in Listing 2–1.

Listing 2–1. The code in the Main.cs file











namespace Example_HelloWorld_iPhone


public class Application


static void Main (string[] args)


UIApplication.Main (args);



// The name AppDelegate is referenced in the MainWindow.xib file.

public partial class AppDelegate : UIApplicationDelegate


// This method is invoked when the application has loaded its UI

// and it's ready to run

public override bool FinishedLaunching (UIApplication app, NSDictionary options)


// If you have defined a view, add it here:

// window.AddSubview (navigationController.View);

window.MakeKeyAndVisible ();

return true;







CHAPTER 2: Our First Application

There are two classes in here: the Application class and the AppDelegate class. This is

where things start to get a little different from traditional .NET GUI development.

The way iOS applications work is that your application class contains all your Windows,

Views, Controls, Resources, etc., and then you have an application delegate class

(derived from UIApplicationDelegate) that handles application lifecycle and runtime


Lifecycle events include things like application startup and shutdown, and runtime

events include things like low memory warnings and device orientation changes.

By handling these events in your application delegate class, you have an opportunity to

respond to them. For instance, when your application is shutting down, the

WillTerminate method is called on your application delegate, and you have an

opportunity to save any user data, application state, etc.

In our Application class, we have a Main method. By calling UIApplication.Main, the

Objective-C runtime will look for your MainWindow.xib file (which contains the name of

your UIApplicationDelegate class), instantiate your Application class (as a Singleton)

and then start calling lifecycle events on your AppDelegate class.

NOTE: You don’t have to name your primary window (also known as the Main Interface

File) MainWindow.xib. You can name it whatever you want, but you have to tell the build

system to look for whatever file you create. If you want it to look for a different file, open up the

project options by right-clicking on your project file, click Options, and then in Build  iPhone

Application  Main Interface File, set that to whatever .xib file you want to be your primary

window. The Objective-C runtime will then try to load that window when your application runs,

and will find your application delegate from the setting in that file.

Additionally, you can name your application delegate class whatever you want. By default it is

called AppDelegate. To change it, open your Main Interface File in Interface Builder, and

change the name of your Application Delegate.

Furthermore, you don’t even need to define your window in a xib file at all. In fact, as a standard

practice, I never define my window in a xib. It’s easier to just do it programmatically. In Chapter 4,

we’ll look at how to do exactly that.

We’ll come back to our Main.cs file in a bit, but first let's dig into the actual GUI of the


Interface Builder

So far we’ve seen a little bit of the code side of our iPhone application, let's dive into

building the interface. Apple’s application design toolset is called Interface Builder.

Interface Builder is loosely coupled to your development environment. It creates xib files


Xem Thêm
Tải bản đầy đủ (.pdf) (500 trang)