Recently just published Asp.Net loves Html. A site targeted at web developers urging them to take the leap away from web forms and back to HTML. Check it out and make your voice known at the bottom of the site page. The site was written using Asp.Net MVC, pretty pretty cool.

P.S. If you know the the Konami code, give it a try. 

I just installed Visual Studio 2010 and I have to say I am impressed so far. The whole user experience is clean and vibrant. It feels like the first time I opened up Visual Studio and wrote my first hello world application. It definetly is exciting. Check out the screenshots below. There are a couple downsides currently: There isn't ASP.NET MVC templates and tools available just yet and Resharper didn't transfer over. Ok, time to great cracking on the new .NET 4.0 framework; can't wait to see what I can do with it.

I recently wrote my first iphone application the other day and found that although it wasn't difficult to write it, I would prefer a language like C#. The one thing I did like was the naming of parameters when making a method call. 

[object methodWithInput:input];

A little wierd compared to most languages which adopt dot notation, but hey the languages have to differ somewhere. This feature is being adopted in the newest iteration of C# and I think it's great and will definetely start using it, but here is why you might get some fight from other developers on using them.

Code Bloat

Adding more text on a line will increase the amount a developer has to read. You might get arguments against named parameters, but named parameters make your code more readable. Any method that takes a boolean instantly becomes more readable once the input parameter is named. I pulled the following from ASP.NET MVC.

MembershipUser currentUser=_provider.GetUser( userName, true);

MembershipUser currentUser=_provider.GetUser( userName, userIsOnline:true);

"You Just Like the Candy"

I hear this a lot, "You just want to use the new stuff cause it's new." Well that may be the case, but new stuff is never created to make things harder for a developer. Named Parameters are no exception. But the value of this candy complements the addition of optional parameters in C#. If you don't use the named parameters, your optional parameter methods might become confusing and harder to read.  

"Do I Have To?"

 Well no you don't have to use named parameters, just like you don't have to use lambda expression. It's all syntactical sugar that makes your development life easer. If you choose not to use it, then it's your decision.

Take a look at this feature and keep an eye out, you'll see an explosion of use regarding named parameters once .NET 4.0 comes out (but that's just the ramblings on one developer).

Here is a great blog post about named parameters take a look. 

I had someone email me and ask me how the XNA Game Engine was going and said they would like to try it out. So here it is. Instead of letting the code die, I thought I would give it a second chance with other developers. I haven't had much time lately and when I heard the diswasher game took 2 years to make, that got me a little bummed about the prospect of slaving away for years making a game by myself.

The features in the game engine include:

• Game screen managment
• Sprite Animation engine and Spritesheet pipeline
• Particle Engine (Mercury)
• Farseer Physics
• Input with Recognition (combos and moves)
• Kick Ass 2D Camera

Ifrit.zip (1.67 mb) (needs XNA 3.0 Studio)

Business applications are great for generating large amounts of revenue for large corporations, but recently I am starting find them a little boring. I feel like most of the business problems I am faced with are not very challenging or simply rehashed problems that need rewritten. That is why I am venturing into the area which started my passion for development. Games! If you've read the last two post's you've seen me jump from WPF to Silverlight. I sat down to start a game in Silverlight but soon realized that I didn't fully understand the concepts behind game development in .NET. It's been a while since I wrote a game (college to be exact). XNA to the rescue.

I started looking at XNA several months ago and was very impressed, but I wasn't at a point where I had time to invest in learning the framework. After a week of looking at what XNA has to offer I think I am ready to create a game, all be it not very graphically impressive. But if you want to get started with XNA there are several things you should look at in the XNA framework. Here they are.

Game

The Game class is your main entry point to your game. It has the methods needed for your game to function: Initialize, LoadContent, Update, and Draw. 

GameComponent and DrawableGameComponent

Think of these classes as plugins. You inherit from these classes and they give you the same methods as in your game class: Initialize, Update, and Draw(if DrawableGameComponent). You don't have to use these classes, but I recommend using them. Why? Well the Game class has a GameComponentCollection. Adding your component to this collection will automatically trigger calls to the components Update and Draw methods. This makes your Update and Draw in your Game class very clean and clean code is very important when writing games.

GameServiceContainer 

This is also a property on the Game class. Think of this as your IoC container for your game. You can drop services and resolve them with from the GameServiceContainer. This is helpful for those cross cutting concerns you want to share amongst your components. A word of warning though, this container will not inject types into your object like you are used to. This container is only used to pull the services. It also doesn't have any generics support, but if you are using .NET 3.5 I've written some extension methods that make using it a little cleaner.

public static class GameServiceContainerExtensionMethods
{
public static T GetService< T >(this GameServiceContainer container)
{
return (T)container.GetService(typeof (T));
}
public static void RemoveService< T >(this GameServiceContainer container)
{
container.RemoveService(typeof (T));
}
public static void AddService< T >(this GameServiceContainer container, T service)
{
container.AddService(typeof(T), service);
}
}

GamePadState,KeyboardState, and MouseState

These are the classes used to retrieve input from your players. Yes your game might have players and you have to be prepared to accept their input.

SpriteBatch

This class is used to draw your content to the screen (2D anyways). 

Conclusion

Their is definetly a lot of stuff to look at in the XNA framework but if you understand the classes I mentioned above then you should have a good start to create your game. 

So if you didn't notice my last three posts focused on WPF and Silverlight. I am really getting into this whole Rich Internet Application (RIA) thing that is happening in the .NET world. It's not to say RIA is better than your standard web applications, but it is something to keep my excitement for learning alive. So when I created my WPF application, it was a very organic learning process. What does that mean?

When I was creating IWuvYou everything I did fell into place relatively easy: Triggers, M-V-VM, ICommand, and your UI. It was quite easy; Silverlight hasn't been quite the same process. Where is Silverlight losing me and what is my fault and what could be better?

I have to first say the Silverlight is not WPF. Let me repeat that; Silverlight is not WPF! I keep reading a lot of blogs and watching a lot of videos telling me to do certain things to make my WPF application to work in Silverlight and vice versa. I could do that, but what I've seen people do seems to compromise what WPF is trying to do and what Silverlight is trying to do.

My first and biggest disappointment with Silverlight is ICommand is not supported in the controls, you have to write your own harnessing mechanism to rig it up. Now that is fine in your Silverlight application but porting your own ICommand harness to WPF breaks the number one rule of development: "Don't reinvent the wheel."

Secondly, to make your WPF/Silverlight application you end up using a lot of conditional compilation symbols. 

#if SILVERLIGHT
// My Silverlight Code
#else
// My WPF Code
#endif

Now imagine that all over your WPF/Silverlight application. It can get ugly really fast. And this just opens up a can of worms when talking about unit testing. How do you unit test code that depends on compilation? (I'll leave you to answer that one).

I don't want this to turn into a rant against WPF or Silverlight. These are two great technologies but I am starting to lose faith in the idea that you can maintain one code base and have it run on every concievable platform. That idea sounds great at first but when you think about it harder, you'll notice that you lose something on each platform that you decide to comprimise on. An application geared to the web ported to your PC loses the ability to be updated in one central location. The idea of a PC application ported to the web loses all the power that a PC application can afford you: file system access, hardware, and background processes.

So what's the best approach to writing an application that works in both WPF and Silverlight? Well my approach would be to write your core code focusing on the Models and Controllers. For Silverlight, I would approach it with a Model-View-Presenter pattern. For WPF, follow the Model-View-ViewModel approach; it really is suited perfectly for WPF. Simply, write two different UI's for your application and abstract away any dependencies that might cause problems in either a PC or Web environment so they can be switched out easily with something like an IoC Container.

I am still new to both technology stacks but I'm leaning more to favor WPF, but I am sure I will contradict myself in later posts. I will end this post by saying that I love WPF and Silverlight, but I think it's like loving Ice Cream and Ketchup; I love each in their own right and not together. I will also say that I may have drank the Kool-Aid too hard on the "Silverlight is WPF" idea that is being sold.

For anyone who wants to embed a Silverlight XAP application in their Blogengine.NET blog I have posted the extension below. Just drop this in your extensions directory and change the settings to meet your Silverlight needs. The extension will work on Blogengine.NET sites targeting both the 2.0 and 3.5 framework. This works for me right now, but could be modified slightly to accept values when setting up the tag.

To use, place the following in your post : [ silverlight : blah.xap ]  (without the spaces).

Note: Remember to allow your Host to serve up XAP files by registering the MIME type. If you don't do this, then you won't see your applications.

SilverlightApplicationExtension.zip (1.51 kb)

I'm all about WPF and Silverlight right now, it really is exciting to get to make something that is has visual merit and not just work merit. Yeah sure your webservice can serve up thousands or objects in less than a second, but can your objects dance? NO! I just downloaded Expression Blend 3 and Silverlight 3 Beta and started playing around. I have to say Expression Blend 3 is not much different but what is different makes the blend experience much much nicer; worth the definite upgrade.

Here it is then my first true Silverlight app, it does nothing other than cycle through states. This is what the code behind looks like for my Silverlight application.

namespace Emoticons
{
public partial class Page : UserControl
{
string[] States = new string[] { "Normal", "Happy", "Sick", "In_Love", "Sad", "Cool" };
int currentStateIndex = -1;
public Page()
{
// Required to initialize variables
InitializeComponent();
}
private void LayoutRoot_Loaded(object sender, System.Windows.RoutedEventArgs e)
{
Button_Click(this, null as RoutedEventArgs);
}
private void Button_Click(object sender, System.Windows.RoutedEventArgs e)
{
currentStateIndex++;
if (currentStateIndex > States.Length - 1)
currentStateIndex = 0;
VisualStateManager.GoToState(this, States[currentStateIndex],true);
Mood.Text = States[currentStateIndex].Replace("_"," ");
}
}
}

Here is my application, (sorta I couldn't find a blogengine extension for silverlight that actually worked. I guess I'll have write one :P).

Update: It is now working, I wrote the extension and now can serve up silverlight apps in Blogengine.net, pretty cool.

Download the Silverlight 3 runtime

Emoticons.zip (28.09 kb)

My girlfriend was telling me that I don't text her nearly enough through out the day. Being a developer, I immediately realized that the act of texting was a completely repetitive task. What else is development for than to solve repititive tasks and make your life easier. So I decided to write a little application that would text her through out the day with little messages to let her know that I still care. This seemed pretty simple and I wrote an initial winform version in no time, but it lacked the humor and character that an app with this intention needs. I realized that WPF would be perfect for this but I had only dabbled with it before. I set off searching for references and there is definetly enough on the internet and especially a good amount on DotNetKicks. Once I felt confident, I ended up with the following.

I want to give credit to Everaldo Choelho for the crystal icons. And I also want to give credit to Clarice Gomes for the HeartVectors off of Vecteezy. There was also code used from James-Newton King found on Haacked.com and Dr. WPF. The online community is great!

The application was a joke and my girlfriend found it funny :P

The Application

These screenshots don't really do the application much justice, I've used the animation aspects of WPF to animate some of the windows and made several of the hearts glow. It's visual candy and WPF is 100% the reason for my rotting teeth. Just kidding, my teeth are fine but you get my point. Download the application and give it a try, if you run into any issues please let me know. I have only tested it with AT&T since that is what I and my girlfriend have.  When you start the application set up your love profile which you can see below. IWuvYou uses email to text message gateways setup by the phone companies, which is not the best solution but works. If you don't have a girlfriend then just set yourself as the love interest (freaky).

Thoughts About WPF

WPF is completely awesome, I was a little hesitant at first because I am a web development kind of guy: WCF, ASP.NET, JQuery, and etc. I thought to myself, how could WPF really be any different than Winforms? It is completely different, you are entering a world where you are no longer constrained by your ideas of what an interface is. If a designer can mock it up, you can take that mock up and bring it to life without any compromise. You have to approach WPF development differently than WinForm development. If you try to use WinForm ideas in WPF you will not be happy with the outcome. I used the Model-View-ViewModel pattern and it made things very easy. If I had more design cred and capabilities then this app could be even more visually dazzling, with exploding hearts, crazy sound effects, and fluid animations (not that cramming all that in one application makes it a good application).

Now the negative. WPF is good and frustrating for the same reason. You can make anything look the way you want it to, but if you want a different look then you have to make it look the way you want it to. There aren't a lot of WPF themes out there. But using someone else's theme doesn't make your application unique so I understand why Microsoft excluded that from Expression Blend and WPF. Xaml can also be daunting if you haven't had time to become accustomed to it; relax and breath and it will get better over time. Other than those two things, I haven't found other things that frustrated me enough to give up on WPF.

The code written for this application works, but that doesn't mean that it doesn't need a lot of refactoring. I attempted to use Unity and IoC but since I didn't fully understand the WPF development domain, the implementation of IoC kind of broke down a little on me. I also was using TDD to create the services and repositories, but once I got to the UI that process broke down. I felt that learning what I was doing this first time was daunting enough. This doesn't mean I have abandoned TDD for WPF because it is definetly applicable, and as this application get more refined tests will be added in. So note, this application works, but it probably has bugs and needs refinement.

Use WPF and leverage it's power to give your apps that extra pop!

Download

IWuvYou.zip (893.66 kb) (no source included)

Afterthought

I am planning to port this code over to Windows Mobile 6.5 and running it on a cellphone; accessing the SMS stack found on the device instead of the email to SMS gateway.

I was reading the Microsoft Application Architecture Guide and I came across this quote on page 58.

"Prefer composition over inheritance. Wherever possible, use composition over inheritance
when reusing functionality because inheritance increases the dependency between parent
and child classes, thereby limiting the reuse of child classes." - Microsoft Application Architecture Guide

It then hit me why I prefer interfaces over deep levels of inheritance. Inheritence is good but when used wrong can put you in strange situations. "What do you mean this Cat object is also a Car?" Composition Oriented Programming are the strengths of patterns like MVP, MVC, and MVVM. It allows you to use atomic chunks of code without building layers of deep inheritence. It's better to be shallow than to be deep, no matter what Dr. Phil tells you.

"First you get the Interfaces, then you get the Power, then you get the Women."

I just thought I would share my epiphany with you, and long live the Interface.