C#

C#

S’interfacer avec une Sphèro en remote avec NancyModule

 

using SpheroNET;

using System;

using System.Collections.Generic;

using System.Drawing;

using System.Linq;

using System.Text;

namespace SpheroConsole

{

public class SpheroModule : Nancy.NancyModule

{

static SpheroConnector spheroConnector = new SpheroConnector();

static Sphero sphero = null;

public SpheroModule()

{

Get[« / »] = _ =>

{

string s = « Novencia TS – WebSphero Proxy<br><br> »;

s += « Command List :<br/> »;

s += « <b>find<b> – Get port id Bluetooth devices<br/> »;

s += « <b>connect/{port}<b> – Connect to the given port id (see find)<br/> »;

s += « <b>sleep<b> – Sleep the Sphero<br/> »;

s += « <b>close<b> – Close the Sphero communication<br/> »;

s += « <b>setrgb/{red}/{green}/{blue}<b> -Change Sphero color<br/> »;

return s;

};

Get[« /find »] = _ =>

{

spheroConnector.Scan();

var deviceNames = spheroConnector.DeviceNames;

string result = «  »;

for (int i = 0; i < deviceNames.Count; i++)

{

result += string.Format(« {0}: {1}<br/> », i, deviceNames[i]);

}

return result;

};

Get[« /connect/{port} »] = PortFinder;

Get[« /close »] = _ => { spheroConnector.Close(); return « OK »; };

Get[« /sleep »] = _ => { sphero.Sleep(); return « OK »; };

Get[« /setrgb/{red}/{green}/{blue} »] = SetRGBColor;

Get[« /setrgb/{colorName} »] = SetRGBColor;

Get[« /goroll/{h}/{s}/{g} »] = Goroll;

Get[« /goroll/{h}/{s}/{g}/{d} »] = GorollWithDelay;

Post[« / »] = _ => « Hello world! »;

}

public string Goroll(dynamic o)

{

int h, s, g;

if (!int.TryParse(o.h, out h)) throw new Exception(« Invalid parameter »);

if (!int.TryParse(o.s, out s)) throw new Exception(« Invalid parameter »);

if (!int.TryParse(o.g, out g)) throw new Exception(« Invalid parameter »);

var programLines = new List<string>();

programLines.Add(« 10 basflg 1\r »);

programLines.Add(string.Format(« 20 goroll {0},{1},{2}\r »,h,s,g));

var area = StorageArea.Temporary;

sphero.EraseOrbBasicStorage(area);

sphero.SendOrbBasicProgram(area, programLines);

sphero.ExecuteOrbBasicProgram(area, 10);

return « OK »;

}

public string GorollWithDelay(dynamic o)

{

int h, s, g, d;

if (!int.TryParse(o.h, out h)) throw new Exception(« Invalid parameter »);

if (!int.TryParse(o.s, out s)) throw new Exception(« Invalid parameter »);

if (!int.TryParse(o.g, out g)) throw new Exception(« Invalid parameter »);

if (!int.TryParse(o.d, out d)) throw new Exception(« Invalid parameter »);

var programLines = new List<string>();

programLines.Add(« 10 basflg 1\r »);

programLines.Add(string.Format(« 20 goroll {0},{1},{2}\r », h, s, g));

programLines.Add(string.Format(« 30 deelay {0}\r », d));

var area = StorageArea.Temporary;

sphero.EraseOrbBasicStorage(area);

sphero.SendOrbBasicProgram(area, programLines);

sphero.ExecuteOrbBasicProgram(area, 10);

return « OK »;

}

public string SetRGBColor(dynamic o)

{

byte r, g, b;

try

{

r = byte.Parse(o.red);

g = byte.Parse(o.green);

b = byte.Parse(o.blue);

}

catch

{

string name = o.colorName;

Color c = Color.FromName(name);

r = c.R;

g = c.G;

b = c.B;

}

sphero.SetRGBLEDOutput(r, g, b);

return « OK »;

}

public string PortFinder(dynamic o)

{

int index = -1;

if (int.TryParse(o.port, out index))

{

if (o.port < 0) return « invalid parameter »;

try

{

sphero = spheroConnector.Connect(index);

return « OK »;

}

catch (Exception ex)

{

return ex.Message;

}

}

else

{

return string.Format(« ‘{0}’ is not a valid device index. », o.port);

}

}

}

}

 

WinRT ou le retour en force du COM+

J’ai voulu ajouter « Lol » à la fin du titre de ce lien, mais il paraît que ça ne se fait pas.

On retrouve plein d’articles sur le NET nous parlant de WinRT, des incidences lorsqu’on doit développer en C#.
Je vous propose donc ce petit post, non pas pour vous parler de WinRT mais plutôt pour vous parler de COM(+) et vous expliquer ce choix, qui semble hasardeux, de Microsoft.

Tout d’abord, un petit rappel.

Observez le schéma de l’article, il a fait le tour du monde. Avec Windows 8, il y a deux façon de considérer Windows. La première en mode WinRT (partie de gauche), l’autre en mode desktop (partie de droite).

En mode WinRT, on vise un nouveau type d’application dites « Metro style Apps », dénomination valable jusqu’en août 2012 date où l’on appris que le terme était déposé et sujet à copyright. On parle désormais d’application ModernUI (ou Windows 8 style)
En mode Desktop, on développe classiquement, C++, C#, VB.NET, Assembleur

Beaucoup de développeurs .NET ont espéré, comme Java en son époque, que Windows allait devenir « CLR ». En d’autres termes, l’OS serait une grande machine virtuelle, on gagnerait en simplicité tout en se débarrassant de ces bonnes vieilles API Win32.

Mais que faire alors des anciennes applications justement Win32 ? Il aurait suffit de les virtualiser ! On le fait déjà quelque part pour faire fonctionner les applications 32bits (et même 16 bits!) sur du Windows 64 bits (merci WoW64^^). Développer une application tournant dans l’OS/CLR, qui émulerait les API Win32 et ferait fonctionner toute application non .NET dans cette Sandbox ! Simple ,non ?

Oui mais voilà, ce n’est absolument pas ce que Microsoft a fait ! Mais allons donc ? Pourquoi ? C’était si simple !

Disons que ce n’est pas parce qu’une chose a l’air simple en apparence qu’elle l’est dans les fait. Tout d’abord, au risque de passer pour un dinosaure, il faut savoir que depuis fort longtemps tout Windows est COM… ou DCOM… Enfin COM+. De quoi je parle ? Du fait que peut après l’apparition de la base de registre (Windows 95), Microsoft a planché sur des vrais soucis de communication inter logiciel : faire en sorte qu’un copier/coller fonctionne entre un Word et un Excel et mieux, que les logiciels échangent des comportements en temps réel (exporter un tableau Excel dans Word par Exemple). Microsoft a commencé par une technologie type OLE (Object Linking and Embedding) qu’ils ont rapidement muté en composant ActiveX et composant COM : les composants ActiveX étant « visuel » (comme une applet Java), les composants COM étant eux des composants sans interface.

Il faut imaginer dès l’époque que tout était bien pensé. On parlait de composants comme au sens moderne. Car à la différence de l’objet qui tourne dans un processus, le composant a une sorte d’existence propre, des entrées et des sorties (je vous passe les histoires de surrogate chez Microsoft^^). Vous avez bien lu ! J’ai fait un raccourci, mais un objet est une représentation binaire qui n’a de sens que dans son process ! Le composant, lui, existe en dehors !
Pour ces raisons, lorsque vous faites du WCF, vos objets exposés peuvent et même doivent prendre la dénomination de composants. Idem pour COM+, ce bon vieux CORBA (certes, on parle d’IOR pour des références d’objets interopérable à distance, mais la vision externe est un « composant »), CCM (pour ceux qui connaissent) et surtout les EJB !

OLE/COM date des années 1995… Et fut transformé en DCOM vers 1998 (Le D signifiant Distributed), technologie permettant d’appeler les composants COM à partir d’un autre ordinateur puis renommé COM+ dès les années 2000. COM+ est le mix de DCOM et d’une technologie transactionnelle (MTS – Microsoft Transaction Server) développée par Microsoft dans l’optique de concurrencer CORBA et ses service OTS (Object Transaction Service). Il faut imaginer MTS comme le service JTS de JEE, où la partie transactionnelle des EJB stateless (avec un peu de stateful mais avec des limitations beaucoup plus forte), où bien encore du WCF avec des TransactionFlow et autres TransactionScopeRequired configurés.

Quand .NET est apparu, il fut vanté par rapport à COM+ pour sa simplicité. Il ressemblait à Java, finit les DLL Hells (ou l’enfer des DLL car COM+ exigeaient des inscriptions en base de registre, le versioning était très compliqué).

Sauf que COM+, tandis que .NET évoluait, a énormément évolué de son côté… notamment en se débarrassant de l’obligation d’aller en base de registre… mais également en améliorant le versionning, la possibilité de faire du side-by-side, etc.

Le choix de faire du WinRT en « COM-like » est beaucoup plus logique qu’il n’y parait. Contrairement aux apparences, C++ ne peut pas être concurrencé par des technologies à base de VM sur un ordinateur. Tout simplement parce que, même si pour bon nombre de projets de gestion c’est suffisant, la performance ultime ne peut être atteinte qu’en se calant le plus possible à la machine : RAM, disques, processeurs, CPU et registres.
Pour ces raisons, Microsoft a fait évoluer son OS dans le bon sens, le rendant multiplateforme (bienvenue aux processeurs ARM) tout en faisant évoluer C++ !

Mais il ne faut pas se tromper. Quand on cible WinRT en C++, on développe en C++/CX (Component Extensions) comme l’on développait en C++/CLI (Common Language Infrastructure) lorsqu’on ciblait la CLR. Ca c’est la façon qui arrange tout le monde. C++ dans le même sac que C#, VB.NET, Javascript, etc… car c’est juste un autre langage, on ne gagne rien.

Demeure pour le puriste, que l’on peut faire du WRL (Windows Runtime C++ Library) ! WRL c’est l’équivalent d’ATL (Active Template Library) en COM+ ! Débarrassé de pratiquement tout, on attaque les choses sérieuses et on a latitude pour réaliser des appels à l’OS… d’un autre monde ;-)

Toutefois, même si je suis un aficionados d’ATL, et donc de WRL, je ne le recommande absolument pas en situation projet, à moins d’y être fortement contraint (pour des raisons de performances notamment, ou bien parce que vous développer un composant hyper technique). Car cela demande énormément de compétence et s’avère très difficile à la maintenance !