Ho chiesto e ottenuto di sviluppare un progetto di una User Interface con WPF e non me ne sono affatto pentito sebbene abbia lavorato sulla beta2.
La peculiarià principale di questa applicazione è stata di non avere un'interfaccia grafica standard Windows ed in cui gli stessi controlli di base non erano direttamente utilizzabili.
Ho dovuto quindi sviluppare diversi user ma soprattutto custom control che, raccolti in un assembly dedicato, hanno costituito i mattoncini base dell'applicazione.
Lo stesso input utente, proveniendo da un dispositivo custom, doveva essere gestito in modo differente da mouse e tastiera e la gestione del controlli attivo non ho potuto demandarla alla gestione del focus di WPF ma mi sono costruito uno stack di classi alle quali ho abbinato i corrispondenti controlli UI attivi.
Infine è stato prezioso il supporto per le animazioni e gli effetti grafici 2D di WPF, cosa che con GDI+ o con DirectX sarebbe stata molto più complessa.
Tutto questo mi ha permesso di scavare WPF molto più a fondo di quanto non avessi mai fatto. La complessità del progetto mi ha dato modo di farmi un idea più approfondita sull'usabilità di WPF in contesti reali e queste sono state le mie impressioni alla luce dei problemi che ho dovuto risolvere.
Aspetti positivi
- L'essere slegati da User32 permette finalmente di progettare interfacce grafiche veramente modulari, partendo da piccoli controlli ed eseguendo l'embedding delle funzionalità in controlli più complessi.
- Il meccanismo di binding di WPF può sembrare più complesso del dovuto ma è estremamente flessibile. Per esempio permette di esporre delle proprietà di un controllo contenuto nel controllo contenitore, evitando di scrivere tantissimo codice. Con WPF si smette di pensare al binding come qualcosa di esclusivamente legato al mondo dei dati ado.net.
- Le dependency property sembrano tanto brutte e ostili all'inizio, ma diventano una vera benedizione man mano che si procede con lo sviluppo. Forniscono un grosso aiuto in termini di valore di default, usabilità in xaml, evento sul cambiamento del valore, validazione, etc.
- L'impostazione "Visual"-centrica è fantastica, non ci sono altre parole.
- Il nuovo uri "pack://" per referenziare le risorse è semplicemente risolutivo. Purtroppo la sintassi di pack:// è ancora poco documentata e neppure qui e qui sono svelati tutti i "trucchi". Ho infatti scoperto che è possibile finalmente referenziare le risorse in un particolare assembly e questo mi ha reso felice nonostante nella beta 2 i problemi che ho avuto sulle risorse sono stati enormi. Ci sarà modo di tornarci sopra.
- Effetti grafici e animazioni sono di una semplicità disarmante.
- L'enorme quantità di esempi nell'SDK aiuta moltissimo... farne buon uso dipende solo da noi.
Aspetti negativi
- La totale mancanza del designer (aka Cider) ha giocato pesantamente a sfavore nel tempo di sviluppo dovendo scrivere tutto il codice xaml a mano.
Sono scettico sul fatto che, anche nella RTM si riuscirà veramente a fare a meno di modificare anche solo piccole parti di xaml a mano, nonostante i ben tre designer che avremo a disposizione quali Cider, Acrylic e Sparkle.
- Le eccezioni generiche XamlParseExcetpions che si ottengono scrivendo erroneo codice XAML e/o code behind C# sono difficili da trovare visto che non c'è traccia neppure del file che ha causato il problema. Per quanto mi è stato detto è un problema che non verrà risolto in questa versione. Potrà però essere minimizzato con l'uso di XamlDebuggingInformation che non ho potuto usare visto che lavoravo con la beta 2 in cui non era ancora implementato.
- L'architettura di WPF non è intuitiva o perlomeno in tantissimi casi premendo "." in vs.net non ci si può aspettare di trovare tutto quello che si vorrebbe dentro la finestra dell'intellisense.
- Nonostante i vantaggi delle dependency property, credo che queste costituiranno un grado di difficoltà supplementare nella learning curve di WPF per un neofita.
- Le attached properties recentemente oggetto di questo post di Corrado sono potenti ma costituiscono un'oggettiva difficoltà per un neofita che vorrebbe trovare tramite intellisense, ad esempio, le proprietà Left e Top nel controllo interno al pannello.
- Le attached properties sono un fatto positivo ma in certi casi possono dare delle rogne. Per esempio se un controllo è contenuto in un Canvas, la sua posizione relativa (Left, Top) è specificata nella attached property ed è quindi custodita dal Canvas stesso. Il problema sorge quando volessi cambiare il Canvas con un altro pannello, magari un mio custom control. È necessario che il controllo contenuto non abbia bisogno di controllare la propria posizione rispetto al suo contenitore. Detto così è una cosa buona, ma in certi casi non è priva di problemi e costituisce un altro ostacolo ai neofiti.
- Stili e Control Templates sono veramente molto potenti ma poco intuitivi o magari sono io che sto invecchiando. Inoltre il fatto di non avere alternative ad usare un control template per poter cambiare il colore di background dell'item selezionato di una listbox mi ha lasciato piuttosto perplesso.
Aspetti sia positivi che negativi
- Chi conosce MFC, VB6 e/o Winform ... è meglio che dimentichi tutto. L'aspetto positivo è che WPF non ha dovuto portarsi dietro alcuna limitazione dovuta a precedenti tecnologie. L'aspetto negativo è che bisogna re-imparare da capo con tanta pazienza e umiltà intellettuale.
Conclusioni
Complessivamente l'architettura è convincente anche se tuttora lacunosa di alcune classi "helper" che consentirebbero una maggiore usabilità come ho già evidenziato qui.
Allo stesso tempo però credo anche che WPF non incontrerà i favori di chi non ha voglia di sudarsi letture, prove, test e tanto tanto tempo per capire bene come funziona. In altre parole chi viene da Access o da VB.net a livello amatoriale non troverà una strada in discesa ma in salita e piuttosto ripida.
Una grossa parte del successo di WPF è affidata, a mio parere, ai designer. Il fatto che ne avremo ben tre da parte di Microsoft la dice lunga. Resta il fatto che anche nel code behind molto del codice rimane poco intuitivo e intellisense è sì prezioso ma solo parzialmente.
La learning curve di WPF è tutt'altro che morbida. Questo non solo perché non c'è analogia con le precedenti tecnologie di UI Microsoft ma perché è assolutamente necessario avere molto chiari una serie di concetti prima di cominciare a progettare (figuriamoci poi a scrivere codice o pasticciare con il designer).
Con tutto ciò è evidente che fioriranno tonnellate di applicazioni WPF monolitiche con enormi blob di xaml e talmente accrocchiate da non rendere neppure necessario l'uso di un obfuscator. Il problema è che probabilmente queste applicazioni non vedranno mai una versione 2 per evidenti problemi di manutenibilità.