This article is part 1 from a 12-part article series on Windows Phone 7 for iPhone and Android Developers.
This article will provide an introduction to the basic concepts of writing code in C# for those of you already familiar with Java from Android development or with Objective-C from iPhone and iPad development. If you’re already a .NET developer and you’ve been building ASP.NET applications and you’re interested in learning how to write WP7 apps, then feel free to skip to the next article in this series. The ultimate goal of this series of articles is to prepare you for writing Windows Phone 7 applications, whether your background is in ASP.NET, Android, iPhone, or iPad development.
The first thing developers notice about C# is how much it looks like C or C++. This is not a coincidence. Contrary to popular belief, C# was inspired by C and C++ and was not inspired by Java. If you’ve seen Java, Objective-C, and C# code side-by-side and you’ve thought about how similar they look at times, you’re not alone. All three of these languages owe much of their heritage to the original ANSI C language. In fact, Objective-C is actually a functioning superset of ANSI C so it does more than borrow it’s heritage from C, it’s a direct descendant.
Like Java and Objective-C, C# is an Object-Oriented programming language. As an iOS or Android developer you should probably be very familiar with basic OOP concepts like encapsulation, inheritance, and accessors. Fortunately, the C# language looks enough like Java and Objective-C that basic arithmetic and even some conditional logic operators are indistinguishable among the three languages.
For example, in the following bit of code, it is impossible to tell which language we’re using without additional context:
int a=5;
int b=10;
int c;
c = a + b;
while (c > 1)
{
c -= 1;
}
The code here is pretty primitive but it illustrates an important point – while there are syntactic differences in the languages, the biggest difference in idiomatic code samples across the three languages isn’t the language itself: it’s the nature and design of base classes being used. When you look at code samples for the iPhone, what you notice is UIKit and heavy use of the delegate pattern and MVC (Model-View-Controller), the fact that the language being used is Objective-C becomes secondary. When you’re looking at Android code, you notice the Android development framework and the underlying APIs more than you notice Java. The same is true for Windows Phone 7 – what you notice when building WP7 code is the extensive use of Silverlight, the base classes that belong to the .NET Framework, and the various device APIs.
Future articles in this series will introduce you to these APIs when we get into the nuts and bolts of actual Windows Phone 7 programming. For now, this article’s goal is to provide you with a quick look at C# so that, as you progress through this series of articles, you can concentrate on the work at hand without letting the language syntax get in your way.
Memory Management
If you’ve been developing iOS or even desktop applications for the Mac then you should be familiar with how memory is managed in Objective-C. At one point in Objective-C’s past was actually little more than a set of symbols that mapped to method calls to add Smalltalk-like object-oriented functionality. To handle the fact that pointers to objects regularly get passed around to multiple other objects, often simultaneously, Objective-C adopted a reference counting scheme. Anytime an object needs an instance of another object to stay around long enough to get work done, the containing object (often called an owner) retains that object. When it is done with that object and can get along without it, it will release that object.
Let’s say you have a game engine class that holds references to all of the various objects currently participating in the game such as the game board, game pieces, and other objects such as a scoreboard. The game board has references to the game pieces but so do the player objects owning said pieces. If a player object decides that it’s done with a particular game piece, it can’t simply deallocate the memory for that object because it doesn’t know who else is using that particular object at the time. A standard solution to this problem that is used by more languages than just Objective-C is reference counting. Every time an object becomes the owner of another object, it will increment it’s reference count by 1. In iOS, you do this with the retain message as shown below:
When an object relinquishes ownership of an object, it can then decrement the object’s reference count. In iOS this is done by sending the release message:
Objective-C has many facilities for making reference counting easier such as autorelease pools which, when drained, will force every object contained within the pool to decrement its reference count by one. A problem that many iOS developers, myself included, have to deal with on a daily basis is tracking down memory leaks. It can get very easy to “over retain” an object, preventing its memory from ever being reclaimed. You can also prematurely release an object so that the next time you try and do anything useful with that object, unpredictable results (up to and including an app crash) can occur.
Introducing Garbage Collection (and there was much rejoicing)
Now that I’ve reviewed the pain and suffering that is the burden of every iPhone developer, let me just tell you that Windows Phone 7 has no such burden: there is no reference counting on this platform. Like Java, C# is a garbage collected language. Objective-C relies on you to keep track of which objects own which other objects and at what point it is acceptable for those objects to be removed from memory. I don’t know about you, but I get uncomfortable anytime anything relies on me to function properly.
In a garbage-collected runtime, there is an omnipresent helper keeping track of everything your code allocates. In C#, it does so by maintaining a tree of “roots”. Rather than manual referencing counting, C#’s garbage collector works by root counting. It keeps track of all of the paths to objects allocated on the heap. When the garbage collector runs periodically, it will seek out all of the orphaned objects that can no longer be reached (this would be like having a reference count of 0 in iOS) and dispose of them.
While garbage collection frees you of the burden of manually managing your own reference counts, this doesn’t give you carte blanche to utterly abuse your application’s heap. Collecting objects and re-organizing free memory on the heap takes time. The more stuff you keep lying around the slower your garbage collection will be. Also, if you are rapidly allocating and de-allocating objects over and over (such as in tight loops) you could also create garbage collection performance problems.
in general, the garbage collector rarely makes its presence known and if you keep your code clean and tight and are fairly responsible with the memory you consume, then you should find the development experience in C# to be much less stressful when it comes to memory management and tracking down memory leaks.
Hello Zombie
To illustrate what some straightforward C# looks like without getting bogged down by the horror of standard “Hello World” applications, I’ll show you a class that exhibits some of the most classic examples of C# programming, including inheritance, interfaces (contract-based programming, or ‘protocols’ to you iOS developers), abstract base classes, properties, methods, and more all without printing '”Hello World” to a console screen.
In this sample, we’re going to build a few classes that might be at home within a game engine. This game engine could be a mobile WP7 game engine or web-based, it doesn’t really matter. The point of these classes is to illustrate some very clear, idiomatic C# and relate that to concepts that might be familiar to Java and Objective-C developers.
First, we know that we’re going to have combatants in the game. Since none of the three languages allow for multiple inheritance, we’re probably already used to the following problem: How do we make a bunch of things able to participate in combat without making them all part of the same inheritance tree? In other words, we want to be able to fight monsters, humans, or maybe even magically animated coffee tables. To do this, we want to create a contract (in C# we call them interfaces, Objective-C calls them protocols). Anything that conforms to this interface, regardless of its inheritance hierarchy, will be able to respond to combat. In other words, if our game engine sees an object of type ICombatant, it knows that it can engage in a fight.
Here’s a look at the ICombatant interface:
public interface ICombatant
{
int HitPoints { get; }
string Name { get; }
void GetHit(ICombatant attacker);
void Attack(ICombatant target);
}
This interface tells us that any combatant in the game needs to be able to report (read-only) it’s hit points and needs to expose a read-only property so the game engine can identify the name of the combatant. In addition, every combatant needs to expose two methods: one to respond to being attacked and one to initiate an attack on another combatant.
In the Java world, you may not be used to properties, so the contract to which your Java class would conform would have a single “get” accessor method called getHitPoints() and another accessor method called getName(). In Objective-C, you might declare your property like this:
@protocol CombatantProtocol <NSObject>
@required
@property(readonly) NSNumber *hitPoints;
@end
This same interface in Java might look something like this:
interface Combatant
{
int getHitPoints();
String getName();
void GetHit(Combatant attacker);
void Attack(Combatant target);
}
Remember that this is a contract and not actual implementation code. So whether we’re looking at C#, Java, or Objective-C code, we’re only describing what the real class must do. In other words, it is up to the implementation of the class to decide how it should support the HitPoints property. As a side note, you may have noticed that instead of using a regular “int” I used an NSNumber pointer. This is because Objective-C is real ANSI C and as such, it’s int type is nothing more than that. Java and C# both treat integers like objects. Even though I used the C# keyword “int” it will actually compile as a System.Int32 object, which has methods on it like ToString() and other handy methods that a C integer doesn’t have. This is why it’s customary in iOS development to use NSNumber pointers rather than their scalar counterparts, especially because in iOS you cannot add ints to collections but you can add NSNumber objects.
Now that we have a contract, we need a class to implement it. We’ve all been around the Object-Oriented Programming block a few times so we know that we’re probably not going to want to start directly with a Zombie class. Instead, let’s create an abstract class (one that cannot be instantiated but rather only serves as a parent class to the real classes) called Monster, from which we can derive other classes like Zombie or Vampire or MotherInLaw (you know I’m right…)
Here’s our Monster class:
public abstract class Monster : ICombatant
{
private int hitPoints;
#region ICombatant implementation
public int HitPoints
{
get { return hitPoints; }
}
public virtual string Name { get { return "Monster"; } }
public void GetHit(ICombatant attacker)
{
OnHitByAttacker(attacker);
}
public void Attack(ICombatant target)
{
OnAttackedTarget(target);
}
#endregion
protected virtual void Say(string message)
{
Console.WriteLine(Name + " says: " + message);
}
/// <summary>
/// To be implemented by deriving classes
/// </summary>
/// <param name="attacker"></param>
protected virtual void OnHitByAttacker(ICombatant attacker)
{
}
/// <summary>
/// To be implemented by deriving classes
/// </summary>
/// <param name="target"></param>
protected virtual void OnAttackedTarget(ICombatant target)
{
}
}
Now we’re getting into some C# that is a little bit more involved and starting to look a bit less like Objective-C and Java. First there’s a class member called hitPoints that provides the backing store for a public (read-only) property called HitPoints. Just like Objective-C and Java, C# is case-sensitive.
Next there’s a read-only property called Name. I’ve marked it virtual because I want deriving classes to be able to provide a replacement implementation. In other words, I want the Zombie class to be able to identify itself as “Zombie” to the game engine rather than just identifying itself as “Monster”. Next up are the two methods required by the ICombatant interface. Here we invoke some virtual methods. This allows the deriving classes to override the OnHitByAttacker and OnAttackedTarget methods. You’ll see this type of pattern used regularly in C# and Windows Phone 7 programming. Using this pattern we can provide some standard behavior that every monster does and then provide enhancements or customizations to this behavior in deriving classes. For example, we could make a type of monster that always runs away screaming like a little baby whenever it gets attacked or another monster that calls for help and summons a bunch of other monsters to it when it gets attacked.
Now that we’ve got a standard Monster class, let’s see what a typical Zombie class might look like:
public class Zombie : Monster
{
protected override void Say(string message)
{
Console.WriteLine(Name + " slobbers: " + message);
}
public override string Name
{
get
{
return "Zombie";
}
}
protected override void OnAttackedTarget(ICombatant target)
{
base.OnAttackedTarget(target);
}
protected override void OnHitByAttacker(ICombatant attacker)
{
base.OnHitByAttacker(attacker);
Say("BRAAAAAIIINNNNSSSSSS!!1");
Attack(attacker);
}
}
Finally we’ve got a class that we can instantiate and that our (entirely hypothetical and nonexistent) game engine can utilize. The first thing we do in our Zombie class is override the Say method so that instead of “saying” text, our monster “slobbers” the text. This adds a little character to the game and allows different monsters of different types to speak with their own style.
Next we override the Name property to return the text “Zombie”. The OnAttackedTarget overridden method has no custom logic in it now but we could easily expand that to do something interesting, such as eventually adding support for brain-sucking or other flesh-tearing maneuvers that are typical zombie attacks.
Finally I overrode the OnHitByAttacker method. The "base.OnHitByAttacker(attacker);” method call will invoke whatever code resides in the Monster base class. No zombie is truly a zombie without shouting the classic “BRAINS!” phrase upon being hit by someone else. In response to being attacked, our zombie simply returns the favor.
Let’s recap some of the basic C# language features we’ve discussed up to this point:
- Basic language features like conditionals and arithmetic
- Memory management and garbage collection
- Basic OOP like creating a class
- Inheritance (Zombie inherits from Monster)
- Interfaces (the Monster abstract class implements the ICombatant interface)
Armed with the information in this article, you’re ready to continue on to subsequent articles in this series where I will talk about basic and advanced UI techniques, push notifications, going from MVC to MVVM, utilizing device hardware like cameras and even FM radios, and much more.
About the Author
Kevin Hoffman (http://www.kotancode.com/) is a Systems Architect for Oakleaf Waste Management (http://www.oakleafwaste.com/), freelance developer, and author of multiple books including the upcoming WP7 for iPhone Developers and co-author of books such as ASP.NET 4 Unleashed and SharePoint 2007 Development Unleashed. He is the author of the Kotan Code blog and has presented at Apple's WWDC twice and guest lectured at Columbia University on iPhone development.