Because Objective-C sometimes makes me want to poke out my eyes with sharp sticks, I’m relieved to see that there are finally other options. Now let me be clear. I think objective-C would be a fine language if it was something that I used day in and day out, but given that I only tinker in it and spend the majority of my time in .NET, I can’t help but see MonoTouch as a godsend.

MonoTouch is a framework, created by the brilliant mono team at Novell, that allows developers to use C# for coding iPhone apps. Not only have they ported the .NET framework to run on the iPhone, but they’ve bound it to the iPhone API. In addition, they provide a first class develop environment in the form of MonoDevelop on the Mac.

This brings up an important point. You still need a Mac to develop C# on the iPhone using MonoTouch. Luckily, I have my trusty Mac mini so I thought I’d take MonoTouch for a spin by porting my existing Objective-C app to MonoTouch.

Background

I developed an iPhone app in Objective-C over the summer and it was approved by Apple. It’s called BragVest and allows Cub Scouts to track their progress toward ranks. It’s currently live in the app store and getting some great feedback from users. I have a lot of ideas for new features, but implementing them is a different story.

When coding in Objective-C, I spend too much time just looking up how to do simple operations. What’s the best way to load a plist? How should I best concatenate that string? Operations that should be simple and probably are to a Mac developer or someone who spends a lot of time with the language.

It’s a simple case of focusing on your strengths. I’m a professional .NET programmer and have been for a long time. I can crank out .NET code in my sleep, but programming in objective-C sometimes feels like I’m pushing a boulder up a hill. It just takes a lot longer to get a feature implemented and I spend a lot of time just looking up language features.

So, in theory, MonoTouch would be a great fit for me. I’ve already mostly learned a lot of the iPhone API, and now I get to use a language I know and love — C#.

At this point, I’m about 75% through porting my app to MonoTouch, and here’s what I’ve learned.

The Good

There’s a lot to enjoy about working with MonoTouch:

• MonoDevelop: MonoDevelop feels much more like Visual Studio.NET (my native development environment) than XCode does. I spent many months in XCode and it just takes a different approach to development. MonoDevelop seems like it was modeled after VS.NET so I felt productive almost immediately.
• C# language: It’s great to have access to the C# language. It feels much more natural to me than Objective-C. I’m sure this is just a matter of experience, but the bulk of my experience is with C#. Also, I’m glad not to have to deal with memory management so I can focus on developing new features and not writing plumbing code.
• .NET Framework: Being able to access the .NET framework is huge, and probably one of the biggest selling points of MonoTouch. Need to parse a plist? No longer do you have to resort to NSArrays and NSDictionaries. Just fire up LINQ to XML! Need to do some fancy string parsing? Don’t use NSString. Just use the standard .NET string type. They also put a lot of thought into translating between the Apple and .NET APIs so it’s mostly seamless. If you need to see how a particular class or API was translated, check out the MonoTouch Rosetta Stone.

The Bad

Most of the issues that I ran into have to do with the fact that this is still a very new platform:

• Lack of Samples/Docs/Community: This was the hardest part of developing with MonoTouch. When I was working with the apple tools, if I wanted to know how to do something in Objective-C, I could generally google for it and quickly find an example. The blogs and docs are just starting to pop-up for MonoTouch so it can be much harder to find real-world examples.
• Stability: One of the most frustrating parts of developing in MonoTouch was that the IDE  (MonoDevelop) would crash on me or throw strange exceptions periodically. It seems to mostly be related to the subversion integration so maybe if I disabled that I’d have more stability. That said, I have not seen any stability issues when the code is running on the phone so that’s what’s important.
• Not Fully Implemented: Every now and then, I would want to do something with MonoTouch and get a “Not Implemented Exception” (such as some LINQ features) or I couldn’t figure out how it was translated (such as NSMutableDictionary).

Some people would also mention cost ($399), but I don’t think that’s fair. The mono team have put in an amazing amount of work that provides real value to developers. It’s only natural, that they should be compensated for it.

I also think the increased file size of MonoTouch app is small price to pay for all the features and frameworks you get.

Verdict

In my opinion, there is more than enough good to outweigh the bad in MonoTouch. I’m also hoping that much of the bad will disappear as the platform matures.

For an experienced .NET developer, it will give you a huge head start in iPhone development especially if C and memory management make you squeamish. That said, there is still a heavy learning curve with getting used to the Mac, the iPhone API, and Interface Builder. And MonoTouch does not eliminate the need to learn how to make a iPhone app that fits Apple’s design guidelines (which you will have to do to get it approved).

Overall, I’m planning to invest in it, and if you are an experienced .NET developer wanting to develop apps on an iPhone I would recommend you take a look as well.

Let’s say you bit the bullet and followed the 5 Steps for Moving to Strict HTML 4.01. Now you have nice, clean HTML. But what if you’re not satisfied and you want to go all the way to strict XHTML? You want to have the cleanest, strictest markup possible!

Well, you’ve come to the right place! Here are the steps to move your mangy HTML doc into the pristine world of XHTML.

1) Add the Correct DOCTYPE

Add the strict XHTML DOCTYPE to the top of your page (replacing any other doctype):

<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

2) Add a namespace

XML documents (and therefore XHTML) require a namespace to define what they are and XHTML is no different

<html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en” lang=”en”>

3) All tags and attribute names must be lowercase

In XML, this does not match <strong>look I’m bold</STRONG> because the beginning and ending tag is a different case.

So in xhtml it needs to look like this: <strong>I’m bold XHTML!</strong>

4) Documents must be well-formed

Any tag that you open, you must close even if there is only one tag. So <br> tags need to be turned into <br />. And tags cannot overlap so this is not allowed:

<strong>this is not <em></strong>right!</em>

5) Attributes must be quoted

Maybe in old-school HTML you could get away with this: <img src=coolgraphic.jpg>

But in the world of XHTML, you will need to do this: <img src=”coolgraphic” />

6) No Attribute minimization

In HTML you were allowed to do this: <input checked>

But XHTML requires that you spell out your attributes like so:

<input checked=”checked>

7) Encode ampersands

XML does not allow ampersands so they need to be encoded as &amp;

8 ) CDATA around Javascript

You will need to escape out your javascript by encoding it in a <![CDATA[ like so:

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>

A CDATA is just the XML way to ignore a piece of data.

9) Move from name to id

In XHTML the name attribute is formally depreciated in favor of the id attribute.

So this: <img name=”coolpic”>

Needs to become this: <img id=”coolpic” />

10) Validate!

Once you have turned your HTML into shiny XHTML, you can double-check that you did everything correctly by going to the W3C Validator: http://validator.w3.org/

And if you read all the way to the bottom, I’ll tell you a little secret. You don’t even need to do these steps by hand! You can use the magical HTML Tidy application to move your documents from HTML to XHTML.

Recently I’ve been brushing on web standards – those pesky guidelines that the W3C has come up with for clean HTML. Why, would I want to torture myself you ask? Well, I think that web standards, while not required, are a good practice.

In my mind, following web standards are the best way to future proof your web app and to ensure that it renders as correctly as possible across as many browsers as possible.

Also, I agree with Jeff Attwood that while HTML Validation against web standards may not matter that much in the big scheme of things, just knowing the rules makes you a better developer. Lastly, I think he’s correct that striving for Strict HTML 4.01 is the sanest start with (as opposed to Strict XHTML).

So let’s dig into the rules of what it takes to achieve Strict HTML 4.01.

1. Start with a Visit to the DOCTYPE

Every HTML page you write should start with a DOCTYPE. It tells the browser what kind of document to expect and determines which rules it uses to render a document. For HTML strict, you’ll want to put this at the very top of your page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

2. Every Page Needs a Head and Body

Next we get to the basic stuff that I’m sure you’re already doing, but let’s just review them here for completeness.

After the DOCTYPE, you’ll need to include an <html> tag. Inside the <html> tag, you’ll need to have a <head> and <body>. Inside the <head> you’ll need a <title>.

That wasn’t so bad, was it? Now onto the hard stuff… 

3. Keep Your Blocks and Inlines Straight

Before we get into this, let’s talk about what a Block element is and what an Inline element is. The short answer is that Block elements will begin a new line whereas inline elements will not.

For example, this paragraph is surrounded a by <p> tag which is a block-level element and therefore your browser rendered it as a separate paragraph. On the other hand, this piece of text is surrounded by a <b> tag which causes it to render inline.

Below are some examples of each.

• Block-level elements: <div>, <h1>…<h6>, <p>, <ul>, <ol>, <li>, <table>, <tr>, <th>, <td>, <blockquote>
• Inline elements: <span>, <a>, <em>, <strong>

Now that you know the difference, let’s talk about the rules: You can only have block elements directly under you <body> tag, and no block elements can be included in inline elements.

Make sense? Good. Because now we’re moving onto the “special” cases.

4. Some Tags are “Special”

 Now that you know the rules, let’s talk about the tags that were born to break them!

The <li> tag will let you put whatever you want inside (block, inline or text) and it will still validate while the <blockquote> tag requires another block element before entering any text.

Why is this? I’m not exactly sure, but I trust that the all-wise W3C has their reasons…

5. When in Doubt, Validate!

If you have any question about whether your HTML page is truly fitting the HTML 4.01 Strict standard, you can always validate it with the W3C. Just enter your site’s URL or HTML and the validator will gladly tell you what you did wrong.

Or if you are really lucky, he’ll say that everything is correct and give you this pretty badge to put on your site:

I’m still working on getting one for my sites…