SilverlightShow: Developing Silverlight Analog Clock - pattern oriented approach Comments

Re: Developing Silverlight Analog Clock - pattern oriented approach

nevin — Fri, 13 Apr 2012 12:36:26 GMT

MERHA.. ÇOK GÜZEL..

RE: Developing Silverlight Analog Clock - pattern oriented approach

Maurice Calvert — Wed, 04 Aug 2010 14:41:54 GMT

Refreshingly well written. Many thanks.

RE: Developing Silverlight Analog Clock - pattern oriented approach

Piyush Sheth — Tue, 15 Jun 2010 21:43:14 GMT

Really good one !!!

open my wing towards silverlight.

RE: Developing Silverlight Analog Clock - pattern oriented approach

Saranyan Yethirajam — Mon, 08 Mar 2010 08:06:47 GMT

Awesome article

RE: Developing Silverlight Analog Clock - pattern oriented approach

Chris — Sun, 29 Nov 2009 22:47:55 GMT

Hi,

This is very nice.

Could you describe how to handle GUI events, such as Button clicks?

Thanks

Chris.

RE: Developing Silverlight Analog Clock - pattern oriented approach

Sergey — Fri, 20 Nov 2009 23:18:36 GMT

> Silverlight is not allowed to bind to an object which is not a FrameworkElement. While in WPF this is allowed. I think that is a lame limitation and it is too strange for me.

There some changes in data binding in Silverlight 4 beta documentation:

The target can be any DependencyProperty of a FrameworkElement. The target can also be a DependencyProperty of a DependencyObject in the following cases:

The DependencyObject is the value of a property of a FrameworkElement.
The DependencyObject is in a collection that is the value of a FrameworkElement property (for example, the Resources property).
The DependencyObject is in a DependencyObjectCollection(T).

RE: Developing Silverlight Analog Clock - pattern oriented approach

Sergey — Wed, 18 Nov 2009 23:58:28 GMT

Hi Pencho!

Thank you for good explanation of MVP pattern. It's clear but situation is changed when an application has more than one Views and Models, then Presenter becomes too complicated. I've never used MVP but I've tried to use MVC and I think they have much in common with each other. But finally, when the Controller became too complex, I decided to reconstruct my application with MVVM pattern and I'm still happy along with it. May be I've left out something and MVC/MVP are good enough too, but I'm still a naive designer and I'm learning by making mistakes. And I haven’t read your other articles about patterns – may be I’ll change my mind.

Anyway I've translated you article for silverlight.su for Russian as well as some of your other articles because I hope it'll be useful for others and I hope you won't mind.

I have a question: why you allow “set” mutator in this code:

public ClockData ClockData
{
      get
      {
            return this.clockData;
      }
      set
      {
            this.OnClockChangind( new ClockDataEventArgs( this.clockData ) );

            this.clockData = value;

this.OnClockChanged( new ClockDataEventArgs( this.clockData ) );
}
}

I think it is not a good idea because you use OnClockChaning and OnClockChanged methods in two placed. So you could delete mutator and use:

clockModel.ClockData.Update( DateTime.Now );
instead of:
clockModel.ClockData = new ClockData().Update( DateTime.Now );

---------

Regards, Sergey

RE: Developing Silverlight Analog Clock - pattern oriented approach

Divyesh Sharma — Sat, 14 Nov 2009 21:33:47 GMT

Nice article and fresh use of code. It has given me a new direction of light in silverlight as i was in dark about this topic

RE: Developing Silverlight Analog Clock - pattern oriented approach

pashute — Wed, 22 Jul 2009 16:59:01 GMT

I wonder if anyone at Microsoft read your concluding comment... They are advertising this article on the sliverlight blog!

RE: Developing Silverlight Analog Clock - pattern oriented approach

ppopadiyn — Tue, 24 Feb 2009 00:47:23 GMT

Hi Blueling,

First I would like to thank you for the nice words. Yes, sometimes I am very frustrated with the lack of functionality in Silverlight. Looking for "work-arounds" is a very common task when developing Silverlight application. But I think this is normal, however Silverlight is only second version and it is at the beginning of its development. I think we have a wrong practice to compare Silverlight with WPF. I am sure the next version of Silverlight will be much better, and I lot of the problems will be solved.

RE: Developing Silverlight Analog Clock - pattern oriented approach

blueling — Sun, 22 Feb 2009 15:16:28 GMT

> Silverlight is not allowed to bind to an object which is not a FrameworkElement. While in WPF this is allowed. I think that is a lame limitation and it is too strange for me.

I have just gone through the same experience as you ... there are so many data binding things that do work in WPF that do not in Silverlight.. either the browser crashes or you get "Attribute {StaticResource xyz} value is out of range"...

That data binding does not work on anything than FrameworkElement is an absolute catastrophe for Silverlight. How fine would it have been to create things like the clock minute markes with a ListBox that uses a Canvas as ItemsPanel and TranslateTransform and RotateTransform to place the bars ... binding to a list of 60 doubles.

I really hope the next Silverlight version will allow a broader usage of data binding. Also it is a pitty that they did not come up with something like x:Array .. most of the collection classes that ship with the SL framework are Generics which cannot be instanciated in a ResourceDictionary in XAML...

Excellent article btw... like the even better looking clock from your other post also very much!

RE: Developing Silverlight Analog Clock - pattern oriented approach

ppopadiyn — Fri, 13 Feb 2009 02:40:49 GMT

Hi Simon,

Sorry for the inconvenience, I will replace the rar archive with zip

RE: Developing Silverlight Analog Clock - pattern oriented approach

Simon — Fri, 13 Feb 2009 01:07:23 GMT

Why use rar ? why not zip ... then we can all unzip for free ....

RE: Developing Silverlight Analog Clock - pattern oriented approach

Miki — Wed, 19 Nov 2008 15:36:00 GMT

Hi!

First of all thanks for the post it was the best sample about the M-V-P pattern that i found over the net. But i have a doubt about it.

I would like to know why in the presenter class, a delegate is used to answer to the model changes (instead of using directly this.ClockView.Update(e.ClockData) ) and why a direct acces to the model.Start() (instead of using a delegate) is used to anwer the view changes.

Is it just to show us both ways or it has a real meaning that i am missing?

Thanks again for everything

RE: Developing Silverlight Analog Clock - pattern oriented approach

ppopadiyn — Wed, 19 Nov 2008 15:27:36 GMT

Hi Miquel

I am happy that you find the article useful. About your question, there isn't any secret meaning that you are missing. In the classical form of the M-V-P pattern the situation is exactly the same as you have described. The presenter update the view directly (without using delegate), and also the presenter must be attached to the Start event of the IView interface and when the event fires then he calls model.Start(). I can't remember for any valid reason that has forced me to use that approach, maybe just for experiment.

RE: Developing Silverlight Analog Clock - pattern oriented approach

Miquel Salvà — Wed, 19 Nov 2008 14:57:31 GMT

Hi!

First of all thanks for the post it was the best sample about the M-V-P pattern that i found over the net. But i have a doubt about it.

Is it just to show us both ways or it has a real meaning that i am missing?

Thanks again for everything

COOL

David — Wed, 12 Nov 2008 14:05:43 GMT

THATS SIMPLY AMAZING, GOOD ARTICLE, I WANNA BE AS U!!!

RE: Developing Silverlight Analog Clock - pattern oriented approach

ppopadiyn — Thu, 06 Nov 2008 09:22:18 GMT

Hi paulo_fg@hotmail.com

It is not possible to see the current application under Linux. In order to see it you should install Moonlight and to build the sample for Moonlight. Moonlight is an open source implementation of Silverlight, primarily for Linux and other Unix/X11 based operating systems.

In September of 2007, Microsoft and Novell announced a technical collaboration that includes access to Microsoft's test suites for Silverlight and the distribution of a Media Pack for Linux users. The main goals of that collaboration are:

To run Silverlight applications on Linux.
To provide a Linux SDK to build Silverlight applications.

I am not a Linux fan and I am not capable to give you more specific information how to do that.

RE: Developing Silverlight Analog Clock - pattern oriented approach

paulo_fg@hotmail.com — Thu, 06 Nov 2008 07:23:12 GMT

why i cant view this in linux?

RE: Developing Silverlight Analog Clock - pattern oriented approach

ppopadiyn — Thu, 06 Nov 2008 02:55:54 GMT

Hi Tom

Thank you for the nice words. I am very happy you find my article useful. If you have any ideas or wishes for future pattern oriented articles, do not hesitate to share them with me. :)

RE: Developing Silverlight Analog Clock - pattern oriented approach

Andi X — Thu, 06 Nov 2008 02:08:44 GMT

That's

RE: Developing Silverlight Analog Clock - pattern oriented approach

ppopadiyn — Wed, 05 Nov 2008 15:28:33 GMT

Hi Bill

Thanks for the comment. The initial idea of the article was introducing the MVP pattern, and the clock is just a simple example, a concrete realization of the MVP. Of course I agree in the real world using MVP or MVC for simple applications is not appropriate and as you said it is an overkill. This leads to needless complexity - a symptom, which frequently happen when developers anticipate changes to the requirements and put facilities in the software to deal with those potential changes. Preparing for future changes should keep our code flexible and prevent nightmarish changes later. Unfortunately sometimes the effect is not what we expect. By preparing for many contingencies, the design becomes littered with constructs that are never used. Some of those preparation may pay off, but many do not. Also that the design carries the weight of these unused elements. All these make the software difficult for understand and complex.

But for advance solutions using that pattern can have great benefits. Really I didn't mention when to use the MVP and when not to use it. I think it is a matter of experience. Everyone should experiment with it.

I will give you a simple example from my experience. Currently I am a part of a team working over a WinForms application for customers from Holland. A very small module of the application was initially intended only for create, read, update and delete data operations (also known as CRUD - a major part of nearly all computer software). That part has been developed before I join to the team and was based on the classical approach - using DataSet, BindingSource, DataRowView, DataBinding.... etc. Everything was perfect until the last 2 months when numerous issues about that module was coming from the clients. All of the issues included implementation of a custom domain logic. I started resolving them one by one mixing the bussiness logic with the user interface (attaching events, adding validation, some calculations....). Suddenly I was faced in a situation where I was asked to make what appears to be a simple change. I looked the change over and made a reasonable estimate. But later when started implementing the change, I found myself chasing changes through huge portions of code, modifying far more functions and classes. Of course the result was "It was too complicated than I thought". After some sleepless nights changing the whole module, removing all bindings and implementing the MVP pattern, my life now is little more easier :)

RE: Developing Silverlight Analog Clock - pattern oriented approach

Bill Sithiro — Wed, 05 Nov 2008 13:52:18 GMT

With all due respect to your article (I think it's a very good MVC induction) but in the particular context you're using it, I think it’s overkill! I know you're just experimenting but it's important for new developers reading this to also understand when it's a good idea to use a particular OOP pattern and when it's not. In your analog clock example, this should simply be a reusable control with styling/templating capabilities for designers to play with (background, hands etc.) or even throw in a project themselves. This at least is the Silverlight way. Any extensions to the clock like stopwatches as you mentioned are nothing more than subclasses of the clock control. But I’m sounding a little too criticizing and that’s not my intention, just my personal thought... Keep it up!

Bill Sithiro

RE: Developing Silverlight Analog Clock - pattern oriented approach

Tom Kinser — Wed, 05 Nov 2008 11:58:16 GMT

Excellent example! It is direct and concise. I am a trainer and would love to use this as an example of how MVP and XAML should be done. Please keep writing...

RE: Developing Silverlight Analog Clock - pattern oriented approach

Mina Saad — Wed, 05 Nov 2008 03:39:41 GMT

very cool illustrating application and very organized topic , keep Going

RE: Developing Silverlight Analog Clock - pattern oriented approach

Naveen — Wed, 05 Nov 2008 00:34:44 GMT

Hi this is Naveen...Excellent!!! Gud Job....keep posting such articles...really usefull for ppl like me who are new this Light.

RE: Developing Silverlight Analog Clock - pattern oriented approach

ppopadiyn — Wed, 05 Nov 2008 00:25:09 GMT

Hello guys

Thanks for the nice words. That was my first real Silverlight project and i was worried about the result. I will keep working harder and plan soon to post a second article about the clock with some improvments and also another patern oriented article with a practicle example. If you have any suggestions about future articles, do not hesitate to share them with me as comments, thanks again for the nice words.

RE: Developing Silverlight Analog Clock - pattern oriented approach

Dave — Tue, 04 Nov 2008 20:25:34 GMT

Really well done article - thanks!

RE: Developing Silverlight Analog Clock - pattern oriented approach

Rajesh Lal — Thu, 30 Oct 2008 10:46:39 GMT

awesome article keep up

RE: Developing Silverlight Analog Clock - pattern oriented approach

davidjjon — Thu, 30 Oct 2008 10:33:14 GMT

Very well done - thank you for sharing this.

David Roh