Catégorie: Silverlight

J’ai lu il y a quelques temps un billet d’Olivier Dahan où, par un titre accrocheur, il proposait son retour d’expérience sur MVVM en proposant de bruler le pattern (voir http://www.e-naxos.com/Blog/post/2011/05/20/Faut-il-bruler-la-pattern-MVVM-.aspx)

Comme ca fait quelques temps que je n’ai pas écrit de billet et que j’ai envie de partager mon expérience sur le sujet, j’en profite

Je suis globalement d’accord avec lui, respecter tout MVVM n’est pas forcément toujours judicieux. Il faut l’adapter aux besoins de l’application.

En général, j’adapte mon utilisation de MVVM en fonction de l’application que je crée. Par contre, aujourd’hui, je ne concevrai pas de créer une application sans MVVM.

Je trouve que le découplage est beaucoup plus clair et j’ai remarqué pour ma part que j’écris plus rapidement mon application en utilisant un viewmodel qu’en utilisant le code behind. De même, un ressenti totalement subjectif et pifométrique me fait trouver que je fais moins de bugs.

Donc, une application sans mvvm ? non. Maintenant que j’y ai gouté, je ne peux plus m’en passer. Par contre, suivant l’application, je respecte plus ou moins le pattern.

Je trouve qu’un des valeurs ajoutées du pattern est qu’il force à utiliser le mécanisme de binding. Il est trop tentant (pour aller vite) de faire du monTextBlock.Text = “…”.

Pour moi ca n’apporte rien, à part des bugs

J’ai vu trop de gens ne rien comprendre au binding et c’est bien dommage. Donc oui au binding, forcé par mvvm.

Je suis d’accord qu’on peut se demander vraiment l’utilité d’un locator et en général, pour une petite application rapide, je ne m’en sers pas. Par contre, je rajoute dès que possible l’utilisation des commandes, notamment grâce à la classe RelayCommand qu’on trouve dans MVVM-Light.

Il est vrai que pour une application rapide, pour un test ou autre, j’ai tendance à ne pas embarquer de dépendances (donc pas de RelayCommand ou autres systèmes de messagerie) et donc j’utilise le code-behind pour récupérer mon viewmodel et lancer les commandes. Ca créé un couplage, mais est-ce bien grave ?

Par contre, dès que l’application est un tant soit peu sérieuse, on ne peut pas s’en passer.

Je partage également le point de vue d’Olivier qui dit qu’on peut vite se perdre avec un système de messagerie (je n’utilise pas celui de MVVM-Light). J’ai l’impression de m’en sortir mieux maintenant en me fixant quelques règles de nommages, d’utilisation. Il est vrai qu’il n’y a pas de guidelines pour et qu’au démarrage on peut vite s’embrouiller… mais avec un peu de pratique, je trouve qu’on peut l’utiliser avec profit.

Les boites de dialogues ? Oui, c’est vrai, c’est casse-pied Mais comme j’ai tendance à ne pas trop en faire et plutôt à afficher des confirmations sous une autre forme, ca ne m’embête pas trop trop. Quand j’en ai besoin, le système de messagerie me rend bien des services.

Les tests unitaires ? J’ai beau être un adepte convaincu du testing, j’avoue ne pas m’en servir pour tester les viewmodels. Je préfère blinder la couche d’accès aux données ou la couche de service.

Dans un des commentaires, on peut lire une remarque sur la création de contrôles personnalisés remplies de DependencyProperty juste pour faire du MVVM qui, pour le commentateur, est un problème. Il est vrai que créer des contrôles utilisateurs juste pour ca, c’est un peu dommage. Par contre, dans certains cas, je trouve que ca apporte un découplage complémentaire et offre une réutilisabiilté. Certains behavior sont tout à fait pertinent.

Bref, voici mon retour d’expérience.

En conclusion : Oui pour MVVM, il faut dans un premier temps faire dans l’extrémisme pour pouvoir comprendre et apprécier les avantages du patron de conception et ensuite y revenir et l’adapter vraiment au besoin.

Et vous ? Votre expérience ?

Windows Phone 7 (WP7) est la nouvelle plateforme de développement de Microsoft destinée aux smartphones.

Dans ce premier tutoriel, vous découvrirez comment démarrer le développement d'applications avec Windows Phone 7.
Nous commencerons par installer les outils nécessaires au développement sur WP7 puis nous créerons un premier programme simpliste en utilisant Silverlight pour WP7.
Enfin, nous l'exécuterons sur l'émulateur et découvrirons son fonctionnement.

Bonne lecture : http://nico-pyright.developpez.com/tutoriel/vs2010/csharp/windows-phone-seven/introduction-developpement-windows-phone-seven-wp7-silverlight/

Je vous présente mon dernier article : Utilisez le pattern Model-View-ViewModel dans vos applications Silverlight grâce à MVVM Light toolkit

Cet article constitue une introduction au développement d'applications Silverlight en utilisant le design pattern M-V-VM grâce au MVVM Light Toolkit de Laurent Bugnion.

Bonne lecture

Pour faire un TextBlock multiligne, on va devoir utiliser la collection Inlines du contrôle. On y ajoutera des sections discrètes de texte (Classe System.Windows.Documents.Run), ainsi que des sauts de lignes (Classe System.Windows.Documents.LineBreak).

Ainsi, on peut imaginer 2 méthodes d'extensions qui font ca :

» Lire la suite!

Je vous présente ici une solution pour envoyer des fichiers grâce à Silverlight sur un serveur PHP. Vous y trouverez notamment comment créer un web service avec NuSOAP afin de réaliser cet upload.

Aller consulter l'article

Je vous présente ici un article qui propose une solution pour utiliser Silverlight avec une base de données MySql. On y verra également quelques utilisations des composants de Silverlight.

Bonne lecture

Il peut être utile de copier des valeurs dans le presse papier, par exemple un lien ou une adresse email afin de l'utiliser dans son navigateur favori.

Pour ce faire, on va utiliser l'objet javascript clipboardData et invoquer la méthode setData :

var pressePapier = (ScriptObject)HtmlPage.Window.GetProperty("clipboardData"); 
 if (pressePapier != null) 
 { 
  if ((bool)pressePapier.Invoke("setData", "text", "http://wwww.developpez.com")) 
  HtmlPage.Window.Alert("Envoi au presse papier OK"); 
  else 
  HtmlPage.Window.Alert("Erreur d'envoi au presse papier"); 
 }

NB : le retour de la méthode Invoke étant un type simple, on peut le caster directement en ce type (ici, bool)

Prenons un exemple, j'ai un objet composé de 2 strings dans mon application. Ces deux strings représentent des entiers. Je veux les passer à une fonction javascript qui me renverra un objet composé de 2 entiers contenant la mise au carré des valeurs contenues dans le premier objet.

Pour ce faire, on va créer nos deux objets en C# coté Silverlight en utilisant l'attribut ScriptableMember.

» Lire la suite!

Prenons cette fonction javascript qui change la visibilité d'un élément, elle est déclarée dans votre page ASPX comme suit :

<script type="text/javascript"> 
function setDisplayDiv(id, visible) 
{ 
  var o; 
  if (document.getElementById) 
  o = document.getElementById(id).style; 
  else if (document.layers) 
  o = document.layers[id]; 
  else if (document.all) 
  o = document.all[id].style; 
  if (o) 
  o.display = (visible ? 'block' : 'none'); 
} 
</script>

» Lire la suite!

En utilisant le DOM.
Soit par exemple l'extrait de page ASPX suivant :

<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager> 
<div style="height:100px"> 
  <asp:Silverlight ID="Xaml1" runat="server" Source="~/ClientBin/monApplication.xap" MinimumVersion="2.0.30523" Width="100%" Height="100%" /> 
</div> 
<div id="result"></div>

qui contient un controle <asp:Silverlight> et un <div> identifié par son id : "result"

» Lire la suite!

En utilisant le web control <asp:Silverlight>.

Par exemple :

<asp:Silverlight ID="Silverlight1" runat="server" Source="monApplication.xap" Version="2.0" Width="400" Height="300" />

Il faudra bien sur avoir défini le tag au préalable :

» Lire la suite!