Scott Densmore

MonoTouch Comparison with Apple Tools

I have been playing around with MonoTouch trying to figure out if I liked the new approach to building Cocoa Touch apps. I decided to take a couple of the samples built using MonoTouch and build them for the Cocoa Touch using Apple's toolset.

HelloWorld

I decided to start out with the easiest thing first: building HelloWorld based on this article. I read through the article and built the Apple version first. Open XCode and choose a new Window-based application. This is the closest to the iPhone application from MonoTouch. The first thing I noticed is that I do things opposite of how they are done in MonoTouch. When I am going to create outlets for connecting objects from Interface Builder, I do that in code then go to Interface Builder. This is how "stylish" programmers do things. At least that is what I learned at the Big Nerd Ranch. So I opened up the header file and updated it to look like this:

#import <UIKit/UIKit.h>

@interface HelloWorldObjCAppDelegate : NSObject <UIApplicationDelegate> {
    UIWindow *window;
    UIButton *button;
    UILabel *label;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet UIButton *button;
@property (nonatomic, retain) IBOutlet UILabel *label;

- (IBAction)sampleTap:(id)sender;

@end

I added two properties for the button and label. I use custom Text Macros for doing this so I don't have to do a lot of typing [more on this later]. After this I opened up Interface Builder and setup the interface and made the connections. The connections are the same except they are already part of the UIApplicationDelegate.

Now for the fun part. Adding in the code for the actions. Unlike Cocoa on Snow Leopard, there is no support for blocks on the iPhone so I don't get similar delegate support. If you want to have it you can get plblocks. The code in the implementation file looks like this:

@implementation HelloWorldObjCAppDelegate

@synthesize window;
@synthesize button;
@synthesize label;

- (IBAction)sampleTap:(id)sender {
    [label setText:@"Second button clicked"];
}

- (void)buttonEvent:(id)sender {
    static int count = 0;
    [label setText:[NSString stringWithFormat:@"I have been tapped %d times.", count++]];
}

- (void)applicationDidFinishLaunching:(UIApplication *)application {
    [button addTarget:self action:@selector(buttonEvent:) forControlEvents:UIControlEventTouchDown];
    // Override point for customization after application launch
    [window makeKeyAndVisible];
}

- (void)dealloc {
    [window release];
    [button release];
    [label release];
    [super dealloc];
}
@end

The addTarget:action message is what happens under the covers when you connect your action and event in Interface Builder. I set the text for the label using NSString stringWithFormat:. This is just like string.Format with printf arguments. All in all, not much code except for the release calls and not much difference in the hello world.

Get code here.

RSS Reader

I moved to a little harder sample. I am using the RSS Reader tutorial. The first thing I needed to do is figure out the layout of the response from the rss. I use HTTP Client to view requests / response. In XCode I created a Navigation based application. I renamed a few files (RootViewController -> NewsArticleViewController) via the Rename refactoring support in XCode (yes XCode has some refactoring and also takes snapshots of your code before it makes the changes). I also added the News Article model class and a parser for the rss feed. The Cocoa framework doesn't have a built in XML Document, but instead uses SAX style NSXMLParser. I wanted to hide this and also do it in a background thread using an NSOperation. Here is what my project looks like:



I will not bore you with the gory details of the code in the parser. I could have used some third party library code to make it easier, yet I decided to stick with what comes in the box. Check out the touchcode project if you want something else. The key was to have it parse through the code and build up the models from the rss feed. Another difference is that I reference the DetailsViewController from the NewsArticleViewController. I dragged a UIViewController into the controller and set it's class to DetailsViewController in the identity inspector and NIB name to DetailsViewController in the attributes inspector.

I added an outlet in the NewsArticleViewController and hooked this up in Interface Builder. I added the title to the navigation controller and showed it so I could navigate back to the list. The UI needs a little love to spice it up. Given everything, not much more code than MonoTouch.

Get code here.

The Takeaways

MonoTouch is a great start. It comes down to language differences. If you want to learn more about them Matt Gallagher has an amazing post that you should read. It took me a while to get comfortable with Objective-C (a couple of months). The language itself is pretty easy. I really like it because of the dynamic nature. The IDE is lacking in functionality especially a debugger, which makes it hard to switch. I find the use of classes for delegate markers a little odd since they are protocols in Obj-C and more akin to interfaces. I understand the reason for not doing this is because in Obj-C, things can be optional. This is not possible in a strongly typed language like C# (see Matt's post). The Garbage Collection is nice yet I think as a platform, Cocoa Touch will get GC just like Cocoa for OS X. I am more of an XCode person, so I wish they would have invested in working with XCode. All in all, to really understand building Cocoa Touch apps, you will need to understand the underlying framework (Cocoa Touch). The abstraction is interesting to make it work with a static language like C#. I will keep my eye on this to see where it goes. I don't think it is worth the $500 US to switch for me right now.

Tools

TextMacros Article
XCode Article
Accessorizer - good code generator / helper / expander

Listened to: Octane Twisted from the album "The Incident" by Porcupine Tree

.NET, Mono

Orlando .NET User Group Talk - 12 Practices to be a Better Developer

Last week I gave a talk at the Orlando .NET User Group on Practical Software Craftsmanship - 12 Practices to be a Better Developer. Most of these 12 are just things I have learned over my years of development. I promised I would put links to the slides and resources from my talk. They are in no particular order and I don't claim they are nothing more than fortune cookie wisdom :D. I will try and write more about these in the future.

Download 12 Steps to a Better Developer.pptx.zip (15261.7K)

The 12 Practices

1. Source Control - If you don’t store your code in source control, you’re putting your company at risk.
2. Test-Driven Development produces higher-quality code. Behavior Driven Design - Behavior is documentation for other developers and users.
3. Build Systems - Building is more than just compiling code.
4. Continuous Integration - Check in early and often.
   
5. Real Time Code Review - Two heads are better than one.
   
6. Refactoring: Easy as red light green light.
   
7. Read Code - "You don’t become a better writer by just writing." Scott Hanselman
   
8. Code In Increments - Real programmers work for hours and hours straight, without a break, without even looking up. Don’t break your flow to stop and compile: just keep typing! :)
   
9. Sharpen your skills by learning a new language.
   
10. Learn SOLID
    • Single Responsibility Principle - There should never be more than one reason for a class to change.
    • Open Closed Principle - A class should be open
for extension but closed for modification.
    • Liscov Substitution Principle - Subtypes must be substitutable for their base types.
    • Interface Segregation Principle - Clients should not be forced to depend upon interfaces that they do not use.
    • Dependency Inversion Principle - High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
11. Know when to unlearn. The ways you learned when you first started are clearly the best ways. Not much has changed since then, really. :)
12. Be a Mentor

Resources

These are great places to pick up some of the key concepts:

Scott Hanselman - Reading To Be A Better Developer
S.O.L.I.D. Month on LosTechies
31 Days of Refactoring
MSpec BDD Tool
MSpec is your BFF
xUnit
xUnit Patterns

Listened to: Death Whispered a Lullaby from the album "Damnation" by Opeth

.NET

Singletons Are Evil Part 2

A while back I wrote a post about why singletons are evil. I still agree with that statement, yet after my comment on twitter today, I think I need to show how you can solve this problem differently.

The first problem we need to solve is creating the instance itself. This can become difficult if we have dependencies and we are trying to limit the creation. For example we have class Foo that is our singleton:

public static class Foo
{
	static Foo instance;
	
	public static Foo Current
	{
		if (instance == null)
		{
			instance = new Foo();
		}
		return instance;
	}
	
	public void SomeMethod()
	{}
	
	public void SomeOtherMethod(int x, int y)
	{}
}

Great! Easy enough and no big issues other than this is quite contrived and nothing in the real world is this easy. So lets go ahead and tackle the next big problem: Multithreading. We fix our class with a double check lock and end up with this:

public static class Foo
{
	static volatile Foo instance;
	static object syncObj = new object();
	
	public static Foo Current
	{
		if (instance == null)
		{
			lock (syncObj)
			{
				if (instance == null)
					instance = new Foo();
			}
		}
		return instance;
	}
	
	public void SomeMethod()
	{}
	
	public void SomeOtherMethod(int x, int y)
	{}
}

I am starting to feel a little dirty, but I can handle a little dirt. Now we are good except that Foo now has a dependency: Bar. Why the dependency? Well that is the object that we use to get some of the information we want in our singleton. Ok, lets see what this looks like:

public static class Foo
{
	readonly Bar bar;
	static volatile Foo instance;
	static object syncObj = new object();
	
	private Foo(Bar bar)
	{
		this.bar = bar;
	}
	
	public static Foo Current
	{
		if (instance == null)
		{
			lock (syncObj)
			{
				if (instance == null)
					instance = new Foo(new Bar(new Bar()));
			}
		}
		return instance;
	}
	
	public void SomeMethod()
	{}
	
	public void SomeOtherMethod(int x, int y)
	{}
}

At this point alarm bells should be going off and your brain should be going to DEFCON 1. We introduced Bar only to see that it needed a Baz. We have violated SRP and coupled all our classes together. Now imagine writing a test around any class that needed to use Foo. You get one Foo and all its dependencies that need to be cleared between tests. This causes you to write that clear method on your class that really is only needed to get rid of state you were trying to support anyway.

So hopefully by now, we agree that this is evil. Yet, I agree that singletons are something useful in the right scenario. So how can you avoid Global Thermonuclear War when using a singleton? Well fire up your trusty IoC container and let it manage it for you. Here is an example in Unity.

public class Baz{}
public class Bar
{
	readonly Baz baz;
	
	public Bar(Baz baz)
	{
		this.baz = baz;
	}
}

public class Foo
{
	readonly Bar bar;

	public Foo(Bar bar)
    {
		this.bar = bar;
	}
	
	public void SomeMethod()
	{}
	
	public void SomeOtherMethod(int x, int y)
	{}
}
...
IUnityContainer container = new UnityContainer();
container.RegisterType(typeof(Baz), typeof(Baz));
container.RegisterType(typeof(Bar), typeof(Bar));
container.RegisterType(typeof(Foo), typeof(Foo), new ContainerControlledLifetimeManager());

Now we have separated the creation of the object and it's life time from the object itself. This way we let the container handle the singletoness of the object and it's creation. You still have to deal with multithreaded access to the dependencies of Foo, but when you decide that is just way to evil and there are better ways to solve this problem, you can change the lifetime management and go on about your business. This also frees you up to easily test this object and perform refactorings (like the ones Sean is talking about this month).

Did I mention singletons are evil?

Deliverance by Opeth

This Code For Rent

Given the current economy and the housing market here in Florida, we have been talking a lot about renting versus owning a home. How does this have anything to do with code? Glad you asked. In the life of any given application, you are probably in it for only a short time (relatively). You might be on the team that builds the version 1.0 product or you might be on the team that is supporting version 6 of a product on version 8. Whatever the case may be, more often than not, you are just there renting the code.
I think this is an important fact to remember. My friend Brain Button taught me a long time that I am not my code and that I definitely do not own it. When I put myself in the mindset of a renter instead of an owner, the idea of The Broken Theory makes perfect sense. When you rent a home / apartment / car, you sign an agreement to take the best care of the thing you are renting the best that you can. Why should that not be any different for code? No matter how you decide to take care of the code you are renting, you should always feel good when you turn (check) it in.

Oblivion by Mastodon

TDDFireStarter in Tampa

Wanted to give a big shout out to the guys putting on this event. Scott, Sean, the guys from Blue Spire (along with others) did a great job presenting this information. And Joe (aka Devfish) [Microsoft] for sponsoring the space. I hope to be able to attend and speak at more of these events in the future .

The Velourium Camper II: Backend Of Forever by Coheed & Cambria

Updating Diff/Merge in VSTS

I am tired of looking up this post every time I repave my machine. So here it is, the definitive list of tools and how to configuration them. Thanks to James Manning and his great post.

NHibernate 2.0 with SQLite for UnitTesting

I spent the last month learning NHibernate and I am definitely a fan. I have been using SQLite for unit testing similar to Ayende in his post. The problem I ran into is that every time I ran my tests the connection was getting reset. A little google whispering and I found the answer in Justin Etheredge's post. Hopefully this will help me remember as well as others.

Here is what the code should look like:

public override ISessionFactory BuildSessionFactory() 
{ 
   var properties = new Dictionary 
                        { 
                            { "connection.driver_class", "NHibernate.Driver.SQLite20Driver" }, 
                            { "dialect", "NHibernate.Dialect.SQLiteDialect" }, 
                            { "connection.connection_string", "Data Source=:memory:;Version=3;New=True;" }, 
                            { "connection.provider", "NHibernate.Connection.DriverConnectionProvider" }, 
                            { "connection.release_mode", "on_close" }, 
                            { "show_sql", "true" } 
                        };

    configuration = new Configuration { Properties = properties }; 
    configuration = configuration.AddAssembly(typeof(Ticket).Assembly); 
    return configuration.BuildSessionFactory(); 
}

The winning line is "connection.release_mode" setting it to "on_close".

Listened to: Apollo I: The Writing Writer from the album "From Fear Through The Eyes Of Madness" by Coheed & Cambria