The next couple of posts will be using RemObjects SDK and RemObjects DataAbstract with .NET to deliver data for an iPhone application. The two previous posts are needed in order to understand my train of thoughts. I will mark these posts with the Delphi category, i.e. they will be fed to DelphiFeeds.com. However, if I will write general posts about general development tasks with Xcode and other iPhone-specific tools, be they interesting for Delphi developers who want to learn about iPhone Development as well or not, I will NOT mark them with the Delphi category.

Thus, if you want to read all my posts, please use the complete feed of my blog and not only the Delphi one that DelphiFeeds.com does consume.

I want to make sure that the Delphi community will only read about Delphi-related topics on DelphiFeeds.com and thus I will make sure that general iPhone issues will not appear there.

Why different? Well, not only is the syntax of the programming language on Mac very odd getting used to for a Delphi or C# developer, but even more using the computer is also needing some time getting used to. Shortcuts are different, there are way less visible shortcuts than on a Windows system and the general approach how to get things done is very much different. With regard to the shortcuts it is sometimes a real pain to find them and they often differ from application to application. Mac OS is very much designed for mouse users, it seems, and keyboard enthusiasts will have to read the docs carefully. A lot of people claim that it is easier and more intuitive to get started, especially if you have not used Windows before. I would not sign that statement as Mac OS has also quite some oddities just as Windows has. Just yesterday, I dragged a file onto my desktop which did not show. When I dragged it again, Mac OS told me the file was already there and if I wanted to overwrite it. Thus, it is not without flaws either. And ever since Windows 7 one can completely forget the generalization “Mac is more stable than Windows”. My Windows systems are just as stable. However, I am derailing from my train of thoughts…

“How would one get started to code on the Mac or code applications for the iPhone?” was the question I had to get an answer to. Firstly, give yourself time to get used to the system.  Do not try to start developing right away. It will not work. Believe me. I tried. Give it some time. Fiddle around with a Mac system at least for 1 or 2 moths before you start developing. You need to get some insight in how the system works, how applications are assembled etc. This will not happen in a week and you definitely cannot read it in a book and hope to get the same understanding as learning by doing. Of course, a book to get started with Mac OS can help. Maybe, you are as lucky as me and have some hardcore Apple Affiliates at your workplace you can nag all day long… They will forgive you for the frequent interruptions sooner or later (thanks, Volker… ).

Secondly, get the tools for the job. With Apple it is very easy to get the right tools in order to develop Applications for the platform as the company publishes the development environment with the operating system itself. Be sure to have a look at your Leopard DVD and install the additional features. Besides, you will miss the command-line tools after a month or so anyways and they are there as well.

The main development environment is called Xcode and if you ever dare to load one of the sample projects you will be overmanned. Yes, you will. There is no way around it. The code simply hits you and it might result in an abrupt thought that may say something like “How did I ever think to develop for this platform in that language?” — It definitely feels like that at first.

Thus, get a book. Or get two actually. One is free, the other is not. I started learning the language with a book that is just about the language. Not about any platform. Just the language. The book is called ‘Programming in Objective-C 2.0′ bz Stephen Kochan and it gives you a very good introduction and gets you used to the funny syntax. Funny is an adjective every Delphi developer I know has used so far for that particular syntax.

For me it was very clear that I wanted to develop applications for the iPod Touch and iPhone. Thus, book number two. Apple has a huge archive of free documentation that comes in a very printer-friendly PDF format. The PDFs are seperated by certain topics, not just a simple reference that has been generated from source files or generated in some other way. It is like a big library at your fingertips. I read quite a few of them and they are very good to read and contain lots of useful information. Access is granted if you join the iPhone Developer Program. Unlike frequent misinformation about this topic, joining this program is free of charge. You get all the documentation and all the programming tools for free. No charge. Not once, not yearly. The only thing you are being charged for on a yearly basis is the ability to deploy to physical devices. There are several different subscription packages available, but in order to get started, you can use the free account. The software development kit (SDK) even comes with an iPhone simulator that allows you to test your application like it was running on an actual physical device. There are only a few restrictions that make using a physical device a necessity. But believe me, these will not affect you in the first couple of weeks of developing applications.

When you got your login details, you can use your iTunes Account as a sidenote, you can download the SDK which includes all the tools you need. Furthermore, during the download I had lots of time to read as the SDK is huge and take a long time to download through my pitiful bandwidth of 2MBits.

After the download, installation is only a double-click away and takes from 10 to 30 minutes. Be sure to drag Xcode into the dock - you will need it all the time.

But how to get started? Well, Daniel Magin suggested a book to me and that really got me started:

• iPhone SDK 3 (Visual QuickStart Guides) by Duncan Campbell

It gives an introduction with use-cases to the most important classes that you need to use in any project and it also describes all the visual components hands-on. After reading this book - it is not that big, so I did read it completely -  you are able to write little apps and are ready to dive into the details. Oh, and be sure to download the free bonus chapters of that book. I did that with two books from Apress from the same group of authors:

• Beginning iPhone 3 Development: Exploring the iPhone SDK by Dave Mark and Jeff Lamarche
• More iPhone 3 Development: Tackling iPhone SDK 3

Those will keep you busy, but afterwards you will be ready to write applications for the iPhone for sure. Patience is most important while typing the new language. Furthermore, Xcode is very different when entering source code. If it felt strange using Visual Studio when being used to Delphi, it is like that…

For the German audience one additional hint. The German Mac keyboard is a bit odd as it has not all keys printed completely. E.g. the {} and [] are nowhere to be found. I have no idea why the German Apple keyboards are built that way. Furthermore, typing source code on a German keyboard is very clumsy. Due to that,  I have coding-keyboard with US typeface, so that I can type source code more easily. It helps quite a lot.

Next time I will introduce you to some architectural ideas and implementations I am dealing with right now. I have some applications that need to work on a Windows Desktop as well as offer access using the iPhone. Furthermore, a web application is not an option  I consider for the iPhone. The usability employing a native iPhone application is just so much better in my opinion.

However, this is going to change in the next couple of weeks as I am finally ready to blog about some interesting, new, innovative things that have come my way the last couple of weeks.

I think it is normal that from time after time you have to catch up with all the technologies that are out there and have to find your way and decide which path to take. In the last months rather than weeks, I have been reading up on software development in general, new programming languages and frameworks in these languages.

For example, I finally caught up with C# and all the new aspects of its new version that is being released with .NET 4 (or Visual Studio 2010 — not sure about the release cycle). The language becomes more and more handy and is filled with quite some magic to make the life of the programmer a lot easier. However, one thing that still is not solved, even in its 4th incarnation, is the missing separation of specification and implementation. Being used to Pascal or Delphi, it is really tough not having a class definition on top and the concrete implementation at the bottom. Also the possibility to define properties and fields “anywhere” in a class makes C# a bit harder to read at first. I am not going to dive into the ‘braces debate’ as I think that it is a bit too geeky and completely insignificant. I do not care if I use ‘begin’ or ‘{’. The readability, however, is important.

From C# I went over to frameworks that .NET offers these days. Be it ASP.NET, MVC, LINQ, Entity Framework, WCF, WPF — I looked at them all with different levels of granularity. WPF I only touched the shell, as my design skills are rather limited. I understand how everything fits together now, though, and I think that must suffice. One has to emphasize the great options the developers have to bind data to the graphical user interface using WPF.

WCF - knowing Indy due to Delphi quite well - is also something that triggered my interest. However, there is one component set available, for free no less, that I never saw the need to jump into it deeper than knowing what is available and how one specifies services etc. Thanks go to Hadi Hariri, for writing some great articles to get you started!

EF - probably the greatest disappointment for me. I did not have the nerves to look at the release candidates or Community Technology Previews that are available for the second installment. The first version did not perform to my liking. I will clearly state that it is mostly not the problem of the product, but I guess think differently and I was not able to transfer my ER-models from my head into the framework. Especially reflexive associations gave me headaches. I never got the result I was looking for.

EF not being what I hoped it was, I looked at Linq to SQL. This required me to learn Linq first as the specializations of Linq - obviously - require a deeper understanding of the base. So, I read into Linq and soon realized that LinqToXml would make my developer days so much more easier. LinqToXml quickly became THE toolset to read and write XML. I can say without hesitation that ever since reading and learning about LinqToXml, I use nothing else when XML is involved and I have the .NET framework available. Especially the performance on huge files of it is breathtaking. As I understood that I went over to LinqToSql. Definitely a tool one can use to write great database apps in .NET, however, spoiled developer-me, who was used to ECO, still was not satisfied. Oh, ECO, yes, I still use it and I will mention it later in this post. I want to point out though that I was able to realize a small project with LinqToSql, which I never was able to do with EF. Yes, I know, it must have been me — still, I prefer LinqToSql to EF 1.0.

I just realized I only mentioned LinqToXml. The simplest incarnation of Linq, which is LinqToObjects, is absolutely not missing in any of my projects. At this point I want to mention that I use Linq in C# and Delphi Prism all the same. Remember, .NET is language-agnostic. Thus, Delphi Prism or C#. Both are becoming a bliss to use with LinqToObjects as soon as lists or any other in-memory data structure is involved.

Good. That were the desktop app frameworks I looked at. I also looked at ASP.NET and its ’spin-off’ MVC, which stands for Model-View-Controller. I like the idea behind it. Actually, I like Ruby on Rails for the same reason. But, I miss the server-controls and I absolutely loathe scripting Java Script to do AJAX in web applications. Thus, MVC never grew on me. Even with all the frameworks that are available… I still never got the hang of it.

As I talked to a buddy from the Delphi Community, he told me he had absolutely no idea what to look at first and how to prioritize. Thus, here is my own list, how I would prioritize things. I assume that you did look at .NET in general already and thus do not need to get started with that, because that would be my number one priority right now. I still do native programming - which reminds me to ask: Why is one old-fashioned coding native? The whole iPhone SDK is a native framework… thus, it is still an up-to-date topic and not to be neglected….

Thus, here the priorities for the technologies mentioned above:

1. Linq
   • Linq to Objects
   • Linq to XML
   • Linq to SQL
2. WPF
3. WCF
4. EF with version 2 just being around the corner

This concludes the list of Microsoft technologies of the .NET framework I looked at. Did I stop there? No. If you had asked me three years ago, I never would have thought it possible, but I went over to a different platform. Yes, really.

Apple - or MacOS.

Ever since I held an iPod Touch in my hands it became very clear to me I wanted to be able to develop applications for these devices. But more about that and how I can connect the Objective-C applications with my .NET applications in the next blog post which will most likely not take as long to write as this one… almost a year… wow.