DarksideCookie

And once again I’m back on my computer with Live Writer and Visual Studio open. I thought it was time to give you the 4th part of the SilverTweet series. If you have missed part 1, part 2 and/or part 3, I recommend heading back and looking through them.

If someone would have told me a year ago that I would be so obsessed with my work, that I would be sitting on a plane at 07:20 in the morning writing a blog entry, I would probably have said that they must have me confused with someone else. Software development is just a job, it isn’t my life… Well, I guess I care more about it than I would like to admit…

Anyhow, in this part of the blog series, I’m going to go on and show you the rest of the models/viewmodels used in the SilverTweet application.

More...

Once again I am back to my Twitter client. The next step in my application is to create some view models to bind the view to. This includes adapting the models I get from the Twitter service to the interface that I am going to create, as well as creating some models of my own. The modification of the auto generated ones, is pretty easy to do using the “new” partial class definition, that the objects defined in by the service proxy use.

Anyhow, let’s get started with some coding. But before I get started with the viewmodels, I am going to create a very simple little layer of abstraction. What? Why? Well, I want to de-couple the Twitter service as much as possible. The reasons for this are a couple, but mainly because of the way Twitter works. Since it is on the web, it means that I need to have internet connection to access it. It also has a limit to the amount of requests one can do per hour. This means that if I work without an internet connection or do a lot of testing with loads of requests to the service, it might cause some problems. By de-coupling it, I can switch the implementation to a mocked version, removing the need for internet access as well as the request limits. It also makes it possible for me to create unit tests for my viewmodels if I wanted that. So this layer of abstraction gives me some options. Not that I will use any of them in this example, but I have the option if I ever needed.

More...

Welcome back! Or at least I hope it is welcome BACK. If you are not coming back, that means that you have missed the first part of this blog series. And in that case, I recommend by starting out by reading the first part. If you have already done that…let’s get cracking…

In the first part, I focused on the connection to Twitter. That included implementing OAuth and the Twitter methods I need to get the client to run. In this part, which will be a lot shorter, I’m going to focus on creating a webservice that can expose the Twitter functionality to the Silverlight client.

More...

A while back, I wrote this blog series about how to build a Silverlight client for flickr. This seemed to be pretty popular among a bunch of the people who stumble across my blog. I don’t know if it was specifically because it was using flickr or if it was because it went through the entire application step by step or if it was something else. But since then, I have gone around thinking about other possible applications that I could dissect in the same way, and for some odd reason I stumbled across Twitter. I know…you don’t stumble across Twitter. It is all over the place, and anybody that hasn’t heard of it is probably dead or deaf  and blind. I’m personally not that active on Twitter, even though I try on and off. For anyone interested, I’m available here.

Anyhow, after having looked at it for a while, I decided to create a Silverlight based Twitter application. Even though it’s not as fancy or useful as some of the other alternatives out there, it will show the basics behind how to build a client. And not a client that just allows you to read a feed, but actually interact with it and send tweets. If you are not interested in how to develop a Twitter client and just want a Silverlight based client, I would recommend Gadfly, which is a fantastic client compared to what I’m going to show. But the idea behind this blog series is not to get the coolest application, but have a look at how one could go about building a client.

More...

[UPDATE]
The code for the CommandManager has been rewritten due to some memory management issues. And together with that change, I have decided to put it on Codeplex. My blog posts about it are still more or less valid, but I suggest also taking a look at the code at http://agcommandmanager.codeplex.com/.
[/UPDATE]

Once again I return to the CommandManager that I have blogged about before. And I know it is getting boring and that I some day must leave that behind me and go forward. However, after having had a look at Prism/CAG/CAL and seen how Microsoft solves the commanding infrastructure, I have decided that the CommandManager still fills a purpose.

I also had a plan to retire the CommandManager completely and implement something similar using Behaviors. However, Behavior<T> or what ever it is called, inherits directly from DependencyObject instead of from FrameworkElement. This made it really hard to use in this situation, since it doesn’t support data binding. So I had to scrap that idea for now. It seems as if Microsoft uses this idea in Prism, but introduces an extra static object to get it to work… At least in the Prism implementation I have been looking at.

So why do I return to the CommandManager again? Just to argue that it is great and boost my ego? No…apparently, my previous implementation had a flaw. I might have a lot more, but I discovered one that caused problems. So I have rectified that…

More...