iOS Development for .NET Developers: Using Blocks like Anonymous Delegates

Learning a new programming language is a lot of fun, but it can be disorienting to not have all of your usual tools in your mental toolbox, so to speak.  We get used to using our familiar patterns and syntax, and even though the new language may be just as capable, it takes some getting used to in order to have the same level of productivity.  It’s been over a year since I started working on iOS apps in Objective C, and still I sometimes find myself searching for ways to write a block of code that I could write with my eyes closed in C#.  Yes, the answers are out there, but in a world of native C and Objective C gurus, it’s not easy to find someone who can relate the new skills in terms of skills I already have – that is, how a .NET developer sees the language, architecture, and syntax of iOS development. 

 

Luckily for me, I happen to have a colleague who is one of the most talented .NET developers I’ve had the pleasure to work with…AND who has been recently working in iOS as well.  You can check out his many awesome blogs here. Together we’ve been compiling ideas, explanations, and comparisons of what we’ve learned in Objective C to what we are most familiar with in .NET.  If this topic interests you, I invite you to come see a full presentation at the 2012 Silicon Valley Code Camp, but for now I’ll start out with just some simple tips.  We had so many ideas, not all of them will make it into the presentation, but that won’t stop us from sharing them here!

 

Anonymous delegates have come so far in .NET, haven’t they?  One thing I really miss when writing code for iOS apps is my beloved lambda syntax!  When I want to write an inline handler, or I need to use some locally scoped variable, they’re just so very useful, simple, and easy (for me, at least) to read.  Especially with async operations, it’s nice to see the code called on completion right there, instead of buried away a hundred lines down.

 

Here’s a simple C# example of using an anonymous delegate to execute a block of code when a storyboard completes.

// execute some code when the storyboard completes
storyboard.Completed += (s, e) =>
{
    storyboard.Stop();
    Debug.WriteLine("Completed");
    NavigationService.Navigate(uri);
};

This is basically a shorthand way of declaring the handler with its arguments in parenthesis (s, e) and then the lambda operator followed by the code block in braces.

 

To do something similar in code for an iOS app, we can use Blocks to execute code on the completion of an animation. 

[UIView animateWithDuration:0.2 
    animations:^{
        // animation block
        self.view.alpha = 0.0;
    } 
    completion:^(BOOL finished){
        // completion block
        [self.view removeFromSuperview];
    }];

 

Blocks can be defined explicitly and then used as functions, but in this case it is more similar to the inline anonymous delegate if we declare the block inline as well.  This example actually shows two kinds of blocks.  The first one has no parameters (note the ^ symbol followed immediately by the opening brace), and the second block has a single BOOL parameter (in this case named ‘finished’).  Both blocks are passed as parameters into the animateWithDuration:animations:completion: method.

 

This nice image from the apple developer library shows the parts of the block syntax.  Our inline block is basically the right-hand side of the equals sign in this example.

 

image: ../Art/blocks.jpg

 

Using blocks in this manner has all of my favorite benefits of the anonymous delegate in C#.  I can use variables in the same scope, and it also makes the intent very easy to read, since the code is right there in the method call.  So, a little something familiar in some otherwise unfamiliar territory is kind of nice! 

 

If you’re a .NET developer looking to get into native iOS development, the best advice I have is to jump right in and just start writing.  There is no amount of study that equals good old practical experience.  If you come upon a problem that makes you think, “Ok, here’s how I would solve this in C#”, then very often you can use that as your guide to work out a solution in Objective C.  Is it always easy?  Definitely not!  But is it fun?  Absolutely!

comments powered by Disqus