13.02.2010 г.

Blend 2 and Blend 3

Before starting this post I promise myself to make it short. If you take a look at my last 2 ones you will understand why. So Blend. What can I say? Not much of course. Blend is a designer tool and I pretend to be a developer. However for some reasons I had to use it, because I had no other option. VS2008 has no designer for silverlight. And I think it is a very good product. You can make animations (storyboards in terms of xaml), to move things around, to edit properties and I'm sure many many other things.
Let me first write something about Blend 2. It is not so good. It supports only silverlight 1.1 projects. To open and edit SL 2.0 projects you need to install Blend 2 sp1. But that brings you just the ability to edit SL 2.0 projects. The same problems Blend 2 has are still present in sp1. It can't show inherited forms. Also you can't select a control by clicking it in the designer. Instead you need to find it in the control tree and then select it. And I'm sure Blend 2 has some other bugs too.

Blend 3 is something different. Again I can give a good review because I use maybe less than 10% of its features, but I think it is much better than Blend 2. The problems mentioned above are solved here. Also Blend 3 is in my opinion faster. It loads the projects faster and also working with it is easier.

However both versions of Blend share a huge disadvantage. They can't work with Visual SourceSafe. So the designer we have at the office needs to install Visual Studio just to check out the files she needs to edit. And then to check them in.
That is not right. Microsoft should do something about this.

And to keep the promise I gave myself I stop here.

What I hate about Silverlight

Don't get me wrong, I like silverlight. It is great. It is fast. It is different.
However some things really drive me crazy.
Silverlight 1.0 was just an advertising campaign. Its purpose was only to make developers anxious for the upcoming versions. I understand that.
I haven't used much of silverlight 1.1 but I know it was a huge leap forward.
Then came 2.0 that was announced as the first version that can be used to write sensible and powerful solutions.
Then came 3.0 which was expected to be also a major release.
I started to use silverlight just after version 2.0 was released. There were some things that were irritating me in 2.0. Those things still irritate me in 3.0. Actually I thing the difference between 2.0 and 3.0 is not so big that I expected.
I read somewhere that 3.0 introduces support for using the 3D power of your video card and also support of using the wheel of the mouse. Hello! Is this the most important.
But what really drove me crazy was that just a few months after releasing SL 3.0 Microsoft announced 4.0 beta. What to expect from this new version?! Maybe voice recognition, which will totally smash the Adobe rival.

So let me point some features I miss in Silverlight.

1) The designer. I miss a designer for silverlight in VS2008. How to create my GUI without designer. Hot to compute the margins? I heard that a powerful XAML designer will be available in VS2010. I'm waiting for it. As designer I use MS Expression Blend, which is very very good tool and even I can work with it. About Blend I will write a separate post.

2) Can reference only silverlight library projects. What about the whole bunch of code that you have. In my case we have some code dll-s that all the other projects use.I have some clues about this restrictions, but they are not worth sharing. However you can always link a file if you need. That btw, I mean the restriction of referencing dll-s != silverlight, has also a good side. Because it is vital to reference as less as possible dll-s. Because every single referenced assembly is then added to the package that every single user of you silverlight control downloads. Also I think there might be some performance penalty when having many assemblies, but I haven't tested that. Also I think here's the place to mention that you must be very careful with memory usage. Try not to hold references to huge collections and objects. Make sure you don't prevent the garbage collector to dispose them.

3) The most annoying one. The design time exceptions. You write some code, compile.Everything seems good. And then when you run it you get AG_E_UNKNOWN_ERROR or G_E_PARSER_BAD_PROPERTY_VALUE. Then you see some line and some position. It took me quite a time to start getting some hints on where the problem is. Was it so hard to make exceptions more detailed? Btw the majority of the exceptions I get are because I omit to implement a event handler in the .xaml.cs file. And I have declared it in the markup. This is a design time exception. Was it so hard to catch it design time? So to sum up I think Silverlight exceptions suck and Microsoft should do something about it instead of dealing with the mouse wheel.

4) Inheritance (of silverlight controls)- there is a workaround to do this. I admit that. But it is not as straightforward as it has to be. To inherit from other "form" you need to mark this in the codebehind file and also in the markup file. There are some other details that are however not relevant. Lets say, yes inheritance is possible. But, as "forms" are not meant to support inheritance there a lots of bugs in the whole thing. I needed all my forms to have some common behavior. For this I needed to handle 3 events. I wanted to hook for the events and write the handlers in the base form. And then all other forms to inherit from the base and to share the base behavior. But I failed. That was not supported. I got exceptions. And yes they were "AG_E_UNKNOWN_ERROR" like :). So I needed to hook in every single form and also needed event handlers for all the 3 events. In those handlers I called the three methods that I had written in the base class. What a mess. So to sum up: Microsoft guys, please do some work on inheritance.

5)And last. Some framework classes omit some of their methods. For example I will point the Enum.GetNames and the Color structure. And you can't use System.Drawing.Color, because System.Drawing is not a silverlight library.

Below is a workaround I use to get the names of all members of particular enum and also a method to get a color from its hex representation. To be honest the second one is not available in System.Drawing.Color too.
public static List GetEnumNames(Type enumType)
{
List enumMemberNamesFuckSilverlight = new List();
System.Reflection.FieldInfo[] fiArray = enumType.GetFields(
System.Reflection.BindingFlags.Public |
System.Reflection.BindingFlags.Static);
foreach (System.Reflection.FieldInfo fi in fiArray)
{
enumMemberNamesFuckSilverlight.Add(fi.Name);
}
return enumMemberNamesFuckSilverlight;
}

public static Color ConvertStringToColor(string source)
{
Color blackDefaultColor = Color.FromArgb(255, 0, 0, 0);

try
{
if (string.IsNullOrEmpty(source))
{
return blackDefaultColor;
}
else
{
source = source.Trim(new char[] { '#' });
if (source.Length != 8)
{
if (source.Length == 6)
{
//Correct color representation, omitting the alpha.
source = "FF" + source;
}
else
{
//Incorrect color...Sorry!
return blackDefaultColor;
}
}

byte a = (byte)Int32.Parse(source.Substring(0, 2), System.Globalization.NumberStyles.HexNumber);
byte r = (byte)Int32.Parse(source.Substring(2, 2), System.Globalization.NumberStyles.HexNumber);
byte g = (byte)Int32.Parse(source.Substring(4, 2), System.Globalization.NumberStyles.HexNumber);
byte b = (byte)Int32.Parse(source.Substring(6, 2), System.Globalization.NumberStyles.HexNumber);

return Color.FromArgb(a, r, g, b);
}
}
catch (Exception exc)
{
return blackDefaultColor;
}
}

Some experience with Silverlight

So as I promised here is the article about what I learned about Silverlight from my first serious touch with it.
As I mentioned before, from some time I'm working on a Silverlight project, that is some kind of workflow designer. Briefly said I have nodes and routes between them and nodes plus routes make a task.I will not deepen on the purpose of this architecture, because it is related to our specific needs. So actually this WF designer is not a general purpose one, but it is specifically designed to serve us. However it was a good experience for me, because you know, the best way to understand some new technology is to start using it. Then comes Google :).

I had some challenges before I start to write.

First of all was the data model.The objects I described above(tasks, nodes and routes) were represented as database tables. To spice the things up, the node object had some bunch of dependent objects, that were not presented as database tables but serialized as XML and stuck in a text column of the node table. So there was a serialize/deserialize process when dealing with the nodes. However this part was already done for an old windows forms application with the same purpose as the silverlight designer. Btw the silverlight designer was meant to replace the old windows forms one. I had the XML <-> objects conversion done. However I couldn't use those objects, because they were not marked as Data contracts. But for that I will write below.
So enough for the issues regarding the data and its representation.

The second challenge was how to get this data from the server and serve it to the client and vice versa. Here the solution was straightforward.

The last major problem was how the hell to implement a GUI for editing the whole bunch of objects. The problem was that I needed to mitigate the complication of the data model and to do the GUI as simple as possible for the user.

So let me start with the decisions I made.
About the data model, I decided to create a mirror object to every object I needed to transfer across the wire. So lets say as example that I had three objects - NodeSettings, NodeCoordinates, NodeSomethingElse. Remember, all these objects are serialized to XML and the result XML is saved in a text column of the node table. Also I had an API to work with these objects. Lets name the "mirror" objects for these three ones respectively NodeSettingsTransfObj, NodeCoordinatesTransfObj and NodeSomethingElseTransfObj. They were marked as data contracts. To work easily with both the framework ones and the transfer ones I created for each of the objects an extension method. Did I mentioned that extensions rule! So for example the pair NodeSettings <-> NodeSettingsTransfObj. I created on NodeSettings an extension method named ToTransfObj and on the NodeSettingsTransfObj an extension method named ToFrameworkObj. All the extension methods I put in a single class. The name of the class can be whatever you want, but the class needs to be static. After this really hard and boring work you will be using the extensions on a single line.

Here is the whole picture:


About the second challenge - the actual transport between the server and the client:
Here as I said the choice was clear. WCF is the only way to transfer information when we talk about silverlight. So there was no other option for me but WCF. And I don't complain. WCF is marvelous. It is bullet fast, extremely stable, reliable and very flexible and easy to configure. But not everything is so pink with WCF services called from silverlight. The key thing here is that you can call operations of the service only in Asynchronous manner. This is a little bit tricky. In some scenarios you will need the synchronous calls desperately but sorry - you just can't do this. I spent a whole day to dig for a workaround in the Internet with no success. I don't exclude the chance that a workaround exists, I simply say that I didn't manage to find a real good one. One of the workarounds was actually helpful. It was using a separate thread for the call to the service operation and also it was using the BeginXXX and EndXXX methods of the service operation. However to assure the thread has finished its work and the call to the operation has returned a result I needed to block the main thread and join the service calling one. This is important: never block the main thread. The main thread appears responsible for handling the communication with the service API. So actually when blocking the main thread you get yourself in deadlock situation. The main thread is needed to handle the response from the service and as it is blocked it can't do that. Also the supporting thread can't finish its job while the call is in progress. Well I hope you got the picture, cause I can't explain it better. It is already blur for me, because it's a month since I fought that problem. But the picture was something like that. So I had to stick to the natural design, because the whole "thread using solution" didn't seem to be stable and reliable. The last thing related to the WCF part and its asynchronous calls is actually more like an advice. Whenever possible do call the service operations before they are actually needed. For example you have a form (or window if you like) that you use to edit object of type NodeSettings. This object lets say has a property that is collection of type SomeType. This collection you edit on a separate form that is shown when you click a button on the first form (a button saying for example "Edit Members"). So the best practice in my opinion is to call the operation that will return all the "members" of type SomeType before the user clicks the button. So to sum up: Call the operations ASAP! These calls are not expensive. WCF is very very fast.

The last one is the GUI. GUI has always been a pain in my ass. My designer abilities are are enough good to realize that my GUI sucks :). However with this project I had to face some issues. I will just mark them briefly, because this article became bigger than planned. First of all I consider a good practice to use a single instance of each form rather than creating and disposing one every time. So I have lots of hidden forms on the visible area of the silverlight application and I show/hide them according my needs. To pass data between forms I use events and stick the data in the args.
Also data can be shared between forms across the whole application by using Application.Current.Resources dictionary.

I hope you can get something valuable from this long and boring article :)

11.02.2010 г.

Back again...

Hello there,
it's been a while since I last posted on my blog. The reasons of course are many. First of all I didn't knew that somebody's actually reading my posts. So I was quite surprised when I read some comments on my older posts. Also I was glad, yes you got me right, glad when I saw the typical russian spam. That was to tell me that my blog is already indexed by Google. Hooray!

From now on I promise myself to write much more. Not that I'm some kind of software GURU and my post have a tremendous influence to the community, but I find it good to share some of my modest experience with the software technologies I work with and also some of the thoughts that my head gives birth of, before they are irretrievably gone.

So, I thought that now is the time to put some lines of text on my latest work experience. Also I'm now stuck for a week at home, sick, sniveling and quite bored. Sometimes I ask myself whether I prefer to be busy or to relax. And I always hate the answer, cause sadly resting I take now as wasting my precious time.

I'm working lately on a silverlight project and that gave me the opportunity to understand silverlight more deeply. Also I use Blend for a designer tool cause Visual Studio lacks a silverlight designer. I'm planning 2 post on that, one on silverlight and another one on Blend 2 and Blend 3.
Also I'm planning to write a substantial article about my opinion on what is going on in my home country Bulgaria. Of course it will be "hater like" one, cause things are getting worse and worse.