DarksideCookie

In my last post I wrote about how I had created a ViewModelLocator that was a bit different from what everyone else was using. I had come up with the awesome idea to use the same VMs at design-time as I used at run-time. This idea sounds very good, as it means that I only needed to build a single set of VMs and instead could switch the service implementations using DI. At the time, it sounded like the most “correct” solution. Little duplicated code, no chance of messing up the bindings and so on…but it has a huge problem…

More...

[UPDATE] This post is somewhat interesting, but the idea doesn’t really work in the real world. More info HERE [/UPDATE]

I have tried to stay out of certain areas when I blog. Why? Well, simply because some things are still heavily debated, and some debates even seem a bit infected. Some topics seem to cause people to get somewhat rabid and I don’t feel like causing a big flame war of any kind. But still, I have decided to talk a bit about some of the options we have when binding our views to our viewmodels, or vice versa. I can’t even write that with out having to be careful…

More...

Ok...I'm back with the final post about extension/plug-in loading in Silverlight. Well, at least I think it is the last as I have tried all obvious ways. I have previously showed how to it manually here and then how to do it "automatically" using MEF here. Both these have some upsides. The custom solution is tiny from a download perspective and offers a lot of control. MEF on the other hand automates a few pieces of the solution, still offering a lot of manual control. The download size does however grow a lot compared to the benefits gained. So, so far, I would say that the custom way is the winner. At least as long as the requirements are as simple as they are in this case...

This last post is all about doing it according to the Composite Application Guidance (CAG). CAG is a set of guidelines and patterns for building composite applications in WPF and Silverlight. The CAG is implemented by using the Composite Application Library or PRISM framework. CAG talks about how to do it, while CAL consists of assemblies helping the developer to actually do it. At least that is the way that I have understood it.

More...

In my previous post I wrote a demo application that used a custom implementation to load plug-ins from the server and place them in a shell. This implementation was very specific and limited in its functionality. It did however do what I needed for the simple task at hand. This post is all about how we can do the same thing using the Managed Extensibility Framework (MEF). MEF is of course a lot more flexible and powerful than my simple implementation, and then what I am about to use it for. But I will build the same application using MEF anyway, and show you how it works in comparison to the custom solution.

More...

Building an application based on discrete pieces (plug-ins) isn’t a new thing. It has been around for ages. Loads of applications support a plug-in model. So, obviously you can do the same using Silverlight. There are even a lot of different ways of doing it. They all have benefits and cool tricks up their sleeve, but they also come with bad things as well. I have decided to take a look at three of the more common ways of handling this whole thing. The first attempt I’m going to show is using the good old “I’ll do it myself” approach. I want to start out in this end, and then compare two other common approaches to the custom built one. This way I feel that you can thorough comparison.

The other two approaches I will show are Managed Extensibility Framework, commonly known as MEF, and Composite Application Guidance, also known as CAG or Prism. And to be honest, I don’t know if the third option should be CAG/Prism or CAL (Composite Application Library), but who cares. You know what I mean…

More...

So…as you may or may not have noticed, I haven’t been posting as aggressively today as I did yesterday…(Well…it wasn’t actually yesterday… I started writing this post when it was yesterday, but got sidetracked and had to continue today, Wednesday). There are a couple of reasons for this. First of all, I have meet WAY too many people I knew to just sit in a corner and write blog posts. Second, I went to the official party last night…which was interesting with about 4000 people attending and only about 50 girls except for the staff…

But anyhow, the yesterday progressed as it should, a great keynote and lots of interesting sessions about the WP7. And even though I have found some gaps in the platform, I still find it VERY interesting. Not to mention that the UI is the cleanest looking UI I have ever seen on a phone. I guess I want to try it before saying it is the best UI, but it looks very promising…

More...

I have just attended the 2nd WP7 session. This was another 100 level, which means that it just just another run through of the vision and platform and stuff. No dev stuff yet. It did produce some new information though. First, the Silverlight environment on the phone will be a superset of Silverlight 3. That is SL 3 with some SL 4 features and some “custom” stuff. This first surprised me, but it is pretty obvious to be honest. A lot of the new features in v4 extended the offline feature of SL, which won’t be available on the phone anyway.

More...

As I mentioned in my previous post, the CommandManager has been moved over to Codeplex. But I have actually created 2 Codeplex projects. I decided to also move the OpenXML code, that I blogged about previously, to Codeplex. It is available at http://agopenxml.codeplex.com/. Initially it is no more than a rewritten version of the code I blogged about, but my goal is to extend it as time goes by. Either by creating extensions of my own, or if I am lucky, by including extensions created by other users.

I am currently working on an article for http://www.openxmldeveloper.org/, which will be about implementing Excel functionality using the library. This article will result in code that will be merged with the current code and extend the Codeplex project with basic SpreadsheetML functionality. I will try to get this up on Codeplex as soon as possible, but I am currently on vacation and will go to Mix10 just after coming back to work. So, if I am lucky, it will go online just before Mix10. If not, it will go online just after…

I just found out that commenting has not been working for a while. Not that I think more than 1 or 2 people have noticed it, but that’s the case anyway. I have now fixed that problem and commenting should be up and running again… Sorry about that!

On another note, I know I have not posted a lot lately, but I have been on vacation and when I got back to work I had a pile of things to take care of. The good thing is that there will hopefully be a bunch of posts going online soon as I am heading to the MIX conference in Las Vegas on Saturday. I start off by helping out on the Azure lab (or watch Chris Auld in action…) on the Sunday and then follow that up with LOADS of Windows Phone 7 Series !@&%£* that is long…It will probably turn into WP7 real quick) sessions. I will also attend a “train the trainer” thing for the Windows Phone 7 Series. So hopefully I will be able to tell you all about how it is developing for Windows Phone 7 Series devices real soon.

The other day, a reader called MAX pointed out to me that the CommandManager has a major flaw. It stores all commands in a static list. This keeps the garbage collection from working as it should, as the commands are always referenced. The commands in turn reference the controls that use them. So the CommandManager actually keeps any control that uses commanding from being GC:ed. So, because of this, I have changed the CommandManager code once more. This time however, I have not just added some information here and posted the new code for download. Instead, since the CommandManager seems to never die, I have put it on Codeplex making it available at http://agcommandmanager.codeplex.com.

The CommandManager never dies? …have I forgotten about Silverlight 4? No, not at all. Silverlight 4 has a bit of commanding built into it. It supports binding ICommands to Command properties on some controls, such as Buttons. This is great and will definitely limit the need for the CommandManager. The CommandManager has one thing that Silverlight 4 does not have. It supports binding ICommands to more or less any event. So if anyone needs this kind of flexibility, the CommandManager is the way to go…