Merci à Microsoft de me renouveler une septième fois sa confiance et c’est toujours avec plaisir que j’apprécie partager mes aventures .NET avec vous.

J’en profite pour vous souhaiter une très bonne année, en espérant que vous avez eu plein de Windows Phone 8 sous le sapin

j’ai le plaisir de vous annoncer la sortie de mon livre, que j’ai écrit en partenariat avec le site du zéro.

Il s’agit d’un livre permettant d’apprendre le C#. Il est orienté débutant dans la mesure où vous avez juste besoin de savoir allumer un PC pour le suivre.

Au menu :

• Qu’est-ce que la programmation ? Quel langage choisir ? Pourquoi C# ?
• Installez Visual C# 2010 Express (gratuitement) et écrivez votre premier programme
• Apprenez à manipuler les variables, les méthodes, les boucles…
• Initiez-vous aux concepts de la programmation orientée objet
• Pratiquez grâce aux TP : créez un jeu, une application de gestion bancaire, un simulateur de météo…
• Connectez-vous aux bases de données avec Entity Framework
• Découvrez les applications que l’on peut développer en C#

Bref, plein de petites choses dans un style où on ne se prend pas la tête, pour vous permettre de démarrer dans l’apprentissage du C#, et tout en couleur !!

Voir le livre sur Amazon

Je reconnais que ce blog est de moins en moins mis à jour mais je vais essayer de me rattraper

Merci encore à Microsoft de me renouveler sa confiance. J’en profite au passage pour vous souhaitez à tous une bonne année, pleine de C# et de .NET.

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 ?

J’en profite pour vous souhaiter à tous une très bonne année 2011, qu’elle soit riche en projet de toutes sortes.

Dans un premier tutoriel, nous avons pu voir une introduction au développement WP7.
Dans le second, nous avons pu voir comment utiliser la ListBox et l’Isolated Storage.
Dans le troisième, vous avez pu découvrir comment utiliser le contrôle pivot, son système de swipe et comment accéder à des ressources sur le net.

Dans celui-ci, nous allons voir comment naviguer entre les pages d’une application Silverlight pour Windows Phone 7. Nous verrons également que le bouton « Back » du téléphone s’interface parfaitement avec le framework de navigation de Silverlight pour WP7. Nous verrons enfin comment faire passer des informations entre les pages.

http://nico-pyright.developpez.com/tutoriel/vs2010/csharp/windows-phone-seven/navigation-silverlight-wp7/

Bonne lecture

Dans un premier tutoriel, nous avons pu voir une introduction au développement WP7.
Dans le second, nous avons pu voir comment utiliser la ListBox et l’Isolated Storage.

Dans celui-ci, à travers la création d’une application de météo, vous découvrirez comment faire appel à des ressources sur le web. Vous verrez également comment utiliser le contrôle Pivot, un des contrôles les plus importants lors du développement d’applications pour Windows Phone 7. Il permet de gérer facilement la navigation horizontale, avec ce qu’on appelle le swipe et qui permet de simuler un comportement où l’utilisateur pose son doigt sur l’écran et le fait glisser vers la droite ou la gauche, comme s’il tournait une page.

http://nico-pyright.developpez.com/tutoriel/vs2010/csharp/windows-phone-seven/web-service-control-pivot-wp7-silverlight/

Bonne lecture

Dans un premier tutoriel, nous avons pu voir une introduction au développement WP7.

Dans ce deuxième tutoriel, vous découvrirez la puissance du contrôle ListBox WP7 et comment il s’adapte au développement sur téléphone.
Vous verrez aussi comment traiter des événements simples, comme un click sur un bouton par exemple.
Vous verrez enfin comment faire persister de l’information entre les différents démarrages du téléphone et lorsque l’application est suspendue.

http://nico-pyright.developpez.com/tutoriel/vs2010/csharp/windows-phone-seven/listbox-isolated-storage-wp7-silverlight/

Bonne lecture

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/

Après quelques recherches, je suis tombé sur cette page qui m’offre l’aglo tout cuit, mais sans son utilisation.

Je montre ici comment l’utiliser après une ou deux corrections de coquille dans l’algo trouvé.

Il faut dans un premier temps une matrice adjacente, qui peut être de cette forme :

   1: #define INFINI 10000

   2: #define NB_SOMMET 6

   3:  

   4: int mat[NB_SOMMET][NB_SOMMET] =  

   5:     {{ 0, 171, INFINI, INFINI, INFINI, INFINI},

   6:     {171,   0,  30, INFINI, INFINI, INFINI},

   7:     {INFINI,  30,   0, INFINI,  39,  13},

   8:     {INFINI, INFINI, INFINI,   0,  30, INFINI},

   9:     {INFINI, INFINI, 39,   30,   0,  26},

  10:     {INFINI, INFINI,  13, INFINI,  26,   0}};

On a une constante “Infini” qui est suffisamment grande, c’est à dire plus grande que la distance maxi entre 2 sommets. Et une matrice carrée contenant la distance entre chaque sommet.

Ensuite la méthode avec les 2-3 trucs corrigés :

   1: void dodijkstra(int sr,int ds, int path[])

   2: {

   3:     if (sr == ds)

   4:         return;

   5:  

   6:     struct node

   7:     {

   8:         int pre;   /* Predecessor */

   9:         int length; /* Length between the nodes */

  10:         enum {perm,tent} label; /* Enumeration for permanent and tentative labels */

  11:     }state[NB_SOMMET];

  12:         

  13:         int i,k,min;

  14:         struct node *p;

  15:         /* Initialisation of the nodes aka First step of Dijkstra Algo */

  16:         for(p=&state[0];p<&state[NB_SOMMET];p++)

  17:         {

  18:            p->pre= -1;

  19:            p->length=INFINI;

  20:            p->label=node::tent;

  21:         }

  22:         state[ds].length=0; /* Destination length set to zero */

  23:         state[ds].label=node::perm; /* Destination set to be the permanent node */

  24:         k=ds; /* initial working node */

  25:         /* Checking for a better path from the node k ? */

  26:         do

  27:         {

  28:            for(i=0;i<NB_SOMMET;i++)

  29:               {

  30:                   if(mat[k][i]!=0 && state[i].label==node::tent)

  31:                      {

  32:                         if((state[k].length+mat[k][i])<state[i].length)

  33:                            {

  34:                                state[i].pre=k;

  35:                                state[i].length=state[k].length+mat[k][i];

  36:                            }

  37:                      }

  38:               }

  39:              k=0;

  40:              min=INFINI;

  41:               /* Find a node which is tentatively labeled and with minimum label */

  42:               for(i=0;i<NB_SOMMET;i++)

  43:               {

  44:                  if(state[i].label==node::tent && state[i].length<min)

  45:                     {

  46:                         min=state[i].length;

  47:                         k=i;

  48:                     }

  49:               }

  50:               state[k].label=node::perm;

  51:         } while(k!=sr);

  52:         

  53:         i=0;

  54:         k=sr;

  55:         /* Print the path to the output array */

  56:         do 

  57:         {

  58:             path[i++]=k;

  59:             k=state[k].pre;

  60:         } while(k>=0);

  61:         path[i]=k;

  62: }

et enfin, l’appel de la méthode :

   1: int path[150];

   2: for (int z = 0 ; z < 150 ; z++)

   3:     path[z] = -1;

   4: dodijkstra(sommetSource, sommetDestination, path);

On initialise le tableau de résultat. Ici j’ai pris 150 arbitrairement, le but est que le tableau puisse contenir toutes les étapes intermédiaires.

L’algorithme nous rempli le tableau avec le trajet optimal.

path[0] contiendra la source
path[i] contient les différents sommets intermédiaires
path[n] contient la destination
path[n->150] contient -1

Simple et efficace !