MonoDevelop isn't bad, but I really prefer VisualStudio

In my last entry I described how I decided to do my iOS development on MonoTouch. Now I discuss how despite the increased efficiency of a familiar language (C#), I still struggled with the MonoDevelop IDE.

First, let me say that my dissatisfaction with MonoDevelop (MD) is in due to comparing it to Visual Studio (VS). According to Wikipedia, VS started in 1997. Clearly it isn't fair to compare the maturity and depth of features of a product that has been under development for more than 13 years to one that is only a few years old. Also, I'm sure the size of the development teams are greatly unequal. Despite that, the reality for me was that I found MD falling short of what I was used to wanted.

I noticed on the MonoTouch Roadmap page that they plan to extend Mono for Visual Studio to "allow developers to use Visual Studio to develop iPhone applications", but since no timeline is given I have no idea when this will happen. So, I tried to do something on my own.
MD saves projects in the same format as VS, so my first thought was to just open the project there and see what happens. I tried this, but VS complained of some error. I did a search and found a page suggesting a solution called VSMTouch.

The solution was to convert the MD projects so that VS can open them. Although the format of the files are the same, the MD projects refer to certain iPhone specific libraries, which don't exist on a Windows PC, of course. What this means is that even using VSMTouch will create a project that can be open in VS, but can't be compiled.

Well, although that  allows me to edit in my familiar environment, I still was not satisfied. VS has some great features that require the ability to compile (e.g., FxCop and built-in unit test framework). Also, I knew that I would want the ability to run my game relatively often as I develop it to test new things. Additionally, in the long term, MT plans to support Android, and Windows Mobile 7 will support .NET out of the box, so there are strong incentives for me to be able to develop more fully across platfroms.

Next time: Divide and Conquer.

iPhone Does .NET

In my last entry I described how I began the process of developing a game for iOS. Now, I'm going to continue that story with what's changed since 1 and ½ years ago when I started.

When I was developing initially I was reading a number of news feeds related to iPhone development to try to learn as I went. I remember at that time Novell announce a Mono based platform for iPhone development. This was very intriguing to me at the time, since Mono is an opensource implementation of the .NET framework, with which I have a lot of experience; far more than C, C++, and Objective-C, which are the default languages for iPhone development. I didn't really look into it at the time as it was pre-release and, if I remember correctly, advertised as being around $1000 for a license.

When I recently returned to developing my game, however, I again quickly became frustrated by the Xcode development environment and the learning curve involved for me. Around this time Apple announced greatly relaxed development restrictions and I remembered the Novell announcement and decided to see how the maturity of the platform was now. As it turns out, MonoTouch (the name of the Novell platform) is still undergoing rapid development and is at the point where it is quite usable. Also, the price either changed or I misremembered and is down to $399 for individuals.

Novell has a free version of MonoTouch that has only the limitation that you can run your program only in the iPhone emulator and not on an actual device, so I downloaded that and started porting my game over from the old C & C++ & Objective-C version I'd previously worked on. I should mention that MonoTouch includes a version of MonoDevelop, an opensource .NET IDE, that integrates well for developing for iPhone.

After a bit of work I got enough of my game running to see that it would work on MonoTouch and that it seemed to run fast enough on .NET on the emulator on my Mac. But, I was a bit worried how well it would run on an actual iPhone.

I debated for a while, but then noticed that Novell was having a sale for MonoTouch of 15% off in celebration of 1 year of MonoTouch, so I jumped in and signed up. I then deployed to my iPhone and was pleasantly surprised at the performance. Everything looked fine.

Admittedly $399 is still a bit of an investment, but I'd already paid for a used iMac (about $300 or $400, I don't remember) and 2 iOS Developer licenses ($99 each year), so I decided to double-down and improve the chances I actually finish the game this time.

Next time: MonoDevelop isn't bad, but I really prefer VisualStudio.

Zoing: The Beginning...

About 1 and ½ years ago I decided I wanted to write an iPhone game. I've had the game idea for a long time and actually implemented a mostly-working version on my Amiga 20 years ago or so, but with the App Store and the iPhone ecosystem, I felt there was finally a way to get the game out there and into peoples hands.

I bought a used iMac from a coworker, signed up as an iPhone OS (now iOS) developer, and began. I immediately ran into a bunch of issues that slowed me down. I hadn't used a Mac in many years, I was new to OpenGL and found most documentation targeted the full OpenGL API, not the more limited mobile version (OpenGL ES), and I found the Apple Xcode development environment unintuitive and feature-limited (sorry, Apple, but despite you repeating that it is a great IDE, it absolutely pales in comparison to Visual Studio).

But, I kept at it. I figured out how to get around the Mac, I found a few OpenGL ES examples to get me started, and I was able to set aside the features I prefer in Visual Studio and use Xcode well enough. Within a month or so (I have a day job too, so I can't put too much time into this), I got enough running to show the main idea of the game. Heck, I even got OpenAL (the audio system to play sounds in the game) included.

Then I changed jobs, and I became very busy at my new job and had no time to work on my game. Then time passed, and my iOS Developer subscription expired.

But, now I'm back. I've renewed as an iOS Developer, and I'm determined to get the game done and released.

Next time: iPhone does .NET.

Adding PDF's to your iPhone (or iPad) from anywhere

So, you're someplace away from your iTunes account and want to add a PDF to your iPhone's or iPad's iBooks collection. How can you do this?

Well, the first way is you can email it to yourself. The problem with this is that your email account (either sender or receiver) may have size limitations that prevent sending large PDFs. If the PDF is too big then here's another idea...

You can use some online storage service, copy the PDF there, open it is Safari, then choose the "Open in iBooks" option. This will both open it in iBooks and copy it into your library.

I poked around on the net a bit and found that Microsoft's Windows Live SkyDrive works pretty well. You get 25GB free, although there is a 50MB per file max upload size.

Making .NET web services use HTTP compression

So, there's two parts to making this work: configuring the server correctly, and coding the client correctly. Both parts are pretty simple, but there are a few gotchas.

First, on the server side, you need to enable HTTP compression and make sure all of the options work for your web services. In IIS 6 the GUI for configuring a web site does provide the ability to enable HTTP compression (it's under the Internet Information Service → Web Sites → Properties (right-click) → Service tab), but there is no way to set which file extensions are compressed. Microsoft has a page that explains how to set this stuff via the command line, but it doesn't seem to work quite right. I searched a bit and found some good explanations, which eventually solved my problem.

The only change I made to my C:\WINDOWS\system32\inetsrv\MetaBase.xml file was to make the HcScriptFileExtensions entries newline delimited instead of space delimited. The same goes for HcFileExtensions as well. Take care that you fix these for both deflate and gzip.

So, I now have aspx and asmx extensions configured for compression and when I hit a page from a browser it is downloaded compressed. Woohoo!

But, when my client program that uses my web services (asmx pages) hit the same pages things were not compressed. Boohoo!

The key is that if you're using automatically generated Web References that extend SoapHttpClientProtocol you need to set the EnableDecompression property to true. E.g.:

using(MyWebService proxy = new MyWebService()) {
    proxy.EnableDecompression = true;
    ...

 
One other thing... It's somewhat annoying that there's no easier way to determine if compression is working. Using a packet sniffer will work, but it can be a pain to install one, especially since you don't need most of its functionality. The way I checked this stuff was to examine the IIS logs and compare the download size of known pages before and after changing various settings. HTTP compression seems to reduce web text to about 25% of its original size. One annoying thing is that the IIS web log file is appended in a way such that the results are delayed by a minute or so. Also, in a live system this file can grow very quickly, so trying to do quick checks in it can be difficult.

Making Windows Server 2008 relay SMTP requests

By default, even if you install the SMTP server in Windows Server 2008 it seems the service is not enabled to start by default, and it is not configured to relay requests, which is good, including those from localhost, which is less good. Fortunately, this is easy to fix, and this article explains it well.
In case that article disappears someday, the simple version is you open the Administrative Tools → Internet Information Services (IIS) 6.0 Manager. In this tool the Access tab in the properties on the virtual server allow you to enable relaying for localhost (or whatever else you need).

Postgres shared_buffers Setting in Windows

Apparently Postgres on Windows doesn’t respond well to a high value for shared_buffers. This thread explains a little, but not definitively. Also, I found that setting the value to greater than 1GB (on a Windows Server 2008 x64 box with 8GB RAM) failed with this error in the event log:

%t FATAL: could not create shared memory segment: 8
%t DETAIL: Failed system call was MapViewOfFileEx.

So, for now I’m going with a conservative 32MB setting.