blogs.ASPItalia.com

Finalmente disponibili i driver delle schede UMTS Vodafone per Windows Vista

Riccardo Golia — Mon, 12 Mar 2007 00:52:00 GMT

Dopo una lunga attesa sono disponibili (almeno cos� pare) i driver delle schede UMTS Vodafone per Windows Vista, nel mio caso la Option Fusion 3G UMTS/GPRS. Non ho ancora avuto modo di provare il software, ma conto di farlo immediatamente quando rientrer� in Italia dal MVP Summit 2007 a Seattle (USA).

Per chi non avesse tempo di aspettare il mio rientro in Italia, segnalo subito il link da cui � possibile scaricare il software sul sito Vodafone. Il software � il Vodafone Mobile Connect - versione 9.1.0.4345; si tratta di un pacchetto di installazione da 77 MB circa. Buon download, era ora!

Continua a leggere Finalmente disponibili i driver delle schede UMTS Vodafone per Windows Vista.

Installazione di Windows Vista

Riccardo Golia — Tue, 21 Nov 2006 02:00:00 GMT

In questi giorni sto installando sul portatile�Windows Vista Ultimate RTM. Devo dire che il livello di performance � davvero�molto buono, nonostante un rate pari a 2,0 dovuto per lo pi� alle caratteristiche scadenti�della mia�scheda grafica (NVIDIA GeForce FX Go5200 64MB). I driver aggiornati tramite Windows Update mi hanno peraltro�consentito di attivare fin da subito AERO, con un impatto sul look&feel davvero sconvolgente. Altri driver non funzionano, per esempio quello del modem UMTS della Option, per cui per ora niente connettivit� UMTS (in attesa del driver). Per questo motivo e per evitare in ogni caso sorprese, ho provveduto ad installare una doppia partizione. Il dual boot mi consente di avviare Vista oppure Windows XP SP2, il primo sistema contiene Office 2007, il secondo Office 2003.

Per attivare il dual boot,�� consigliabile installare per prima la partizione con XP. Nel caso in cui questo non�sia possibile, una volta installato il sistema legacy (XP appunto), Vista diventa "invisibile", perch� le modalit� di boot di Vista sono gestite in modo differente rispetto a XP e la modifica del boot.ini non serve a nulla.

Per�rendere nuovamente visibile e "bootabile"�la partizione di Vista, occorre fixare le impostazioni di startup reinserendo il disco di installazione di Vista. Una volta riavviato il sistema, occorre andare a modificare la configurazione del boot manager. La cosa pu� essere fatta tramite l'utility da linea di comando�BCDEDIT.EXE, che si trova in \windows\system32.

In realt� esiste un modo pi� efficiente per attivare il dual boot su Vista: usare l'applicazione EasyBCD 1.5. Si tratta di una applicazione molto carina che permette di configurare facilmente e senza errori il boot manager di Vista, con la possibilit� di attivare partizioni con Windows (NT, 98, 2000, Me, XP e Longhorn), Linux e Mac OS X. Il tool � scaricabile da questo URL: http://neosmart.net/dl.php?id=1.

Tags: Windows Client, Windows Vista

Continua a leggere Installazione di Windows Vista.

WWF e WCF January 2006 CTP

Riccardo Golia — Sat, 21 Jan 2006 18:00:00 GMT

Con l'uscita delle nuove CTP di WinFx sono apparsi dal 18 gennaio 2006 un paio di siti dedicati a Windows Workflow Foundation e Windows Communication Foundation.

Tags: .NET Framework 3.0, Windows Workflow Foundation

Continua a leggere WWF e WCF January 2006 CTP.

ServiceContract e interfaccia di classe in Indigo

Riccardo Golia — Wed, 23 Mar 2005 10:00:00 GMT

Quello che segue � l'esempio di codice proposto da David Chappell nella presentazione delle caratteristiche di Indigo durante la giornata di ieri all'Architect Day 2005.

using System.ServiceModel;

[ServiceContract]
class Calculator
{
[OperationContract]
private int Add(int a, int b)
{
return a + b; 
}

[OperationContract]
public int Subtract(int a, int b)
{
return a - b;
}

public int Multiply(int a, int b)
{
return a * b;
}
}

Di fatto quello che si nota nel codice proposto � l'associazione dell'attributo OperationContract ad un metodo privato della classe che funge da servizio. Questa cosa testimonia il disaccoppiamento tra ServiceContract e interfaccia di classe, che riprende la necessit� di diversificare il concetto di servizio da quello di oggetto.

In altre parole una classe che funge da servizio viene marcata con l'attributo ServiceContract ed i metodi esposti dal servizio vengono marcati con l'attributo ContractOperation indipendentemente che siano private o public. Questo perch� il comportamento del servizio non deve essere necessariamente uguale a quello dell'oggetto. Servizio e oggetto sono due astrazioni diverse e vanno trattate come tali, ovvero ognuna � caratterizzata da un contratto indipendente dall'altro. Proprio per questo motivo David parlava addirittura del fatto che probabilmente tutti i metodi esposti da un servizio dovrebbero essere private!!!

Un oggetto infatti espone un contratto che descrive il suo comportamento nell'ambito del contesto applicativo in cui l'oggetto stesso � attivo, ovvero i metodi che possono essere chiamati nell'ambito dell'applicazione da altri oggetti. In questo caso si definisce come public ci� che pu� essere richiamato e come private ci� che deve essere mascherato.

Parallelamente un servizio espone a sua volta un contratto descritto nel WSDL che � rappresentato dall'insieme dei metodi accessibili. Questo contratto non necessariamente deve essere coincidente con il contratto relativo all'oggetto. Ecco allora che si usano gli attributi per dire quali metodi devono essere esposti dal servizio.

Se sulle prime sono rimasto un attimo disorientato, una volta capiti i concetti e le differenze tra i due ambiti e le due astrazioni, ho colto l'importanza di questa cosa.

A questo punto direi che � cosa buona e giusta! :)

Continua a leggere ServiceContract e interfaccia di classe in Indigo.

Avalon e il data binding

Riccardo Golia — Wed, 19 Jan 2005 22:57:00 GMT

Per concludere la carrellata di post relativi a Longhorn (sospesa per causa di forza maggiore), in vista del prossimo evento di ASPItalia in cui si parler� di XAML e Avalon, direi che � doveroso spendere qualche parola sul data binding, ovvero l'associazione tra elementi della UI con le informazioni provenienti dalle sorgenti dati.

Oggi siamo abituati a considerare il data binding come un meccanismo fondamentalmente unidirezionale. Questo significa che in generale le informazioni vanno dal data source al controllo della UI oppure, in alternativa, i dati possono venire salvati nel data source. In ogni caso oggi non si parla di data binding bidirezionale.

Rispetto all'approccio per cos� dire tradizionale, i meccanismi di data binding tra sorgente dati e controlli dell'interfaccia utente in Longhorn vengono estesi e potenziati. Il data binding pu� essere anche (ma non solo) bidirezionale, nel senso che viene supportato contemporaneamente il flusso in entrambe le direzioni, dalla sorgente al controllo, dal controllo alla sorgente. Parallelamente il data binding pu� essere statico oppure dinamico (un meccanismo che in un certo senso a me ricorda il concetto di cursore in ADO). Ma andiamo per ordine.

Tipi di data binding

DATA BINDING ONE-TIME
In questo caso, in base al data source e al percorso specificato, il runtime recupera il valore dalla sorgente e imposta la propriet� target. In seguito a questo, di solito non avviene assolutamente pi� nulla nel caso in cui o il valore sorgente o la propriet� target dovessero cambiare.

DATA BINDING ONE-WAY
Nel caso one-way, il runtime recupera il valore della sorgente e imposta la propriet� target, proprio come prima. Ma la differenza sta nel fatto che, qualora il valore sorgente dovesse essere per qualche motivo cambiato, il binding propaga la modifica dalla sorgente alla propriet� target.

DATA BINDING TWO-WAY
E' il data binding bidirezionale di cui si parlava prima. Il runtime recupera il valore della sorgente e imposta la propriet� target, proprio come nei primi due casi. Qualora o il valore sorgente o la propriet� target dovessero cambiare, il binding propaga la modifica o in un senso o nell'altro, a seconda dei casi. Questo � il tipo di data binding predefinito.

La classe in Avalon che rappresenta il data binding � MSAvalon.Data.Bind. Questa classe � caratterizzata da una serie di propriet� utili allo scopo:

Path: indica la propriet� o il valore sorgente.
BindType: specifica il tipo di binding secondo quanto detto in precedenza (OneTime, OneWay, TwoWay).
UpdateType: propriet� valida con il binding two-way, nel caso di propagazione delle modifiche dalla propriet� target alla sorgente. Pu� valere Immediate (ovvero subito), OnLostFocus (ovvero quando il controllo perde il focus) oppure Explicit (ovvero in maniera esplicita quando viene invocato l'oggetto bind).
Source: specifica il data item sorgente.
Transformer: permette di assegnare un oggetto che implementa l'interfaccia IDataTransformer (metodi Transform e InverseTrasform) che consente di trasformare il valore in entrata in un nuovo valore in uscita; si tratta di una specie di mappa di trasformazione che accetta in input un Object e restituisce un Object, nei due sensi.
Culture: consente di specificare un CultureInfo.
BindFlags: permette di un impostare un flag che informa dell'avvenuto trasferimento dei dati.

Inutile dire che il corrispondente della classe Bind in XAML � l'elemento <Bind />. In realt� poi si usa spesso una forma contratta per definire un data binding, assegnando alla propriet� target una stringa che inizia con un asterisco, seguita dalla parola Bind e dall'elenco delle propriet� sopra elencate separate da un punto e virgola.

Per rendere pi� chiari i concetti passerei ad un paio di esempi, che sono molto di pi� di tante parole.

CODICE C#

using MSAvalon.Data; Bind dataBinding = new Bind(sourcePath, bindType, dataSource, updateType); element.SetBinding(property, binding); �

XAML

<DockPanel> ��<DockPanel.Resources> ��<SqlDataSource def:Name="mySource" ConnectionString="..." SelectCommand="SELECT * FROM Table" /> ��</DockPanel.Resources> ��<SimpleText Text="*Bind(Path=Field;BindType=OneWay)" /> </DockPanel> �

Io mi fermo qua! Tutto il resto (e molto di pi�) lo lascio dire a Ricciolo e a Daniele al WDD del prossimo 28 gennaio.

Continua a leggere Avalon e il data binding.

XAML, di che si tratta?

Riccardo Golia — Sat, 08 Jan 2005 17:05:00 GMT

Dopo aver parlato del modello applicativo di Longhorn e dell'oggetto Application nei post precedenti, passiamo a vedere cosa ha da offrirci di tanto interessante il linguaggio XAML.

Essendo un documento XML well-formed, una pagina XAML contiene uno o pi� elementi organizzati gerarchicamente che controllano il layout e il comportamento della pagina stessa. Esiste un unico elemento radice, ciascun elemento pu� avere un solo padre, ma pi� figli. E' interessante notare che ogni nome di un elemento corrisponde al nome di una classe managed. Del resto ogni elemento XAML deriva da System.Windows.UIElement oppure da System.Windows.ContentElement a seconda dei casi. In generale si possono raggruppare gli elementi in quattro macro-categorie:

controlli (derivano dalla classe System.Windows.Control), che permettono di gestire l'interazione con l'utente;
panels (derivano dalla classe System.Windows.Panel), che fungono da contenitori di elementi e permettono di suddividere la pagina in porzioni in cui gli elementi risultano raggruppati;
elementi testuali (derivano da System.Windows.TextElement), che permettono di gestire la formattazione del testo;
forme che gestiscono le rappresentazioni grafiche vettoriali.

1) Controlli
Si tratta dei controlli che siamo abituati ad usare in Windows, ovvero pulsanti, checkbox, radio buttons, combo, dropdownlist, menu, scrollbar, slider, ecc. Un aspetto interessante � che XAML consente di combinare diversi controlli al fine di ottenerne uno composito, ovvero una combinazione dei controlli costituenti (si parla di control composition). L'esempio classico � quello del pulsante con una immagine. Basta annidare l'elemento Image tra il tag di apertura e chiusura dell'elemento Button e il gioco � fatto. Facile, no?

2) Panels
Rappresentano dei contenitori di elementi. Ne esistono di diversi tipi, per tutte le esigenze:

Canvas, che permette di posizionare gli elementi interni usando le coordinate relativamente all'area del panel;
DockPanel, che consente di organizzare gli elementi interni sia in senso verticale che orizzontale (Top, Bottom, Left, Right, Center);
FlowPanel, che permette di posizionare gli elementi interni in modo adattivo in base alle interruzioni di linea;
TextPanel, per organizzare contenuti testuali secondo diversi layout (per esempio, per colonne);
GridPanel, per rappresentare griglie di dati;
FixedPanel, per rappresentare gli elementi interni secondo una struttura di layout fissa (non adattivo).

3) Elementi testuali
Sono elementi che permettono di gestire la formattazione del testo e la struttura dei documenti (Text).

4) Forme
XAML supporta la grafica vettoriale grazie alle Shapes (Ellipse, Line, Rectangle, Path, Polygon, ecc.), utili per disegnare forme geometriche, ai diversi tipi di Transforms (RotateTransform, TranslateTransform, ScaleTransform, SkewTransform, ecc.), ovvero trasformazioni delle propriet� di un oggetto, e le Animations, che non sono altro che trasformazioni protratte nel tempo.

Oltre a quanto visto sopra, esistono degli elementi pensati per gestire al meglio la visualizzazione on-line dei documenti (come nel caso di applicazioni navigabili). PageViewer � un controllo disegnato per la visualizzazione, paginazione e navigazione di contenuti on-line, un po' come avviene con un browser Web. Il controllo suddivide automaticamente i contenuti in diverse pagine e fornisce gli strumenti necessari per navigare da una pagina all'altra. I contenuti possono essere rappresentati secondo un layout adattivo (adaptive flow), al fine di occupare tutto lo spazio a disposizione, oppure fisso, indipendente dalle dimensioni della finestra e/o dello schermo o dal tipo di dispositivo di output. Esistono per l'appunto degli elementi che consentono di ottenere uno o l'altro tipo di layout.

Dato un elemento, � possibile associare ad esso una collection di risorse (il nome della collection � Resources). Si tratta di un modo per riutilizzare oggetti o valori comuni. Se una risorsa non � definita nella collection di un elemento, questa viene ricercata nella collection dell'elemento padre. Definendo per esempio delle risorse per un elemento Canvas, � possibile utilizzare queste risorse nell'ambito di tutti gli elementi figli del panel (Canvas.Resources). Gli stili sono un tipo particolare di risorsa (il nome della classe � Style).

Dopo tanti bla bla bla, � arrivato il momento di mostrare qualche esempio...

Codice C# ed equivalente in XAML

Questo frammento di codice C# crea una finestra, in essa scrive "Tutti al Windows Development Day!" (mi raccomando accorrete in tanti!) tramite un controllo SimpleText (colore nero e dimensione del carattere uguale a 10pt) e la rende visibile.
�

myWindow = new MSAvalon.Windows.Window();
myElement = new MSAvalon.Windows.Controls.SimpleText();
myElement.Text = "Tutti al Windows Development Day!";
myElement.Foreground = new MSAvalon.Windows.Media.SolidColorBrush
(Colors.Black);
myElement.FontSize = new FontSize(10, FontSizeType.Point);
myWindow.Children.Add(myElement);
myWindow.Show();

�
Notare che in XAML elementi e attributi hanno nomi uguali a quelli delle classi e propriet� corrispondenti. Nel tag di apertura di Window l'attributo Visible="true" equivale alla linea di codice myWindow.Show();.
�

<Window xmlns="http://schemas.microsoft.com/2003/xaml" Visible="true">
����<SimpleText Foreground="Black"
��������FontSize="10">Tutti al Windows Development Day!</SimpleText>
</Window>

Control composition

Come si fa ad ottenere un pulsante contenente una immagine usando XAML e control composition? Ecco un esempio.
�

<Button>
����<Image Source="aspitalia.jpg" />
</Button>

Collection delle risorse e stili

Come si vede, lo stile � un tipo di risorsa e ad esso pu� essere assegnato un nome o meno. A me ricorda qualcosa dei CSS e a voi?
�

<Border
����xmlns="http://schemas.microsoft.com/2003/xaml" xmlns:def="Definition">
����<FlowPanel>
��������<FlowPanel.Resources>
������������<SolidColorBrush def:Name="MyColor" Color="Gold"/>
������������<Style>
����������������<Button Background="Green" FontSize="15"/>
������������</Style>
������������<Style def:Name="MyStyle">
����������������<Button Background="Red" FontSize="24"/>
������������</Style>
��������</FlowPanel.Resources>
��������<Button>Bottone di colore verde</Button>
��������<Button Style="{MyStyle}">Bottone di colore rosso</Button>
��������<Ellipse Fill="{MyColor}"/>
����</FlowPanel>
</Border>

To be continued...

Tags: Windows Presentation Foundation, XAML

Continua a leggere XAML, di che si tratta?.

Application, ApplicationNavigation e XAML

Riccardo Golia — Thu, 06 Jan 2005 13:48:00 GMT

Terza puntata dei post dedicati ad Avalon e Longhorn (puntata precedente)...

Semplificando si pu� affermare che le applicazioni per Longhorn consistono in un oggetto Application e in un insieme di pagine in XAML che rappresentano l'interfaccia utente. L'oggetto Application � di tipo singleton e rimane attivo durante l'esecuzione dell'applicazione. Questo oggetto non � altro che una istanza della classe MSAvalon.Windows.Application o di una sua derivata e fornisce l'entry point, nonch� consente di gestire lo stato, la sicurezza e gli eventi a livello applicativo. L'oggetto in questione determina anche il tipo dell'applicazione: 1) applicazione stand-alone (a finestra singola) oppure 2) applicazione navigabile. In questo secondo caso l'oggetto che rappresenta l'applicazione � una istanza della classe MSAvalon.Windows.Navigation.ApplicationNavigation che estende la classe vista in precedenza con il supporto per la navigazione (eventi di navigazione, gestione dello stato tra le pagine, condivisione di propriet�, ecc.).
Come detto sopra, solitamente le pagine che compongono la UI vengono scritte in XAML (eXtensible Application Markup Language), che, come si pu� capire dal nome stesso, � un linguaggio di markup basato su XML che permette di descrivere il modello degli oggetti utilizzati dall'applicazione. In pratica una pagina XAML descrive l'albero delle istanze delle classi che il runtime andr� a creare una volta lanciata l'esecuzione dell'applicazione. Quando il runtime crea la pagina, esso istanzia ogni elemento e ogni nodo indicato nel file XAML e crea in memoria un modello a oggetti corrispondente. Questi oggetti possono in ogni caso essere modificati via codice.
E' importante sottolineare che tutto ci� che pu� essere fatto utilizzando XAML pu� essere fatto anche in maniera programmatica (ovvero scrivendo del codice che dichiara e istanzia oggetti), ma non � vero il viceversa. Di fatto quello che si pu� fare tramite XAML � descrivere l'insieme gerarchico di oggetti che verranno creati dal runtime, impostarne le propriet� in modo statico o acquisendo i valori da qualche sorgente dati, memorizzare i valori delle propriet� in qualche sorgente dati, associare un event handler ad un evento.
Le applicazioni in Longhorn basano il loro modello di sicurezza sul modello Code Access Security (CAS) fornito dal CLR. Oltre a questo, Longhorn fornisce un ambiente sicuro e gestito denominato SEE (Secure Execution Environment) che protegge gli utenti da comportamenti non proprio consoni e corretti da parte delle applicazioni. Il Trust Manager fornisce un sistema basato su punteggi per determinare il livello di fiducia (trust appunto) che gli utenti possono assegnare alle applicazioni. Come accennato nei post precedenti, a differenza di quanto avviene oggi, dove le applicazioni girano con il set FullTrust, le applicazioni in Longhorn possano girate con la corretta policy (per esempio, uguale a quella del sito da cui l'applicazione � stata scaricata). Questo � possibile proprio grazie all'esistenza del manifest di deployment, in cui sono contenute le regole di sicurezza e isolamento.

To be continued...

Tags: Windows Presentation Foundation, XAML

Continua a leggere Application, ApplicationNavigation e XAML.

Il modello applicativo di Longhorn

Riccardo Golia — Wed, 05 Jan 2005 16:21:00 GMT

Riprendo da dove avevo lasciato...

L'application model di Longhorn definisce i vari aspetti caratteristici di una applicazione in termini di:

entry point
flusso di controllo e di navigazione
stato e risorse
eventi
isolamento
distribuzione
aggiornamento e rollback

Faccio una distinzione tra applicazioni Web e applicazioni Windows, anche se di fatto le differenze che esistono oggi tra le due tipologie di applicazione tendono a venir meno grazie al nuovo application model.

Nel primo caso il modello applicativo consente di scrivere applicazioni Web in modo non dissimile da quanto avviene gi� oggi. Ma il codice pu� utilizzare in modo completo il livello di presentazione fornito da Longhorn. Per questo una applicazione Web non differisce poi di molto da una applicazione Windows, se non per gli aspetti collegati alla distribuzione, ovvero per il fatto che una applicazione Web risiede in ogni caso su un server. Per il resto una applicazione Web pu� sfruttare i controlli client, supportare multimedia e grafica, gestire eventi, ecc.
Nel secondo caso il modello applicativo di Longhorn prevede che, sebbene sia installata localmente, l'applicazione pu� girare sia in modalit� on-line sia in modalit� off-line, all'interno del browser oppure come applicazione stand-alone. A proposito delle applicazioni Windows si parla anche di NavigationApplication, ma questo � un discorso che vorrei affrontare a parte in un post futuro.
Per realizzare un'applicazione in Longhorn occorre definirne il modello ad oggetti; lo si pu� fare sia in via programmatica tramite codice sia in maniera dichiarativa tramite l'uso del linguaggio di markup XAML che la vera novit� del nuovo application model. Una volta compilato il codice e/o il markup, all'applicazione viene associato un manifest applicativo (in cui sono indicate le dipendenze e le parti costituenti dell'applicazione) e un manifest di deployment, che riferisce al manifest applicativo (ovviamente!), ma permette anche di definire il livello di isolamento e le direttive di aggiornamento dell'applicazione.

Vorrei spendere un paio di parole sulla compilazione...

La compilazione pu� essere eseguita in due modi al fine di produrre due tipologie di risultato diverse, pensate per scopi diversi. Prima tipologia: si parla di CAML, ovvero compiled XAML, quando i file XMAL relativi ad una applicazione vengono compilati al fine di ottenere semplicemente IL (Intermediate Language). Seconda tipologia: si parla di BAML, ovvero binary XAML (rappresentazione binaria di XAML), quando il risultato atteso dalla compilazione � un documento, ovvero un container ottimizzato per il download a scapito della velocit� di esecuzione. Infatti BAML � molto pi� compatto rispetto a CAML e per questo i file BAML si scaricano pi� rapidamente. Per contro eseguire un file BAML comporta un overhead derivante dalle operazioni di parsing da parte dell'interprete a run-time al fine di generare l'albero delle istanze delle classi definite in esso.
Altro aspetto da sottolineare riguarda MSBuild. Che cosa � MSBuild? E' il nuovo sistema di build che va a sostituire il classico Make. MSBuild � in grado di acquisire le regole di compilazione dai file di progetto .proj. Queste regole sono espresse in XML secondo un preciso schema di validazione che prevede elementi quali PropertyGroup e Property, ItemGroup e Item, Import, Task e Target. Diciamo che MSBuild assomiglia a NAnt (dove � possibile definire le direttive del processo di compilazione in XML), ma rispetto a questo presenta degli aspetti che lo rendono superiore.

To be continued...

Continua a leggere Il modello applicativo di Longhorn.

Cosa si può fare con Longhorn e Avalon?

Riccardo Golia — Mon, 03 Jan 2005 16:44:00 GMT

Anno nuovo, vita nuova... Riprendiamo con i post sul blog!

In vista dell'imminente evento organizzato da ASPItalia e Visual Basic T&T in collaborazione con Microsoft su Windows Development, ho ritenuto opportuno documentarmi in anticipo sull'application model di Longhorn, visto che questo argomento verr� affrontato durante l'evento da Daniele e Ricciolo, al fine di cogliere al meglio le inevitabili "chicche" che verranno mostrate durante la manifestazione.
Utili allo scopo si sono rivelati i dieci giorni di ferie che sto trascorrendo in questo periodo (finalmente l'occasione buona per dedicarsi al riposo e allo studio senza l'assillo delle scadenze, semplicemente per il puro gusto di farlo) e il libro del buon Brent Rector, che include una panoramica interessante relativamente a quanto incluso in Longhorn da un punto di vista dello sviluppo e delle tecnologie (ed in particolare Avalon).
L'application model di Longhorn rende possibile la realizzazione di applicazioni utilizzando un unico modello di programmazione che supporta interfacce utente in stile applicativo, presentazione di testo, grafica e contenuti multimediali. Longhorn fornisce una architettura unificata che supporta diversi tipi di applicazione. L'obiettivo � quello di uniformare il procedimento e le tecniche di realizzazione delle diverse tipologie di applicazione. Oggi il procedimento di realizzazione di una applicazione Web rispetto a quello di una applicazione Windows � profondamente diverso, in quanto diverse sono le tecnologie e gli strumenti utilizzati per sviluppare le due tipologie di software. Questo significa avere sviluppatori con skill diversificati in base al tipo e alla porzione dell'applicazione, aspetto che sicuramente pu� introdurre complessit� nel processo di realizzazione del software, dato che i vari componenti, oltre che ad essere sviluppati, vanno assemblati insieme, testati e distribuiti. Unificare il modo di procedere pu� avere dei vantaggi non trascurabili in un ottica di deployment e integrazione.
Quindi, che cosa si pu� fare in Longhorn di tanto rivoluzionario rispetto a quello che gi� esiste oggi? Perch� � cos� interessante il nuovo modello applicativo introdotto con Longhorn? Beh, basta fare un po' di esempi per intravedere le potenzialit� legate a Longhorn e Avalon.
Si vuole creare una interfaccia utente per una applicazione Windows in modo dichiarativo utilizzando un linguaggio di markup come solitamente oggi si fa con le applicazioni Web? In Longhorn tramite XAML (eXtensible Application Markup Language) si pu� fare! Si vuole scrivere event handler fortemente tipizzati in un linguaggio managed? In Longhorn si pu� fare! Si vuole mixare testo, grafica e contenuti multimediali in un documento ottimizzato per il download? In Longhorn si pu� fare! Si vogliono distribuire le applicazioni Windows allo stesso modo con cui si fa il deployment delle applicazioni Web? In Longhorn si pu� fare! Si vuole far girare una applicazione come software stand-alone piuttosto che ospitata in un browser semplicemente ricompilando lo stesso sorgente? In Longhorn si pu� fare! Si vuole creare una applicazione Windows in modo tradizionale, basata su form, oppure creare una applicazione basata su pagine navigabili come avviene oggi per le applicazioni Web? In Longhorn si pu� fare! Si vogliono controllare gli aspetti di sicurezza delle applicazioni in modo che possano girare non con il set FullTrust (come avviene oggi), ma con la corretta policy (uguale a quella del sito da cui l'applicazione � stata scaricata)? In Longhorn si pu� fare!
Beh, mi pare di poter dire che lo scenario futuro � quanto meno interessante, anche a fronte di quanto semplicemente detto sopra. La cosa diviene ESTREMAMENTE interessante nel momento in cui si vedono un po' di esempi di codice e/o si fanno un po' di prove. In attesa di ulteriori post sull'argomento che non mancher� di postare nei prossimi giorni sul blog, invito intanto tutti quanti ad iscriversi al Windows Development Day. Di carne sul fuoco ce n'� parecchia e credo proprio che il prossimo 28 gennaio a Bologna ne vedremo delle belle!

Continua a leggere Cosa si può fare con Longhorn e Avalon?.