iPhone programming might be getting a whole lot easier

The mono project has announced MonoTouch. MonoTouch is Mono for the iPhone and the iPod touch. Applications writen with MonoTouch work and non-jailbroken phones, and can be submitted to the app store.

See Miguel's blog for additional details. According to the comments, a beta should be released in August.

Time to start brushing up my C# skills.

Guido just doesn't get windows programming

Among the blogs I follow is that of Guido van Rossum, the creator of Python. Mostly they are interesting but his latest one (IronPython in Action and the Decline of Windows) is a large pile of wtf. Apparently programming windows apps is tedious and gui creation requires many lines of code. Even more surprising to me, web apps are far easier to create.

Wow, apparently he has never heard of delphi, visual studio or any of the other gui editors that have been about since at least the mid 80s. The last time I laid a gui out in code, other than for eductational purposes, would have been about 1986. I have no desire to do it again either.

iPhone Dev: Zombie Mansion post mortem

Overview
I released Zombie Mansion in mid December 08. It is a 1st person shooter, the 2nd available on the iPhone and the first one to be designed for mobile devices rather than being a pc port. ZM was a port and extension of the work I had done previously on the Yeti engine.

Seeing as how every other iPhone developer is sharing their tales of mega success, or crushing failure, I though I would add my story.


Sales
ZM has sold steadily, if not spectacularly. Unfortunately I have not made enough to pay off my house and buy a fast car. On the other hand, it sold well enough to pay my mortgage payments for the 1st 3 months. Sales are as you would expect: hundreds sold in the first couple of days, rapidly dropping off as ZM moved off the recent releases page. My first update provided a brief blip but my second update was unnoticeable in terms of sales.

I took 2 weeks leave to finish ZM, and I estimate that I spent the equivalent of another 2 weeks previously. This doesn't include the original porting work I did moving the yeti engine to the pocket pc.

As a return on time spent, ZM performed slightly better than working at my day job. It was however considerably more fun. It would have performed even better but I made a couple of bad design decisions.


Programming
Unusually, I did the bulk of the development in windows using visual studio rather than in xcode on OSX. I already had an OpenGL ES port running on Windows Mobile and Windows so an iPhone port wasn't much of a problem.

Coding was done in a mixture of C (yeti code) and C++ (my code).
On the iPhone, I used the Oolong engine to handle the sound, input and 3d setup. Oolong provides c++ wrapper classes for all this (and more).

On the pc and windows mobile side, I used the PowerVr sdk to handle 3d setup. Keyboard handling is trivial, and I used Hekkus to provide sound support.

Once I had this all set-up,I did most coding in visual studio. At irregular intervals, I would reboot into OSX and compile with xcode. I mostly used xcode for iPhone specific stuff and performance testing. All my support tools (map editor, 3d importer etc.) are windows based (in c++ builder and Delphi) so that necessitated mostly using windows. I prefer visual studio to xcode, so it wasn't much of a chore.


Mistakes
I made a couple of mistakes. The first, and most major was simplifying the weapons too much. I went with one weapon, a staff, with upgrades rather than with multiple weapons. In retrospect, a bad call.

The second mistake was not putting some help tips around controls. The controls work well if you leave your thumb on the d pad and slide it to control. If you pick your thumb up and move it, the controls don't work as well. Some easy way of explaining this to the player would have made their initial impressions better.

The underlying problem is that perennial development favourite, I underestimated the time needed to write the software. I ran out of annual leave and thus ran out of time. While I enjoyed the game that I wrote, it would have been better if I had more time to add extra features and polish.


Dealing with Apple
There are 3 major drawbacks to iPhone development: Apple, Apple and Apple. I don't know if they are overworked, incompetent or just don't care. Either way, developer support seems to be missing in action.

Since I have had children, I have made a concious effort to improve my language, removing the more robust terms I picked up working in the abbottiors. Three months of dealing with Apple has made a mockery of my self-betterment attempts, leaving me swearing like Gordon Ramsey on a bad day.

Simply getting a paid developer contract took six weeks. My first payment, for December, didn't get paid until late March. Emails asking when money was going to arrive were ignored, or fobbed off with stock responses or outright lies. Whenever I phoned, I was told they couldn't help and to email another department.

Even when I did get paid, there was no notification. Apple can email me every week, trying to sell me a second rate album farted out by a talentless boy band, but they can't be bothered sending me an email saying "We have now condescended to pay you".

As a comparison, RegNow emailed me on Jan 4th letting me know my December payment had been released, and the money was in my account on Jan 6th. Even now that Apple has decided to make my monthly payments on a monthly basis, they still take nearly 40 days longer than Regnow.


Random thoughts
There is clearly still money to be made in iPhone dev. ZM hasn't disturbed the sales charts, but it has still sold well enough to cover it's costs and my time. I imagine that there are many developers in a similar position, not making riches, but making enough to get by and keep developing. A small stable of good games/applications could provide a nice living without requiring a hit.

It used to be that you could get a large amount of exposure and thus sales by releasing an update every couple of weeks. However the volume of new applications has changed that. There are so many apps being released each day that the initial rush of sales from being in the "what's new" charts is much smaller. You need to get sales the hard way, with marketing; promotion and advertising.

I also have a couple of windows shareware applications, Pics Print and Rental Property Manager. While it is not easy to compare windows utilities and business applications with an iPhone, the return on time invested is far greater for these 2, particularly RPM, than for ZM.

All this brings me full circle from where I started out six months ago. There is money to be made in iPhone apps, but there is also money to be made in windows shareware as well. If you are a windows developer, particularly if you are a Delphi developer, then you are probably better off developing windows shareware than iPhone apps. I know a lot more developers making money off windows than off iPhones.

Oh, and developing for iPhones still sucks! Not as badly as I first thought, but still noticeably.

And Now for Something Completely Different

One of the pragmatic programmer tenets is to learn a new programming language every year. I'm a bit behind on that, I haven't learn a new language since 2002 (I don't count objective C because I hate it and have only learnt the bare minimum necessary to get by). Unfortunately the need to earn a living has gotten in the way of random learning.

However I have now been programming in Delphi for 15 years. It's starting to get a bit boring and it's time to kick-start the brain again. While Delphi will be my main language for the near future, I am going to make the effort to learn something different.

The main things I am looking for in my language de jour are

• Dynamically typed (I have done statically typed languages for decades)
• Popular (general rule of thumb, should be at least as popular as delphi)
• Object Orientated
• Cross platform
  
• Batteries included
  

This pretty much narrows it down to Perl, Php, Python and Ruby. I was initially tempted by Ruby as I don't yet have an R on my alphabetical list of programming languages. However I have settled on Python instead.

Part of the reason for going with Python is the presence of the Python for Delphi components. These promise to let you use python as a scripting language inside delphi apps. These components are used in the PyScripter ide.

The easiest way I have found to get started is to use Portable Python. This will put Python and a few tools (inc. PyScripter) into a portable drive along with a few tools and useful modules such as Django. This is considerably easier for a python newbie than sourcing and installing the packages separately.

Some useful links to get started with:
Official website
Official python tutorial (v2.6)
Dive onto python online book (useful but a bit old)
Pycon US 2009 videos
Reddit python feed

Filtering generic collections with anonymous methods

I have recently been adding generics to the ti Object Persistence Framework. As part of that I was asked to add enumerator filtering. I did this using a similar technique to that shown here by Malcolm Groves.

I ended up with code used like this:

for item in Flist.FilteredEnumerator(function (TestObject: TtiOPFTestIntegerProp): Boolean
                                begin
                                  result:= TestObject.IntField mod 2 = 1;
                                end) do
begin
 inc(intCount);
 intSum:= intSum + item.IntField;
end;

I was happy enough with the result, but I wasn't happy with the implementation. I wanted something that was, well, more generic. What I ended up doing was wrapping the existing enumerator into one containing a filter. This will work with any generic collection that descends from TEnumerable. I.e. TList, TQueue, TStack, TDictionary and the TObjectXXX variations

To implement an enumerator, a class must have a GetEnumerator function. This returns an object (or a record) that has the Current property and the MoveNext function. Delphi does a fair amount of work behind the scenes to wrap this all up nicely. See The Delphi Geek's series on enumerators here for more background.

Wrapping an existing enumerator meant I could use the existing GetCurrent and MoveNext for accessing the collection. Filtering then becomes as simple as:

function TFilteredEnumerator<T>.MoveNext: Boolean;
begin
  while  FEnumerator.MoveNext do
  begin
    if FPredicate(FEnumerator.Current) then
     exit(true);
  end;
 result:= false;
end;

The full code is as follows:

unit FilteredEnumeratorU;

interface

uses Sysutils, generics.collections;

type
 TFilteredEnumerator = class
  private
   FEnumerator: TEnumerator;
   FPredicate: TPredicate;
  protected
    function DoGetCurrent: T;
  public
    constructor Create(AEnumerable: TEnumerable; APredicate: TPredicate);
    destructor  Destroy;
    function GetEnumerator: TFilteredEnumerator;
    property Current: T read DoGetCurrent;
    function MoveNext: Boolean;
  end;

implementation

{ TFilteredEnumerator }

constructor TFilteredEnumerator.Create(AEnumerable: TEnumerable; APredicate: TPredicate);
begin
  inherited create;
 FEnumerator:= AEnumerable.GetEnumerator;
 FPredicate:= APredicate;
end;

destructor TFilteredEnumerator.Destroy;
begin
 FEnumerator.Free;
  inherited Destroy;
end;

function TFilteredEnumerator.DoGetCurrent: T;
begin
 result:= FEnumerator.Current;
end;

function TFilteredEnumerator.GetEnumerator: TFilteredEnumerator;
begin
 result:= self;
end;

function TFilteredEnumerator.MoveNext: Boolean;
begin
  while  FEnumerator.MoveNext do
  begin
    if FPredicate(FEnumerator.Current) then
     exit(true);
  end;
 result:= false;
end;

end.

To use filtering in action, simply do something like:

for xxx in TFilteredEnumerator<T>.Create(queue, function (Arg1: T): Boolean
                                                        begin
                                                          result:= ...;
                                                        end)
do
  ...

eg

var
 queue: TQueue<string>;
 cur, combined: string;
 filter: TFilteredEnumerator<TTestObject>;
begin
 queue:= TQueue<string>.Create;
  try
...

   for cur in TFilteredEnumerator<string>.Create(queue, function (Arg1: string): Boolean
                                                         begin
                                                           result:= Arg1 < 'A';
                                                         end)
   do
   begin
     combined:= combined + cur;
   end;

If you are deriving from a collection, you could also wrap this into a method:

function TFilterableList.Filter(APredicate: TPredicate<ttestobject>): TFilteredEnumerator<ttestobject>;
begin
 result:= TFilteredEnumerator<ttestobject>.Create(self, APredicate);
end;

Source can be downloaded from here.

Microsoft Study: TDD reduced defects by 40%-90%, increased dev time by 15% - 35%

Found via Reddit.

See here (pdf).

Garbage collection - it's not about lazyness

There seems to be a common belief amongst a number of Delphi programmers (and c++ programmers etc) that garbage collection is all about being too lazy to do your own clean-up.

E.g. Babnik asks "What is it about Garbage Collection?" (kudos for actually asking the question) and his post has the implicit assumption that advocates are trying to avoid doing a bit of minor work.

Others have posted far more stronger comments (check the responses to Babnik's post) straight out stating that gc = lazyness, bad coding and a slack attitude to life. I find this attitude condescending and offensive. The reason I want gc, is not because I write bad code, but because i want to write better code.

I would like to see garbage collection in native Delphi, not as a mandatory feature, but as an option. It's not something I am holding my breath for, but if there was one thing I could add, that would be it.

I know I am repeating myself, but here are my main reasons for wanting a gc (expanded from an earlier post on the subject):

• Better code: In a non gc language, you end up with a number of idioms and practices to guard against memory leaks. Delphi has several of these.
  E.g.:
  It is rare to return an object from a function. Typically you would create an object and then pass it to a procedure to be modified.
  The use of assign rather than :=
  The use of Owner, Owned and the like to solve object destruction problems)
  
  
• Less code: I performed a naive analysis on my most recent project by removing most .Free calls and the supporting destructors and try … finally blocks. The result was about 4% fewer lines of code. More importantly, the code I removed was boring, boilerplate which solved no business problems and added no value (other than preventing leaks)
  
  
• Faster development: There are some minor time savings to be had simply by typing less code. However when I was regularly programming in c# I found my productivity improved due to the change of coding style that gc allowed.
  
  
• Fewer memory leaks: By reducing the need for manually freeing memory, a gc significantly reduces the scope for memory leaks. It is still possible to leak memory, but much harder.

• There are some problems that it is difficult to solve without a GC. Linq is often given as an example. Class operators (as opposed to record operators) is another
  

One of the main reasons I see for Delphi to have a gc, is that it's competitors have it. If we are to persuade people to write applications in Delphi as opposed to C#, Java etc then requiring manual memory is at best a speed bump.

Finally garbage collection definitely falls into the "Your kilometreage may vary" category. If you are working in memory constrained environments then manual management is the way to go. If you are writing database driven business apps or web apps (as I usually am) then manual management offers little or no advantage over a garbage collector.