A C# Developer’s Adventures in Objective-C

The other day, my father asked me how to get started developing for the iPhone and iPad. He is looking for a technical hobby that he can do while he travels in his upcoming retirement. I had no idea really how to get started so I asked around. I learned quickly that it doesn’t take much to learn if you have an Apple computer.

All that I did is:

  1. Download XCode 4 which is a free download from the Mac App Store.
  2. Download the Stanford University iPhone and iPad Application Development Collection for iTunes U.
  3. Watched the first 2 lectures from the course.
  4. Fired up XCode 4.
  5. Attempted the Reverse Polish Notation Calculator targeting the iPhone described in the second lecture.

Of course, this was a very simple iPhone application that was built with only about three ours exposure to Objective-C (the programming language), Cocoa Touch (the iOS framework), and XCode (the integrated development environment). It was a fun exercise. However, if you are only familiar with .NET and/or Java there are some uncomfortable moments with the Object-C syntax that you are bound to encounter. Mind you I am a complete novice with the language, the framework, the development environment, and the platform. Nevertheless, these are my experiences.

First things first… The iPhone application makes heavy use of the model-view-controller (MVC) pattern. I like this. I am familiar with the MVC pattern and I can work with that. What was surprising is that the only code I really touched was the model objects and controller objects. The view was entirely created with the visual designer which generated a storyboard file to describe the view. This file is an XML file. This wasn’t difficult to get used to as I only really worked with the native Cocoa view objects. I am curious to find out what the story for creating your own view objects is.

After dragging and dropping controls on the storyboard, I started working with the controller. This experience was mostly clicking and dragging connections from the visual designer to the controller source code and implementing a few properties and methods. Take a moment to review the controller header file:

Even with some exposure to C and C++ over a decade ago, this header file appeared strange to me. It’s purpose is similar to C or a C++ header file as it serves to declare class, type,  function, and constant declarations.

Now look at the source file:

This is the source file which contains the implementation details of the declarations in the header file. There really is a lot going on in both of these files that are needed to compile the view controller.

To be honest, at first glance I was really confused and it took me some time to understand the high level basics of the syntax and what it was doing. The @notation did not make sense. There are many keywords here that don’t translate directly to C#, or Java. I didn’t understand what the dash (-) in front of method declarations and implementations was for. What was the difference between the @interface structure in the header file and source file? I was really lost. The syntax was extremely foreign. Did you notice all the square brackets?

I will summarize what I can here, but really at this point I would recommend looking at a good Objective-C primer like the Learning Objective-C Primer found the iOS Developer Library. By the way, the documentation packaged with XCode 4 and the developer libraries found in the Apple Developer Center are your friends!

Concepts in the Header File


The header file is small and concise and is not too hard to understand. The first think you should notice is the #import directive. This directive is similar to the using keyword in C#. It tells the compiler that you want to include code defined somewhere else in your header. In my header file, I am telling the compiler to include the UIKit header file where the interface of the UIViewController class is declared.


The @ symbol indicates a compiler directive. The interface directive is used to presents the class name (CalculatorViewController) and begins the declaration of the class interface. This should not be confused with the concept of an interface in C#.

It is my understanding that the declarations made in the header file are accessible to other header and source files when they are imported.  So in C# terms, you can think of these declarations to have the public visibility modifier applied to them.

@property (weak, nonatomic)

The property directive is a convenient way of declaring a property backed by an instance variable. The closest think I can think of is a the declaration of a property in a C# interface like this (even though it is a really far stretch):

The next thing are the custom options contained in the parenthesis. These options define how the accessor methods behave. If you want to find out more, check out the declared properties documentation.


This directive is used to close other opening directives. In this case, it closes the @interface directive.

Concepts in the Source File


Here we see the #import directive again. In this file we have two of them. The first is the header file for this source file. The second is the header for a Calculator class that is used in the controller.


Again we see the interface directive. This time it is followed by parenthesis. I have no clue what these are for yet. Again my understanding here is that the declarations in this interface block are only visible to my implementation in this source file (somebody please correct me if this assumption is incorrect). Nothing really new here besides those things I don’t quite get.

Within this interface I declare two more properties and introduce some more custom options. I suppose these would be how you declare private properties in C#. But again it is a really far stretch that is not an accurate translation.


The implementation directive is similarly structured to the interface directive as it begins with the presentation of the class name. The difference is that this directive contains the implementation details of the class. It is closed with the @end directive at the bottom of the page.


The synthesize directive the implementation counterpart to the @property directive. This directive tells the compiler to generate the setter and getter methods for the property according to the custom options presented in the interface declaration. In addition, we can also specify the instance variable that backs the property.

– (ReturnType)methodSignatureKeywords:(ParameterType)parameterName moreMethodSignatureKeywords:(ParameterType)parameterName

What the heck is this? Tons of stuff going on here. What you have here is the pattern of a method prototype. It starts with a dash (-) or a plus (+). The dash makes it an instance method while the plus makes it a class method (or a static method). In the first parenthesis we present the return type. This is followed by the method name interlaced with parameter types and names. I found this very hard to read at first. But with a little practice you can get some really readable methods.

When declaring a method with in the context of the the @interface directive you would terminate it with a semicolon. By contrast, within the context of the @implementation directive it is followed by an open curly brace, the method body, and terminated with a closing curly brace.

For instance, take a look at this method:

This method specifies the getter method for the calculator property. Yes, the compiler would have created a simple getter for the calculator property since I used the property and synthesize directives. But since I implemented the getter, the compiler will only generate the getter method. But moving on to talk about the method. Here I am declaring an instance method that returns pointer to a Calculator object. The method name is “calculator”. This is followed by curly braces that contain the method implementation details.

A loosely translated C# equivalent might look like this:

I added the auto setter in the translation to give you an idea of what the @property and @synthesize directives did for me in this source file.

Let’s look at one more method in the source file:

This example method takes a single parameter. And may be loosely translated to C# like this:

You will notice the return type here is void and that is because the IBAction return type is a constant in the UIKit that the compiler translates down to void. The constant is used for integration between XCode and the Interface Builder tools. I probably don’t have this right either, but it is my understanding at this time (again if I wrong please point it out to me).

[targetObject methodSignatureKeywords:parameter moreMethodSignatureKeywords:parameter]

I’m sure you are asking about these now. The brackets are another notation that just did not make sense to me until some discussion in the Stanford lecture discussed them and even then I had to do a little reading in the documentation. The bottom line is this is the syntax for sending a message to an object. You can also think about this notation invoking a method.

So there you have it… my first experience with Objective-C, Cocoa, and XCode. I have much more to learn, but I am really happy that I tried it out. It was fun working with something new. I am still curious about how refactoring will work and I am sure I will miss my ReSharper features (if I do get into this I will probably try AppCode). I am also interested to investigate the unit testing options available.

[Update 4/17/2012] The walkthrough for the iOS calculator is available in PDF on the Stanford Course web site.

Running Apache Cassandra 0.8.2 on Windows 7

I needed to get Apache Cassandra running locally on my Windows 7 box for development purposes. This post will cover what I did to get it running.

Prepare the Run Time Environment

Cassandra was developed in Java. This means that my environment needs to have a functional Java run time environment. According to the Cassandra documentation at the time of installation, it requires the most stable version of Java 1.6. I figured since I am a developer and our current project may need some Java development in the near future then I may as well have an up to date Java development environment. So I surfed my way to Oracle’s web site and got the latest and greatest Java Development Kit (Java Platform (JDK) 7). After downloading and running the installer. I was ready to get Cassandra installed.

Running Cassandra Locally

After getting my Java environment in order it was time to get Cassandra running. The first thing I did was to download the binary package for the latest stable Cassandra release (version 0.8.2).

I then realized that I didn’t have a was to extract the contents on this current box. So the next step was to get a utility that was capable of extracting from a g-zipped tar ball. There are plenty of utilities that do this and I just grabbed 7-Zip since its free and works.

Now back to business. The next step was to extract the Cassandra binary files. I extracted them to c:\dev\cassandra\apache-cassandra-0.8.2 using the 7-zip utility. NOTE: Make sure there are no spaces in the path as this may cause problems later.

Now for everything to work correctly, you need to update the JAVA_HOME and CASSANDRA_HOME system variables. In my case, I needed to create them. To this, I did the following:

  1. Click the Start Menu
  2. Right click Computer
    1. Click Properties (this opens the Control Panel in the System and Security > System view)
  3. Click Advanced system settings on the left side (this opens the System Properties dialog in the Advanced tab)
  4. Click the Environment Variables button (this opens Environment Variables  dialog)
  5. Under the System variablesgroup:
    1. Click New… (This opens the New System Variable dialog)
    2. Input JAVA_HOME for the Variable name text box
    3. Input the path to your java installation for the Variable value text box (I entered C:\Program Files\Java\jdk1.7.0)
    4. Click OK
  6. Under the System variablesgroup:
    1. Click New… (This opens the New System Variable dialog)
    2. Input CASSANDRA_HOME for the Variable name text box
    3. Input the path to your Cassandra extraction for the Variable value text box (I entered C:\dev\cassandra\apache-cassandra-0.8.2)
    4. Click OK
  7. Click OK
  8. Click OK
  9. Close the Control Panel

We are almost ready. Before running Cassandra, the storage configuration must be modified to make sure that any UNIX style paths are replaced with their corresponding Windows style paths. This is done by opening up the cassandra.yaml file in your favorite text editor and looking for those paths. My file was located in C:\dev\cassandra\apache-cassandra-0.8.2\conf\cassandra.yaml. I had to make the following changes:

  1. On line 72, I changed /var/lib/cassandra/data to C:\dev\cassandra\apache-cassandra-0.8.2\data
  2. On line 75, I changed /var/lib/cassandra/commitlog to C:\dev\cassandra\apache-cassandra-0.8.2\commitlog
  3. On line 78, I changed /var/lib/cassandra/saved_caches to C:\dev\cassandra\apache-cassandra-0.8.2\saved_caches

At this point you should be able to start up and run Cassandra. This can be done via the command prompt like this:

cd \dev\cassandra\apache-cassandra-0.8.2\bin

You can also start the client from the command prompt like this:

cd \dev\cassandra\apache-cassandra-0.8.2\bin
connect localhost/9160;

What’s next? Now you can do your development tasks and use your local Cassandra instance as needed. I will probably use Topshelf or something similar to get Cassandra running as a service so I don’t have to start it up manually every time I need it. Another option for this is to use RunAsAService.


Here are some links that I used to learn how to do this:

Setting up a SharePoint Development Environment to Support Silverlight Development

[via Andrew Connell]

This morning Andrew Connell held a webcast introducing ASP.NET developers to Silverlight development for SharePoint. The webcast is the third in a series of webcasts to help ASP.NET developers get primed for SharePoint development. After the webcast Andrew was kind enough to post the steps he took in preparing his SharePoint development environment for Silverlight development.

I wonder if it is possible to create a solution file to deploy the Silverlight 2 Beta 1 DLL and make the necessry configuration changes to the web.config file to make the set up of the environment easier? I might have to try that.

Creating WSS Solution Packages for Microsoft Office SharePoint Server 2007

I am assuming you have done custom development for Microsoft Office SharePoint Server 2007. Whether it was a custom web part, workflow, event handler, feature, or module, at some point you probably had to figure out how to deploy it. If you are like me and learn a lot of what you know by doing, then you probably had to fiddle with web.config files and debugging errors with code access security exceptions. This post takes a stroll through a couple of ways to build and bundle a WSP file (a WSS solution package) and deploy it.

Before I begin, you should know that what assumptions I am making about the environment:

A Simple WSP Solution Package

I will update this post with a walk through of creating a simple WSP solution package using the Visual Studio 2005 extensions for Windows SharePoint Services 3.0 in the near future.