A while ago I posted a small tool that validates a VAT ID through an official Web service provided by the EU. In the meantime they change the Web service. The downloads below updated to reflect that change and I also updated to Delphi 2010.

Source code : VAT-Checker.zip

Executable: VAT-Checker.exe.zip

foo := TFoo.create;
try
  //do something with foo
finally
  foo.free;
end;

It basically means, that if you create an instance of some class and if there is no “owner” who takes care of the new instance’s life cycle, then it is your responsibility to destroy the instance again, as soon as you are done with it.

If you don’t care about freeing the objects you created, then you will get “memory leaks”, i.e. you app will use (possibly a lot) more memory as it should.

The technique above is clear and simple, but what if you have more than one object that is needed in a routine? Line them up?

foo := TFoo.create;
bar := TBar.create;
try
  //do something with foo and bar
finally
  foo.free;
  bar.free;
end;

Looks good, and I see this pattern frequently – but hold on! What happens if there is an exception when TBar is created? Right, foo won’t be destroyed in that case. So maybe handle it like this then:

foo := TFoo.create;
try
  bar := TBar.create;
  try
    //do something with foo and bar
  finally
    bar.free;
  end;
finally
  foo.free;
end;

In theory this would be the correct way, and there are a lot of examples that work like that. But look at the code – right: looks really ugly, esp. if we extend that to even more objects being created. Apart from readability there is also some performance hit: every try-frame needs some extra CPU cycles, which may sum up if your routine is time critical already.

My suggestion is this one:

foo := nil;
bar := nil;
try
  foo := TFoo.create;
  bar := TBar.create;
  //do something with foo and bar
finally
  bar.free;
  foo.free;
end;

Now lets discuss some questions about this pattern:

Didn’t we learn, that calls to “Create” have to be made outside the try-finally block?
No, not really. In fact it doesn’t matter where you create an instance of a class. The first example (which is mentioned in many articles) only suggests this, because it’s easy to do so with just one object.

If TBar.create fails, what happens with its bar.free counter part? Wouldn’t it actually be executed on some not “really created” object?
No, in fact bar.free is special method, which can safely be called even on variables pointing to NIL. Free checks if self<>nil and only then the actual destructor is called.

Why did you initialize fo and bar with NIL?
Because otherwise they might have random values. Esp. if they are declared as local variables. And we need NIL initialized variables so that “free” does not call random code in the case of an exception in one of the create calls.

If TBar.create fails with an exception, wouldn’t be there the chance that some address value would have been written to bar already – so that bar.free would be executed on some half initialized instance?
No, if TBar.Create fails with an exception, then the class function “create” would (like any other function) return NO value at all. bar would keep its original value that is.

Silverlight has quickly developed from version 1.0 to 4.0, which is the most current version as of today. Version 1.0 was released in September 2007, which means that Microsoft pushed 4 major releases in less than 3 years. Considering that the technology is non-trivial (some sort of .NET integration, derivation of WPF, plugins even for Mac OSX and non Microsoft friendly browsers, VS and Web Expression designers …), Microsoft obviously put in quite some man power to get this done.

Now I look at the recently released Office 2010 version, which also comes with a “Web version” of Office. Via office.live.com Microsoft offers Word, Excel, OneNote and PowerPoint as some sort of light editions of their desktop counter parts.

The layout looks nice, and indeed it feels almost like Office 2010 running on your desktop. The feature set is of course not (yet?) that rich, but for the occasional writer probably all features are there. Here and there it feels a little sluggish, but it works,. Collaboration is way below from what docs.google.com offers, but for a 1.0 version it’s okay.

Now you could have guessed “alright Microsoft’s Office Web team took Silverlight and made this a killer use case for it”, but interestingly if you look under the hood, by examining the HTML source, there appears to be not a single trace of Silverlight. At least I couldn’t find anything but HTML, Javascript and CSS.

This of course leads to the question “Is Silverlight dead?”. If Microsoft does not eat its own food or if the Silverlight team cannot even convince other Microsoft teams to use Silverlight (the SL pieces on the MSDN pages does not really count here imho), does that possibly mean there is something wrong with the technology?

Wir werden diesmal gewissermassen das Thema “Sauberkeit am Arbeitsplatz” behandeln, d.h. wir zeigen Ihnen alles zum Thema Sourcecodeverwaltung (Subversion), Debuggen, Fehlereingrenzung und Speicherprobleme. Als besonderes Extra zeigen wir Ihnen, wie man native iPhone/iPad Anwendungen mit einem Delphi Backend verbinden kann.

Die genaue Agenda und Anmeldung findet sich unter www.DelphiExperts.net

It’s an iPad only application – it’s a magazine. So it really makes use of the large iPad screen. On the iPhone it just wouldn’t be readable. Daniel and I (and actually Holger assisted us a bit) developed that application for our partner American International Media, who own the magazine. That copmany also owns the USA Sevens Rugby series, which is an interesting Rugby variant: 7 Players per team – 2 * 7 minutes.  From 2016 its gonna be Olympic.

Get the mag at Apple’s AppStore

We considered using Delphi Prism / MonoTouch for this application, but as we know that Apple would come out with a couple of new beta releases of the 3.2 SDK right before the submission deadline, we decided against it, to make sure we were able to deliver. We are working on a DelphiFeeds app though – which will be using Delphi Prism. Stay tuned for that.

We are going to repeat that workshop in Hamburg next week, and there are still a very, very few seats left – so if you got time and want an iPhone development introduction, then come join us in Hamburg on March 22/23.

Sessions are in mixed language mode, i.e. understanding German and English is a requirement. We focus on Xcode and Objective-C, but we also demonstrate MonoTouch / Delphi Prism for Mac briefly.

Event pictures can be found on our partner’s Website: MacWelt.de

Event info and registration for Hamburg can be found here.

Update: Hamburg is sold out too.

Die Postion ist zur Festanstellung ausgeschrieben und es wird eine branchengerechte Bezahlung geboten. Neben Delphikenntnissen und Führungsqualitäten sind Kenntnisse in Betriebswirtschaft wünschenswert.

Bei Interesse ganz unverbindlich per Kontaktformular oder auch über unsere DelphiExperts Seite antworten. Alle Anfragen werden selbstverständlich diskret behandelt.

Die Ergebnisse finden sich hier: www.delphiexperts.net/events

"Are you sure you want to delete the Internet?".

Please don’t bash me if you cannot get to the Internet anymore – I am working on restoring a backup

Native iPhone Anwendungsentwicklung bedeutet normalerweise das Auseinandersetzen mit Objective C, der Haus- und Hof-Sprache von Apple. Man bekommt, nachdem man sich als Entwickler bei Apple registriert hat, die komplette X-Code IDE inklusiver aller Werkzeuge praktisch kostenlos zur Verfügung gestellt.

Man kann also, ohne viel Geld in die Hand nehmen zu müssen, mit der Softwareentwicklung für Mac und iPhone/iPod Touch quasi ad-hoc loslegen. Zumindest wenn man einen schnellen Internetzugang hat – der komplette SDK Download ist über 2 GB groß.

Dass dies auch in der Praxis funktioniert, sieht man sicherlich auch daran, dass es mittlerweile zehntausende Anwendungen in Apples AppStore gibt. Wieso gibt es aber nun Interesse an Pascal auf dem Mac/iPhone? Nun, wer Pascal kennt und dann mit Objective-C (OC) konfrontiert wird, erleidet doch einen gewissen Kultur-Schock. Mit “normalem” C mag man sich noch abfinden (Volker, nichts für Ungut aber wenn man dann die Syntax von OC sieht, fragt man sich doch ob der Erfinder Klammer-Fetischist war…

Nicht dass wir uns missverstehen:  Die Mac und iPhone Frameworks – rund um Cocoa –  sind superinteressant und haben klasse Features. Auch die kostenlose IDE X-Code ist hervorragend – aber für mich als alter Pascal Haudegen “geht” diese OC Sprache einfach nicht. Bisher habe ich öfter mal gesagt: “die Sprache ist wurscht, man lernt halt einfach die Syntax” – aber das war vor Objective C …

Nun haben Daniel Magin, Holger Flick und ich von RemObjects eine frühe Beta von Prism (aka Oxygene) für den Mac bekommen. Prism ist bisher als Plugin für Visual Studio bekannt geworden. Im Prinzip also Pascal für .NET.  Da .NET in seiner Mono Inkarnation auch auf dem Mac (und Linux) existiert, kam also Marc Hoffman von RemObjects  vor einiger Zeit auf die Idee das Prism Plugin mit .mono zu übersetzen.

Herausgekommen ist mittlerweile ein Beta-Plugin für MonoDevelop (die Mono IDE), welches Pascal unter Mono implementiert. Dadurch, dass Mono und MonoDevelop auch unter OSX lauffähig sind, können wir nun endlich OSX Anwendungen entwickeln, deren Sourcecode richtig gut verständlich und wartbar ist. Und das sogar mit Zugriff auf Cocoa, der Apple UI API.

Wer sich schon mal mit der iPhone Entwicklung befasst hat, wird sich nun fragen, wie man managed Mono-Anwendungen auf das iPhone bekommen soll, da da iPhone ja bekanntermaßen keinen managed Code erlaubt. Hier kommt das kommerzielle MonoTouch Add-In für MonoDevelop von Novell zum Tragen. MonoTouch tut im wesentlichen 2 Dinge:

1. .NET/Mono Schnittstelle zum iPhone  SDK, d.h. APIs wie z.B. das MapKit sind aus Mono ansprechbar
2. managed to native Code Compiler für iPhone. Der sog. mtouch Compiler übersetzt managed Mono Anwendungen in nativen iPhone CPU Code

Innerhab der MonoDevelop IDE kann man dann mithilfe von MonoTouch auf das physische IPhone deployen. Hierzu ist KEIN Jailbreak erfordelich. Auch das Ausliefern in den AppStore wird natürlich unterstützt.

Wenn man bedenkt, dass Delphi Prism/Oxygene noch eine frühe Beta ist, funktioniert das ganze schon hervorragend. Gestern konnte ich mit Daniel eine in Pascal geschriebene Anwendung auf Daniels iPhone installieren, die auf den GPS Sensor zugreift und die Koordinaten in einem Google Maps View darstellt.

Hier noch ein kurzer Blick auf die MonoDevelop Umgebung mit installiertem Oxygene: