Wpf Threads

Les aplicacions amb WPF tenen dos threads d’execució: un per renderitzar i l’altre és el de tota la vida, el que crea els controls, el que accepta les entrades, el que executa els events,… Però aquesta vegada han volgut donar un nom a aquest Thrad. Dispatcher.

Dispatcher és el nom que han donat al thread UI i és des d’aquest objecte que podem invocar els mètodes necessaris per actualitzar els controls UI des de threads secundaris. També controla i gestiona tots els problemes de seguretat i sincronització que pot tenir el thread UI.

El Timer de Windows.Forms ara és el DispatcherTimer. Aquesta classe té el mateix event Tick.

Realment és molt útil i fàcil d’entendre.

NavigationWindow a les aplicacions Windows

WPF ens ofereix un tipus de window que permet la navegació. Aquesta navegació pot ser de pàgines web com si d’un navegador iexplorer es tractés o cap a altres window que tinguem al nostre projecte.

Les window que permeten navegació son les NavigationWindow. Aquest element navega per Page o PageFunction<T>.

Una Page és un element que pot tenir les mateixes prestacions que una Window però que permet la navegació. Les PageFunction<T> son com les Page però tenen la particularitat que podem retornar un valor com si es tractés d’una crida a un mètode.

Les aplicacions que podem tenir amb aquests elements és la de construir wizards o aplicacions de windows on minimitzem el numero de finestres que obrim i tanquem, millorant així l’experiència de l’usuari.

Microsoft Expression als cursos de WPF

Aquesta setmana que entrarem faré un curs de WPF a distància utilitzant la tecnologia Adobe Connect que ja he parlat aquí.

WPF és una tecnologia que personalment m’agrada molt per la potència gràfica que té i per la facilitat que hi ha de separar el disseny del codi a les pantalles de les nostres aplicacions.

Aquesta separació permet que les pantalles es puguin dissenyar amb el Microsoft Expression. Suite de Microsoft on hi trobem l’Expression Design per poder crear imatges vectorials i tractar-les, l’Expression Blend per poder dissenyar les pantalles dels nostres projectes WPF o Silverlight i l’Expression Web per dissenyar les pàgines ASP.NET.

L’Expression Blend és una bona eina per poder dissenyar les nostres pantalles, donar-l’hi les animacions i els tractaments dels events.

Però la pregunta que em faig és: Cal fer-l’ho servir en un curs de WPF? és a dir, per ensenyar com crear les pantalles wpf és millor fer-ho amb una eina visual i opaca com és el Blend o és millor ensenyar la sintaxi XAML, fer alguns exemples i que a partir d’això ells utilitzin el Blend.

La meva opció sempre ha sigut que és millor ensenyar XAML ja que és la base per entendre l’eina de disseny i el perfil dels alumnes que tinc (programadors) penso que així ho volen.

Espero no estar equivocat, tu què opines?

DockPanel o StackPanel

En el moment que programem amb XAML sempre apareix la necessitat d’utilitzar un Panel que d’una manera senzilla ens col·loqui els elements un al costat de l’altre.

En un primer moment pensem en l’StackPanel ja que és un Panel molt senzill que col·loca els elements un a sota a l’altre o un al costat de l’altre depenent del valor que l’hi donem a la propietat Orientation.

El problema és quan volem que l’ultim element col·locat ocupi tot l’espai que resta en el Panel, és a dir, que no es vegi cap posició buida.

L’StackPanel és un Panel massa senzill i no controla aquesta propietat. La solució passa en utilitzar el DockPanel. Aquest control col·loca els elements segons les coordenades: Top, Left, Right, Bottom o Center. En un primer moment sembla que no hagi d’ajudar massa, però no és així.

DockPanel té una propietat que es diu LastChildFill, que si el posem a True indica que l’ultim element col·locat ocupi tot l’espai restant.

Com ho hem de muntar? En el cas de l’StackPanel amb orientació horitzontal substituïm StackPanel per DockPanel i afegim l’atribut LastChildFill a True. Per cada element dins del ara DockPanel afegim l’atribut DockPanel.Dock=”Left”.

Avui he estat a Canadà

Aquest matí he anat a Canadà i he tornat, tot sense gastar masses diners ni patir massa fred.

Efectivament, he estat al consulat de Canadà de Barcelona però això no em treu poder dir que he estat oficialment 5 hores a Canadà.

5 hores impartint un curs d’Excel, tot i que no és la meva especialitat fer aquest tipus de cursos ja que els meus son d’aplicacions amb .Net i ara també amb Sharepoint, l’experiència d’anar al Canadà valia la pena.

L’experiència ha sigut bona, en un moment estàvem parlant català, castellà, anglès i francès a la mateixa sala.

Sharepoint 2010 as Developer

Ja he parlat del què penso del Sharepoint en altres posts (aquest i aquest altre) i ho he fet des del punt de vista d’un usuari final, és a dir, el que ha de fer ús de l’eina.

Ja quedava clar en aquests posts que el Sharepoint és una eina molt complerta i funcionalment molt potent.

Ara vull parlar com un desenvolupador d’aplicacions per Sharepoint. Porto uns mesos treballant amb aquesta eina i experimentant amb les coses que es poden fer amb el Visual Studio 2010. N’estic totalment encantat de tot el potencial que té. (una vegada més)

El Visual Studio 2010 porta integrat plantilles de projecte per el Sharepoint 2010. Per tant, ens facilita molt la feina alhora de crear web parts, application pages, content pages, content types, List definitions, etc. Acabo d’enumerar algunes de les coses que es poden arribar a desenvolupar amb el Visual Studio per el Sharepoint.

El Sharepoint amb el seu Client Obect Model podem interactuar amb els components de tot el site mitjançant classes. Disposa de WCF que per REST podem accedir a les dades del Site. Tant una cosa com l’altre ho podem fer per aplicació windows, per ASP.NET, Silverlight i Ajax.

S’acaba en què entrem en un entorn de programació propi que és el Sharepoint utilitzant les mateixes tècniques de programació que s’utilitza en aplicacions winforms, wpf, silverlight o asp.net.

Framework 4.0 Client Profile i la seva limitació amb el serveis d’autentificació

En el meu ultim post us he explicat la decisió que hem de prendre sobre la versió Client Profile o Full Versión en els .Net Framework i què hem de tenir present en el moment de fer-ho.

Ara em toca explicar una limitació que no té perquè ser interpretada en les especificacions oficials del Client Profile. Actualment estic desenvolupant una aplicació en WPF que inicialment s’executava tot en local. En aquell moment vaig prendre la decisió d’utilitzar el Client Profile doncs tampoc necessitava més i premiava el temps de descarrega i el temps d’instal·lació.

Però ara l’aplicació ha evolucionat i necessito que es connecti a una web des d’on es gestionen els usuaris. Per tant, passa a ser una aplicació com les d’avui en dia son iTunes, Spotify,… És a dir, una aplicació que treballa en local però que et permet connectar a la teva compta per poder tenir funcionalitats addicionals.

.Net 4 té una manera de treballar amb això que és utilitzant web service d’autentificació, de roles i de perfils ja integrats en les seves aplicacions ASP.NET. A més, les aplicacions en windows tenen la opció de poder utilitzar aquests serveis utilitzant mètodes molt senzills que t’aporten la gestió de l’autentificació en les teves aplicacions en windows, de manera, que també et gestionen les cookies d’autentificació.

Doncs aquesta última característica no és possible utilitzant el Client Profile. I on està escrit això?

Passar l’aplicació a Full versión no és cap problema, ho sé, el problema està amb totes aquelles persones que tenen instal·lada aquesta aplicació s’els hi haurà de fer un canvi de Framework.

També podria utilitzar mecanismes d’autentificació pròpis, però per experiència ser que això acaba sortint més car que canviar les versions de tots els usuaris.

Framework 4.0 Client Profile o Full Version

En el moment que engeguem un projecte amb .Net hem de prendre primer la decisió de quina versió de Framework utilitzarem. Aquesta decisió s’ha de prendre en base a les necessitats del projecte per un lloc i les necessitats de les persones a qui va dirigit per un altre.

És molt important tenir en compte les característiques que aporta cada versió del Framework per saber quins avantatges es pot tenir una respecte l’altre.

Un cop hem valorat i decidit la versió queda llavors decidir si es vol la Client Profile o la Full Version. Això passa des de la versió 3.5.

La Client Profile està pensada per instal·lar al client el mínim necessari per poder executar les aplicacions sacrificant algunes característiques. En el cas del .Net 4 podeu veure les diferències que hi ha a la pàgina oficial de Microsoft : .Net Client Profile

És important tenir clar si volem el Client Profile o no. Hem de tenir clar les diferències que hi ha entre un i l’altre.

Anem a veure quina diferència en quant a volum de l’instal·lable hi ha:

41 MB el .Net 4 Client Profile per x86 i x64

48 MB el .Net 4 Full version  per x86 i x64

És evident que per el volum de la descarrega no ho han fet. Doncs només hi ha una diferència de 7 MB.

Segons Microsoft és recomanable el Client profile quant es vol un instal·lable de poc volum i ràpid tenint present que les característiques sacrificades son:

  • ASP.NET
  • Avançades característiques de WCF
  • Proveïdor .Net per Oracle
  • MSBuild per compilar

Firefox adéu!

Vaig començar a descobrir Internet amb un navegador que es deia Netscape que era el millor que hi havia en aquells moments.

En els meus anys d’universitat estava de moda anar en contra del que treia Microsoft, mentre tots anàvem bojos darrera de les versions pirates de W98, i per tant ens agradava molt el Netscape ja que era en diferència superior al IExplorer d’aquella època, que si no recordo malament estava per el 3.X

Finalment Microsoft va comprar el motor de Netscape i va fer enfonsar aquest producte fins a desaparèixer.

Al cap d’uns anys va aparèixer Firefox com aquell navegador lliure i gratuït que havia de ser l’alternativa, i així ha sigut durant molts anys, a un IExplorer que deixava molt per desitjar, no era obert i no anava del tot massa bé.

Evidentment  tots el friks es van passar al Firefox, aquest va demostrar ser un navegador molt bo, ràpid i més segur, encara que això és una cosa que no hi he estat mai d’acord, fins al punt que si no erets de Firefox ja erets una mica “raret”.

No vull fer una història de Firefox, el que si que vull manifestar és el desencant que per mi ha anat tenint aquest navegador per dues causes:

a) S’actualitza sense demanar fent que quan s’obra el navegador et diu que s’està actualitzant, algunes vegades aquest proces és molest si utilitzes el navegador per feina

b) Porta algunes versions que és lent d’arrencar, ocupa massa memòria i provoca baixades de rendiment a la màquina

El que per mi l’hi ha fet molt mal és la sortida del Chrome que sincerament m’està enamorant per la seva agilitat, velocitat i facilitat. El recomano sincerament.

IExplorer també el recomano, a partir del 8 és un navegador que va molt bé.

Firefox adéu. Crec que has sigut un bon navegador però no has sabut solucionar els teus problemes amb eficàcia i rapidesa i és per això que no et puc tornar a utilitzar.