Jeremy Bytes

Happy New Year!

2012-01-01T14:00:00.000-08:00

Another year has gone by, and we have another year to look forward to. Thank you to everyone who attended one of my sessions at a code camp or user group. You are why I keep presenting.

Over the last 2 years, you've come out to see me at 45 sessions across 20 events, with a total of over 1,500 people in attendance (1,510, but who's counting?).

We've got another great year coming up. I've already got several sessions scheduled, and I hope to see you at one in the future.

Jan 28 & 29 - So Cal Code Camp (Fullerton, CA)
Mar 6 - San Diego .NET Developers Group (San Diego, CA)
Mar 20 - Disney .NET Developers Group (Burbank, CA)
Mar 21 - San Gabriel Valley .NET Developers Group (Monrovia, CA)
Apr 26 - Southern Nevada's .NET User Group (Las Vegas, NV)
May 8 - Inland Empire .NET User's Group (Riverside, CA)

All of these dates are subject to change (so be sure to check beforehand), and there will be more events in 2012 as well. Hope to see you at one of them.

Happy Coding!

Exceptions in Multi-Cast Delegates

2011-11-13T11:29:00.001-08:00

At the last 2 code camps (So Cal Code Camp and Desert Code Camp), the same question came up. How do exceptions affect the process flow when invoking a multi-cast delegate? Let's do a quick review and then take a closer look. For more information, please take a look at Get Func<>-y: Delegates in .NET.

Multi-Cast Delegates
All delegates in .NET are multi-cast delegates. This means that we can assign multiple methods to the same delegate variable. When we invoke the delegate variable (to run the methods), then all methods that have been assigned are run.

For example, take a look at this Action variable:

Action<List<Person>> act;

Then we can assign multiple methods as follows (in this case using lambda expressions):

act += p => Console.WriteLine(p.Average(r => r.Rating)).ToString();
act += p => Console.WriteLine(p.Min(s => s.StartDate));

Then we can invoke the delegate (assuming that "people" is a list of Person objects):

act(people);

The resulting output to the console window is as follows:

6.4285714285714288
10/17/1975

Single-Threaded Execution
.NET does not do anything magical when it runs the methods assigned to the delegate. They simply run in order, synchronously, on the same thread where the delegate is invoked. In the examples from the "Get Func<>-y" session, we invoke the delegate from the UI thread of a WPF application, and we see that if one of the methods is blocking (such as a MessageBox.Show() method that waits for user input), then the other methods do not execute until that method has completed. (As you can imagine, if we wanted the methods to run on separate threads, we could do that; but that is not the default behavior.)

Exceptions
Now, what happens if we add an exception into the mix:

act += p => Console.WriteLine(p.Average(r => r.Rating)).ToString();
act += p => { throw new Exception("Error Here"); };
act += p => Console.WriteLine(p.Min(s => s.StartDate));

What do we expect to happen? Will all 3 methods execute? None of the methods? Only the first one?

The answer turns out to be pretty simple. Since the methods are run in order, the first method will execute successfully, the second method will throw an exception, and the third will not execute. Since we do not have any exception handling defined, our application will stop working. The console window will have the following:

6.4285714285714288

So, we can see that the first method did in fact run, but the third method did not.

Exception Handling
We can keep our application operational by adding a try/catch block around the invocation of the delegate. This will keep our application from completely erroring out:

try
{
act(people);
}
catch (Exception ex)
{
Console.WriteLine("Caught Exception: {0}", ex.Message);
}

And our output now looks like the following:

6.4285714285714288
Caught Exception: Error Here

But something to notice, even though our application continues (and completes normally), the third method still does not run. And this should not be surprising. When an exception is thrown, the system will walk up the call stack until it finds an exception handler. If it does not find one, then the application will error out. In this case, when the exception in the second method is thrown, it walks back up the call stack to the method that invoked the delegate. There it finds the try/catch and handles the exception. But since we exited out of the actual delegate invocation, the third method is not called.

Some Things to Think About
Now let's consider a bit how we use delegates. Generally, we (as developers) are on one end of the delegate or the other -- meaning we are creating a delegate so that other developers can hook into our code, or we are using a delegate to hook into someone else's code.

If we are creating a delegate that we invoke (such as the call to act(people) above), then we should definitely consider wrapping the invocation in a try/catch block. When someone assigns a method to a delegate that we then invoke, we really have no control over what that assigned method does. This means that we need to protect our code to make sure that someone else's mistake does not cause our code to crash. We need to handle any exceptions that are generated by the invocation so that our application can continue to operate (or at least fail gracefully).

Also, as we noted in "Get Func<>-y", we should be checking the delegate before invocation to make sure that it is not null. In this code sample, it would look like the following:

try
{
if(act != null)
act(people);
}...

If we try to invoke a delegate variable that does not have any methods assigned, then we will get a null reference exception. Alternately, we could handle the NullReferenceException in our catch block, but it's usually better to avoid the exception if it can be anticipated.

But what if we're on the other side of the delegate? What if we are a developer who is assigning methods to a delegate to hook into someone else's code? In that case, we need to follow standard practices for error handling in those methods. We could easily add a try/catch block to the method that we assign to a delegate variable. This way we would have the first shot at handling the exception. And since the exception is happening in our code, we are probably in the best position to try to handle it. If we cannot handle the exception, then we can let it bubble up (as we saw in the sample above). How we handle this will depend on the type of delegates that we are working with, what our business processes are, and how we have designed our error handling and failure modes through the rest of the application.

We always need to be on the lookout for the unexpected. In the sample code that shows up in my demos, the error handling has been excluded (just so that we can more clearly focus on the topic at hand). But when building our applications, we need to make sure that we are following good programming practices and making sure that we can handle the exceptions that may occur in our code.

Happy Coding!

Upcoming Code Camps

2011-09-18T12:06:00.000-07:00

Code Camps are a great way to spend a day or two hearing great presentations, talking to other developers, and seeing what's hot in the dev community. Best of all Code Camp is always FREE!

If you are a developer, you have something to share. Sign up as a speaker. It's easy, it's fun, and you'll learn a lot doing it. Here are some tips for Code Camp Speakers: Meet the Next Code Camp Speaker: You!

So Cal Code Camp - Los Angeles, CA
October 15 - 16, 2011
If you're in the Southern California area (or are looking for an excuse to go there), come join us at the So Cal Code Camp. There are a ton of sessions to choose from, lots of developers to meet, and always a good time to be had.

So Cal Code Camp
I'll be speaking. Will you?

Desert Code Camp - Chandler, AZ
November 5, 2011
If you're in the Phoenix area (or are looking for a reason to head out to the desert), come join us at the Desert Code Camp. There are great developers to meet, a ton of variety in the sessions offered, and even session tracks just for kids.

Desert Code Camp
I'll be speaking. Will you?

Hope to see you there!

Meet the Next Code Camp Speaker: You!

2011-08-16T21:23:00.000-07:00

If you are in the So Cal area, the next code camp is only 8 weeks away. It's the perfect time to sign up to be a speaker: http://www.socalcodecamp.com/.

Code Camp speakers come from the developer community. That's you! It turns out that most developers have something to say. We have all picked up tips and tricks with each new project we work on. In addition, we constantly find things in the development platform that we weren't familiar with before. And many times we find ourselves saying, "I wish someone had told me about this before."

Now's your chance. Code Camp is an easy place to get started as a speaker. As a developer, you are speaking to other developers. We all understand each other. Also since Code Camp is free, we're not expecting professional technical speakers (although, I'll admit that I've heard speakers at Code Camp who were better than some of the speakers at the professional conferences).

I'm going to share some tips that I've learned along the way, including some things that I specifically set out to avoid. There are no rules for speaking. Everyone has a different style. These are a set of tips which have worked for me. They may or may not work for you.

Danger: You May Get Hooked
I had done a few presentations for fellow developers within my department at work but never thought I would get up to speak in front of complete strangers. But after speaking at my first Code Camp, I was hooked. I signed up to speak at more Code Camps in my area, and let the local user groups know that I was interested in speaking.

Here's what hooked me: there's nothing quite like helping other people. The speaking part itself is a lot of fun for me, but what is most rewarding is if I get an email a week later from someone who let me know how they were able to use the information that I presented. Being helpful to someone else really drives me forward.

How Did I Get Started?
I got started as a speaker almost by accident. In my mind, I didn't have anything ground-breaking to talk about. I wasn't dealing with the latest beta products or cutting-edge software. I was just a competent developer working with established technologies. It seems like everyone was interested in whatever was new and shiny, so I didn't think I had anything to say.

Then I was listening to .NET Rocks! (a really good podcast, by the way). There was a panel discussion and one of the topics that came up was the lack of beginning and intermediate sessions for people who were new to development or just new to .NET. When .NET was first released, there were all sorts of introductory sessions including the basics of the languages, the CLR, garbage collection, and just how to get started creating applications. Then over the years, the introductory sessions faded away to be replaced by whatever the latest technologies were. The panel agreed that there was a need for people to present those introductory topics to keep bringing more people into the world of .NET development.

I thought, "Hey, I can do that." And I took it as a challenge. About 2 weeks after the podcast, I heard about an upcoming Code Camp and determined that I would put together three sessions for it. (It may have been a lot to bite off my first time around, but I had 8 weeks to prepare).

Those first sessions went very well. And I attribute that primarily to the preparation.

So let's take a look at some tips to get started with.

One Rule
Earlier I mentioned that there were no rules. But that wasn't quite true. In reality there is one rule: Have fun! If you aren't going to enjoy this, then no one attending will enjoy it either. It's okay if you are nervous. But once you get started, just like any other performance, the nervousness usually fades away. Just go with it and have fun.

Picking a Topic
One of the first things you will need to do is pick a topic. Pick a topic that you are passionate about, something you really love. Okay, love is a bit of a strong word, but select something that you have found really useful in your development -- something that you wouldn't want anyone to take away from you.

Here's a tip from Scott Hanselman: Give the presentation that you want to attend. When you are thinking about a topic, go back to the "I wish someone had told me about this before" moment. It may be a common subject; it may seem basic or simplistic. That's okay. If it is something that you wish you had known about earlier, chances are that there are a lot of other developers who don't know about it yet.

One other thing about picking a topic: be aware of the scope. You have limited time to present your session. If you pick a topic that is too broad, then you may end up skimming over the top without going into any useful detail. If you pick a topic that is too narrow, you may find that you don't have material to fill up the time slot.

Preparation
I cannot say enough about being prepared for your presentation. I know what I am going to say before I walk in the room. If I end up giving the same presentation a second or third time, it will generally be almost exactly the same content each time.

Often at Code Camp, you will see people in the back of the room frantically typing away. These are usually speakers who are finishing up their slides or code samples. This works for some people (people who love the "deadline"). And if you are a veteran speaker, you can often get away with it. It doesn't work for me. Your first time out, you are going to have a lot of things on your mind (How do I use the AV equipment? Is Visual Studio working right? Can I find my slides?) If you have your presentation nailed down, that is one less thing to worry about.

The first step in preparation is to know your material. By putting together a presentation, I find that I have big gaps in my knowledge about the topic. This is usually because I needed to use a technology for a specific project with specific requirements. But if you want to present the broader topic, you will find that there are parts of the technology that you have not used and need to learn about. This doesn't mean you need to become an expert. But you do need to at least know all of the terminology and have a general idea of how ti all works, even if you can't give the specific details.

Once you have everything put together (topic, slides, demo code, etc.), then practice, practice, practice. Run through the presentation all the way through multiple times. And not just in your head. Speak out loud (pets are a great audience for your first practice runs). I generally run through a new presentation at least 4 times. This helps me find the places where I stumble or need to clarify my thoughts. Sometimes you get tongue-tied. That's what practice is for. Even if I am doing a repeat of a presentation that I've done before, I'll run through 1 or 2 practices to make sure that I still know what I'm talking about.

Stay on Time
One thing that all of the practice will help you with is to stay on time. Is your presentation running long? Figure out what you can cut or speed up. Is your presentation short? That may be okay. It leaves more time for questions or to explore some of the items a little further.

One of the worst things you can do at Code Camp is run long. Code Camp is usually a very compressed day. People have limited time to get from session to session (and to visit the restroom or grab a soda in between). If you run long, then you will lose the attention of the people in the room anyway, so it's best to make sure that won't happen.

Things don't always go according to plan. My first time out, I thought that I had my timing down fine. I was confident and took time for a few questions in the middle of the session. But because I had practiced so much, I recognized about halfway through the time that I wasn't halfway through my material. I made some quick mental cuts and decided what I could skip over. I was able to do this on-the-fly without it being too obvious that I had done so.

Slides
No one likes slides at Code Camp. We're not executives that want bullet points. We want to see code in action. So feel free to go light on the slides.

With that said, I would not recommend ditching the slides entirely. If you have slides, then the folks in the room know that you spent at least a little bit of time in preparation. I've gone to a couple completely slide-free presentations, and they seemed to be completely ad-libbed (which could be fine depending on the topic). My personal approach is to have a couple of slides that introduce me and the topic, but then I spend most of my time in the code. This is just my style; other people approach this differently. Again, the goal is to find what works best for you as a speaker.

Remember the advice to give the presentation you would like to attend. Do you want to see a lot of wordy slides with the presenter simply reading them? Probably not. The slides are there to augment what you have to say, not repeat it or replace it.

One other thing that I do with my slides is have a reference links slide at the end of the presentation. This would contain links to web sites, blog articles, MSDN articles, or other helpful materials. I post my slides on my website so that people can get to these links without having to scribble them all down during the presentation.

Demo
Code Campers love demos. We want to see what you are talking about in action. There are a lot of different styles for this part.

First, there is the advice to never do a live demo. There are too many things to go wrong. And Murphy's Law says that it will probably all go wrong right in the middle of your presentation. Personally, I think that preparation can mitigate a lot of this risk (and I'll talk about a few specific items of preparation that help in just a bit).

If you have a demo set up that is very complex, such as one that requires multiple computers networked together or needs access to a specific web site, then you might consider doing a screen capture of the demo and then playing it during the presentation. And even if you want to do this live, it doesn't hurt to have the video as a backup in case the network goes down or something else goes wrong.

But the most effective demos are live demos. How you approach this will depend on your topic and how deeply you want to cover things. You may want to start with a blank project and build an entire application live. This works well in a lot of cases, but be aware that you will be limited in how much you can show.

You may want to start with several different projects that are in various stages of completion. In this case, you can open the #1 project, add some code and show what it does. Then move on to the #2 project which has more code in place, add some more code and show what that does. This can be a very effective way of presenting a topic.

Here's what I do -- again, take this as part of my personal style based on how I pick topics; it is what has worked well for me. I generally start with a project that is prepared just enough for me to start putting in the important code. For example, if I am doing an introduction to XAML, I start out with a completely new, blank project and move from there. If I am speaking about lambda expressions, then I have the UI already laid out and start with mostly blank code behind the UI. The idea is that anything that is already in place is not necessary to understand for the topic being discussed; it is part of the background.

One other thing you can do. If you have large blocks of code to add as part of your demo, don't make people watch you type. This can be especially painful if you are not a good typist. If you have large blocks of code, then create another file within your project that contains the code in comment blocks. Then you can copy/paste the blocks of code into your project during the demo. This saves you a lot of time, and it also helps to avoid typos.

As part of my preparation, I have 2 copies of each of my projects. The first copy is the "Starter" project. This is the mostly-blank project that I am going to fill in with the code during the presentation. The second copy is the "Completed" project. This is what the project looks like after I have completely run through the demo. This is my safety net. If something goes horribly wrong during the live code demo, I can always open up the completed application and show the pieces already in place. The good news is that I have only had to do this once (knock on wood). I attribute this to preparation; I have practiced the code demo so many times that I know exactly what I need to do. And if something does go wrong, I've probably already seen that same issue during the practice runs.

The Tools
Feel free to ignore this tip. This is a personal preference based on sessions that I have attended. The tip: run naked. Okay, don't do that literally (no one needs to see that). What I mean is disable the add-ins in your development environment unless they are critical to what you are trying to demo. When I see someone do a demo, I want to be able to go home and do exactly the same thing. If the speaker is using an add-in that has magic keystrokes, then it makes it harder for me to follow.

This primarily applies to non-free add-ins. If you have free tools that you find useful, then by all means recommend them. As developers we are always looking for new tools that can make our development faster and more effective.

One other thing about tools: if you know any shortcuts that are native to the development environment, be sure to share them. Not everyone is aware of what Ctrl+K,D does. Not everyone is aware of what the little purple box means. Not everyone is aware that you can press 2 keys to stub out an interface. If you can fit these tips into your presentation, then go ahead and do it.

Organization
How you organize things is part of your preparation. You need to know where all of your slides, code samples, demos, and websites are. I have been in a few presentations where the speaker opened the wrong projects and had trouble finding the code he was looking for. Don't let this happen to you. Something that I find useful is to create a folder that has shortcuts to everything I need. You can put this folder on the desktop or even dock it to the taskbar. If you have multiple shortcuts to code projects, then number the shortcuts so that you can open them in the correct order.

During the Presentation
You will probably be jittery as the presentation starts. That's fine. This is normal. A lot of times, this may lead to you speaking too quickly or getting tongue-tied. If this happens, just pause and take a deep breath. Have a bottle of water with you, and take a sip. You don't have to fill every second with talking. Taking a deep breath will give your brain a chance to catch up and organize your thoughts. Then you can continue clearly and confidently.

Watch your speed. If you have practiced, then you should know where the quarter, half-way, and three-quarter marks are in your presentation. When you hit those spots, how does that compare to the clock? If you are ahead of time, then you may want to slow down, or pause to see if anyone has questions. If you are running late, then you may want to start thinking about what you can skip later on or if you can simply speed up a little bit.

Focus on Individuals
When you are speaking, try to look at individuals in the room. It is tempting to talk directly to one person (the one person who is paying most attention). But make sure that you are talking to everyone. Talking to "everyone" does not mean simply throwing your words into the room; you need to talk to the individual people in the room. While speaking, take a few moments to make eye contact with one person, then move on to another person. Remember that you are talking to actual people.

I forgot this once. I was on my third presentation of the day. The other two presentations had full rooms with lots of energy. The third presentation just had a few people in the room. I tried to continue the energy into that room, but it didn't work. It was awkward, and I bombed the presentation. I got all of the information out there (because of the practice I had), but I never made a connection with anyone in the room. Ultimately, I'm glad that it happened. I learned from what I did wrong, and I've been better able to adjust my presentation style based on the situation.

Taking Questions
It's up to you to decide whether you want to take questions during your presentation. If you are going to take questions freely, then plan your presentation so that it would normally end 10 to 15 minutes before the end of the allotted time. If you want to save questions for the end (if there is time), that is fine, too. Just let your attendees know how you would like to handle questions.

If you take questions, stay on topic. If someone asks a question that will take you off topic, it is okay to put the question off. As developers, we always want to show off how much we know. So if someone asks a question, your first instinct is to answer it. But here's the problem: if the question takes the session off topic, it may be good for the one person in the room (the person who asked the question), but it will be horrible for the rest of the people in the room. After all, they all came to hear you speak about a particular subject. I have often been frustrated (as an attendee) when a session was derailed by someone asking questions that are relevant only to that one person.

If you take questions, it's okay to defer. It may be that the question is either off topic or that the question is on-topic but would take too long to answer. If this is the case, then let the person know that you would be happy to talk to them about it later, either between sessions or in email.

If you take questions, it's okay to not know the answer. You don't have to know everything before you become a speaker. I have often had people ask me a question that I did not know the answer to. This is usually because they bring up a scenario that I had never thought through or tried before. In these situations, I generally write down the question and then say that I will post the answer on my blog once I have time to research it. Exactly how you handle the situation is up to you. But it is better to say that you don't know than to make up an answer.

After the Presentation
There are a couple things that you can do after the presentation to wrap things up. First, if you have code samples or slides that you say you will make available for download, then do it. I have been at professional conferences and had the speaker say that the code from the session would be on the website after a week. I checked after a week, and it wasn't there. I checked after two weeks, and it still wasn't there. Because of curiosity, I went back two months later, and it still wasn't there. If you say that you are going to post your code, then post your code. And by the way, if you don't want to post your code, that's okay, too. Just make sure that if you say you will do something, you follow up on it.

Another "this works for me": I always post my code samples and slides on my website before the presentation starts. This way, I don't have to worry about finding the time to do this later (because I'm very good at forgetting things). It also has the side-effect of forcing me to prepare. I can't post the slides and code samples until after my preparation is complete.

Finally, follow up on questions. If you say that you will post answers on your blog or follow up with an individual over email, then make sure you do that.

Final Words
So, we've talked about a lot of different tips. As I noted, most of these things have worked well for me. Some of them are things that have bothered me from sessions that I have attended. But everyone is different.

Remember the one rule: Have fun! The fate of the world does not depend on you giving a good presentation. If you mess up, no one's going to die. You learn best when things go wrong.

And make sure to be yourself. Everyone has a different style of speaking. Everyone has a different style of coding. Don't pretend to be someone else when you are speaking. Just be yourself. If you are prepared, then things are bound to turn out just fine.

Everyone has something to share with other developers. Take the next step and sign up for the next Code Camp in your area. You might find that you love it, and you'll be speaking more and more. You might find that it's not your thing. That's okay, too. But you never know until you try.

Happy speaking!

Upcoming Speaking Engagements

2011-05-10T13:09:00.000-07:00

I have a couple of speaking engagements scheduled later this month. Come on out if you can.

May 19, 2011
Southern California .NET Architecture Users Group
Santa Ana, CA
http://www.socaldotnetarchitecture.org/

May 24, 2011
BiTKOO Webinar
BiTKOO, a leader in authorization management software (and the company I work for), is hosting a free webinar on Tuesday, May 24 at 1:00 PDT. The topic is "Leveling Up: Authorization in Your Application". You can get more information on the topic and sign up here: https://www3.gotomeeting.com/register/975758094

And next month...
June 25 & 26, 2011
So Cal Code Camp - San Diego, CA
It's code camp time once again. Code camp is a great place to meet and talk to your fellow developers, find out what tools people are using, and what's working and what's not. Plus, you get 2 solid days of FREE sessions -- over 100 to choose from. If you can make it, be sure to hunt me down to say, "Hi".
http://www.socalcodecamp.com

Happy Coding!

1,000 Attendees!

2011-04-04T19:40:00.000-07:00

A big thank you to those of you who came to my sessions at the Desert Code Camp this weekend. I had a great time, and it was good to see some of you back in my sessions again. You helped me pass the 1,000 mark -- over 1,000 people have come to my sessions since I started speaking publicly in January 2010 (although I know it is fewer than 1,000 unique people since some of you have come to more than one of my sessions).

Here's a breakdown of my speaking engagements:

Jan 2010 - So Cal Code Camp - Fullerton, CA
135 attendees (3 sessions)

Feb 2010 - Disney .NET Developers Group - Burbank, CA
30 attendees

Jun 2010 - So Cal Code Camp - San Diego, CA
59 attendees (3 sessions)

Jul 2010 - LA C# User Group - Manhattan Beach, CA
20 attendees

Jul 2010 - So Cal .NET Developers Group - Buena Park, CA
25 attendees

Oct 2010 - ASP.NET SIG - San Diego, CA
30 attendees

Oct 2010 - So Cal Code Camp - Los Angeles, CA
339 attendees (8 sessions)

Nov 2010 - Desert Code Camp - Chandler, AZ
77 attendees (3 sessions)

Jan 2011 - Inland Empire .NET User's Group - San Bernardino, CA
20 attendees

Jan 2011 - Disney .NET Developers Group - Burbank, CA
30 attendees

Jan 2011 - So Cal Code Camp - Fullerton, CA
145 attendees (3 sessions)

Feb 2011 - Disney .NET Developers Group - Burbank, CA
38 attendees

Feb 2011 - San Gabriel Valley .NET Developers Group - Monrovia, CA
20 attendees

Apr 2011 - Desert Code Camp, Chandler AZ
63 attendees (3 sessions)

Grand Total: 1,036!

I've had a great time speaking. Hopefully you've had a great time listening. If you'd like to have me come to your user group or other event, just drop me a note. As a reminder, if you've come to one of my sessions, you can download the session materials from my website: http://www.jeremybytes.com/Demos.aspx.

Happy Coding!

Desert Code Camp - April 2nd

2011-03-20T21:07:00.000-07:00

Desert Code Camp in Chandler, Arizona is coming up quickly (Saturday, April 2, 2011). If you are in the Phoenix area -- or simply need an excuse to go for a road trip -- it's a great way to spend the day. I was able to attend last October, and I'm looking forward to going back again.

Talk to your fellow developers, get some free training, and make some great contacts. There are over 100 sessions on the schedule including a track just for kids.

Desert Code Camp 2011.1
April 2, 2011
Chandler, AZ

Hope to see you there!

Additional Links for Design Patterns

2011-02-24T17:43:00.000-08:00

I've had some folks who have attended my Design Patterns session suggest some links that they have found useful. (And if you want to check out the session materials, just go to my website: Learn the Lingo: Design Patterns.)

Head First Labs - Head First Design Patterns
http://headfirstlabs.com/books/hfdp/
This is the link for the "Head First Design Patterns" book that I've recommended. And there's some really good news. I noted that the book is written with Java samples, but that it's not too hard for a C# developer to follow along. The good news is that the labs includes a link to a collection of C# samples. Just search for "C#" on the labs page, and you should find it.

Head First Design Patterns Study Group
http://onjava.com/pub/a/onjava/2005/04/06/designpatterns.html
The O'Reilly On Java website has suggestions on forming your own study group based on Head First Design Patterns. I've heard from some folks who have done this, and they found that it was a good learning experience for everyone involved. Discussion with other developers usually leads to new insights for everyone.

Do Factory - Design Pattern Framework 4
http://dofactory.com/Default.aspx
This site sells a product called Design Pattern Framework 4. As a disclaimer, I have not actually used this product, nor do I really know much about this. But I have received recommendations from session attendees, so it may be something worth looking into further. In going through the information, there is also an endorsement from Miguel Castro (who is one of the big players in the .NET community), so that leads me into wanting to look at this a little more closely.

If you've had experiences with either the Head First Design Patterns study group or using the Design Pattern Framework 4, please drop me a line and let me know what you think.

Happy Coding!

Upcoming Speaking Engagements

2011-02-06T17:27:00.000-08:00

I have a couple of speaking engagements scheduled in February. Feel free to come out if you can.

Feburary 15, 2011
Disney .NET Developers Group - Burbank, CA
Web cast available. Disney employees and Cast Members can check TechSpot for details.

February 16, 2011
San Gabriel Valley .NET Developers Group - Monrovia, CA
http://sgvdotnet.org/

Also, it looks like I'll be heading back to the Desert Code Camp on April 2, 2011 in Chandler, AZ. More information here: http://apr2011.desertcodecamp.com/

Hope to see you there! And if you have a user group or other event you'd like me to come speak at, just drop me a line and let me know: feedback@jeremybytes.com.

Happy Coding!

Thank You for Coming!

2011-02-01T19:09:00.000-08:00

I want to thank everyone who attended one of my sessions at the SoCal Code Camp this past weekend (and even those of you who were brave enough to attend more than one of my sessions). As a reminder, the Walkthroughs, Slides, and Code Samples are all available for download: http://www.jeremybytes.com/Demos.aspx.

If you have any questions, suggestions, or even session topics you'd like to see me present in the future, feel free to drop me a line at feedback@jeremybytes.com.

Until next time...

Happy Coding!

Mini Review: Code - The Hidden Language of Computer Hardware and Software

2011-01-18T20:50:00.000-08:00

I recently finished reading Code: the Hidden Language of Computer Hardware and Software by Charles Petzold. Here are a few quick thoughts:

This is not really a programming book; it is a description of how computers work. Designed for the layman, it starts off with the basics of codes (Morse Code, Braille, binary codes) and then moves on to how to communicate those codes using electro-mechanical relays (such as telegraph relays). From there, it talks about how these relays can be combined in various ways to create logical operations and built up to a simple adder -- the basic building block of computer hardware. The components are pieced together from the earliest computers to modern machines (well, almost modern -- the book was written in 1999). As a non-CS major, I found this book to be very approachable and it gave me a good understanding of how software can be turned into instructions for the hardware.

Overall, this was an interesting read. For me, it went quite quickly (just a few weeks in small chunks), and I have a better feel for how computer hardware works at its most basic level.

Happy Coding!

Update: Learn to Love Lambdas

2011-01-09T14:37:00.000-08:00

Lambda Expressions have turned out to be a popular topic (I've got three presentations scheduled for January alone). With that in mind, I have expanded the Learn to Love Lambdas walkthrough and demo code.

Get It Here
You can get the complete walkthrough (18 pages) and code samples here:
http://www.jeremybytes.com/Demos.aspx#LLL

Direct Links:
PDF Walkthrough
Code Download

Happy Coding!

Quick Bytes: Get Func-y

2011-01-08T14:27:00.000-08:00

If you look into the LINQ extension methods, you will run across Func quite a bit. If you see Func in a method definition, you can treat it like a big sign that says "Put your lambda expression here." This quick demo will show that Func is simply a shorthand for creating a delegate and that Func and lambdas go together hand-in-hand.

Get It Here
You can get the walkthrough (just 5 pages) and the code sample here: http://www.jeremybytes.com/demos.aspx#QBGF.

Direct Links:
PDF Walkthrough
Code Download

Happy Coding!

Book Review: Pro ASP.NET MVC 2 Framework

2011-01-03T20:22:00.000-08:00

I just finished reading Pro ASP.NET MVC 2 Framework by Steven Sanderson (Apress). What I found was a good introduction to ASP.NET MVC as well as a deeper dive into the majority of the features.

This is labeled as "Intermediate to Advanced". It assumes that you are familiar with C# and .NET, but it doesn't expect you to be an ASP.NET WebForms programmer. If you are familiar with web technologies (HTML, CSS, Javascript), then you should be just fine. And although this is covering the 2nd version of the ASP.NET MVC framework, it does not assume that you have any prior knowledge of version 1.

There are several things I liked about this book. First, it is very approachable. The tone is inviting and easy to understand. Next, the code samples are thorough. Since ASP.NET MVC 2 can be used with either .NET 3.5 or .NET 4.0, it shows how to use the framework in either environment, and the differences are pointed out where the environments vary. Finally, the overall organization makes you want to read more.

Part 1 includes an introduction to ASP.NET MVC 2 and a sample application showing a real-world (although simplified) implementation of the framework. Since the MVC pattern lends itself to unit testing and test-driven development (TDD), the book also shows a few useful techniques including using dependency injection and mocking with unit testing. And to keep things more accessible, Sanderson uses free tools (such as NTest) for the examples since not all versions of Visual Studio include unit testing.

Part 2 takes all of the features that were introduced in Part 1 and goes into them in detail. This includes all of the core features of ASP.NET MVC including Routing, Controllers, Actions, Views, and Models. But going beyond just a description of using what's "in the box", the book also talks about how you can extend the framework yourself, such as by creating custom controller classes, filters, or even your own view engine. In addition, it gives a number of helpful techniques for putting together user interfaces including a trip into the world of AJAX and jQuery.

Part 3 covers some of the nitty-gritty details including Security and Deployment. This is where the world of ASP.NET MVC and WebForms starts to overlap. And this last part also goes through many of the features of the standard ASP.NET platform that you will want to make use of in your MVC applications.

Unlike my previous review of an ASP.NET MVC book, I highly recommend this book. The quality of the book is very high. There are few errors (no book is perfect) and the code samples are well done and complete. I have become a big fan of ASP.NET MVC. Although it is not the "best" or "only" way to write web applications, it is a great tool to have in the toolbox. I can think of a number of applications from my past that would have been much more elegant using ASP.NET MVC.

If you are curious and want to get started in the technology, Pro ASP.NET MVC2 Framework is a great way to go. Part 1 will give you a taste of the feature; Part 2 will take you through each one in depth; and Part 3 will show how MVC integrates with the rest of the ASP.NET framework.

Happy Coding!

Upcoming Speaking Engagements

2011-01-03T10:34:00.000-08:00

I have several speaking engagements coming up in January. If you've always wanted to meet me in person, come on out. I'd love to meet you.

January 11, 2011
Inland Empire .NET User's Group - San Bernardino, CA
http://iedotnetug.org/

January 18, 2011
Disney .NET Developers Group - Burbank, CA
Web cast available. Disney employees and Cast Members can check TechSpot for details.

January 29 - 30, 2011
So Cal Code Camp - Fullerton, CA
http://www.socalcodecamp.com/

Hope to see you there!

Happy New Year!

2010-12-31T20:37:00.000-08:00

I know it's been a while since I've posted anything new. I decided to take the month of December a little easy. Coming up soon I'll have some information on speaking engagements in January and also a review of Pro ASP.NET MVC2 by Steven Sanderson (preview: it's an excellent book).

I wish you a Happy New Year! And as always, Happy Coding!

Learn to Love Lambdas Session Questions

2010-11-20T22:12:00.000-08:00

Here are a couple of questions that came up during the Learn to Love Lambdas sessions at recent Code Camps. If you would like to review the session, you can check out the walkthrough and code samples here: Learn to Love Lambdas.

Extension Methods
Question: Could the AddSort() and AddFilter() methods be rewritten as extension methods?

Answer: This question came up during two presentations, so there are at least two people who are curious about this. The answer in this case is no. Let's look at the signuatures of the methods as we created them:

If we wanted to convert these to extension methods, we would need to make these methods "public" (instead of private) and "static" (instead of instance methods). For a quick review of how to create and use extension methods, you can check here: Quick Byte: Extension Methods. The problem is that we cannot make these methods static since they reference specific UI elements on the form. We could do some refactoring and pass in values (for example, the check box true/false values) as parameters. That would allow us to make these methods static; however, this may not be a good idea.

First, I like to reserve extension methods for generic methods that I am planning on re-using. In this case, we have a very specific use case that we are implementing based on UI elements. Second, in making these methods public and static, it exposes them to broader usage than simply as private members of the class. Because these methods are so specific, this may just end up resulting in errors if they are used elsewhere. So, even though it is technically possible to convert these to extension methods, I would not recommend it in this case.

Captured Variables
Question: You metioned that if the callback method grew any larger, you would be tempted to refactor it out into a separate method. How would this affect the captured variable?

Answer: Even if we refactored the method, we would not eliminate the lambda expression itself; we would simply move the body of the lamba to another method. In this case, we could add the captured variable as a parameter, and it would remain available to the separate method.

Here's the refactored code:

Here, you can see that we take the "selPerson" variable (the variable that is captured by the lambda expression) and pass it as a parameter to the "UpdateUI" method. Since the "UpdateUI" method is called within the body of the lambda expression, we still has access to the captured variable which we can pass through to the method. This maintains the same functionality that we have before and allows us to keep the "selPerson" variable as a method-level variable.

Thank you for the great questions. Feel free to drop me a note if you have any more.

Happy Coding!

BackgroundWorker Session Questions

2010-11-15T21:28:00.000-08:00

I want to thank everyone who attended my sessions at the So Cal Code Camp in Los Angeles, CA and at the Desert Code Camp in Chandler, AZ. As I mentioned, I take the questions that come up in my sessions and look into them further. Here's the good news: I have some answers for questions that came up regarding the BackgroundWorker Component. (If you want to take a look at the session walkthrough and code download, you can get them here: Keep Your UI Responsive with the BackgroundWorker Component.)

Passing Additional Data During Progress Updates
Question #1: What is the "UserState" property that shows up in the ProgressChangedEventArgs?
Question #2: Is there a way to pass data from the background thread to the UI thread?

Answer: As you might guess since I grouped these questions together, the UserState property can be used to pass additional information from the background thread to the UI thread during the ProgressChanged event.

As a reminder, we call the ReportProgress method in the background thread which then fires the ProgressChanged event on the UI thread. In the sample code, we used the ReportProgress method that takes a single integer paramter (the percentProgress). But there is an overload that takes both a percentProgress and an additional object parameter called userState. As you might imagine, this will populate the UserState property of our ProgressChangedEventArgs. Let's take a look at updating our application.

First, on the background thread, we will add an additional "update message" where we calculate the progress and call ReportProgress:

This "update message" will contain a string such as "Iteration 45 of 150".

Next, we'll use the new UserState to update the text in our output box:

And here's the output from the running application:

As you can see we have now passed some relevant information from our background thread to our UI thread. It is easy to imagine several uses for this type of behavior. For example, if we were downloading multiple files, we could show the name of the current file in the UI. In addition, since the parameter and UserState are of type "object", we can put anything we want in there, including complex types or collections of complex types.

BackgroundWorker and MVVM
Question: The BackgroundWorker component can be used with WPF and Silverlight. Does this mean that it can be used with MVVM (Model-View-ViewModel)?

Answer: I've thought about this one quite a bit. The question isn't just can the BackgroundWorker be used with MVVM, but whether it makes sense to do so. I've decided that the answer is yes, it does fit in with MVVM.

In the MVVM patthern, the UI elements on the screen (the View) are data-bound to properties and methods in the ViewModel. The ViewModel is responsible for making data from the Model available to the View. In this situation, we would place the BackgroundWorker in the ViewModel. If we were to convert our sample application to MVVM, we could imagine a property for the percent complete that would be bound to the progress bar, and a property for the output that would be bound to the output text box.

The BackgroundWorker would live in the ViewModel and kick off the long running process in the background. When the ProgressChanged event fired (in the ViewModel), it would update the percent complete property (which would in turn update the View due to the data binding). The same would be true of the output property. This would prevent the ViewModel (and the View) from "hanging" while waiting for the long-running process to complete.

MVVM is a much larger topic, and there are a variety of different ways to implement it. But it seems like the BackgroundWorker component may be a useful addition when we are making sure our UI stays responsive.

Again, thank you for the great questions. I hope that I'll see you at one of my sessions in the future.

Happy Coding!

Book Review: C# 4.0 in a Nutshell

2010-10-30T19:06:00.000-07:00

A few weeks ago, I finished reading C# 4.0 in a Nutshell: The Definitive Reference by Joseph Albahari & Ben Albahari. I'll start off by saying this is an extremely large "nutshell" (the index starts on page 997), and I spent several months reading it in small pieces. The good news is that it was extremely worthwhile.

I had not read a book dedicated to C# since .NET 1.0 came out. And that was simply to get to know the language. Through the years, I've read numerous .NET books, but mostly focused on a particular technology, not on the C# language itself. So, this was a good chance for me to read up on the language from beginning to end. This helped refresh things that I had learned long ago and forgotten, as well as fill me in on the pieces that I missed over the years, and finally including all of the new features that we got with C# 4.0 including dynamic types, code contracts, and the parallel library.

In the preface, the book itself describes what it is not. It is not a replacement for IntelliSense or on-line help; meaning, it does not have a complete listing of all members of each class. Instead, it gives a good overview of select classes and the primary members that you need to know to utilize those classes. Also, it is not a beginner book or a replacement for tutorials that introduce a new programmer to specific topics.

With that said, I found the book extremely useful. The chapters are well laid-out, and I have found it easy to go back and use this as a reference book for particular topics when needed. Here's a list of the chapters:

Introducing C# and the .NET Framework
C# Language Basics
Creating Types in C#
Advanced C#
Framework Overview
Framework Fundamentals
Collections
LINQ Queries
LINQ Operators
LINQ to XML
Other XML Technologies
Disposal and Garbage Collection
Diagnostics and Code Contracts
Streams and I/O
Networking
Serialization
Assemblies
Reflection and Metadata
Dynamic Programming
Security
Threading
Parallel Programming
Asynchronous Methods
Application Domains
Native and COM Interoperability
Regular Expressions

As you can see, there are quite a few chapters that cover pretty much every part of the C# language (as well as parts of the .NET framework itself). I really can't go into details on each of the topics.

One thing that is nice about this book that makes it a complete reference is that it covers parts of the language even if they are no longer the recommended techniques. For example, there is a complete chapter on LINQ to XML. For those of you who have not yet tried LINQ to XML, take a look at it. After trying it, you will never go back to the "old" way of parsing and creating XML documents. With that said, the book also has a chapter on "other" XML technologies. This is important because even if you are not creating new code using these technologies, you may experience existing code that uses them.

There are a number of advanced topics, which further complements the "not a beginner book" statement in the preface. These include things like reflection, the insides of building, signing and deploying assemblies, the security model (such as trusted callers and encryption), and the ins and outs of threading.

The new features in C# 4.0 are covered as well. This includes a full chapter on the parallel library. There were some interesting points that were made here including showing how the order that things happen in the parallel processes is indeterminate. Also, there is a discussion of the various ways of "partitioning" -- helping the parallel library know how to best split up the tasks. (Of course, you can also let the framework take it's best shot at splitting up the tasks, and this will work most of the time.)

Overall, this was an excellent (if extremely long) read. For me, I was reminded of some of the fundamentals of the C# language, I picked up a few tips on things I didn't know existed, and I also learned about the new pieces that were added to the 4.0 version of the language.

I'll recommend this book to intermediate level .NET programmers or experienced programmers who are new to C#. I'll keep this as a reference on my shelf and refer to it frequently.

Happy Coding!

Thanks for Coming - SoCal Code Camp Los Angeles

2010-10-25T20:50:00.000-07:00

Thank you to everyone who came to my sessions at the SoCal Code Camp this last weekend. And a special thank you to all of you who came to more than one of my sessions. I had a great time doing the presentations and meeting all of you. I hope that you found it worthwhile. As a reminder, the slides, code samples and walkthroughs are available on my website: http://www.jeremybytes.com/Demos.aspx.

I've collected a number of questions that came up and will have answers posted here in the near future. A couple questions even came up in both the Saturday and Sunday sessions, so those will go to the top of the list.

Still coming, I also have a book review for C# 4.0 in a Nutshell by Albahari & Albahari. Short version: excellent book in a gigantic nutshell (over 1,000 pages). I've been a little delayed in getting the review out with my preparation for Code Camp (plus, I started a new job this week). I've started reading my next book: Pro ASP.NET MVC 2 Framework by Steven Sanderson. This has been a great read so far and will most likely end up on my "recommended" list.

In the meantime...

Happy Coding!

Upcoming Speaking Engagements

2010-09-28T20:24:00.000-07:00

I have several speaking engagements coming up in October and November. If you've always wanted to meet me in person, come on out. I'd love to meet you.

October 19, 2010
ASP.NET SIG - San Diego, CA
http://www.sandiegodotnet.com/

October 23 - 24, 2010
So Cal Code Camp - Los Angeles, CA
http://www.socalcodecamp.com/

November 13, 2010
Desert Code Camp - Chandler, AZ
http://nov2010.desertcodecamp.com/

Hope to see you there!

Learn the Lingo: Design Patterns

2010-09-21T14:15:00.000-07:00

You already use Design Patterns but probably don't know it. Observer, Adapter, Iterator, Proxy -- Learning the lingo allows you to better communicate your ideas with other developers. We'll take a look at several GoF patterns that we regularly use without realizing it. Don't know who the GoF is? Read on to find out.

Get It Here
You can get the walkthrough and sample code here: http://www.jeremybytes.com/Demos.aspx.

Direct Links:
Walkthrough (PDF)
Code Download -- Visual Studio 2010
Code Download -- Visual Studio 2008

I'll be presenting this topic at the upcoming So Cal Code Camp, October 23rd and 24th in Los Angeles, CA. Hope to see you there!

Happy Coding!

So Cal Code Camp - Los Angeles

2010-09-20T21:24:00.000-07:00

The So Cal Code Camp is coming to Los Angeles October 23rd & 24th. As always, Code Camp is FREE! It's a great chance to get some training and hook up with other developers / coders / hackers in your area. I'll be presenting several sessions, so it's your chance to see me, too.

Hope to see you there!

Learn To Love Lambdas

2010-08-24T19:38:00.000-07:00

Lambda expressions can be confusing the first time you walk up to them. But once you get to know them, you’ll see that they are a great addition to your toolbox. Used properly, they can add elegance and simplicity to your code. And some .NET constructs (such as LINQ) lend themselves to lambda expressions. We’ll take a look at how lambda expressions work and see them in action.

Get It Here
You can get the walkthrough and sample code here: http://www.jeremybytes.com/Demos.aspx.

Direct Links:
PDF Walkthrough
Code Download -- Visual Studio 2010 (Silverlight 4)
Code Download -- Visual Studio 2008 (Silverlight 3)

I'll be presenting this topic at the upcoming So Cal Code Camp, October 23rd and 24th in Los Angeles, CA. Hope to see you there!

Happy Coding!

Quick Bytes: Extension Methods

2010-08-19T19:28:00.000-07:00

Extension methods allow you to add functionality to existing types by adding new methods -- no subtyping required. Here's a quick overview of how they work.

Get It Here
You can get the walkthrough (just a short 3-page one) and sample code here:
http://www.jeremybytes.com/Demos.aspx.

Direct Links:
PDF Walkthrough
Code Download

As always, feel free to let me know what you think: feedback@jeremybytes.com.

Happy Coding!

The Ticker Class - Ready for Production?

2010-08-03T22:12:00.000-07:00

My "Introduction to XAML" code samples -- both the WPF and Silverlight versions -- include a Ticker class that does the work behind the scenes. (You can find the walkthroughs and code samples here: http://www.jeremybytes.com/Downloads.aspx.) The Ticker.cs file contains the following comment at the top:

// This class is a simple time ticker class. Note: this
// class is for the included demo only and would require
// modifications before using in a production application

I recently received an e-mail from Tim M. asking about this comment. Let's take a closer look to see why this class may or may not be "Ready for Production."

No Guarantees
This class uses a DispatchTimer that fires a Tick event based on a specified interval. Our sample application uses a 100 millisecond interval. But here's the trick: the Tick event is not guaranteed to fire at exactly the interval specified. The only guarantee that we have is that the Tick event will never fire *before* the interval has elapsed. And depending on what else your computer is doing at the time, the discrepancies may be quite significant.

Let's Experiment
So let's take a look at the completed code sample from "Introduction to XAML with WPF". (This will work the same with the Silverlight version.)

1. Navigate to the Ticker.cs file in the WPFStopWatch project.
2. Modify the "UpdateValues" method so it looks like the following:

We've modified the last line to include milliseconds in our display. Now, if you run the app and click the Start and Stop buttons repeatedly, you will notice that the display doesn't stop at exactly a 100 millisecond interval. Here's a screenshot from my run:

But it's still hard to see exactly what's going on here. Let's add each "tick" to an output that we can look at more closely.

3. Add one more line to the "UpdateValues" method to output the value to the Console:

4. Open the "Output" window in Visual Studio -- on the "View" menu if you don't already have it showing.
5. Run the application in "Debug" mode.

Now when you click the Start / Stop buttons, each interval value is recorded in the Output window. (The Output window is the standard output for "Console" when running a WPF application.). Here's a screenshot of the output from one my application runs:

What you can see here is that the "1 second" tick occurs a full 1/10th of a second after the 1 second mark. The time drift on my machine is between 4 and 12 milliseconds for this run. But this is based on my computer/processor (a 2.66 GHz Core2Duo) and what was happening at the time. If my machine was busy doing something else, then the tick events would fire further apart. The good news is that the time reported (the DisplayInterval property of the class) is correct. So, the "00:01.100" value itself is accurate.

You can do further experimentation by changing the DispatchTimer interval to 10 milliseconds or even 1 millisecond. By doing this, you can see the minimum time resolution that you can get on your computer with the Ticker class as it currently exists. On my machine, it varies between 10 and 20 milliseconds with only Visual Studio and this application running.

Is This Really So Bad?
For a simple timer (like we created in the sample), this behavior really isn't a big deal. I keep a timer such as this on my desktop to get a rough idea how long other processes take (such as running a report or fetching data from a web service). It works great for that. But if I wanted to do a "real" stop watch that could be used for high resolution timing (such as millisecond), then I would want to approach this a little differently.

I haven't had to create a high-resolution timer, so I don't have a recommendation on exactly what to do. A first step may be looking at the DispatcherPriority (an optional parameter in the constructor). The default DispatcherPriority for the DispatchTimer is Background, which according to the documentation means "Operations are processed after all other non-idle operations are completed." You can find a complete listing of values on MSDN here: http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcherpriority.aspx.

Also, we need to consider the limitations of the .NET Framework and the underlying operating system. Desktop PCs just weren't designed for ultra-high resolution timing purposes. People who do have time-critical activities, such as complex music sequencing, often have specialized hardware and software (although software-only solutions have become more practical with the increase in processor speed and number of cores).

Ready for Production?
So what we see is that the Ticker class will work perfectly well for a simple timer (which is what we created in the sample project). But we can also see that there are limitations in the timer resolution. The good news is that the DisplayInterval value is always correct -- this value does not drift; the drift is in the times between the Tick event firing.

So whether this class is ready for production depends on your needs. I added the caveat in the comments since there are quirks that need to be considered.

Happy Coding!

The Use and Misuse of Design Patterns

2010-07-28T21:03:00.000-07:00

Design Patterns have always been of great interest to me. (If you doubt this, you can see that I have a section of my Bookshelf dedicated to the topic.) One of the greatest advantages to learning the basic patterns is to share a common language with your fellow developers, so when you talk about a Factory Method or Decorator, I know what you are talking about. But at the same time, I see a tendency for some developers to use patterns for the sake of using patterns without fully considering the benefits and costs.

Rocky Lhotka has a great article about what developers should think about when considering patterns in their projects. You can find it here: On the use and misuse of patterns. Go take a look at it now. Don't worry; I'll wait.

Okay, are you done reading it? Go back and read it again. It's that important.

Welcome back. I've experienced a few of the issues that Rocky mentions. First, I have seen the "Pattern of the Year" phenomenon. It seems like some of the developers in my group get stuck on the current popular pattern. I won't mention any specifics, because as Rocky notes, there's nothing wrong with the pattern itself. The problem is that the popularity leads to a sort of cult of people who feel like they need to implement the pattern whether it fits in with the application or not.

Second, I have seen developers that get so enamored with a particular pattern than they try to use it at every turn. Rocky's analogy is great on this:

"It is kind of like a carpenter who spends a lot of money buying some really nice new power tool. And then trying to use that power tool for every part of the construction process -- even if that means being less efficient or increasing the complexity of the job -- just to use the tool."

Design patterns are just tools. Part of being a good developer is understanding the strengths and weaknesses of each of those tools. As developers, we need to focus on the problem space that we are working on and pick the appropriate tools for that job. (As a side note, this extends beyond design patterns to the technologies that we use -- whether WPF, Silverlight, or WebForms -- and even further out to the platform -- whether .NET, LAMP, Java, or whatever.)

I do have an issue that I'm not quite sure how to approach: I have worked with a developer and talked about the benefits and costs of a specific design pattern. We both agreed on the strengths (what the pattern was trying to solve for) and the weaknesses (the added complexity). And we also agreed that we would not get the benefits of the pattern in the current application we were discussing. The frustration is that the other developer still wanted to use the pattern because "we might need it later." Experience shows that this would be unlikely.

So, if you have any suggestions on how to approach this type of situation, let me know. I'll be sure to share the good responses here. Send them to feeback@jeremybytes.com.

If you are new to the design patterns world, I would encourage you to learn the benefits and costs of each pattern. And above all, consider their usage carefully. Patterns are a wonderful tool. But don't get so wrapped up in the tool that you forget the problem you are trying to solve.

Before you go, go back and read Rocky's article one more time: On the use and misuse of patterns.

Happy Coding!

Intro to XAML Questions

2010-07-10T22:26:00.000-07:00

While presenting the Intro to XAML session at recent code camp and user groups, a few questions came up. Here's some more information on those topics that I didn't have at my fingertips at the time.

FrameworkElement in the Ticker Class
Question: Why does the Ticker class in the demo code descend from FrameworkElement?

Answer: As I noted during the session, the Ticker class exposes the DisplayInterval property as a DependencyProperty. A DependencyProperty is a WPF/Silverlight construct that adds functionality above a normal property. This is used for features such as animation, styles, and data binding. We used it for data binding in our sample.

So where does FrameworkElement come in? A dependency property can only be added to a DependencyObject (or a class that descends from DependencyObject). FrameworkElement happens to be a descendent of DependencyObject. And since it is also the base class for most of the elements in WPF and Silverlight, it also makes a convenient base class for our custom Ticker class.

If you want more information on dependency properties, you can check out MSDN here: http://msdn.microsoft.com/en-us/library/ms752914.aspx.

User Controls in WPF/Silverlight
Question: Can you create user controls in XAML that would allow you to use the same control on multiple screens?

Answer: The answer to this is definitely yes. "UserControl" is one of the common root-level elements in XAML UIs (in addition to "Window" and "Page"). UserControl is now the default root element for Silverlight, but you can create your own user controls and embed them in other screens (whether they are Window, Page, or another UserControl).

I do have an example in Silverlight that creates a UserControl in a separate XAML file and then uses it on a screen. The sample is available here: http://jeremybytes.blogspot.com/2009/06/more-silverlight-part-2-user-controls.html. There is a small caveat to this, though: it is Silverlight 2. Fortunately, the part that shows how to create a user control and use it in your application is still relevant in Silverlight 4 (and WPF as well). The section on events is also still accurate; however, there is a much easier way to build this particular sample in Silverlight 3 or 4 by using object binding instead of events.

Attached Properties
Question: The XAML syntax for attached properties is intriguing. How do they work?

Answer: An attached property is a construct in WPF and Silverlight, and how the framework handles it internally is more information that you probably want. So, let's just take a look at a short sample.

In the demo code, we use an attached property by setting Grid.Row="0" inside of our TextBlock. Here's a reminder of the code:

To get an idea of how this property gets set, let's take a look at how we would set this property in code rather than in the XAML. We'll assume that our text block is named "myTextblock". There are actually 2 ways we can set the property: either from the point of view of the Grid or from the point of view of the TextBlock.

From the Grid's viewpoint, the property is set like this:
Grid.SetRow(myTextBlock, 0);

From the TextBlock's viewpoint, the property is set like this:
myTextBlock.SetValue(Grid.RowProperty, 0);

Although this doesn't explain the internals, it does give you an idea of how it works. With the first method, we are passing the element (myTextBlock) and value (0) to the Grid's SetRow method. SetRow is a static method of the Grid class that allows for the "Row" attached property to be set. With the second method, we use the SetValue method which allows us to set an attached property from the element (myTextBlock) itself.

Of course, there is more info on attached properties available on MSDN: http://msdn.microsoft.com/en-us/library/ms749011.aspx.

ZoomIt
Question: Where can I get the zooming tool used during the presentation?

Answer: ZoomIt is a tool that was created by a Microsoft employee (Mark Russinovich) for his own use in presentations. It has several features including zooming the screen (like a magnifier), adding annotations (either drawing or text), and showing a break timer. I ran across it while watching a webcast where the speaker was using the tool.

You can download ZoomIt for free here: http://technet.microsoft.com/en-us/sysinternals/bb897434.aspx

Additional XAML Samples
Not exactly a questions, but there are additional XAML samples available on my website. The Target Practice application is a sample I built to see if I could build an application using XAML only. I did this in both WPF and Silverlight 3. Here are the links to the walkthroughs:

WFP: http://jeremybytes.blogspot.com/2009/03/wpf-xaml-sample.html
Silverlight: http://jeremybytes.blogspot.com/2009/09/target-practice-silverlight-3-xaml.html

As with all of my samples, the code can be downloaded from my website: http://www.jeremybytes.com/Demos.aspx.

That's it for now. If you have any questions, feel free to send them to feedback@jeremybytes.com.

Happy Coding!

What's Wrong with VB.NET?

2010-07-08T07:30:00.000-07:00

VB.NET has the reputation of being a second class language in the .NET world. A lot of this has to do with the history of VB and its transformation from VB6 into VB.NET. Conversely, there is a perception that C# is the "real" .NET language, and I think that comes from its (much shorter) history.

At a recent user group meeting, someone joked that VB had been deprecated, and I will admit that I picked up and echoed that joke. I hope that folks could tell that I wasn't serious. When I'm talking to people, I try to point out VB resources where I can -- for example, my favorite Silverlight and WPF books have both VB and C# versions available -- but I'm personally more familiar with the C# resources since those are the ones I use on a day-to-day basis.

Today, VB.NET and C# are pretty much the same language with different syntax (at least that's how I like to think of them). And the great thing about .NET is that whatever language you work with still gets compiled down to the same IL, and you can use assemblies in your project that are created in any .NET language (in fact, you probably don't even know what language a third-party assembly was created with).

Real programmers don't get stuck on syntax. Programmers in general are opinionated and have their tools and languages of choice. Good programmers generally have several different languages under their belts (and not just .NET languages, but things like Ruby, Python, Perl, Delphi, and Java). I have my language of choice (which is currently C#, but has been different in the past), and before I start a task I try to make sure there isn't another tool that would do the job better.

Why the Bum Rap?
So, why does VB.NET have this reputation? My theory is based on looking at the history of .NET. When .NET launched, it was a brand new platform. Along with that launch, Microsoft was promoting a brand new language (C#) that was created just for that platform. In order for .NET to succeed, Microsoft had to get as many people on board as possible. C# was the vehicle they used for most of their demonstrations. This was because C# had all of the capabilities of .NET (at the time). Because of this, C# became equated in many people's minds as the "primary" .NET language.

But Microsoft also knew that there were millions of people invested in VB. They could not succeed if they forced all of the programmers who were comfortable with the VB syntax to switch over to a C-based syntax. And more importantly, they couldn't force those developers to abandon all of their existing code. So, we got VB.NET. And that's sort of where the problems started.

First of all, VB.NET was very different from VB6. There were a number of "features" that were put in to VB.NET to make migration of existing VB6 code easier. But if programmers wanted to really start using the .NET platform to its full potential, they needed to re-write quite a bit of code to fit in with the new paradigm.

VB.NET and C# had quite a few differences in the early versions. There were some constructs in C# that did not have an equivalent in VB.NET (and vice-versa). In addition, Visual Studio tended to favor C# when it came to features such as refactoring and IntelliSense. C# would get these feature updates first, and then they were made available to VB.NET later (as much later as the next release).

Forget Everything You Thought You Knew
But it's time to forget everything you thought you knew about the differences between VB.NET and C#. With the latest release of .NET 4, the languages are almost equivalent; there are a few minor differences, but for all intents and purposes, you can accomplish the same tasks in similar ways.

Steve K. pointed me to this blog article from Steve Wiltamuth regarding the futures of both languages: VB and C# Coevolution. In short, Microsoft is committed to moving both languages forward in the same direction and keep parity in the features and tools (such as the refactoring and IntelliSense features in Visual Studio).

Wrap Up
The good news of the similarities between the languages is that both C# and VB.NET programmers can take advantage of the vast amount of sample code that's available on the net.

Having both C# and VB.NET is great for the .NET development community. C# (and the C-based syntax) provided a comfortable migration for folks using Java and C++; VB.NET provide a comfortable migration path for folks using VB. Together, this has created a mix of developers that can share code and still hang on to their preferred syntax. That sounds like the best of both worlds to me.

Happy Coding!

Upcoming User Groups

2010-06-28T21:26:00.000-07:00

I'll be presenting at a couple of upcoming users groups in the Greater Los Angeles area. Here are the dates and links to the websites:

Tuesday, July 6
LA C# (Manhattan Beach, CA) - http://www.lacsharp.org/

Wednesday, July 7
SoCal .NET (Buena Park, CA) - http://www.socaldotnet.org/

Meetings start at 6:00 p.m., and it's a great chance to interact with other developers in your local area. Hope to see you there!

Thanks for Coming - SoCal Code Camp San Diego

2010-06-27T16:13:00.000-07:00

Thank you to everyone who took the time to attend my sessions at the SoCal Code Camp this weekend. I had a great time doing the presentations, and I hope you found the information useful.

As a reminder, all of my sessions are available on my website here: JeremyBytes.com - Demos.

If you liked the sessions (or didn't like the sessions), feel free to drop me a note at feedback@jeremybytes.com. I'll also be glad to answer any follow-up questions you may have.

Happy Coding!

Book Review: Effective C# - Second Edition

2010-06-20T15:27:00.000-07:00

I just finished up Effective C#: 50 Specific Ways to Improve your C# (Second Edition) by Bill Wagner. This is a collection of expert tips presentented in a clear and concise manner. These are targeted at the intermediate/advanced developer; it is assumed that you understand the basics of C# programming. With that said, this is an excellent resource for folks like me. Bill Wagner brings to light best practices, some pitfalls, and issues to consider, especially if you are designing libraries/APIs for consumption by other developers.

Overview

This is an updated version of Effective C# (First Edition) and More Effective C#. Each of these covered different versions of the .NET framework. This edition covers C# 4; the content is not limited to "what's new in C# 4." It covers items that go back to the earliest versions of .NET, but also includes new items such as dynamic typing and parallel programming with PLINQ.

As the title suggests, there are 50 "items" (spread over 6 chapters). The book is a fairly brief 300 pages; which translates into an average of 6 pages per item. The items are well-presented with an introduction to the problem space, a recommendation (based on a set of parameters), and clearly written code snippets. Each item is also summarized in a closing paragraph that reiterates the problem and solution.

Here's one thing that I like: Bill Wagner does not say "always do this." Each recommendation includes the pros and cons as well as when you may want to do things one way versus another. Many items will also refer to other items in the book. This helps build a cohesion to the overall text.

Chapters
Here's a quick listing of the chapters with a few items from each to give you an idea of the types of things covered in each:

C# Language Idioms
Item 3: Prefer the is or as Operators to Cast
Item 5: Always Provide ToString()
Item 8: Prefer Query Syntax to Loops
.NET Resource Management
Item 14: Minimize Duplicate Initialization Logic
Item 15: Utilize using and try/finally for Resource Cleanup
Item 18: Distinguish Between Value Types and Reference Types
Expressing Designs in C#
Item 22: Prefer Defining and Implementing Interfaces to Inheritance
Item 24: Express Callbacks with Delegates
Item 25: Implement the Event Pattern for Notifications
Working with the Framework
Item 32: Avoid ICloneable
Item 35: Learn how PLINQ Implements Parallel Algorithms
Item 37: Construct Parallel Algorithms with Exceptions in Mind
Dynamic Programming
Item 38: Understand the Pros and Cons of Dynamic
Item 40: Use Dynamic for Parameters That Receive Anonymous Types
Item 44: Minimize Dynamic Objects in Public APIs
Miscellaneous
Item 45: Minimize Boxing and Unboxing
Item 47: Prefer the Strong Exception Guarantee
Item 48: Prefer Safe Code

A Couple Specific Examples
Item 8: Prefer Query Syntax to Loops
Wagner takes a look at advantages that query syntax (LINQ) has over loops (for, while, do, foreach). He doesn't say that standard loops are bad or that we should stop using them. Instead, he shows some specific examples that illustrate how query syntax can make your code more readable and maintainable.

Personally, I've become a big fan of LINQ. But it did take me a while to get to that point. Wagner challenges the developer to step out of his/her comfort zone (loops) and take a look at query syntax and to consider the difference between the imperative model (telling your code how to do the task) and the declarative model (telling your code what task you want to do).

Item 14: Minimize Duplicate Initialization Logic
Wagner points out the pitfalls of having multiple constructors as part of your class and having "copy/paste" code in each of the constructors. This seems obvious once you think about it; after all, we always strive to minimize duplicate logic. The first tendency may be to move all of the logic into a shared private method, but Wagner points out that this is not the optimum solution. Instead look toward having the simpler constructors (those with fewer or no parameters) call the more complex constructors (those with several parameters).

Then he goes a step further and shows specific cases where you may introduce bugs in your code if you are not careful with how you implement the shared logic. In addition, he takes a look at the efficiency of the code generated by the C# compiler in various situations.

Overall Quality
The overall quality of the text is very good. I did notice a few typos here and there (no one is perfect -- I'm sure you'll also find some typos in this post). There was only one item (#23) that had what I would consider significant issues with the code samples. Fortunately, there is a blog on the SRT Solutions (co-founded by Wagner) web site that lists the errata. Be sure to check this out.

Tech books are notoriously hard to produce due to how quickly technology changes (especially Microsoft technologies). The errors that I noticed were well within the tolerable range and did not distract from my understanding of the content.

Recommendation
I would definitely recommend this book to intermediate and advanced C# developers. There are a number of items (especially in the dynamic and parallel items) that gave me insight into things to watch for as I look into the new features in C# 4. As any developer advances, he/she usually ends up creating shared libraries (shared utilities, for example). Wagner includes many items that cover best practices for creating shared libraries and APIs that are consumed by other developers. This is also helpful when one works as part of of a team on projects that have multiple interoperating assemblies/modules.

So, pick this book up. It has bite-sized chunks of good information and some good tips on new C# features.

Happy Coding!

Updated Sessions

2010-05-31T10:46:00.000-07:00

I have updated a number of my sessions for Visual Studio 2010 and/or Silverlight 4. I will be presenting three of these sessions at the So Cal Code Camp coming up on June 26 & 27, 2010. These are all available for download here: http://www.jeremybytes.com/demos.aspx.

Introduction to the BackgroundWorker Component with WPF
Long running processes are a user experience killer. How many times have you had an application "lock up" while trying to do some function? The BackgroundWorker component in .NET allows you to spawn those long running processes in the background and keep your WPF, Silverlight, or WinForms user interface responsive. We'll take a look at the features of the BackgroundWorker in a WPF application including running a background process, updating the progress in the UI, and cancelling the process before it has completed.

This session has been expanded to include Exception Handling and additional error checking.

Walkthrough: BackgroundWorker-WPF2010.pdf
Sample Code: BackgroundWorker-WPF2010.zip

Introduction to Data Templates and Value Converters in Silverlight
Business applications are all about data, and laying out that data is critical to creating a good user experience. Silverlight has several tools, including Data Templates and Value Converters, that make this easier for the business developer to manage. By the time we're done, you will have a good understanding of the basics of both of these valuable tools.

This session has been updated for Silverlight 4.

Walkthrough: DataTemplatesAndConverters2010.pdf
Sample Code: DataTemplatesAndConverters2010.zip

Introduction to XAML - WPF 2010 / Silverlight 4
Understanding XAML (eXtensible Application Markup Language) is a key to creating the latest .NET user experiences in WPF and Silverlight. We will introduce the basic concepts around XAML and take a look at various features such as namespaces, elements, properties, events, attached properties and some basic layout. We’ll create a simple WPF or Silverlight application that covers these fundamentals. Although you will probably end up doing most of your UI design with a drag-and-drop tool such as Expression Blend, knowing the internals gives you a leg up in making the final tweaks to ensure an excellent user experience.

This session has been updated to include both WPF and Silverlight versions. The same core XAML features are covered in each environment.

Walkthrough (WPF): IntroToXAML-WPF2010.pdf
Sample Code (WPF): IntroToXAML-WPF2010.zip

Walkthrough (Silverlight): IntroToXAML-Silverlight4.pdf
Sample Code (Silverlight): IntroToXAML-Silverlight4.zip

As always, your feedback/questions on any of these sessions is appreciated: feedback@jeremybytes.com.

Happy Coding!

So Cal Code Camp - San Diego Coming in June

2010-05-15T20:54:00.000-07:00

The So Cal Code Camp is coming to San Diego June 26th & 27th. As always, Code Camp is FREE! It's a great chance to get some training and hook up with other developers / coders / hackers in your area. I'll be presenting a few sessions, so it's your chance to see me, too.

Hope to see you there!

More Thoughts on ASP.NET MVC

2010-04-29T19:58:00.000-07:00

I've had two months to work with ASP.NET MVC since my last post on the topic. Since then, I've worked through two projects and have picked up some good experience. There are plenty of pros and cons (more pros in my opinion). Let's take a look at how it differs from other .NET web technologies.

Routing
ASP.NET MVC is more than just Model-View-Controller pattern (the MVC which lends its name). One of the key features is routing. With routing, a URL does not point to a physical resource on the server. Instead, it contains information that allows the Controller to instantiate the appropriate Model and send the data to a specific View. You're probably familiar with the pattern. Let's take a look at the URL for my previous post: http://jeremybytes.blogspot.com/2010/02/new-to-me-aspnet-mvc.html.

The first part is (http://jeremybytes.blogspot.com) points to the server. The next part (2010) would normally be parsed as a physical path (file folder) on the server. But instead, it is a parameter that references the year of the post. The same is true of the "02" portion (the original post is from February 2010). The final part is the name of the article. Now, I can't tell you what lies behind the blogspot link or how it is parsed, but I'm pretty sure that there are no physical directories that refer to the year and month of my posts.

You use this same type of routing in the ASP.NET MVC world. The default is for a URL to take the form of {controller}/{action}/{id}, but you can alter this default implementation however you like. As an example: http://www.example.com/sales/customer/217. This would call the "Sales" controller and ask for Customer #217.

As mentioned previously, this is an "action-first" or "resource-first" model (as opposed to WebForms "page-first" model). I say "action" or "resource" because that will depend on what you are doing. In the above example, we are requesting a specific Customer resource. But we could just as well be requesting an action, such as "UpdateCustomer".

This strikes me as very REST-ful, although that is a topic for another time. The good news for those who like the idea of routing but aren't ready to dive into the rest of ASP.NET MVC: Routing is included in ASP.NET 4.0 (it's actually also available somewhat in 3.5 but requires some extra work).

ASP.NET MVC vs. WebForms: Repeaters
I spent 3 years developing WebForms apps, so I've tried quite a few different techniques for displaying data. The control I ended up liking best is the Repeater. This gives me the most flexibility in laying out my data. But it does have one severe limitation: you cannot nest Repeaters.

The idea of a Repeater is that it will loop through your data set and "repeat" a specified section for each record. This is fine for single level lists, but it gets more complex when you have parent-child relationships.

Let's say that I have data that includes Category, Sub-Category, and Details. I only want to display the Category label at the top of each Category (not on each record). The same is true for Sub-Category. But since I can't nest Repeaters, that means that I must include Category, Sub-Category, and Detail in every single one of my records (flattened data rather than a hierarchy). Then, to get the display that I want, I hook into the Event that runs before displaying each record. In that event handler, I check to see if the current Category is the same as the Category of the previous record. If so, then I suppress (hide) the Category display. Same for Sub-Category. This creates quite a bit of messy, conditional code.

ASP.NET MVC handles this situation entirely different. You are much closer to the metal. So, if I wanted to implement the above scenario, it's quite a bit more elegant. In the View, I simply have a foreach loop that goes through all of the Categories and displays the Category header. Inside there, I have a nested loop that goes through the Sub-Categories and displays that. And inside there, I have a nested loop that goes through the details. This means that I can have a much more natural structure to my data (Model) with a parent-child-grandchild relationship. Add some LINQy goodness, and you have an easily understandable solution without the messy conditionals.

ASP.NET MVC vs. WebForms: File Size
Yes, file size is still important -- just take a look at how prominent smart phones and other mobile devices are becoming. I took an existing WebForms application and converted it to ASP.NET MVC. This was a proof-of-concept so I could try out the technologies. Since the existing application had a well-defined business layer and clear separation from the UI, it was easy to put the ASP.NET MVC front end in place.

Here's what I found: a particular page on the WebForms apps that was 24KB was only 9KB in the ASP.NET MVC version!

I know your initial reaction: just turn off ViewState, moron. But ViewState was turned off. The WebForms page is so much bigger because it uses server-generated names for all of the controls. This can look like "ctl00_mainRepeater_headerLabel_001". When you multiply this by the number of controls for each record and the number of records in the data set, it all adds up.

Conversely, the majority of the ASP.NET MVC output is text -- the equivalent of using a Response.Write instead of using a server-side control. When you look at the output (view source in the browser), it looks like hand-coded HTML rather than machine-generated code. This will vary depending on how you code up your Views, of course. My experience is that the output is pretty straight forward compared to WebForms output.

ASP.NET MVC vs. Silverlight
I won't really get into this debate. Both technologies have their uses and benefits. I was recently listening to .NET Rocks! and heard about a "challenge" that took place at the Visual Studio 2010 Launch Event. Apparently Phil Haack (and team) and Rocky Lhotka (and team) were tasked with creating an application in ASP.NET MVC and Silverlight, respectively. I have a great deal of respect for both of these guys, so I'll just leave that discussion there.

After using Silverlight myself, I was determined that I would never create another WebForms app again (the programming style is just so much more natural). But there is a problem (mentioned above): mobile users.

The reason that I started using ASP.NET MVC is because I needed to create a solution for Blackberry users. And I'm not talking about the shiny-new Blackberry Bolds. I'm talking about (relatively) old devices with browsers that are a step above WAP. Obviously, Silverlight was not an option. ASP.NET MVC, however, allowed me to put together a clean and efficient application.

One Last Thing: Parameters
There are a number of things I like about ASP.NET MVC, but I'll wrap up with one item: Action parameters. The ASP.NET MVC framework does everything it can to automatically pull in the parameters for you.

Let's say that I have an Action (method) like this: UpdateCustomer(int Id, string firstName, string lastName). When this method gets called, the framework tries to populate the parameters from the following locations:

Routing Parameters: These are the parameters that appear as part of the URL "path", such as the "217" in the Customer example above.
Query String: These are additional parameters that are part of the URL query string. These are separated from the rest of the URL with a question mark and take the form name=value (separated by ampersands).
Form Data: These are pulled from fields that are posted back in a form.
Post Parameters: These are the parameters provided as part of a POST (not necessarily part of a form).
Header Information: These items can be pulled from the request header.

If the framework can find matching, case-insensitive names that match the parameter names, it will pass them through to your method. There's something about this that strikes me as very cool -- anything that makes my life easier is good.

Wrap Up
I've grown to like ASP.NET MVC. At a later date, I'll put together a case study with my actual code to give you a better idea of exactly how the technology works. For now, we'll just stay with what we've discussed so far.

ASP.NET MVC 2 is now shipping as part of Visual Studio 2010. I've only taken a cursory look at it, but it seems to have added some good features to make views even easier and cleaner to generate. Plus, having it included in Visual Studio means that other members of your team will also have it available without having to install the bits separately. If you're doing web programming, this is definitely something to look into.

Happy Coding!

A Programmer's Bookshelf

2010-04-06T22:13:00.000-07:00

Due to several requests, I added a Bookshelf to my website. This has a listing of many of the books that I have read over the last several years. My ultimate goal is to create a searchable Silverlight application, but I'm waiting for Silverlight 4 to come out before I get started on that. In the meantime, we'll have to settle for a static list.

If you have any books that you are fond of, feel free to drop me a note.

Happy Coding!

BackgroundWorker Component Questions

2010-04-05T21:07:00.000-07:00

I recently received an e-mail with a few questions regarding the BackgroundWorker Component (original article). I decided to share the answers here.

Page Navigation with the BackgroundWorker
Question: I want to navigate to another page in the BackgroundWorker thread -- for example: "frameNavigator.Navigate(new OtherPage());" in the DoWork method. I tried this, but an exception occurred because the Page class uses the main thread whereas the BackgroundWorker uses a separate thread. How can I get around this?

Answer: As you noticed, things like Pages, Winodws and ListBoxes are all items on the UI thread (and they need to stay on the UI thread). And the BackgroundWorker component processes items on a different thread (not the UI thread). So, you will not be able to do things like "Navigate" in the DoWork method.

But here's what you should do: try to figure out why the navigation process is slow. This is usually due to something that happens when your new Page loads -- it could be loading data from a database, transferring a file across the network, or calling a web service. So, even though you cannot put the "Navigate" into the background, you may be able to take whatever is in your Page Load process and put that in the background. In this type of scenario, you could put the database call method or the file transfer method into the background, not the entire Page object. This will have the effect of keeping your UI thread running and responsive while your data loads in the background.

Using the Progress Bar
Question: I want to get the progress completed from the actual process time, not from a predetermined time as you used in the walkthrough. The application must know how much time the BackgroundWorker process will take to navigate to the target page and then show a progress bar based on this information. How can I accomplish this?

Answer: Progress is a tricky subject. In the example in my walkthrough, I am not technically doing the progress bar based on a predetermined time; I am calculating the progress (a percentage) based on the number of iterations completed in the loop. I purposely kept my background process simple so that I could focus on the methods, events and properties of the BackgroundWorker component itself. But you can use the progress event for anything you can calculate a percentage complete for. For a more complex example, you can look at the BackgroundWorker examples on MSDN: http://msdn.microsoft.com/en-us/library/c8dcext2.aspx. One in particular, calculates a Fibonacci sequence using a recursive method call and calculates a percentage for a progress bar.

As an example of a calculation: if you are doing a file transfer, you can calculate a percentage based on the number of bytes received compared to the total number of bytes. So, if you have received 257 bytes of a 1,356 byte file, you are 19% complete. The limitation is that you have to know how far along you are in the process. If you are doing something like making a database call or a web service call, you may not know how long it will take to complete or how much data you are getting back. In those situations, you cannot calculate a percentage and so you may be better off using a "busy animation" (and there are plenty of examples available on the web for WPF and Silverlight).

Complex Results
Question: I don't like examples of BackgroundWorker using results of "string" or "int". I want a real object. How would I do this?

Answer: The e.Result parameter in the DoWork and RunWorkerCompleted can be as simple or as complex as you like. In my example, I simply use an "int", but e.Result is of type "object", so you can put whatever you want in there (including an entire database result set). There are a few limitations such as the objects that need to be on the UI thread (like we mentioned above). As another option, you can use a separate variable (or set of variables) that is accessible to both the UI and the background process. If you do this, you will want to look into the "lock" method to ensure that you don't end up with multiple processes trying to modify the value at the same time.

Round Up
The BackgroundWorker component is not the right solution for everything. But it can be helpful in quite a few situations. As we saw above, you may not be able to do exactly what you want (such as navigating in the background), but if you think about the problem a little differently, you can often come up with a workable solution.

Happy Coding!

Target Practice Live Demo

2010-04-02T20:50:00.000-07:00

I have finally posted a live demo of the Silverlight 3 Target Practice demo application: Target Practice Live Demo.

As a reminder, this is a mini-app created entirely with XAML (no code-behind). The original article is here: Silverlight Target Practice.

And you can get the source code here: SilverlightTargetPractice.zip

Happy Coding!

Book Review: ASP.NET MVC Framework Unleashed

2010-03-01T21:58:00.000-08:00

I just finished reading ASP.NET MVC Framework Unleased by Stephen Walther. It was an extremely fast read: I finished it in a little under two weeks. Unfortunately, I was able to finish it so quickly because it contained very little information. I was rather disappointed by the content. I really don't like giving bad reviews, but I feel like I should get my thoughts down for other folks who may be interested in this topic. Please note, this is a review of the book itself, not the underlying ASP.NET MVC technology.

Beginner, Intermediate, or Advanced?
My biggest problem with Unleashed is that it cannot decide what level it is targeted at. The cover lists it as "User Level: Intermediate-Advanced," but the actual content seems to jump from one level to another. For example, there are step-by-step instructions on configuring and using the ASP.NET Membership Database (ASPNETDB.mdf). I would consider this to be "beginner" level content. For the majority of real-world applications, you will not use the ASPNETDB.mdf database for your user authentication / authorization, instead going for a more robust security model such as implementing a custom MembershipProvider. This is not covered, however.

But the text does not qualify as Intermediate or Advanced as there is very little actual content. The majority of the book is code samples. Code samples are generally a good thing, but the code samples here are full-files. This means that when looking at the various elements (such as Views and Controllers), you end up seeing the same "boiler-plate" code over and over again. Many times there are only a few unique lines of code in a 30 line listing. In addition, descriptions of the code samples are limited to a paragraph or two with no in-depth description of the concepts at hand. This is combined with listings in both C# and VB (again, not necessarily a bad thing). I often felt like I was "skimming" a 30 page chapter in just 10 minutes or so due to the use of code samples and lack of description.

As a final example, there are 2 chapters devoted to AJAX and jQuery. In the introduction to the book, the author assumes that the reader is familiar with HTML and .NET (either C# or VB). However, it does not mention AJAX or jQuery as pre-requisites. AJAX is used much differently in ASP.NET MVC than it is in Web Forms, yet there is no discussion of those differences. There is just a handful of samples with little explanation.

Lack of Focus
Another problem is the lack of focus. ASP.NET MVC has many unique features, but many of the concepts are shared with ASP.NET Web Forms and the .NET framework at large. I wanted the book to focus on the concepts that differ from non-ASP.NET MVC applications, but there was a lot of overlap.

To expand on the example above (the Membership database), the security concepts (users, roles, principles, etc.) are the same as ASP.NET Web Forms applications, but there were several large sections dedicated to authentication. And as noted above, this was only at the "beginner" level and did not touch on intermediate or advanced topics.

As another example, Unleashed spends a lot of time with the Entity Framework. There are step-by-step instructions on creating a SQL Express database and setting up Entity Framework entities. In addition, it also spends a bit of time talking about the Repository pattern and Service layers of the application. These all related to the "M" (Model) of MVC. But the point of the "M" is that you can implement your model in an infinite number of ways. Again, this may be appropriate for a "beginner" level book, but it should go beyond merely mentioning other options if it is trying to be something more.

Ironically, I think that the topic covered best by this book is Test Driven Development (TDD). Throughout the text, there is a focus on the "Red / Green / Refactor" methodology of TDD. And the final part of the book (6 chapters on building a sample application) is a very good walkthrough of using the test-first method to fulfill the use cases. Had this book been called Test Driven Development with ASP.NET MVC, I would probably give this book a much better review.

Summary
Ultimately, the only reason that I was able to follow this book is because I went through ASP.NET MVC training. But the reason that I purchased the book was so that I could have a reference with more detail. As an example, I was looking for details on HTML Helpers, both the helpers "in the box" and custom helpers. The book has a few mentions of the existing helpers, but does not go into any detail on the options and parameters available. As for creating custom helpers, there is an example of it, but nothing much beyond the sample code.

I really don't like giving bad reviews. I realize that putting any technical book together is a lot of work. However, technical books are also my life-blood. They are my primary source of in-depth learning. In addition, they are quite expensive. I do have enough information to complete my project (which was the primary goal of training + book), but I'm still looking for a good reference book. Since ASP.NET MVC version 2 is just around the corner (releasing with .NET 4.0 in April), I'll probably hold out before purchasing another.

In working with ASP.NET MVC, I'm becoming a fan of it. So, I'll be posting more about the technology topic in the future. I'll also keep you informed of other useful resources that I run across.

Happy Coding!

New to Me: ASP.NET MVC

2010-02-23T21:34:00.000-08:00

ASP.NET MVC was New 18 Months Ago
I first heard about ASP.NET MVC in October 2008 (at the VSLive! conference). Scott Hanselman gave a keynote that presented an overview and announced the beta release. At that point, it looked interesting, but with all of the new technologies that have been thrown at us over the last several years, I couldn't devote any time to look into it. Plus, I was comfortable with WebForms, having spent the previous 3 years developing fairly significant web apps.

So, here we are a year and a half later. I was struggling with a project at work. I knew that I could accomplish the task with WebForms, but all of my UI designs that I had worked through on the whiteboard seemed to come out as a mess. I had a nagging feeling that ASP.NET MVC was the solution to this problem. I took some time to look into it some more, and it turns out that it was the right direction.

Why ASP.NET MVC was the Answer
My main problem is that I needed to present data to the user in a different format depending on the record type. And I wouldn't know the record type until run time. ASP.NET WebForms is a "page first" model. This means that the user requests a particular page (through a URL). The page is then processed on the server which then presents the output to the user. ASP.NET MVC is an "action first" model. This means that instead of requesting a physical page, the user requests an action (also through a URL). This action is processed by a Controller. In my situation, the Controller can instantiate the Model (from my business layer) and then, based on the record type, can present the specific View (aspx page) that is appropriate.

So, I've taken a crash course in ASP.NET MVC. After going through some on-line training and working through a simple test app, I'm convinced that this is the right solution for this particular project. The design is much cleaner and will be easier to maintain.

Resources
I was fortunate enough to win a 1-year subscription to the Pluralsight OnDemand! library. In the library is a 10 hour on-line course for ASP.NET MVC, and I took a couple of days last week to go through it. This was an excellent resource. (If you are interested in trying Pluralsight OnDemand! yourself, just stop by the website; they offer 7-day trial subscriptions if you drop them a note.)

In addition, I picked up "ASP.NET MVC Framework Unleashed" by Stephen Walther as a printed reference. I'm still working my way through the book, but I've found a lot of useful information so far.

More to Come
Stay tuned for more to come. My project at work is still in progress. I'll have a lot of learnings from it (as I do with most of my projects). When I run across interesting items, good tips, and pitfalls, I'll be sure to post them here.

Happy Coding!

Jeremy on .NET Rocks! (sort of)

2010-02-17T09:23:00.000-08:00

Okay, so now that I have your attention, I wasn't really on .NET Rocks!. But Carl and Richard did read my e-mail on show #525. Here's a link (if you're curious): .NET Rocks! Show #525. You can skip ahead to about 4 minutes in.

And BTW, they are sending me a hoody.

Quick Byte: Statement Lambdas

2010-02-13T22:06:00.000-08:00

Overview
The first time I came across a lambda expression, I was perplexed. I could tell that something important was going on, but I got stuck on the new syntax. As I studied them some more, I had an "aha" moment, and it all clicked into place. This is a brief runthrough of that process with statement lambdas.

Get It Here
You can get the walkthrough (just a short 3-page one) and sample code here: http://www.jeremybytes.com/Demos.aspx.

Direct Links:
PDF Walkthrough
Code Download

Let me know what you think. If you find this useful (or not), drop me a note at feedback@jeremybytes.com.

Happy Coding!

SoCal Code Camp

2010-01-31T18:01:00.000-08:00

Thank you!

A big thank you to everyone who attended my sessions at the SoCal Code Camp. I had a great time, and I hope that all of you did, too.

As a reminder, for all of my sessions: the slides, code samples, and walkthroughs are available here: http://www.jeremybytes.com/Demos.aspx.

Drop me a note if you had a chance to attend. I'd love to hear what you thought.

Introduction to XAML with WPF

2010-01-10T15:08:00.000-08:00

(Editor's note: I will be presenting this topic at the SoCal Code Camp Jan 30 & 31, 2010.)

Overview
Understanding XAML (eXtensible Application Markup Language) is a key to creating the latest .NET user experiences in WPF and Silverlight. We will introduce the basic concepts around XAML and take a look at various features such as namespaces, elements, properties, events, attached properties and some basic layout. We’ll create a simple WPF application that covers these fundamentals. Although you will probably end up doing most of your UI design with a drag-and-drop tool such as Expression Blend, knowing the internals gives you a leg up in making the final tweaks to ensure an excellent user experience.

Get It Here
As mentioned in a previous post, the demos are now available in PDF form here: http://www.jeremybytes.com/Demos.aspx.

Direct Links:
PDF Walkthrough
Code Download

Happy coding!

Introduction to Data Templates and Value Converters in Silverlight 3

2010-01-04T19:27:00.000-08:00

(Editor's note: I will be presenting this topic at the SoCal Code Camp Jan 30 & 31, 2010.)

Overview
Business applications are all about data, and laying out that data is critical to creating a good user experience. Fortunately, Silverlight 3 has several tools, including Data Templates and Value Converters, that make this easier for the business application developer to manage. Today, we'll take a look at consuming a WCF service and creating the layout of the data. By the time we're done, you should have a good understanding of the basics of Data Templates and Value Converters.

Get It Here
As mentioned in a previous post, the demos are now available in PDF form here: http://www.jeremybytes.com/Demos.aspx.

Here's some direct links:
PDF Walkthough
Code Download

Happy coding!

More Demos Coming

2010-01-01T19:20:00.000-08:00

A New Direction

Okay, so I've posted several demo articles here so far. The unfortunate thing is that the blogging tool I've been using is not the easiest thing to use for these demos. One of the primary shortcomings is the inability to have code samples that can easily be copy/pasted. With this in mind, I've decided to post upcoming demos as PDFs (along with downloadable code samples). I think this should improve usability for me and my readers.

You can get the PDFs and code samples here: http://www.jeremybytes.com/Demos.aspx.

If you miss the HTML walkthroughs and really want to see them again, just post me a message at feedback@jeremybytes.com, and I'll see what I can do for future articles.

Introduction to the Background Worker Component in WPF

2009-12-31T16:25:00.000-08:00

(Editor's Note: I will be presenting this topic at the SoCal Code Camp Jan 30 & 31, 2010.)

The Problem

We've all experienced it: the application UI that hangs. You get the dreaded "Not Responding" message, and you have to decide if you should wait it out or simply kill the process. If you have long-running processes in your application, you should consider putting them on a separate thread so that your UI remains responsive. However, threading is a daunting subject. We've heard horror stories about race conditions and deadlocks, and needing to use the thread dispatcher to communicate between background threads and UI threads. At this point, it sounds like a subject best left to the experts.

The Solution

Fortunately, the .NET framework provides a simple way to get started in threading with the BackgroundWorker component. This wraps much of the complexity between your background thread and your UI thread without doing any special coding. You can use this component with WinForms and WPF applications. We'll be using it with WPF here.

The BackgroundWorker offers several features which include spawning a background thread, the ability to cancel the background process before it has completed, and the chance to report the progress back to your UI. We'll be looking at all of these features.

The Set Up

We'll start with a fairly simple WPF application that has a long-running process that blocks the application until it has completed. You can download the source code for the application here: http://www.jeremybytes.com/Downloads.aspx. The download includes the starter application and the completed code. The starter application includes the following.

1. A Simple WPF form:

You can find the XAML for this in the download. It consists of 2 Text Boxes (Iterations and Output), a Progress Bar, and 2 Buttons (Start and Cancel).

2. A long-running process (in the code-behind the form):

(click image to enlarge)

You can see that we're using the famously slow process Sleep(100) that loops based on the parameter value.

3. Event-handlers for the buttons (in the code-behind):

(click image to enlarge)

When you run the application and click the Start button, you'll see that the application hangs until the process is finished. If you try to move or resize the window while the process is running, nothing will happen for several seconds. And you'll see the "Not Responding" message if you look in Task Manager:

When the process is completed, you will see the value from the Iterations box mirrored in the Output box. This is simply a confirmation that the process completed. You can try this with different values. Since we are using a Sleep(100), a value of 50 iterations will translate into a 5 second process; a value of 100 is 10 seconds, and so on. Just as a side note, I chose a value of 1/10th of a second for the Sleep rather than the usual 1 second so that we will have a smoother progress update later on.

Adding the BackgroundWorker

The BackgroundWorker is a non-visual component. In the WinForms world, this would mean that we could just drag the BackgroundWorker from the Tool Box onto the Form, and it would show up as a non-visual component. In WPF, things are a little bit different. We need to add the BackgroundWorker as a window resource that we can reference throughout our code. Here's the steps:

1. Add the System.ComponentModel namespace to the XAML. We do this in the markup for the Window. The good news is that Visual Studio IntelliSense helps you out quite a bit with this. We'll give the namespace a "cm" alias so we can reference it easily. Here's the Window markup with the namespace included:

(click image to enlarge)

2. Add a BackgroundWorker as a Window Resource.

(click image to enlarge)

Hooking Things Up

To use the basic functionality of the BackgroundWorker, we need to do a couple of things. First, we need to hook up two event handlers: DoWork and RunWorkerCompleted. These events are much like they sound. To kick off the background process we call the RunWorkerAsync method of the BackgroundWorker and pass any parameters needed. This fires the DoWork event (which is where we'll put our long-running process). The RunWorkerCompleted event fires after that process is done. At that point, we can update our UI and do clean up (if required).

So, let's put our process into the background. We'll start by creating the handlers for the events mentioned above. As a reminder, Visual Studio IntelliSense helps us out quite a bit with this. In our BackgroundWorker markup that we created above, just type "DoWork=" and you'll get the option for "New Event Handler". This will create the stub and give the handler a name based on our component. We'll do the same for "RunWorkerCompleted" and end up with the following XAML:

(click image to enlarge)

Now we'll flip over to the code-behind and implement these handlers. Let's look at the code, then we'll talk through it. Note, in addition to the code below, I have also added a "using System.ComponentModel;" to make things a little less verbose:

(click image to enlarge)

First, you'll see that our DoWork event calls the DoSlowProcess method (our long-running process). You'll note that we are getting an integer argument from the DoWorkEventArgs (we'll see how this gets passed in just a minute). The e.Argument is of type Object, so we have to cast it to the integer type that our method is expecting. Next, you'll note that we're passing the result back to the DoWorkEventArgs in e.Result. This will be used in the next handler.

The RunWorkerCompleted event fires after the long-running process is complete. You can see that the first thing we do is check to see if an error occurred. If not, then we'll go ahead and populate the output box with the result of our method. The e.Result here is actually the same e.Result from the DoWork event. In our case, the DoSlowProcess returns an integer that we populate in the output. In addition, you can see that we are enabling and disabling the buttons as appropriate.

The important thing is what you don't see. Notice that our completed handler is manipulating our UI elements without any use of the Dispatcher or Invoke methods that you need to do if you are handling the threading on your own. Instead, we just reference the elements on the UI thread directly. The BackgroundWorker takes care of all of the complexity on the back end.

Finally, we need to kick off the DoWork event in our Start Button handler. In order to do this, we need a reference to the BackgroundWorker component in our window. The problem is that it is simply a resource right now. The first task is to get a reference to it. We'll put this code at the top of our Window class and modify the constructor:

(click image to enlarge)

In this code, you see that we create a private variable to reference the BackgroundWorker component. Then in the constructor, we pull the component out of the resources by using the FindResource method. Now we can use the component in our code.

Here's our updated code in the Start Button Click event handler:

(click image to enlarge)

You'll notice that instead of calling the DoSlowProcess directly, we are now calling the RunWorkerAsync method of the BackgroundWorker. This method takes an optional object parameter. In our case, we will use this to pass the number of iterations through. This is the value that shows up in the e.Argument of the DoWork handler that we saw above.

The next thing we do is update the button states appropriately. Since the Cancel button is not yet implemented, it won't have too much effect. But we'll get to that in a bit.

Finally, note that we are clearing the output text. Remember that since we are running the process in the background, our UI still remains responsive. We want to clear out the output while the process is running, and then populate it agian after the process is complete. This is handled by the RunWorkerCompleted event that we saw above.

Now we have a fully-functional application with a background process. If you run the application now, you'll notice different behavior from what we saw before. After you click the Start button, the UI remains responsive: you can move and resize the window, type in the boxes, or whatever. When the process if finished, the output box is updated.

But we're not done yet. We still need to look at the Cancel and Progress functions.

Updating Progress

Next we'll look at reporting progress back from our long-running process. One thing to keep in mind if you want to have a progress bar in your UI: you will need to come up with some type of metric for the percent complete. For example, I have used the BackgroundWorker for long-running SQL queries. In this case, I was unable to report percentage because I had no idea exactly how long the process would take. In our sample here, we can use some fairly simple math to report the percentage completed.

The BackgroundWorker has a property we need to set (WorkerReportsProgress) and an event handler (ProgressChanged). These are fairly straight forward to implement. But here's where things get a little complicated. We need to update the progress in our DoSlowProcess method. This means that we need a reference to the BackgroundWorker.

Let's start with the easy parts. First the updated XAML:

(click image to enlarge)

Here we just set the WorkerReportsProgress to True (the default is False) and add the stub for the ProgressChanged event handler. As we did above, we'll just let Visual Studio create a New Event Handler for us.

To implement the event handler, we'll just set the value of the progress in our UI:

(click image to enlarge)

Now we'll make updates to some of our existing code. First, the DoSlowProcess method:

(click image to enlarge)

We've added both BackgroundWorker and DoWorkEventArgs parameters to the DoSlowProcess method. In order to update the progress, we'll add some code to each iteration of the loop. First, we check to make sure that the BackgroundWorker parameter was populated; then we check the WorkerReportsProgress property to see if the BackgroundWorker reports progress. If false, then we'll skip the code. If true, then we calculate the percentage and call the BackgroundWorker.ReportProgress method. This will fire the ProgressChanged event that we implemented above.

Now, since we've added additional parameters to DoSlowProcess, we'll need to update the method call. As a reminder, this was in the DoWork event. Here's the updated code:

(click image to enlarge)

We'll just cast the sender to a BackgroundWorker and pass it on through. We'll just pass the DoWorkEventArgs parameter through as well.

Finally, we'll add a line of code to the RunWorkerCompleted event to zero out the progress bar after it has completed:

(click image to enlarge)

The reason for this is if you are using Windows Vista or Windows 7, the progress bar continues to animate even after it is as 100%. This makes it difficult to tell that the progress is complete. So, we'll just set it back to 0 after it's done.

Now, if we run the application again, we'll see that we have a functional progress bar. The last step is to add cancellation.

Canceling the Background Process

Before implementing cancellation in your application, you will need to take a few things into consideration. First, when you cancel a BackgroundWorker process, there is no event that fires, and the process does not stop immediately. Instead, a cancellation flag gets set on the BackgroundWorker. It is up to your long-running process to check for this flag and to stop running if necessary. In my example above with the long-running SQL query, I could not implement cancellation because there was no "iteration" in my process -- it was simply waiting for the query to return.

In our example here, since we are using a loop, we have a perfect place to check for cancellation and stop our process. Here's an overview of the steps we'll take, then we'll look at each in more detail.

First, we need to set a property on the BackgroundWorker ("WorkerSupportsCancellation"). Then we'll tell the component we want to cancel in the Cancel Button event handler. Next we'll add the cancellation code to our DoSlowProcess method. And finally, we'll make a few changes to the RunWorkerCompleted event handler to behave differently if the process was canceled.

First, the XAML:

(click image to enlarge)

Next, the Cancel Button event handler:

(click image to enlarge)

You can see that we're simply calling the CancelAsync method of the BackgroundWorker.

Next, add the cancellation logic to the DoSlowProcess:

(click image to enlarge)

You can see that we added another conditional to check CancellationPending. If so, then we'll set the e.Cancel property of the DoWorkEventArgs and return from our method.

And finally, the RunWorkerCompleted:

(click image to enlarge)

Here, you can see that we are checking the e.Cancelled property of the EventArgs. If it's true, then we'll put "Canceled" in the output box. One thing you'll note: we are not resetting the progress bar in event of cancellation. This is so that if you stop the process, you can still see how far it got before the cancellation.

Now, when we run the application, we'll see that we have a long-running process that runs in the background (keeping the UI responsive), an updating progress bar, and a working Cancel button.

Wrap Up

The BackgroundWorker component allows us to put long-running processes onto a background thread without the usual complexities of threading. We have seen how we can get progress updates that we can show in our UI as well as how to cancel a process before it has completed. In addition, we've seen that even when updating our UI, we don't have to worry about communicating across threads. It is all handled for us in the component.

Probably the best thing about the BackgroundWorker is that it allows us to get our feet wet in the world of threading in an easy and relatively safe way. Think about this the next time you come across an application that is "Not Responding". And do what you can to keep your UIs responsive for your users.

Happy coding!

Where's Jeremy?

2009-12-27T17:07:00.000-08:00

I'm Still Here

So, it's been a while since I've posted anything. But I've still been working. Coming up at the end of January, I will be doing some presentations as the SoCal Code Camp. The good news is that it's forcing me to put together another 3-4 demos. So, if you check back over the next month, you should see them pop up.

In addition, I've got a website where you can download the sample code for all of the demos that I've presented so far. It's at http://www.jeremybytes.com/. Just check out the Downloads section. (I'll be adding links to my various blog posts as well).

Lots of exciting things coming up.

Happy New Year!

Target Practice - Silverlight 3 / XAML Sample

2009-09-04T09:57:00.001-07:00

XAML has intrigued me ever since I took a close look at it. In a previous post, I created an entire WPF application using only XAML (it's trivial, yet functional). When I got started with Silverlight 2, I wanted to replicate that application. Unfortunately, there were limitations to Silverlight 2 (such as a lack of triggers) that kept me from implementing it. I could have built the same application, but it would have required some code-behind to handle the animation.

The good new is that Silverlight 3 has additional support that allows us to replicate the XAML-only version of the application. It does vary a little bit from the WPF version, so even if you've looked through the previous post, you're likely to learn something new. I'll point out the differences as we come across them.

Scenario
We'll be creating a simple shooting gallery-type application. I call it "Target Practice" since it will require some more work to turn it into an actual game. In the final version, we will have a 3 x 3 grid of targets. Each of these is clickable adn will result in a "hit" animation. After 3 seconds, the target will reset to its previous state -- all inside the XAML. You can scroll down to the bottom to see the finished product.

Step 1 - Application Set-Up
We'll start by creating a new Silverlight 3 application. You'll need Visual Studio 2008, plus the Silverlight 3 bits (start here if you need them: http://silverlight.net/GetStarted/). Create a new project by selecting File -> New -> Project. From there, choose the "Silverlight" category under "Visual C#" and then select "Silverlight Application". I named my application "SilverlightTargetPractice".

You'll be asked if you want to create a web application to host the project. Go ahead and leave the defaults (create a new ASP.NET Web Site). This will give you 2 projects: "SilverlightTargetPractice" is your Silverlight application, and "SilverlightTargetPractice.Web" is the hosting web site. Whenever you run the project, you will want to run the web application.

In the Silverlight project, you will find the "MainPage.xaml" file. That's where we are going to start. Open up the xaml file, and you'll see the xaml editor. Note: There is no Silverlight 3 designer support in Visual Studio 2008; for that, you'll need Expression Blend 3. You can see my notes on this in a previous post. Here's the default page the project template creates:

(Click image to enlarge)

We're going to make a couple changes in the "UserControl" tag. Update the following properties:

d:DesignWidth="335"
d:DesignHeight="335"

Next, we'll replace the Grid with a set of nested StackPanels. The nested StackPanels will set up our 3 x 3 grid. As mentioned in the previous post, you can use a Grid here if you'd like, but I chose the StackPanels to keep the Button tags a little "cleaner". For the outer StackPanel, I set the Background to Black. Inside each of the nested StackPanels, I have placed 3 buttons. The buttons have fairly arbitrary names; this is just so we can tell them apart when we're doing the design work. The updated XAML looks like this:

(Click image to enlarge)

If you build and run the application at this point, you'll see this result. (Remember to run the Web application).

(Click image to enlarge)

Step 2 - Templates
Now we're going to take advantage of the "lookless" controls in XAML and replace the default Button template. This will allow us full control over the way our buttons look and behave. This varies a little bit from the WPF sample: in the WPF sample, I used a combination of Templates and Styles; in this sample, we'll use only a Template.

We'll start our Template by adding a local resource to the file. Add a tag "UserControl.Resources" just above the outer StackPanel. As we've seen before, Visual Studio IntelliSense is very helpful when hand-editing XAML; so, let the code-completion do a lot of the work for you. You can also do this entire application in Expression Blend, but that's a lesson for another time. Inside the Resources section, we'll add a ControlTemplate for our buttons.

(Click image to enlarge)

A few key things to point out. The TargetType is set to Button. This means that we can apply this template to Button controls (or their descendents) and only Button controls. Next is the x:Key. This gives a name to the Template that we can use to assign it elsewhere. Next we have a Canvas (our drawing surface with a Margin to space things out a little) and an Ellipse (which is just a DarkRed circle at this point). Note: the Ellipse is named "Outer Red Stripe" in the comments because we will be adding more to this template in just a bit.

Now we'll need to apply our new Template to our Buttons. We do this by assigning the Template property of each button to the StaticResource that we just created. The highlighted code below is repeated for each button.

(Click image to enlarge)

Here's our result (ignore the jpeg artifacts in the picture; it actually looks much better in person):

(Click image to enlarge)

Something to note: the red circles are still buttons. They are clickable (although they don't visibly change when you click on them), and they have standard button events (such as Click). Notice that the Content does not appear in the buttons. This is because our Template does not have a ContentManager, nor do we need one for this application. Because we aren't displaying the Content, we can remove the Content properties from each of our buttons to clean up the code.

Now, let's spice up our visuals.

Step 3 - Eye Candy
Now we'll take the boring red circles and make them into glassy 3-D buttons. As I mentioned in the WPF XAML sample, the best way to learn how to do this is by looking at some Photoshop tutorials. The same techniques (gradient opacity ellipses) can be used in Expression Blend. I take no credit for the "glow" parts of the design template; I copied them from a demo by Walt Ritscher. He's also a good resource for WPF styles and templates.

First, the top glow. This is simply added to our Control Template below the "Outer Red Stripe" code. It is just an ellipse with a radial gradient that moves from white to transparent.

(Click image to enlarge)

The bottom glow is much the same: just an ellipse with a radial gradient. We'll put this directly below the "Top Glow" code.

(Click image to enlarge)

If you build and run the application now, you'll see a distinct difference compared to what we had before:

(Click image to enlarge)

Cool, huh?

Step 4 - Completing the Targets
Next, we just need to complete the visual design of the Targets. This is just a set of ellipses, each smaller than the last, alternating between Red and White.

(Click image to enlarge)

A few things to note here. First you'll see that we are moving the Canvas.Left and Canvas.Top properties because the Top Left corner is considered to be the starting point for drawing on a Canvas. We are moving down and a bit to the right to keep the smaller circle centered on the previous one.

Order is important here. The XAML parser processes items in the order that they appear in the file. This means that the "Outer Red Stripe" is drawn first, and then each smaller circle is drawn on top of it. The same is true of the "glows". We want these on top of the rest, so we specify them last in the file. The Canvas in Silverlight 3 does have a Z-Order property, so you can adjust this if you have a more complex drawing.

We're done with the visuals for our Targets. Now they look like this:

(Click image to enlarge)

Step 5 - The Action
The last step is to add the behavior. This entire section is quite a bit different from the WPF sample, and all brand new to Silverlight 3.

As a reminder, when we click on any of the target buttons, we want it to animate by "falling over" and then reset after 3 seconds. The animation will work by using a Transform. The first step is to define an empty Transform to our Canvas. I have this inside the closing Canvas tag, but below all of the visuals we added above.

(Click image to enlarge)

This is where things really start to get interesting. For the Animation to be triggered by a Click, we need to add some References to our project: Microsoft.Expression.Interactions and System.Windows.Interactivity (noted below).

(Click image to enlarge)

Now we need to add a namespace reference to these assemblies. We add these at the top of the file with the other "xmlns" references. The good news is that you don't have to type all of this in (see the image below). Instead, IntelliSense will help you out. After you type the "=", you will get a pop-up of the assmeblies that are available from the project references. The completed namespace references should look like the image below:

(Click image to enlarge)

Next, we'll add an Interaction section to the Template that includes an EventTrigger. This needs to be placed before the closing Canvas tag. (I have it between the Transform and the end of the Canvas.) The EventTrigger specifies that it acts on the "MouseLeftButtonDown" event. And inside of that, we have an Animation Storyboard. Take a look at the EventTrigger and Animation specified below. Then we'll walk through it step by step.

(Click image to enlarge)

First, note the "i:Interaction.Triggers" tag. The "i:" is specifying that we are using an object in the System.Windows.Interactivity namespace that we referenced above. Next, we define our Event Trigger (also in the "i" namespace) and specify that it will act on the MouseLeftButtonDown event.

Now, we move on to the "im:ControlStoryboardAction" tag. The "im:" is referencing the Microsoft.Blend.Interactions namespace. This is denoting that we want to "Play" the Storyboard when the EventTrigger fires. Finally, we'll define the actual Storyboard in the "ControlStoryboardAction.Storyboard" section.

This contains a standard-looking Animation storyboard that we have named "ClickAnimaton". Let's look at each of the 2 animations in a little more detail.

The "DoubleAnimationUsingKeyFrames" says that we want to animate a double property (in this case the Y-Scale of the Canvas) and that we want to use KeyFrames to control the flow of the animation. The "Storyboard.Target" tells what object the storyboard is acting on (the Canvas in our Template), and the "Storyboard.TargetProperty" tells what property we are acting on. As noted before, we are operating on the Y-Scale of the Canvas by using the RenderTransform we defined earlier. Duration is 1.5 seconds and Auto-Reverse is true. This means that our total animation will be 3 seconds long.

Here's how we want our animation to work: first, we want it to "fall over" quickly (in 0.5 seconds), then stay "laying down" for a while, then pop back up quickly (also 0.5 seconds). They KeyFrames will let us do this. In the first "LinearKeyFrameAnimation", we are giving the starting position of 1, meaning set y-scaling to 100%. In the next, we want the y-scale to be set to 1% (almost invisible) at the half-second mark. The third shows that we want the y-scale to sill be at 1% at the 1.5 second mark. The auto-reverse runs the animation backwards (starting with the third KeyFrame and working up). This gives us a total animated time of 3 seconds.

The second animation is required because the origin of the Canvas is at the Top Left. This means that if we only had the first animation, the target would shrink up (toward the origin). The second animation says that we want to move the center point of the Canvas down so that it will shrink down and "fall over".

You'll have to run it yourself to see the final result. Here's a screen shot of things in action:

(Click image to enlarge)

Round Up
So, Silverlight 3 allows us to do much more in the XAML than Silverlight 2 allowed. We were able to reproduce the WPF XAML sample with a few changes. I expect that by the time .NET 4.0 and the next version of WPF rolls around, that WPF and Silverlight will look pretty much the same. But we'll still have to wait and see with that.

This is a good example of the power of declarative programming with XAML. The more I use it, the more I like it. When I think about trying to do an application like this in WinForms, I just shudder. It would be a mess of custom drawing code, timers, and crazy calculations. XAML gives me the freedom to easily take control over the layout and appearance of my application. And as we've seen here, it's not just limited to "look and feel", we can also program quite a bit of functionality with it.

You can add some code-behind and create a full fledged shooting gallery game that keeps track of scores and gives you a time limit. But I'll leave that as an exercise for the reader.

Happy coding!

Silverlight 3 -- D'oh! and Woo Hoo!

2009-08-02T21:08:00.000-07:00

In July, Microsoft released Silverlight 3. On the one hand, it's good to see the features moving forward at a good pace. On the other hand, we only had 9 months with Silverlight 2. I just thought I was starting to understand how to work with Silverlight 2 effectively, and wham! new version.

The Bad
First, the bad. I was surprised by some of the items that are included in the Silverlight 3 release notes. Fortunately, I read these before installing the bits.

1. Silverlight 2 & Silverlight 3 compatability

Silverlight 2 projects cannot be created with the Silverlight 3 Tools for Visual Studio 2008. To create Silveright 2 projects, uninstall the Silverlight 3 runtime and the Silverlight 3 Tools from Add or Remove Programs and re-install the Silverlight 2 Tools for Visual Studio 2008.

This was a showstopper for me at work. As I've mentioned, I've been developing a Silverlight 2 application at my day job. Due to certain circumstances, I can't upgrade the project to Silverlight 3 (yet). Since I still need to support it in the meantime, I need to keep the Silverlight 2 bits installed on my machine.

There are some blog posts out there with tips on how to switch back and forth between the 2 versions, but it's making things a bit more complicated than I would like. So, the work machine stays on Silverlight 2 (but Silverlight 3 immediately gets installed at home).

2. Design Preview in Visual Studio 2008

Due to performance and rendering issues, the preview window has been disabled in the Silverlight 3 Tools for Visual Studio 2008. The functionality of the XAML editor remains intact, including IntelliSense, error messages, and the ability to drag controls from the Toolbox into the editor. WYSIWYG XAML design can be done by using Expression Blend or Visual Studio 2010.

This limitation is somewhat disappointing to me. I'm a XAML guy. I'm comfortable typing in the design code directly (and IntelliSense works great in Visual Studio). But I did use the preview window to see how things look. Now, I have to have Expression Blend open to check the preview. I wouldn't mind so much if I used Blend more extensively (which I probably should anyway), but right now it seems like a bit of a kludge to have to toggle back and forth.

There are other notes as well, and I would encourage you to read them in full. These are the ones that jumped out at me as being disappointments.

The Good
So, now the good parts. These are just the items that struck me as useful. There are plenty of other new features (such as out-of-browser support and 3-D support that are interesting but not very applicable in my world).

1. WCF Service Support
Silverlight 3 has support for the full WCF stack. This means that we are no longer limited to basicHttpBinding for our WCF services that are consumed by Silverlight. We can use WS* bindings or any of the other bindings.

2. Controls
In addition, there are plenty of new contols available (including a TreeView) and loads of new layout controls. The Silverlight 3 toolbox is starting to look a lot closer to the WPF toolbox (and excels it in a few cases).

3. Improved XAML
New features such as Behaviors and Triggers greatly enhance the ability to define things declaratively in XAML as opposed to having to implement them in code.

Here's my example: One of my first demos on this blog was a WPF application that was written entirely in XAML. It included a visual re-design of buttons and animation that triggered by clicking the button. It was fully functional with absolutely no code-behind. You can see that entry here: WPF Target Practice.

When I first started getting into Silverlight 2, my goal was to reproduce the same application in Silverlight. However, due to limitations (specifically a lack of Triggers), the only way to implement the animation would be in code. I moved forward with learning how to do the animation that way (and implemented some pretty cool visuals in my application at work), but I never posted the results since they missed the goal of using XAML only.

Silverlight 3 has some additional assemblies available that allow you to implement the triggers and fire off animations. So, in an entry in the near future, I'm planning on posting the Silverlight 3 version of Target Practice. So be sure to stay tuned!

Installation
To use Silverlight 3, you'll need Visual Studio 2008, plus the Silverlight 3 bits. Start at the Silverlight site here: http://silverlight.net/GetStarted/. As mentioned above, you want Expression Blend 3 (there are trials available if you don't want to purchase the full suite). Be sure to take a thorough look through the release notes as well.

Wrap Up
So, like most things in life, there is the bad along with the good. I'm hoping that by the time Visual Studio 2010 comes out, we'll have some better options available. In the meantime, the Silverlight 3 does have a lot to offer (I just scratched the surface with a few items that interested me).

Keep learning!

More Silverlight Part 2 - User Controls & Events

2009-06-13T23:19:00.000-07:00

The story so far: In More Silverlight Part 1, we created a Silverlight 2 application and a WCF service. We then used a DataTemplate and various ValueConverters to format and display the data in the ListBox.

Here's what the app looked like when we left off:

(Click image to enlarge)

Now, we're going to move on, first by creating a Detail panel, then abstracting out the ListBox to a User Control, and finally creating an Event that will let us know when a new Person record is selected.

Creating a Detail Panel

We'll start by adding a Detail panel that shows the First Name, Last Name, Birth Date, and Age for a single Person (the Person selected in the ListBox). This will be a StackPanel that is in the 2nd column of the Grid in our Page.xaml.

(Click image to enlarge)

The code is pretty self-explanatory. We set up TextBlocks to serve as labels for the data, and TextBlocks with data binding to hold the data. You'll notice that we are using the same DateConverter and AgeConverter that we used in the ListBox.

Getting Data into the Detail Panel

We want the Detail Panel to update whenever the selection changes in the ListBox. To do this, we'll hook up a "SelectionChanged" event to the ListBox. As a reminder, you can just type "SelectionChanged=" and Visual Studio will give you the option to add a New Event Handler.

(Click image to enlarge)

Now, we'll navigate to the Event Handler in the Page.cs file. What we need to do here is set the DataContext of the DetailPanel. But the question is, what should we bind to? Do we need to make a service call?

The answer comes through the fact that Silverlight data binding is extremely flexible. We can bind to any object, including an object that exists somewhere else on the page. In this case, we want to bind to the Person that is selected in the ListBox. So, we do just that.

(Click image to enlarge)

A couple of things to note here. First, you see that we are getting the SelectedItem for the ListBox and then casting it as a Person. What you should be aware of is that this may result in a null value. The SelectionChanged event will fire whenever the currently selected item changes; this includes when an item is un-selected. When a ListBox is first loaded, the default is to have no selection. This event will fire, and the SelectedItem will be null.

In many circumstances, you will want to check the "var p" to see if it is null after the assignment. In our case, we will want to let p be null (we'll see why in just a bit).

After we get the SelectedItem cast as a Person, we just assign this as the DataContext of our DetailPanel. Pretty straightforward, huh? Here's the result:

(Click image to enlarge)

To see how the nulls are handled in the Event, simply click the Button again. This will clear the selected item in the ListBox, which will in turn clear out the DetailPanel data.

Creating a User Control

But what if we want to re-use the Person ListBox multiple places in our application? Rather than duplicating code, it would be better to abstract out this piece as a separate User Control. That's what we'll do right now.

Step 1: Add a new User Control to the Silverlight project
Right-click on the Silverlight project, select "Add", then "New Item". From the dialog, select "Silverlight User Control" and name it "PersonListControl". This will create a default PersonListControl.xaml and PersonListControl.cs that look very similar to what we started with for Page.xaml/Page.cs. This is because Page is also a Silverlight User Control.

Step 2: Cut the StackPanel xaml from Page.xaml to PersonListControl.xaml
We'll be moving everything from the first Grid column of Page.xaml to the new user control. Just cut the entire StackPanel (the one that has Grid.Column="0"), and paste it over the Grid (LayoutRoot) in PersonListControl.xaml. This will leave us with a StackPanel as the root element of the user control. Note: after pasting it in, you will want to remove the "Grid.Column" attribute. The app will still run with it there, but it's better to keep the xaml as clean as possible.

Step 3: Copy the UserControl.Resources Section
The xaml that we moved in the step above makes use of the Converters we created earlier. This means that our new user control needs to have references to these as well. The easiest way is just to copy these from the Page.xaml. Note that we are doing a copy (not a cut) because these are used in the DetailPanel that is staying on Page.xaml.

Copy the "xmlns:local=" namespace and the entire "UserControl.Resources" sections with all three converters to PersonListControl.xaml.

Step 4: Change the Size
Our new UserControl will need to fit in the first column of our main Grid, so we'll want to change the sizes a bit. Change Width to 240 (to allow for a little bit of padding) and the Height to 300.

Step 5: Move the Event Handlers
The xaml that we moved contained 2 Event Handlers: one for the ListBox selection changed event, and one for the Button click event. Now we'll move the Event Handlers as well.

From the Page.cs file, cut the "PersonList_SelectionChanged" and "GetPeopleButton_Click" methods and paste them into PersonListControl.cs. One thing to note: since the PersonList_SelectionChanged event directly references the DetailPanel, this won't compile. For now, just comment out the 2 lines in this Event Handler. We'll be re-implementing this a little later.

You should be able to build now, but if you run the application, you will find that we still need to place the new user control onto our main Page.

Step 6: Using the User Control
Actually using the new user control on our main Page couldn't be easier. In the spot in our Page.xaml where we used to have a StackPanel (in the first Grid column), we will now have our control:

(Click image to enlarge)

Notice that this uses the "local" prefix (the same as our Converters) since everything is in the same namespace. If we were to split out the User Control into a separate namespace, then we would need to add a new xmlns and give it a different alias to use.

We can now run the application, and the ListBox will look just like it did before. If we click the Button, it will fetch the Person list and display it. The application doesn't work completely, though. We can't get the data into the DetailPanel. For that, we will need to expose an Event in our new User Control.

High Level Event Overview

Before we create the Event, let's take a look at how we'd like it to work. What we want to do is get the Person that is selected in the ListBox and display it in the DetailPanel. The problem is that the ListBox and DetailPanel are now in different scopes. So, we need to get the Person from the ListBox to the DetailPanel somehow. We'll do this by exposing an Event in the ListBox that has the selected Person as part of the EventArgs.

We'll need a custom EventArgs class that will hold the selected Person. Then we'll set up an Event on our new User Control that we can hook in to from our Page.

Custom EventArgs

We'll create the custom EventArgs class in the PersonListControl.cs file. You may want to abstract this out into its own file for other projects, but we won't do that here. We'll descend from RoutedEventArgs (which is a little more specific than EventArgs and is commonly used in Silverlight and WPF). Our custom EventArgs only needs to have a single Property (SelectedPerson) and a contructor that takes a Person as a parameter. Here's the completed code:

(Click image to enlarge)

Declaring the Event Handler

Next, we need to declare the Event in our PersonListControl class. We can do this with a single line of code:

(Click image to enlarge)

Note that there are several ways to make this declaration, including using "delegate" syntax. The syntax used here is the most compact. You'll see that we are using our custom EventArgs class as a generic type. Our Event is called "SelectedPersonChanged".

Invoking the Event Handler

To invoke the Event Handler, the convention is to create a method called OnEventName -- in our case "OnSelectedPersonChanged". Take a look at the code below:

(Click image to enlarge)

If the comments look familiar, it's because they came straight from the Microsoft Help file. They aren't really applicable for this particular application because we're not making descendant classes or doing complex invokation, but it's good to use the "safe" version so that we can get used to it.

You'll see that we are using our custom EventArgs as a parameter for this method. And as noted in the comments, we are making a copy of the handler first. This is because we can only invoke handlers that are actually hooked up to something (i.e. not null). If the handler is null, then we do not want to do anything (and thus we have the null check). The reason that we make the copy is that it is possible that the handler is deleted between the time we check for null and the time we invoke the method. If we make a copy, then we are acting on a snapshot in time, and so eliminate this possibility.

Raising the Event

Now we need to actually raise the event. We will do this in the "PersonList_SelectionChanged" method (the one that we commented out earlier). We will get the SelectedItem from the ListBox and cast it to a Person -- just like the old ListBox SelectionChanged handler. Then we'll use that Person to create the custom EventArgs and pass it to the OnSelectedPersonChanged method.

(Click image to enlarge)

Notice that it is possible for the Person to be null (as we discussed above). This is okay. If there is no SelectedItem, then we will pass the null through the Event and ultimately to the DetailPanel (as we'll see next). Be sure to build everything to make sure that there are now errors. If you run, you still won't see any difference. Yet.

Using the Newly Exposed Event

Now we'll go back to our Page.xaml to hook up the new Event. You'll notice that if you start typing "Select" in the PersonListControl element, IntelliSense will show the Event. Like other events, if you type "SelectedPersonChanged=", Visual Studio will let pop up "New Event Handler" (as we saw above). If you do this, you'll end up with something like this:

(Click image to enlarge)

Finally, we'll navigate to the event handler in the Page.cs file. Since the custom EventArgs exposes a SelectedPerson object, we just need to assign this to the DataContext of the DetailPanel.

(Click image to enlarge)

If you run the application now, you'll see a fully functioning Person ListBox and DetailPanel.

(Click image to enlarge)

This will behave the same as above. If you click the Button again, the DetailPanel is cleared. This is because the SelectedItem is cleared when the ListBox is loaded. Because the SelectedItem changed, the Event fires. And because there is no SelectedItem, the EventArgs contains a null SelectedPerson. This results in a null for the DataContext for the DetailPanel (which is what we want here). You may need to rework this if you need different behavior.

Summary
We've taken our application and abstracted out a significant part of it into a separate User Control. Then we implemented an Event on that User Control that we can use when we add the element to our Page. If we were to have several different forms that needed this same Person ListBox, we can simply add the custom User Control and get all the same functionality. We even have an Event to hook into so we know when the selected Person changes. These are just the basics, of course. For a production app, we would want to add Error handling and other such things.

As you can see, Silverlight has several powerful features that allow us to create flexible and well-designed applications. Since pretty much everything in Silverlight is a User Control, it's possible to nest these elements within each other and come up with some interesting abstractions in our UI.

Happy Coding!

More Silverlight Part 1 - Data Templates & Value Converters

2009-06-06T21:46:00.000-07:00

I've pretty much finished up my Silverlight 2 project at work, so I thought I'd share a few more useful things that I've come across. This time, we'll take a look at Data Templates (which make List Boxes extremely flexible) and Value Converters.

Setting Up the App

We're going to start by building a application similar to what we built in the last few posts: a Silverlight 2 application that gets data from a WCF service. Start by following Steps 1 - 3 from this post. I'll point out where we'll make a couple of changes.

Step 1: Create a New Silverlight Application
We'll call it "TemplatesConvertersEvents" this time. Let it create the ASP.NET hosting site as well.

Step 2: Build a WCF Service

Step 2a: The WCF Service Contract
We'll create the same PersonService, but we'll add a new field "BirthDate" to the Person class. See the Service Contract below:

(Click image to enlarge)

Step 2b: The Service Implementation
Again, this will look pretty similar. We'll just add a BirthDate value to each of the Person objects.

(Click image to enlarge)

Step 2c: WCF Service Configuration
Same as last time. Make sure to change the binding from "wsHttpBinding" to "basicHttpBinding".

Step 3: Add the WCF Service Reference to the Silverlight Application

Step 4: Update the XAML.
This is pretty similar to the previous examples, with just a few differences. Check out the code sample below for Page.xaml. Then we'll walk through it.

(Click image to enlarge)

Start by changing the Width and Height properties of the page (500 x 300). Then replace the default Grid with a Border. The Border contains a 2 column grid. We'll be concentrating on the first column here (the 2nd column will be used in Part 2). The Grid contains a ListBox.

Notice that the ListBox looks a little different. We are no longer using the "DisplayMemberPath". Instead, we have an ItemTemplate that contains a DataTemplate. The DataTemplate is simply a container that can hold whatever content you like. For now, we'll just include a TextBlock that is bound to the FirstName field. This will have the same effect as if we were to set the DisplayMemberPath. One thing to be aware of: the DisplayMemberPath and ItemTemplate are mutually exclusive; if you try to include both, you will get an error.

Finally, we have a Button that looks similar to our previous examples. As a reminder, to add the Click handler, just type "Click=" and Visual Studio will pop up an option for "New Event Handler". This will create a handler based on the control name and put the stub in the code-behind.

Next we implement the handler. You can right-click on "GetPeopleButton_Click" and choose "Navigate to Event Handler" and it will take you to appropriate spot in Page.cs. The handler implementation should look like this (again similar to what we've seen before):

(Click image to enlarge)

Another reminder: you will need to add the "using" statement for the PersonService. If you type in the code above, you can place the cursor on "PersonServiceClient", then press Ctrl+. to bring up the option to add the "using".

You should be able to build and run the application now. After you click the button, the results should look like this:

(Click image to enlarge)

Expanding the Data Template
Now we'll see the power that the ListBox has by expanding the DataTemplate a bit. The DataTemplate can only have a single child element, so if we add multiple items, we'll need to wrap them in some sort of container. We'll use a set of nested StackPanels -- some vertical and some horizontal.

(Click image to enlarge)

This is fairly straightforward XAML. Note that we have multiple TextBlocks that are databound and a little bit of formatting. Here's what we get when we run the app now.

(Click image to enlarge)

Creating a Value Converter
One thing I don't like about the output is the format of the BirthDate field. To take care of this, we'll use a value converter. A value converter is simply a class that implements the IValueConverter interface (profound, eh?). The interface consists of 2 methods: Convert and ConvertBack. An incoming value is passed in as a parameter; all you need to do is do the conversion and return the new value.

Our DateConverter isn't going to be that interesting, but it's a good place to start (then we'll look at something a little more challenging).

In the Silverlight project, add a new Class. I've called mine "Converters.cs" because I'll use the same file to hold all of my converters. Then we'll rename the class from "Converter" to "DateConverter" and add the IValueConverter interface. IValueConverter is in the System.Windows.Data namespace, so you'll need to add this to the "using" block as well.

As we've done before, we'll just right-click on "IValueConverter", choose "Implement Interface", then "Implement Interface" again. This will put the "Convert" and "ConvertBack" method stubs into our class. We'll only be doing one-way conversion (read-only data), so we will only implement "Convert". If you had a TextBox or other editable control, then you would also implement "ConvertBack" which reverses the process. Here's our code:

(Click image to enlarge)

Since the "value" parameter is of type object, we'll need to start off by casting it to the inbound type that we are expecting (DateTime in this case). Our outbound type is simply a string, so we'll call the ToString function with a formatting string that we like. Note that there are additional options (some that are especially useful for Date conversions) by using the "parameter" and "culture" parameters. Take a look at the Microsoft Help file to get more information on those.

Using a Value Converter
So, now that we have a DateConverter, how do we use it? First, we'll need to add the namespace to our xaml (see below). Again, VisualStudio is helpful here; if you type "xmlsns:local=", then you will get a list of namespaces that are in the project, including everything that appears in the project References. We'll select the project namespace "TemplatesConvertersEvents". You can use whatever alias you like for the namespace; "local" is a convention for items contained within your project.

The next step is to add our DateConverter as a Static Resource.

(Click image to enlarge)

Now all that's left is to add the Converter to the Binding declaration in our TextBlock.

(Click image to enlarge)

If you run the application now, you'll see that we have a nicely formatted mm/dd/yyyy date for the BirthDate field. Let's try something a little more complex.

An Age Converter
In addition to the BirthDate, I'd like to display the age of the Person as well. The problem is that we don't have an Age field. So, instead, we'll use the BirthDate field to calculate the age. We'll just add another class (AgeConverter) to the Converters.cs file.

(Click image to enlarge)

We won't worry about the specifics of the code too much (I'm sure that I'll get letters with better ways to calculate age). The main point is that we are taking a DateTime (BirthDate) and converting it to an Integer (Age). Well, actually, we're converting it to a string for display purposes, but you get the idea.

Using the AgeConverter is just the same as the DateConverter. Add a Static Resource (I called mine "myAgeConverter") and then use it in a Binding statement. Notice that we are still Binding to the BirthDate field; by using the AgeConverter, we control what we will actually display. Here is a portion of our expanded DataTemplate (we appended the Age portions to the section with the BirthDate).

(Click image to enlarge)

If you run the app now, you'll see both the BirthDate and the Age are included.

One More Converter
As one final step, we'll get a little more creative with our converter. So far, we've more or less just converted a value from one format to another. This time, we'll convert to a completely different type. I want to display ages that are over 30 in a green font and 30 or under in blue. We'll do this by changing the BirthDate to a Brush.

Once again, create a new class "AgeBrushConverter" in the Converter.cs file. The code looks like the "AgeConverter" code, but instead of returning the age, it uses it to create a SolidColorBrush:

(Click image to enlarge)

For the implementation, our final "Resources" section looks like this:

(Click image to enlarge)

And our final DataTemplate (notice that we are using the AgeBrushConverter for the Foreground property of the TextBlock):

(Click image to enlarge)

And our final result:

(Click image to enlarge)

Summary
We've taken a chance to look at DataTemplates and ValueConverters to add flexibility to how we display our data in ListBoxes. DataTemplates can contain complex layouts (including Grids and Images, if desired). ValueConverters also go beyond simple formatting (like Dates and Currency); they can also be used to show or hide items (think of Binding a value to the "Visible" property) or even to add text formatting to differentiate values (such as using red for negative numbers and black for positive, or possibly graying-out inactive items).

Hang on to this application. In Part 2, we'll take a look at creating a custom user control that abstracts out part of the functionality and exposes an event that we can use.

Silverlight 2, WCF, and Lambda Expressions - Part 2

2009-05-12T20:34:00.000-07:00

In Part 1, we set up a Silverlight 2 application that consumes a WCF Service. In Part 2, we'll look at a problem with the implementation and different ways of solving it -- ultimately ending with Lambda Expressions. Hopefully by the time we get done, you'll be comfortable with how lambda expressions work and how to use them to make your code cleaner and easy to understand.

Where We Left Off
Here's a quick reminder of what we did last time:

We created a WCF Service that is Silverlight 2 compatible.
We added a reference to the service in a Silverlight application.
We created a UI (Button and ListBox) to call the service and show the results.
We called the WCF Service and hooked up the Completed event to an event handler.

The Page.xaml.cs file we finished with is as follows:

(Click image to enlarge)

And the UI:

(Click image to enlarge)

A Problem
There is a small problem with the UI. After calling the service (by clicking the button), the list gets populated with the names. You can select a name in the list by clicking on it. But if you click the button again, the list refreshes and the selection goes away. We want to update this so that the selected item is maintained when the service is called again.

Solution #1 - Using the Event Handler
The SelectedItem of the ListBox gets cleared when the service is called because we are re-binding the data. From the ListBox's point of view, it is getting a new object to bind to. When the old object is un-bound, the selected item goes away and doesn't come back.

We'll solve this by simply saving off the SelectedIndex of the ListBox before we make the service call. Then after the service call returns, we will reassign the SelectedIndex. (This is assuming that the order of our items is not changing, and we're not getting any new items -- you can extend this basic functionality for more complex situations).

Since we need to save off the SelectedIndex in one method (the Button Click event handler) and then use it in a different method (the Service Completed event handler), we'll need to create a class-level variable to hold this information. See the code below:

(Click image to enlarge)

You'll see 3 new lines of code to get this to work:

private int ehListIndex;
The class-level variable
ehListIndex = EHList.SelectedIndex;
Saving the index
EHList.SelectedIndex = ehListIndex;
Re-assigning the index to the list box

If you re-run the application, you will see that if you make a selection in the list box, that selection is maintained when you call the service multiple times.

Solution #2 - Using an Anonymous Delegate
Now, we'll try this again using an anonymous delegate instead of an explicit event handler. You'll see why this is an advantage in just a bit.

We'll update our XAML by adding another StackPanel to our Grid.

(Click image to enlarge)

You'll notice that this section looks almost identical to the EventHandler UI section. Here's a summary of the differences:

The 2nd column of the Grid is specified in the StackPanel.
The Names of the ListBox and Button start with AD (for anonymous delegate) instead of EH.
The ListBox border is blue (just to make it different).
The button Content is "Anonymous Delegate".
There is a new Click handler for the button (you can look at the hint in Part 1 about letting IntelliSense create the handler for you).

So, what is an anonymous delegate? In our case, it is an in-line definition of an event handler (for the service callback). This is defined by using the "delegate" keyword, then a set of parentheses with the appropriate parameters, then a set of curly braces with the method implementation. The implementation will look just like in our callback when using the EventHandler.

Here's the initial implementation:

(Click image to enlarge)

What you will notice is that that the first and last lines are the same as our previous button click event. You'll also notice that the parameters for the anonymous delegate ("object" and "GetPeopleCompletedEventArgs") matches the parameters in the explicit event handler we implemented earlier. Finally, the body of the delegate matches the body of the event handler callback.

I know what you're thinking: big deal. Other than "in-lining" some code, exactly what did we gain here? We're about to find out.

We still have the same issue we had earlier with the ListBox SelectedIndex. The advantage to using an anonymous delegate is that any variables in the outer method can be accessed in the delegate implementation. This means that instead of using a class-level variable to store the index, we can use a local variable. Check out the completed code below:

(Click image to enlarge)

You'll see that we now have a local variable named "adListIndex" that is assigned outside of the delegate and then used inside of the delegate. We've just eliminated the need to have a class-level variable.

Solution #3 - Using a Lambda Expression
Let's take this one step further. Instead of using an anonymous delegate, we'll use a lambda expression. First, update the UI. This XAML is very similar to the anonymous delegate section:

(Click image to enlarge)

The same items are updated as above: grid column, element names, border color, button content, and click event.

So, now lets take a look at lambda expressions. There are 2 types of lambda expressions: statement lambdas and expression lambdas. Both use the same syntax (consisting of 3 parts):

Parameters
These are normally enclosed by parentheses (although, parentheses can be excluded if there is only a single parameter).
The parameter types may be excluded if the compiler can determine the correct types.
=>
This is known as the "goes to" operator and denotes that this is a lambda.
Statement(s) or Expression(s)
A statement lambda has one or more operations wrapped in curly braces. The statement(s) denotes some type of work to be done.
An expression lambda has one or more expressions (that return true or false) wrapped in curly braces. These are used extensively in LINQ.
If there is only a single statement or expression, then the curly braces can be excluded.

We'll be working with an Statement Lambda. The first steps to convert the anonymous delegate to a lambda expression are to remove the "delegate" keyword and place the "=>" operator between the parameters and the method implementation. Take a look at the "LEButton_Click" method below and compare it to the first "ADButton_Click" method above:

(Click image to enlarge)

But, as we noted above, if the compiler can determine the parameter types, then we don't need to include them in our code:

(Click image to enlarge)

If you hover over the "s" and "ea" parameters, you will see that Visual Studio recognizes these as being of type "object" and "GetPeopleCompletedEventArgs" respectively. This means that we still have strongly-typed objects. The same is true of "ea.Result". This is the strongly-typed collection that is returned from our WCF Service.

As a final step, we can add the SelectedIndex handling code into the mix:

(Click image to enlarge)

If you run the application, you will see that all three list boxes behave the same way. All three list boxes will keep the selected index between service calls.

What We Learned

We took a look at 3 different ways to solve a particular UI issue. We see that both the Anonymous Delegate and Lambda Expression solutions have the advantage of being able to use a local-scoped variable (thus, keeping our class-level clutter-free). In addition, we see that the Lambda Expression solution has the advantage of not needing to include the parameter types. This is especially helpful if you have a delegate that has the standard 2 parameter signature ("object" and "SomeKindOfEventArgs"); you don't need to know the particular EventArgs class -- just let Visual Studio figure that out for you.

My advice: become familar with Lambda Expressions. You will find that when used judiciously, they can help keep your code understandable and easier to maintain.

Silverlight 2, WCF, and Lambda Expressions - Part 1

2009-05-01T19:58:00.000-07:00

This is a 2-part series in using WCF with Silverlight 2. Part 1 is about creating a Silverlight-compatible WCF service and consuming it in a Silverlight application. Part 2 is about lambda expressions, but uses the foundations in Part 1.

Step 1 - Create a New Silverlight Application
First we'll create a new Silverlight application. In Visual Studio, create a New Project, and select the "Silverlight Application" template. I've called mine "SilverlightWithWCF", so that's what you'll see in a couple places throughout the post.

Visual Studio will prompt you with the following:
(Click image to enlarge)

We want to include a new ASP.NET Web Application Project, so we'll leave the defaults as-is. Other options include "ASP.NET Web Site" and possibly "ASP.NET MVC" (if you have the MVC bits installed). In addition to using the ASP.NET application as a test site for the Silverlight application, we will use it to host our WCF service.

Step 2 - Build the WCF Service
We'll add a new WCF Service at this point. Right-click on the Web Application project ("SilverlightWithService.Web" in my case), and choose "Add", then "New Item". Select the WCF Service. We'll name ours "PersonService.svc". See below:

(Click image to enlarge)

You'll notice that there are 2 options we could choose from: "WCF Service" or "Silverlight-enabled WCF Service". You might wonder why we didn't pick the Silverlight one. The answer is that I wanted to look at the standard WCF Service, so that you will know what to do if you already have an existing WCF Service that you want to hook into. I'll point out the difference below when we look at the Web.config file.

Step 2a - The WCF Service Contract
WCF Service consist of 3 main pieces: the Service Contract, the Service Implementation, and the Service Configuration. First, we'll look at the Service Contract.

The contract is simply an interface decorated with a few specific attributes. Visual Studio will create an I[ServiceName].cs file that contains the placeholder contract. If you open the IPersonService.cs file, you'll see an interface that is decorated with the [ServiceContract] attribute. Visual Studio also gives you a sample method called "DoWork". You'll notice that this is decorated with the [OperationContract] attribute. You can think of this as being analogous to the [WebMethod] attribute that we used in ASMX Services. The [OperationContract] attribute denotes which methods will be exposed to the outside world.

We're going to replace the "DoWork" method with a "GetPeople" method. Take a look at the completed code below, and we'll step through it:

(Click image to enlarge)

You'll notice that our method returns a List of Person. Person is a custom class, and so we need to include the definition of the class as well. You'll notice that we have a separate public class called "Person" that is decorated with the [DataContract] attribute. The class consists of 2 public properties (FirstName and LastName) that are each decorated with the [DataMember] attribute. The DataContract and DataMember attributes let the WCF sub-system know that it needs to include this type in the definition of the Service.

On a side note, the [DataContract] and [DataMember] attributes can be excluded in this particular case. .NET 3.5 SP1 will automatically include the type definition for public classes that have automatic properties and a public default constructor. This was added to facilitate Entity Framework. I'll leave it as an exercise for the reader to do further research into this.

The contract only tells what the service will do, not how it does it. For that, we'll need to look at the service implementation.

Step 2b - The WCF Service Implementation
The WCF Service implementation is a class that implements the WCF interface. Open up the "PersonService.svc.cs" file (note: you can simply double-click on the "PersonService.svc", and it will open the .cs file).

You'll see that the class "PersonService" implements "IPersonService" and still has the placeholder "DoWork" method from the stub that Visual Studio created. Delete this method. We'll let Visual Studio add the stubs for the updated interface. Simply right-click on "IPersonService" and select "Implement Interface", then "Implement Interface" again (we won't cover "Implement Interface Explicitly"). This will create a stub for the "GetPeople" method. Here's the implementation:

(Click to enlarge image)

This simply creates a List object and populates it with some Person instances. In real life, you'll probably be doing something more complex (such as accessing a database).

Next comes the configuration.

Step 2c - WCF Service Configuration
Open up the Web.config file, and then navigate to the "system.serviceModel" section (at the bottom). The only thing that you'll need to do is update the binding to "basicHttpBinding" (from "wsHttpBinding"). See below:

(Click image to enlarge)

Remember when I promised to show the difference between "WCF Service" and "Silverlight-enabled WCF Service"? This is it. Silverlight 2 is limited in that it can only use WCF Services that use the "basicHttpBinding". This is the same binding that ASMX services use. (Note: Silverlight 3 will not have this limitation). The "Silverlight-enabled WCF Service" defaults to basicHttpBinding, while "WCF Service" defaults to wsHttpBinding. If you have an existing service, you'll just need to change this value (or add an endpoint that uses this binding).

Note: This is a very important step. If you try to add a Service Reference in a Silverlight application to a WCF Service that is *not* using basicHttpBinding, then the proxy will not work. Even better, you don't get any helpful error messages, just a rather obscure one. So, make sure you don't skip this step.

From here, we'll build everything just to make sure that things look good. This completes our updates to the Web Application. Next, we'll move on to the Silverlight application.

Step 3 - Add the WCF Service Reference to the Silverlight Application
We'll start in the Silverlight application by adding a Service Reference to our newly created service. Right-click on the Silverlight Application project ("SilverlightWithService" in our case), and choose "Add Service Reference". If you click the "Discover" button, it will search out the Services that are included in the Solution. We'll use the namespace "PersonService". See below:

(Click image to enlarge)

Before you click "OK", be sure to check out the "Advanced" button. This opens a dialog that lets you choose how collections are returned from WCF Service calls:

(Click image to enlarge)

You'll see that there are 4 options to choose from: Array, Generic List, Collection, and ObservableCollection. The ObservableCollection is preferred in Silverlight for data binding purposes, but you may want to experiment with the other options as well. It doesn't matter the actual collection type that is returned from the service; it will be converted to the type you select here.

Now that we've added our Service Reference, we'll take a look at the Silverlight UI.

Step 4 - Update the XAML
Next, we'll create the UI. Open up the Page.xaml file. We're going to be making a few changes to the default values and adding some controls of our own. The final layout may look a little odd. This is because we will be adding some more elements to this in Part 2.

Here's the final layout:
(Click image to enlarge)

Let's look at the XAML; then we'll go through it step by step:
(Click image to enlarge)

First, update the Width and Height of the UserControl to 600 and 200 respectively. Then we'll swap out the "Grid" root element for a "Border". Then add a Grid with 3 columns (the other 2 columns will be used in Part 2). Inside the first column is a StackPanel with a ListBox and a Button. The ListBox sets the ItemsSource to "{Binding}". This says that each ListBox item will be bound to each item in the collection. The data binding will use a DataContext that we set in code at runtime.

Next is the Button named "EHButton" (for Event Handler Button -- Part 2 will have 2 additional Lists and Buttons and these names will make more sense). When adding an event handler in XAML, Visual Studio will help you out a bit. If you type "Click=" and hit Ctrl-Space (or let Intellisense pop up on its own), you will have the option "New Handler" to pick from. This will automatically name the handler based on the control name, and then add the stub to the code. In this case, it will create "EHButton_Click" in the code and hook up event.

Now that our UI is laid out, let's put the last of the pieces together.

Step 5 - Call the WCF Service
Here's another short-cut. If you right-click on "EHButton_Click" (the event handler) in the XAML, one of the options is "Navigate to Event Handler". This will open up the Page.xaml.cs file and put the cursor on the "EHButton_Click" event handler.

First, add the WCF Service namespace to the "using" section. This will make the code more readable. The namespace is [projectName].[serviceNamespace]. In our case, it is "SilverlightWithService.PersonService".

Now, we'll go back to the event handler. Start by creating a new proxy object. The proxy is the service name with "Client" appended to the end. In our case it is "PersonServiceClient". Next we'll hook up the callback. Since all Silverlight calls are asynchronous, we have to call the service asynchronously (it's the only choice). Start by hooking up an event handler to the "Completed" event. Visual Studio helps you out with this, too. Type "proxy.GetPeopleCompleted +=", and you'll see Intellisense for creating a new event handler. If you press "Tab" twice, it will create the new handler, and add the implementation. This is a great short-cut. The last step is to call the service using the "Async" method. In this case, just call "proxy.GetPeopleAsync()". See completed button click event handler below:

(Click image to enlarge)

The final step is to implement the callback. This is as simple as getting the result of the call (in this case a List of Person) with "e.Result" in the code. Then we assign this to the DataContext of the ListBox in the UI. One thing to note, if you hover over "e.Result", you will see that it is actually of type ObservableCollection of Person. This is due to the selection we made when we added the Service Reference earlier. The completed Page.xaml.cs file is as follows:

(Click image to enlarge)

Step 6 - Build and Test

Let's build and run. What you should see is that when you click the "Event Handler" button, you will get a list of 5 names in the ListBox. This may take a few seconds for the Service to fire up and run -- remember we're running asynchronously here. Also note that the list only includes the First Name because we did not do a full data template; we just set the DisplayMemeberPath. It's easy enough to enhance yourself, though.

(Click image to enlarge)

Conclusion

You should have a pretty good idea of how to create a WCF Service and consume it with Silverlight 2. We've created a new WCF Service, ensured that it was Silverlight 2 compatible, created a Silverlight 2 application, added the Service Reference, updated the UI, and finally called the Service and bound the results to the UI. In Part 2, we'll be looking at other ways of handling the asynchronous calls.

Book Review - Data-Driven Services with Silverlight 2

2009-04-14T21:41:00.000-07:00

As mentioned in a previous post, I deal with data-centric applications on a daily basis. Data-Driven Services with Silverlight 2 by John Papa is an excellent book for folks in the same situation. Here's what I really like about it:

Focused Topic
Concise Code Snippets
Clear and Useful Samples
Full Coverage of Silverlight 2 Data Access

Let's take a look at each of these.

Focused Topic
The book covers only data access concepts in Silverlight 2. It assumes that you have a basic Silverlight background and does not focus on areas such as controls, XAML or layout. This keeps the book brief (around 350 pages) and allows you to focus on the relevant topic: data in Silverlight 2.

Concise Code Snippets
Code snippets are used liberally throughout the text, both XAML and C#/VB code. The snippets build on previous samples and so only show the "new" parts. This keeps the code snippets short and relevant. And even though the code shows both C# and VB, neither seems to be too long or distracting. I found myself even forgetting that the "other" language was included at times. (You should be able to figure out which language I'm referring to -- not that there's nothing wrong with it. Both languages are pretty much equivalent, so it's just a matter of preference when it comes to syntax.)

Clear and Useful Samples
The samples (downloadable from John Papa's webite) are very clear. When there are multiple examples covering a single topic, they are packaged into a single application. This makes it very easy to navigate the samples both at design-time and run-time.

(Click image to enlarge)

A couple things to notice in the screen-shot. First, the menu system on the left. This lists the different samples that are included in the project. This makes it very easy to flip back and forth to make comparisons among the samples.

Second, notice that the sample on the right is pleasant to look at. I know that this isn't really all that important. But, many times sample applications for data access methodologies are merely functional. These actually use a custom control template library to make the samples look less generic. The control templates are out of the way in the samples, so it is still easy to focus on the functionality when reviewing the XAML.

Full Coverage of Silverlight 2 Data Access
Finally, since this book is focused simply on data access, it can cover a variety of data sources and methodologies. Chapters 1-4 are overviews of the technologies used in data access in Silverlight. Chapters 5-11 cover specific data sources. Here's a breakdown of the book chapter by chapter:

Getting Started with Silverlight 2
A few Silverlight 2 basics (such as Data Services and the Control Model) and .NET topics (such as LINQ and C# language enhancements) which are needed in later topics such as data binding.
Silverlight Data-Binding Foundation
The data-binding basics including dependency properties, XAML binding markup, and the DataContext.
Modes and Notifications
OneTime, OneWay, and TwoWay binding modes and the INotifyPropertyChangedInterface.
Managing Lists, Templates, and Converters
An overview of working with list-based controls, implementing data templates, and building value converters.
WCF, Web Services, and Cross-Domain Policies
How to build and call ASMX services, and also using WCF services that are compatible with Silverlight 2.
Passing Entities via WCF
How to send entities (simple classes) back and forth using LINQ to SQL and Entity Framework.
Consuming RESTful Services with WebClient and HttpWebRequest
An introduction to REST and using WebClient (simpler) or HttpWebRequest (more complex, but more flexible) to interact with RESTful services.
Consuming Amazon's RESTful Services with Silverlight 2
A specific example interacting with Amazon to search items, create a shopping cart, and add items to that cart.
Creating RESTful Services and Introducing SilverTwit
More REST, including consuming JSON services. The SilverTwit sample uses a series of services to create a Twitter client in Silverlight.
Syndication Feeds and Silverlight 2
How to interact with RSS and Atom feeds.
Silverlight 2 and ADO.NET Data Services
An overview of ADO.NET Data Services and how to interact with them with Silverlight.

Summary
If you create data-centric applications and are working with Silverlight 2, you need this book. By the time I got to the end of this book, I was extremely comfortable creating services and consuming them with Silverlight. This is an excellent addition to my collection of reference books, and I am finding myself repeatedly opening up the sample applications to review different data access techniques. I am very glad that I came across this excellent resource.

I read between 8 and 10 technical books per year (generally in the 500 to 900 page range). I find the majority of them useful, but occasionally one will jump out as being particularly relevant. That is how I felt with Data-Driven Services with Silverlight 2.

Getting Started with Silverlight 2

2009-04-04T20:40:00.000-07:00

I was planning on doing my next application at work in WPF, but it turned out that Silverlight 2 was a better fit. So, I've been doing some quick and dirty work to get up to speed. The good news is that the UI model with XAML is pretty similar (I'll let others get into the specific differences). The bad news is that everything happens asynchronously. Okay, so that's not really bad news, it's just something to get used to. I'll be covering some of my specific learnings on asynchronous programming a bit later, so stay tuned.

Database Programming
As I said earlier, I write business applications for a living. And that means database access. Silverlight does not support direct database access (such as ADO.NET or LINQ to SQL), so that means that everything happens through network calls. WCF is the best choice for this (with some limitations).

It took me a while to get comfortable with this concept. The best introductory resource that I found is actually on the silverlight.net site, including very useful tutorial videos. The most helpful one for me was #58 "How to Consume WCF and ASP.NET Web Services in Silverlight" by Tim Heuer. It's about 23 minutes and definitely worth the time.

Here's the short version:

Create a WCF Service using basicHttpBinding (Silverlight 2 only supports this binding).
Generate a proxy class for the service in the Silverlight application using the standard Add Service Reference.
Create an instance of the proxy.
Hook up a call-back by assigning a handler to [methodName]Completed. Visual Studio is good at helping create the stubs for you (see the video for a demo).
Call the [methodName]Async() to kick off the call.

Resources
If your applications are data centric, then you will definitely want to check out John Papa's book: Data-Driven Services with Silverlight 2 -- with an introduction by Tim Heuer. This book is all about data access, whether you are creating your own services or consuming existing services. This is a relatively short book (at about 350 pages -- small for a tech book), but the text and samples (easily available for download) are very good. By the time that I got to the end, I was so comfortable with consuming services with Silverlight and working with the asynchronous calls that I could code them up with my eyes closed. I'm planning on doing a full review of this book in a later post.

The official Microsoft site has a lot to offer. In addition to the video mentioned above, there are lots more on all different topics. Just check out http://silverlight.net/Learn/.

I mentioned the Matthew MacDonald WPF book in a previous post. The good news is that there is a sibling Silverlight book: Pro Silverlight 2 in C# 2008. This is a very good overview of Silverlight 2 including XAML basics, layout, controls, animation, styles/templates, service calls, and browser integration. The accompanying samples are also very good and cover all of the included topics.

I always point to dnrTV for good web-casts. You can check out episode #127: Shawn Wildermuth on Silverlight 2 Data. Lots of interesting tidbits scattered throughout.

My Experience So Far...
Silverlight 2 is an adventure. It's not quite web programming, and it's not quite WinForms programming. It sits squarely between the two. More details coming up...

Target Practice - WPF / XAML Sample

2009-03-09T14:03:00.001-07:00

This time we'll be looking at a few of the points from my last post: What I Like About WPF. I set out to create a short demo that uses only XAML (with no code behind) to show the power of some of the features; specifically declarative programming, templates, styles and "lookless" controls. So, let's get to the scenario.

Scenario
We'll be creating a very simple shooting gallery-type application. I call it "Target Practice" since it will require some more work to turn it into an actual game. In the final version, we will have a 3 x 3 grid of targets. Each of these is clickable and will result in a "hit" animation. After 3 seconds, the target will reset to its previous state -- all inside the XAML. You can scroll down to the bottom to see the finished product.

Step 1 - Application Set-up
We'll start by creating a new WPF application. I'm using Visual Studio 2008, but everything I'm doing here should work in 2005 as well. Create a new project by selecting File -> New -> Project. From there, choose the "Windows" category under "Visual C#" and select "WPF Application".

In the new application, you will find a "Window1.xaml" file. That's where we are going to start. Open up the xaml file, and you will see a designer and xaml editor. We'll be focusing on the xaml editor. Here's what the project template creates:

(Click images to enlarge)

We're going to make a few changes. Again, this isn't a tutorial on XAML, we're just focusing on showing some of the power. Resources from the previous post are helpful if you are completely new to XAML. First thing we'll do is change a few properties in the "Window" tag. Set the following properties:

Title="Target Practice"
Height="370"
Width="350"

Next, we'll replace the Grid with a set of nested StackPanels. The nested StackPanels will set up our 3 x 3 grid (I could have used the Grid here as well, but the StackPanels are better at letting things "flow"). Inside each nested StackPanel, I have placed 3 buttons. The StackPanel code (that replaces the Grid) looks like this:

When you run the application, you will get a highly exciting result that looks like this:

Step 2 - Templates & Styles
So, we have a grid of buttons; now what? Next, we are going to take advantage of the "lookless" controls. WPF controls do not have any inherent visual styling to them. They simply use a default template that is provided by the framework. We are going to replace that template with our own to create a custom button. And hopefully, by the time we get done, you'll see how much easier this is to do in WPF than it is in other UI technologies.

We're going to add a local resource to the file. Add a tag "Window.Resources" just above the outer StackPanel. You'll find that Visual Studio IntelliSense is very helpful when hand-editing XAML. There are visual ways of doing this with Expression Blend, but that's another topic. Inside the Resources section, we'll add a ControlTemplate.

A few key things to point out. The TargetType is set to Button. This means that we can apply this template to button controls (and only to buttons). Next is x:Key: this gives a name to the template that we can use elsewhere. Next we have a Canvas (basically our drawing surface) and an Ellipse (which is just a DarkRed circle). Note: this is called the "Outer Red Stripe" in the comments because we will be adding more to this later on.

From here we are going to add a Style. The reason for adding a Style will become apparent as we move along. For now, you can see that we create a new Style, give it some Margins, and then set the Template property to our ControlTemplate:

Styles work by using Setters. The Setters let you select a property (such as Template) and then assign a value to it. You'll notice the syntax for the Template setter looks like this: Value="{StaticResource targetButton}". The curly braces denote that we aren't setting the value directly; we are binding to another object, in this case a StaticResource. The "targetButton" is the x:Key that we specified on our ControlTemplate above.

One thing to note on our Style: we would normally use an x:Key here as well, which would give us a named style that we can apply in our UI. Styles have the special behavior that if you exclude the x:Key, then the style will automatically be applied to every control in that scope. In this case, since the TargetType is Button, it will be applied to every button in our Window. Here's what our application looks like now.

One thing to note: the red circles are still buttons. They are clickable (although they don't visually change when you click on them), and they have standard button events (such as Click). Notice that they do not have any content (Button1a, Button1b, etc.). This is because our template does not contain an element for the Content. If you are creating your own buttons, then you will want to look at this and other behaviors (such as having different visuals for up, down, and hover). So far the visuals for our application aren't that great. Step 3 is going to change that.

Step 3 - Eye Candy
Now we'll take our boring red circles and make them into glassy 3-D buttons. The best way to learn how to do this is to take a look at some Photoshop tutorials and use the same techniques in Expression Blend. The cool part about using Blend is that when you have what you want, you can simply copy the XAML (or have it included as a resource in your project). I am not a graphic designer, and I will admit to stealing this "top glow" and "bottom glow" sections from a demo by Walt Ritscher. He is also a good resource for WPF styles and templates.

First, the top glow. This is simply added to our ControlTemplate below the DarkRed Ellipse. All it is is an ellipse with a radial gradient that moves from white to transparent.

The bottom glow is much the same: just an ellipse with a radial gradient.

What you see when you run the application is a distinct difference in what we had before:

Pretty cool, eh?

Step 4 - Completing the Targets
Next, we just need to complete the visual design of our Targets. This is just a set of ellipses, each smaller than the last, alternating Red and White.

A few things to note here. You'll see that we are moving the Canvas.Left and Canvas.Top properties because the Top Left corner is considered the starting point for drawing. We are moving down a bit and to the right to make a smaller circle on top of the previous one.

Order is important here. The XAML parser processes items in the order that they appear in the file. This means that the "Outer Red Stripe" (our first circle) needs to be specified first, and then as each smaller circle is defined, the XAML parser layers it on top of the last. If we were to reverse the order, then the large circle would simply cover everything underneath it. The same is true for the "glows." We want those as the top layer, so we specify them last in the XAML.

On a side note: Silverlight has a Canvas.ZIndex property that allows you to explicitly set the order of the layering. This is not available in the current version of WPF, but we'll see what the future holds when .NET 4.0 comes out later this year.

When we're done, our targets will look like this:

Step 5 - The Action
The last step is to add the behavior. As a reminder, when we click on a Target, we want it to animate to fall over, and then reset after 3 seconds. The animation will work by using a Transform. The first step is to define an empty Transform in our Style (note: we are adding this to the Style, not the ControlTemplate).

Next, we will add a Trigger to our Style. A Trigger denotes a change to a style based on some external influence. In our case it will be a response to a Button.Click, but it could be a MouseOver or other event.

This is a big bit of code, so let's walk through it. First, we are setting up a Triggers section in our Style. Next we are setting up a EventTrigger on the "Button.Click" RoutedEvent. Inside the EventTrigger, we have an Action section which will contain our actual animation. The EventTrigger and corresponding animation is why we need to use a Style here (as opposed to using just the ControlTemplate).

The animation is declared with Storyboards. This is another section where using Expression Blend is helpful. You can define an animation using visual tools, and then copy the XAML back into your application (or use it directly as a Resource).

The first "DoubleAnimation" on "RenderTansform.ScaleY" means that we will be changing the "Y" scale (meaning the Height) over the duration specified (0.3 seconds) and changing it from 1 (full height) to 0.01 (which ends up looking like a line on the screen). If we were to use this animation by itself, then our button would actually shrink "up" because the origin is at the top left corner. In order to get it to shrink "down", we need to add another transform.

The second "DoubleAnimation" on "RenderTransform.CenterY" means that we will be moving the origin of our button. This time from 0 (the top) to 110 (which is actually a little bit below the bottom of our 100 unit Canvas -- the Canvas is a special container in that you can actually draw outside of its boundaries).

Let's take a step back for a moment and talk about animation. What you will notice is that we do not have any timers specified here. To perform this animation in the WinForms world, we would use a timer, and then perform some action on every tick (such as moving an image a few pixels). Animation in XAML is declarative. This means that we tell it what we want to do (move from here to there and take 0.3 seconds to do it) and not how to do it (move 3 pixels each 100 milliseconds). The animation declaration itself is just changing a Property on the element. In this case, we are making changes to the empty RenderTransform that we defined earlier. The "DoubleAnimation" denotes that we are changing a Property that is of type Double (specifically the RenderTransfor.ScaleY and RenderTransform.CenterY).

These two animations together will result in our Target being "hit" and falling down.

The next 2 "DoubleAnimations" are basically doing the opposite. Note that these both have a BeginTime of "0:0:3", which means that this section of the animation will start after 3 seconds have elapsed. This will return our Target to the upright position after 3 seconds.

You'll have to run it yourself to see the final result. Here's a screen shot of things in action:

Round Up
So, what we've seen here is a pretty impressive application for not having any C# code. In fact, we could have started with a VB project and come up with exactly the same results. We were able to declaratively program the behavior using XAML only -- and all in less than 120 lines. We took advantage of the lookless controls by replacing the default template and style with our own. With a little bit of C# code, we could turn this into a full fledged Shooting Gallery. But I'll leave that to you.

Happy coding!

What I Like About WPF

2009-03-01T15:07:00.000-08:00

Windows Presentation Foundation (WPF) is the future of Rich Client (or Smart Client or Fat Client or whatever term is in fashion) programming in .NET. Microsoft is using WPF for the UI in Visual Studio 2010. If you are like me, then you still haven't had a chance to work with it extensively (due to constraints of my day-job). But, if you are like me, you are also very excited about the technology -- and not just because of the eye candy (although that is an added bonus; albeit a potentially dangerous one).

Note: this isn't an introduction to WPF. I have some resources listed below if you want more info. So, here's what I like...

Declarative Programming Model
You can do quite a bit of the UI work in the XAML itself (XAML stands for eXtensible Application Markup Lanuage -- for more information, look for an intro to XAML). This UI work includes triggers, animations, and data bindings. Sure, you can do the work in your C# (or VB) code, but it's nice to be able to put it into the XAML.

Data Binding
I write business applications for a living -- that means pretty much everything requires some sort of data access. There are several WPF data binding features that seem to combine the best of WinForms data binding and ASP.NET WebForms data binding, plus some new features thrown in.

Binding to the container
Since you can bind the DataContext (your data source) to a UI container (which is pretty much everything -- see below), every child element can use that DataContext implicitly.

Good Support for value converters
IValueConverter is nothing new, but I have seen several WPF demos that use it in the data binding, making things dead simple. For example, you can use a value converter to convert a bank balance (an integer) to a brush (red for negative values, black for positive). In your bindings, you can bind the Brush on a TextBox directly to the bank balance, and the value converter takes care of the rest.

Binding to static resources
You can use data binding syntax to connect properties to static resources that are either defined locally to the page or globally to the application. As a programmer, you need to do less internal context switching since the syntax is the same regardless of whether you are binding to a static resource or a dynamic data context.

Binding from one element property to another
I'm not sure why I like this so much, but for some reason I do. If you need to display the same data twice on a page (like in a master / detail or selection / detail relationship), you can bind the Content property of one element ot the Content property (or any other property) of another.

Commands
Coming from the Delphi programming world, I always wondered where the concept of Actions went in C# (after all, Anders Heilsberg was the architect of both languages). Commands allow you to hook up several UI elements to the same command. For example, you can hook up a menu item, tool bar item, and a button to a single Command (such as Save). This lets you enable or disable the Command, and it will affect all connected UI elements. (Also, you have centralized code which is always good.)

Now let's move on to some more visual features. (I'm skipping the eye-candy at this point to focus on usability.)

Most controls are also containers
This adds immense flexibility to the UI designer. You have full control over layout of a button that has both an image and text. Anyone who has fought with the layout of an image button in WinForms will greatly appreciate this.

Flexible layout and resolution independence
If you pay attention to your layout, you can design an UI that is usable on both a 23" desktop monitor and a 9" netbook. This will seem somewhat familiar to web developers. Plus, if you focus on using vector graphics (as opposed to bitmaps), then you can get good scaling without aliasing (i.e. "jaggies").

Templates and styles
This seems very comfortable to web developers who use CSS. But it is incredibly more powerful. I'll be focusing on this in a future post.

"Lookless" controls
None of the WPF UI controls have a built in rendering. Instead, they have default templates. This means you can replace the default with your own template to make a control appear however you want. Because the base control is "lookless", it means that all of the functionality (such as "Click" on a button) is separated from the rendering; so, you can replace the visual rendering without impacting the underlying functionality.

Lack of a DataGrid
This one may sound weird. Most of the WPF forums are littered with developers complaining about the lack of a data grid. There is even a CodePlex project to implement one. But I have found the lack of a DataGrid to be an opportunity.

In my applications, I generally use data grids because they are easy -- not because they are the best way to present the information to the user. I have started to think about the power of the ListView. By using containers and templates (including data templates), I have full control over how I present the data, and it's dead simple.

"Dead simple" is the key. Most of the things that I've mentioned are possible to do in WinForms, but you end up jumping through hoops to accomplish them. WPF makes these things "dead simple." If you're curious about alternatives to displaying data (without a Data Grid), then check out some of Billy Hollis' web casts (see below for links).

So, that's why I am excited about WPF. If you are, too, then you can check out these resources:

The Official Microsoft WPF and Windows Forms Site
This site is loaded with tutorials, samples, downloads, and lots of info.

dnrTV
This site has web casts (generally about an hour long) on all sorts of .NET topics. As mentioned above, Billy Hollis has done some excellent episodes:
dnrTV - Episode 115 - Billy Hollis: Getting Smart with WPF
dnrTV - Episode 128 - Billy Hollis: XAML for Developers Part 1
dnrTV - Episode 129 - Billy Hollis: XAML for Developers Part 2

Pro WPF in C# 2008: Windows Presentation Foundation with .NET 3.5, Second Edition - Matthew MacDonald
This is an excellent (large) book. It's around 1000 pages, and has lots of great information and samples. There is also a VB version of this book if that is your language of choice.

I'll be digging in to specific WPF topics as time goes on, so stay tuned!

What's this all about?

2009-02-21T23:30:00.000-08:00

I am not an expert.

Computer programming is about constant learning. I like to think that I'm competent in my field (currently doing .NET programming). But with the depth and breadth of the technologies, it's also very easy to feel lost and inadequate. Still, I keep moving forward and keep learning new things along the way. If I ever get to the point when I've come to the end of another project and I haven't come across some new technique or optimization along the way, then it probably means that it's time to move on to another field.

But I don't see that happening for a while.

I wrote my first program in 1985 on a knock-off Apple ][. I was 14 at the time. So, that puts me squarely between the old-timers who talk about punch cards and big iron, and the newcomers who have never had a computer with a floppy drive. Over the years, I've used various programming tools and languages, including BASIC, C++, Visual Basic, Java, Delphi and C#. In addition, I've used various web technologies, such as HTML, JavaScript, PHP, Visual InterDev, ASP, ASP.NET, and even dabbled in assembly (just for the "fun" of it).

My professional programming career began in 2000. I was fortunate enough to have been given access to good training, knowledgeable colleagues, and access to the occasional technical conference. I'm also an avid reader and can usually be found with some 600 page tome in my bag.

So, what's this all about? My goal is to help other programmers take a step up. Together, we will be looking at various topics ranging from general programming techniques (such as common design patterns) to specific technologies (such as WCF and WPF) to application architecture. The focus will be on those elements that have made me more effective as a programmer. But I will also include mistakes that I've made along the way. Many times, basic tenets become clear when you look at the way not to do things.

Be prepared to think. And above all, keep learning.