This past weekend I had the wonderful opportunity to attend and speak at the Southwest Florida .NET Code Camp 2012 in sunny Naples, FL.  It was a great event with over 80 attendees.  I was there as both a speaker and a sponsor and I also brought my father and brother to the event.  I’d like to thank John Dunagan again for putting on a fantastic event.  I presented 3 sessions at the code camp and I wanted to take some time to provide some additional resources for those that attended the sessions.

HTML5 and jQuery Fundamentals

Originally, my boss Jason Beres was supposed to be attending this event but he needed to attend TechEd Australia instead.  Since he was planning on presenting a session on HTML5 and jQuery I figured I would take that session slot and give it a try.  I’m still learning HTML5 and jQuery so I’m certainly not an expert.  However, I took Jason’s content and made some slides of my own and gave it a shot as a high-level overview.  I thought the session went well and the attendees seemed engaged and appreciative.  I promised I’d share my slides and Jason’s original material (including some content I didn’t get to talk about).  Here are the links:

• My slides: HTML5 & jQuery Slides.ppt
• Jason’s material: Fundamentals-Webinar-Download.zip

Windows 8 Design Fundamentals

The material in this session hasn’t changed since previous events I’ve given the talk at.  You can find more details on those here and here.  However, one thing that is new is that I’m writing a book on the subject.  Please pre-order Designing for Windows 8 today and you’ll get it when it’s done in December!

Designing for Windows 8

Create iOS apps using C# with Monotouch

I added this session for a bit of fun after I noticed that there weren’t any sessions at the code camp dealing with MonoTouch or Mono for Android.  I think these are very important technologies and I didn’t want to let them go unrepresented.  The session was at the end of the day so I kept it lighthearted with no slides and a few “Hello World”-style demos.  I discussed the origins of MonoTouch and Xamarin and a little bit of the turmoil those have been through in the past.  Thankfully, those things are in the past and we can safely use MonoTouch to build iOS apps without worrying about Apple interjection.  I showed how to use MonoDevelop in tandem with Xcode to create a very basic application.  I then showed how to build the same application using just Xcode with Objective-C.

I didn’t have slides for this session but I do have one follow-up piece of information from the session.  I mentioned a service that allows you to run MonoTouch in the cloud in case you don’t feel like buying a Mac.  That service is called MacInCloud and it might be a good option for you.

Summary

I had a great time at this event.  I would highly recommend it to anyone next year.  The location is fantastic, the facilities were very accommodating, and the people were very friendly.  If you’re looking for an excuse to take a trip to Florida, this would be a good one.

Model-View-Controller, or MVC, is a design pattern that is often used in creating mobile applications. In an MVC application, the major building blocks of the application are either model objects, view objects, or controller objects.

Definition of MVC objects

Model objects are used to represent the data in your application. If designed appropriately, model objects can be reused in multiple projects. This is especially important in cross-platform scenarios. For model objects to be reusable,  they should not know details about how your views and controllers operate.

View objects represent things on screen. For instance, a button or a table view would be view objects.  Primary responsibilities for view objects include drawing themselves on screen and responding to events.  View objects should not have direct access to the model.

Controller objects are used to coordinate the models and the views to create the application.  Controllers can fetch data from the model and hook it up to the corresponding views in the application. When data needs updated or saved, the controller can help facilitate this task by leveraging the model.  Controllers are also responsible for handling application flow, e.g.  navigating between screens.

MVC in MonoTouch

Model objects can range in complexity from simple arrays all the way up to complex custom object hierarchies.  The data they represent can either be static data contained in the project or dynamic data fetched from a database or the Internet.

View objects in iOS derive from UIView or any of its subclasses, such as UIButton or UISlider.  Views can either be standard controls from UIKit or custom view classes derived from UIView.

Controller objects in iOS are represented by subclasses of UIViewController. In an iPhone application, each view controller represents one screen’s worth of data. In an iPad application, a view controller might represent a whole screen or it may just represent a functional unit of the screen such as a controller for a list displayed on the screen. For this tutorial, we will focus on the iPhone scenario since iPad view controller hierarchies can get complicated. Each view controller has a View property that is used to manage its view hierarchy. Methods defined in UIViewController can be overridden in view controller subclasses to participate in what Apple refers to as the View Controller Lifecycle. For instance, a view controller can override LoadView to create and load its view object and override ViewDidLoad to customize the view after it has loaded.

Tutorial: Implementing a basic Model-View-Controller application

In this tutorial, we will create a single screen iPhone application that displays the name and price for a grocery store product. The model object will be a simple C# object called Product with properties for name and price. The view object will be a custom view object called ProductView which will derive from UIView and contain UILabels to display the name and price for a product and a button to raise the price 10 cents. Even though most of the examples you will find on the Internet will use Interface Builder XIBs to create the user interface, the first version of this application will layout the controls in code to show how this is done programmatically. Future tutorials will cover how to create the views in the interface designer in Xcode. The controller will be a subclass of UIViewController which will be called ProductViewController.

Setting up the project

Start by creating an empty iPhone project by selecting File->New->Solution… in MonoTouch and then selecting C#->MonoTouch->iPhone->Empty Project in the New Solution window. Name your project “MVCTutorialOne” as shown in the screenshot and click “OK”.

Right-click on the MVCTutorialOne project node in the Solution pane and select Add->New Folder to create a new folder. Name it “Models”. Then create two more folders named “Views” and “Controllers”. These folders are not required for the application to work, but they help to reinforce which files in the project are supporting which roles in the MVC pattern we are following. When you have finished this step, your project should look like the following screenshot:

Creating the Product model

Right-click on the Models folder and select Add->New File… Select “Empty Class” from the “General” category. Name the class “Product” and click “New”. Add two public properties to the class, a Name property of type string and a Price property of type double. We don’t need the default constructor, so you can delete it if you want. Your model class should look like (or similar) to this:

using System;
namespace MVCTutorialOne
{
    public class Product
    {
        public string Name { get; set; }
        public double Price { get; set; }
    }
}

Very simple object to represent a basic product.

Creating the Product view

Right-click on the Views folder and select Add->New File… Select “Empty Class” from the “General” category. Name the file “ProductView” and click “New”. There are options in the “MonoTouch” category for creating views with and without view controllers but they all create Interface Builder files for creating the user interface. Since we are creating the view manually in code, we want to start with an empty file.

The following steps are based on the Checklist for Implementing a Custom View which is found in the View Programming Guide for iOS.

Step One: Add using statements for System.Drawing and MonoTouch.UIKit to the top of your ProductView class.

using System.Drawing;
using MonoTouch.UIKit;

Step Two: Set the superclass for ProductView to UIView.

public class ProductView : UIView
{
    // ...
}

Step Three: According to the checklist, since we are planning to create the view programmatically we need to implement the version of the constructor that takes a frame as the parameter.

// Initialization
public ProductView (RectangleF frame): base(frame)
{
    // ...
}

Step Four: The next step in the checklist that pertains to our view is setting the AutoresizingMask, which we’ll add to the constructor. We’ll also set the background color of the view to white.

// Set the background color for the view
this.BackgroundColor = UIColor.White;

// Set the AutoresizingMask to anchor the view to the top left but
// allow height and width to grow
this.AutoresizingMask = (UIViewAutoresizing.FlexibleRightMargin | UIViewAutoresizing.FlexibleBottomMargin | UIViewAutoresizing.FlexibleHeight | UIViewAutoresizing.FlexibleWidth);

Step Five: Next up in the custom view checklist is the creation and initialization of the subviews the custom view will manage. In our view we will have 3 subviews: the name label, the price label, and the increment button. Create public properties for the three subviews.

// Subview properties
public UILabel NameLabel { get; set; }
public UILabel PriceLabel { get; set; }
public UIButton IncrementButton { get; set; }

To create the name label and add it to the ProductView, add the following code to the ProductView constructor:

this.NameLabel = new UILabel () {
    Frame = new RectangleF (20, 20, 280, 20),
    AutoresizingMask = (UIViewAutoresizing.FlexibleWidth | UIViewAutoresizing.FlexibleRightMargin)
};
this.AddSubview (this.NameLabel);

This code sets the location of the name label to be 20px from the top and left of ProductView. It also sets the width to 280px and the height to 20px. All of these are set on the Frame property. The AutoresizingMask is set such that the width will be flexible while remaining anchored to the left side. Add similar code to the constructor to set up the price label (the only difference is the y-coordinate in the Frame):

this.PriceLabel = new UILabel () {
    Frame = new RectangleF (20, 49, 280, 20),
    AutoresizingMask = (UIViewAutoresizing.FlexibleWidth | UIViewAutoresizing.FlexibleRightMargin)
};
this.AddSubview (this.PriceLabel);

Now we will add code to create the increment button subview.

// Create a default rounded rectangle button
this.IncrementButton = UIButton.FromType (UIButtonType.RoundedRect);

// Set the frame
this.IncrementButton.Frame = new RectangleF (20, 78, 280, 37);

// Adjustible width with left anchor
this.IncrementButton.AutoresizingMask = (UIViewAutoresizing.FlexibleWidth | UIViewAutoresizing.FlexibleRightMargin);

// Set the title to "Increment Price $0.10
this.IncrementButton.SetTitle (String.Format ("Increment Price {0:C}", 0.1), UIControlState.Normal);

this.AddSubview (this.IncrementButton);

Since our subviews don’t require and custom layout and we aren’t handling any touch-based gestures in the ProductView class, we have satisfied the custom view checklist. The final ProductView class should look like this:

using System;
using System.Drawing;
using MonoTouch.UIKit;

namespace MVCTutorialOne
{
    public class ProductView : UIView
    {
        // Subview properties
        public UILabel NameLabel { get; set; }
        public UILabel PriceLabel { get; set; }
        public UIButton IncrementButton { get; set; }

        // Initialization
        public ProductView (RectangleF frame): base(frame)
        {
            // Set the background color for the view
            this.BackgroundColor = UIColor.White;

            // Set the AutoresizingMask to anchor the view to the top left but
            this.AutoresizingMask = (UIViewAutoresizing.FlexibleRightMargin | UIViewAutoresizing.FlexibleBottomMargin | UIViewAutoresizing.FlexibleHeight | UIViewAutoresizing.FlexibleWidth);

            this.NameLabel = new UILabel () {
                Frame = new RectangleF (20, 20, 280, 20),
                AutoresizingMask = (UIViewAutoresizing.FlexibleWidth | UIViewAutoresizing.FlexibleRightMargin)
            };
            this.AddSubview (this.NameLabel);

            this.PriceLabel = new UILabel () {
                Frame = new RectangleF (20, 49, 280, 20),
                AutoresizingMask = (UIViewAutoresizing.FlexibleWidth | UIViewAutoresizing.FlexibleRightMargin)
            };
            this.AddSubview (this.PriceLabel);

            this.IncrementButton = UIButton.FromType (UIButtonType.RoundedRect);
            this.IncrementButton.Frame = new RectangleF (20, 78, 280, 37);
            this.IncrementButton.AutoresizingMask = (UIViewAutoresizing.FlexibleWidth | UIViewAutoresizing.FlexibleRightMargin);
            this.IncrementButton.SetTitle (String.Format ("Increment Price {0:C}", 0.1), UIControlState.Normal);
            this.AddSubview (this.IncrementButton);
        }
    }
}

Creating the Product view controller

Right-click on the Controllers folder and select Add->New File… Select “Empty Class” from the “General” category. Name the file “ProductViewController” and click “New”. There are options in the “MonoTouch” category for creating ViewControllers, but this templated approach will add a lot of methods we won’t need and might make it difficult to understand what is going on. It’s better to build the view controller with only the parts we need.

Step One: Add using statements for System.Drawing and MonoTouch.UIKit to the top of your ProductView class.

using System.Drawing;
using MonoTouch.UIKit;

Step Two: Set the superclass for ProductViewController to UIViewController.

public class ProductViewController : UIViewController
{
    // ...
}

Step Three: Since our controller will be coordinating a product model and the product view, we will create fields to manage these objects.

// Model
private Product _product;

// View
private ProductView _productView;

Step Four: In the constructor for the view controller, initialize the _product model and set some values for the product. (Note: Since the model object is small and we are using static data, we will create the product here in the constructor for this tutorial. In a situation where we need to fetch more substantial data we’ll need to asynchronously fetch the data at a different point in the process. This will be covered in a later tutorial.)

public ProductViewController ()
{
    _product = new Product () { Name = "Strawberry Fizzy Pop", Price = 1.59 };
}

Step Five: We are going to use a few methods that update the _productView’s labels based on the _product model’s values. These will be needed later in the view controller creation process.

public void UpdateNameLabel ()
{
    _productView.NameLabel.Text = string.Format ("Product Name: {0}", _product.Name);
}

public void UpdatePriceLabel ()
{
    // Format as currency
    _productView.PriceLabel.Text = string.Format ("Price: {0:C}", _product.Price);
}

Step Six: Next, we need to override the LoadView method. This method is used to programmatically load the view for the view controller when an Interface Builder XIB is not being used to create the view. We didn’t create or refer to the view in the view controller’s constructor because iOS lazy loads the view controller’s view. LoadView will only be called if the ProductViewController.View property is accessed and is null at the time of access.

public override void LoadView ()
{
    // Set the frame for the product view to fill the screen taking into
    // account the 20px tall status bar.
    _productView = new ProductView (new RectangleF (0, 20, 320, 460));
    this.View = _productView;
}

Step Seven: Once the view has loaded, there is a method that will get called on the view controller called ViewDidLoad. We can override this method to provide code to customize the newly loaded view. All of the view hierarchy for the view controller will have been created by this point so it is safe to update these objects. We first call base.ViewDidLoad() to allow for superclass initialization. Then, we call the UpdateNameLabel() and UpdatePriceLabel() methods to set their text based on the _product model.

if (_product != null) {
    UpdateNameLabel ();
    UpdatePriceLabel ();
}

In the MVC object introduction I mentioned that one of the view responsibilities was responding to events. ProductView’s IncrementButton object can respond to a variety of touch related events. The one we are interested in is the TouchUpInside event which will fire when a user presses and releases the button. We will set up an event handler for this event in the ViewDidLoad method the first updates the _product model’s Price property and then calls UpdatePriceLabel() to refresh the price label based on the new model value. (Note: I am using lambda syntax but you can use a delegate as you would with any other event.) This is a very good example of the type of coordination work a controller performs in the MVC pattern.

_productView.IncrementButton.TouchUpInside += (s,e) => {
    _product.Price += 0.1;
    UpdatePriceLabel ();
};

Step Eight: There is one last method we will override in our view controller for this tutorial. This method is the ShouldAutorotateToInterfaceOrientation (UIInterfaceOrientation toInterfaceOrientation) method. By overriding this method we can define which orientations we wish to support in the application. For this tutorial, we will support all orientations except PortraitUpsideDown.

public override bool ShouldAutorotateToInterfaceOrientation (UIInterfaceOrientation toInterfaceOrientation)
{
    // Support all but the "upside down iPhone" orientations
    return toInterfaceOrientation != UIInterfaceOrientation.PortraitUpsideDown;
}

At this point, the view controller code is complete. All iOS applications have a single window which can contain a view hierarchy. To add our ProductViewController’s view to the window, we’ll need tocreate an instance of ProductViewController in the AppDelegate’s FinishedLaunching method and add its view to the application window’s subviews.

var pvc = new ProductViewController ();
window.AddSubview (pvc.View);

Once this step is completed, our app is done. Run the application and try pressing the Increment button to see the price change.

Get the code

If you’re having trouble with recreating the tutorial, you can find the original source on GitHub at https://github.com/brentschooley/monotouch-tutorials

Conclusion

This article and corresponding tutorial introduced the Model-View-Controller pattern that is used in MonoTouch. We created a simple model object, a custom view to represent it, and a controller object to make them work together within the iOS framework. The next tutorial will cover creating the view objects as Interface Builder XIB files and hooking them up to a view controller. A follow-up to that tutorial will cover how to load a data model from a SQLite database asynchronously and display it in a table view.

It has been a bumpy road for those who want to use .NET to target iOS and Android.  The products we’ve had available to us were definitely not the problem — they are fantastic.  The big hurdles have always been related to legal and availability issues.  MonoTouch was released in September 2009 and immediately questions were raised as to whether Apple would allow it.  There was a bit of a war of words between those who would use MonoTouch and Cocoa developers who thought it was a bad idea to not use and learn the native tools/platform.

After about 7 months of Apple allowing apps to be developed with third party tools and languages, they dropped a bombshell on all of us on April 8, 2010 with the infamous change to Section 3.3.1 of the iOS Developer Program license.  The changed section read:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This looked to be a deathblow primarily aimed at Adobe.  Adobe has a set of tools that allows for developers to create iOS apps in Flash and Apple wasn’t too keen on that idea.  Unfortunately, this meant that MonoTouch fell under this new restriction and there was a lot of worry that we would lose the ability to create iOS apps with C# forever.  However, Miguel and his team at Novell pledged to move forward despite the change to Section 3.3.1.  Miguel proposed a few theories on his blog and explained why he thought MonoTouch was misrepresented in the conversations regarding 3rd party tools and languages.  Many in the community stuck around in spite of the change while others were unable to due to their companies not wanting to wade through the uncertainty.  Those that stuck around quickly found that Apple was still allowing apps developed with MonoTouch into the App Store.  Section 3.3.1 was clearly a policy that Apple was going to enforce on a very subjective basis.  Either they did not want to enforce it in all cases, could not enforce it in all cases, or were using it to pick and choose their battles.

Thankfully, it didn’t last long.  On September 9th, 2010 (almost a year after MonoTouch was officially released), Apple published a statement announcing a change to Section 3.3.1.  The new version of the section relaxed “all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code”.  This was a definite victory for the 3rd party platforms and indicated that the path was clear for MonoTouch to thrive.

Now we come to the aforementioned whirlwind that was kicked up on May 3rd of this year by InternetNews.com when they reported that Attachmate “laid off an unknown number of U.S. based Novell developers that were working on the open source Mono project” (link).  What followed was an almost two week period of uncertainty.  Was the rumor true?  Was the entire Mono team released or did some of them stay?  What about MonoTouch and MonoDroid?

None of these questions were answered until May 16th, 2011 when Miguel announced the formation of Xamarin which would carry the torch for iOS and Android development using C#:

This set off another round of speculation since Xamarin was going to be developing new tools instead of leveraging the existing MonoTouch code.  This was primarily due to licensing issues regarding Mono and MonoTouch/MonoDroid.  The plan was for the team to rapidly get up to a public beta on the new tools within a few months.  Clearly, they had their work cut out for them.

Again, however, the uncertainty surrounding the future of Mono was short lived.  On July 18th, Miguel announced on his blog that a partnership had been formed between Novell/Attachmate and Xamarin.  The partnership included Xamarin obtaining a perpetual license for “all the intellectual property of Mono, MonoTouch, Mono for Android, and Mono for Visual Studio” which would allow them to begin immediately selling and supporting MonoTouch and MonoDroid.

This brings us to today where we now have the opportunity to benefit from all that has transpired in the past.  We are able to buy MonoTouch in its current state and get support from the team that created it.  We will also benefit immensely from the work that the team did in the time between May and July of this year.  A lot of new ideas were formed in this time period.  This is very common when you take a fresh look at an existing problem.  Miguel has stated that these new features will be rolled into the existing MonoTouch codebase in future versions.  So, where is MonoTouch heading?

I think now that the team has the opportunity to fully focus on the future of C# for mobile, we are likely to see some wonderful things coming soon.  Xcode 4 integration was previewed at one point for MonoTouch and I can’t wait to see that full integration happen.  iOS 5 is on the horizon and if the past is any indication, MonoTouch will be ready to support it when the time comes.  Miguel has also mentioned improvements to MonoDevelop which would be welcomed with open arms.  I guess what I’m waiting for more than anything are the surprises that the team most likely has in store for us.

All I can say is I’m hoping for a bright (and stable) future for MonoTouch!

Update: Seems like the future is now!  Miguel announced Mono 2.10.3 and there also is a new version of MonoTouch (4.0.4.1).

A lot has been said about the iPad in the week since Steve Jobs unveiled it to the world at the Yerba Buena Center for the Arts in San Francisco. The response has ranged from jubilation from those who consider the

device a must have all the way down to disdain and utter contempt from those who were somehow hoping this companion device would be able to replace their laptops. While I understand both camps (and everyone in between), I’m not going to voice my allegiance to either opinion.  To be honest, I’m actually somewhere in the middle. I would much rather discuss how important this device is to the already thriving iPhone ecosystem and why you will want to develop for the iPad.

Without divulging any specific iPhone 3.2 SDK details (and thereby breaking my NDA), I can tell you that the new APIs and features present in the SDK are very exciting. Some of them are iPad specific and others will probably be available for iPhone development some time in the near future. If you have been doing any iPhone development, you are already familiar with the tools, languages, and concepts necessary to program for the iPad. From what was shown in the iPad event, it is clear that the applications that are possible for the iPad are much more robust than anything we have seen or created for the iPhone. The split pane and popup menus provide the ability to do a lot with the copious screen real estate the iPad offers. I don’t want to spend too much time talking about the SDK because I can’t do it justice without breaking the NDA. Just suffice it to say that if you haven’t looked at it yet, you really need to. It’s exciting.

As for the hardware, I think the story there is pretty phenomenal too.  The larger screen will allow developers to create applications that are much closer to desktop functionality than the much smaller iPhone screen currently allows.  The Apple A4 processor (which is apparently based on the same ARM Cortex A9 as the Nvidia Tegra chip) appears to be very snappy which should allow for a smooth user experience.  The accelerometer is there in full force and there are speakers and a built-in microphone.  There is GPS capability in the 3G models.  This opens the door for some fantastic GIS applications.

One last thing that is easy to overlook from a developer’s perspective is the financial impact of this device.  The people that will buy this device will buy your applications if they add value to their iPad experience.  They had the funds to purchase the device at a minimum entry point of $499 so it is almost a given that they will be willing to plunk down some money on your well written apps.  It would be wise to not leave them hanging.

So, there’s my take on the new device.  I, for one, am beginning development on my first application and hope to have it ready by launch time.  I encourage all developers to follow suit.  We are what will make this device a must have.

I may call on a few of you in the community for help on this project and I look forward to your input when that time comes.  Stay tuned to this this blog (subscribe to the RSS feed!) for more updates as they become available. 

I have modified the uitvc template for generating a UITableViewController that uses this new UITableViewSource class.  Create an Empty class file from the File->New File…->General menu.  Delete everything in this class file.  Type uitvc and hit the tab key. This will create a UITableViewController subclass that sets up a UITableViewSource as its Source.  All you need to do is specify the namespace for the controller, the name for your class, the shorthand that will be used to reference the instance of the controller in the UITableViewSource, and the Title for the controller.  I have provided a few overrides that will get you started after that.  You can download the template here: uitvc.template.xml

You will need to add this to ~/.config/MonoDevelop/templates/code (choose “Go to folder…” from the Finder menu and paste the directory to find it) and restart MonoDevelop. (Note: If you don’t see templates/code in ~/.config/MonoDevelop, go to Preferences in MonoDevelop and click on Code Templates under Coding.  This should populate this directory.  You don’t need to do anything else here, just close Preferences and follow the instructions above to add the file to the ~/.config/MonoDevelop/templates/code directory.)

The really cool thing about this debugging support is that it works on both the simulator and the device.  Since Apple does not directly allow third parties to participate in their debugging infrastructure, Geoff Norton and Michael Hutchinson, et al., had to do a lot of work to get this to work and they should be commended for their efforts.  Debugging MonoTouch requires the iPhone to communicate back to the computer.  From the upcoming documentation at http://monotouch.net/Documentation/Upcoming/Debugger:

The MonoTouch debugger is a soft-debugger, that means that the generated code and the Mono runtime cooperate with the MonoDevelop IDE to provide a debugging experience.  This is different than hard debuggers like GDB or MDB which control a program without the knowlege or cooperation from the debugged program.

For on device debugging, your iPhone needs to be on the same Wi-Fi network as your computer (yes, debugging over Wi-Fi…even Apple doesn’t completely allow this).  You should note that the debug build of your code will include the cooperative Mono runtime so the resulting program will be larger than a regular program. This is because the generated code has been instrumented to be debugged.   A debug build will also be slower than a regular release build so it should not be used for performance testing.

The team has put a lot of really hard work into this.  The result of this work is a truly native feeling debugging atmosphere that should be familiar to anyone who has used IDE debugging in the past.  You set a breakpoint on a line and when your code hits that breakpoint you can inspect local variables in the Locals window, see the Call Stack in the Call Stack window, and get on-hover information for variables in your code.  At the end of this post there are screenshots for you enjoyment (and salivation!).

I can really only summarize this release in one word: awesome.  Go check it out for yourself later today at http://monotouch.net and stop into the IRC channel at irc.gnome.org #monotouch and say thanks to the development team for this awesome feature.

Update: According to Miguel de Icaza, there will be a beta of MonoTouch 1.2 available later today.

Here are the screenshots I mentioned previously:

If you have purchased MonoTouch, you can download the updated version from the download link provided when you purchased the product. 

If you are using the evaluation version you can download the updated version of MonoTouch from http://monotouch.net/DownloadTrial to receive the update.
You can download the updated MonoDevelop at: http://monodevelop.com/Download/Mac_MonoTouch 

Highlights:

            • All new iPhone 3.1 APIs are now available.
            • Native code generation is now 30% smaller for core assemblies.
            • Reduced startup time by up-to 50%.
            • Web Services support.
            • MonoDevelop now has an updater feature, so developers can more easily get the latest Mono, MonoDevelop and MonoTouch.

Fixes:

            • Fixed invalid CFRelease in CFRunLoop (#541524)
            • Fixed IList<T> in full-aot (#540355)
            • Fixed Delegate.BeginInvoke in full-aot
            • Fixed XElement[].Count in full-aot (#539085)
            • Fixed MKAnnotation in Simulator
            • Fixed linker to not always pull in Mono.Security
            • Fixed System.Timer linked-away exception
            • Decreased startup time on device by up to 50%
            • The System.JSon assembly is now available for inclussion.

Additions:

            • Added bindings to new 3.1 APIs
            • Added generic trampoline for marshal-runtime-invoke wrappers, providing significant code savings (34% on mscorlib size, equivalent savings for other assemblies).
            • Added 2 new ctors to NSFoundation.NSMutableUrlRequest
            • Added additional support for alternate types to NSData
            • Added new StringSize overloads to UIView
            • Added CALayer.Sublayers property
            • Added CoreAnimation.CATransaction class
            • Added new SystemSound constructors
            • Added SystemSound.FromFile (string)
            • Added System.Web.Services client support.
            • Added WCF client support (EXPERIMENTAL)
            • Added support to emit DWARF debug symbols in full-aot mode
            • Added support to be auto-updated from MD.
            • Updated keybidings to MonoDevelop for Emacs.

Changes:

            • SystemSound.FromFile no longer throws exceptions on error, and instead will return null.
            • iPhoneOSGameView no longer calls GL.Oes.BindFrameBuffer () during the second and subsequent CreateFrameBuffer () calls.  Code overriding iPhoneOSGameView.CreateFromBuffer () does not need to call GL.Oes.BindFramebuffer (All.FramebufferOes, base.FrameBuffer) to add a depth buffer to the frame buffer.

If you have any questions or concerns please see http://monotouch.net/Support

Please help me in my planning for the upcoming MonoTouch screencast series.  Screencasts will be the same (or better!) high quality as the “Getting Started With MonoTouch” screencast.  The goal of the series will be to take the viewer through all aspects of iPhone development and provide comprehensive training for this development framework.

To keep the quality at this level and produce the number of screencasts that will be needed to cover all of the topics that need to be covered, these screencasts will not all be able to be free.  That is where I need your feedback.  Please submit your answers to the following polls to help me make some pricing decisions!  Your input will help make this training series successful.

Update:

An update to this screencast for MonoTouch 5 will be coming soon.  Other than downloading from http://ios.xamarin.com instead of the old MonoTouch site and some changes to MonoDevelop, most of the concepts in this screencast are still valid.

MonoTouch is a new framework from Novell for creating iPhone applications using C#.  Since some of the concepts of developing for the iPhone platform will be foreign to the .NET developer, I thought it would be a good idea to create a screencast that eased them into the process.  Since a lot of .NET devs will be new to the Mac, I have tried to make as few assumptions as possible with regards to the your comfort level and proficiency with Mac OS X.

In this screencast, I will walk you through installing Mono (the open source cross platform .NET implementation), MonoDevelop (an IDE), and MonoTouch.  Once everything is installed, we will develop a “Hello iPhone” application.  Throughout the process of developing this application I will introduce you to core concepts of MonoTouch as well as familiarize you with Interface Builder (Apple’s tool for creating iPhone interfaces).

Getting Started with MonoTouch : click to view screencast

I hope this screencast helps get you up and running creating awesome iPhone applications using C#!

Note: The link to the web client for the IRC channel is actually on the Community page, not the Support page at monotouch.net.

If this screencast helped you, consider “touching” is to promote it at MonoTouch.info by clicking the “Touch it” button below and “kicking” it to promote it at DotNetKicks.