Programmazione di device Windows 10

Vi traduco alla meno peggio (e ci metto un po’ del mio) i primi paragrafi presi da questi due articoli

http://windowscomments.com/?p=596

https://msdn.microsoft.com/en-us/magazine/dn973012.aspx

Una mezza rivoluzione in casa Windows.

Non ci speravamo neanche più ma è arrivato: un unico sistema operativo Windows che gira su tutti gli hardware compatibili con Windows e fa girare lo stesso binario su tutti i device!! Gulp!

MS sembra sia riuscita nell’impresa di definire le specifiche per un hardware universale nei confronti del sistema operativo.

In questo modo è possibile scrivere drivers universali sui quali appoggiare una API universale che chiaramente a questo punto consente le famigerate App Universali.

Anni di lavoro e una grande opera di ingegneria.
Nulla da dire.

A livello di S.O., avere la possibilità di astrarre uno strato di software vicinissimo all’hardware (io la vedo come una sorta di HAL) che, per chi lo usa da sopra, sia sempre uguale, significa avere una unica, molto manutenibile e agile base di codice sulla quale costruire davvero le app universali.

Per lo sviluppatore, avere una API universale, significa studiare meno dettagli e allargare a dismisura il parco di potenziali utenti del proprio software.

Le universal App infatti girano senza modifiche (compatibilità binaria!) sia su device Iot come Raspberry Pi 2, sia su Telefono, Xbox, Tablet, (potenzialmente ogni Tablet purchè sia dotato di Win10), Surface Hub, Laptop, PC Desktop, Hololens e chi più ne ha, più ne metta.

Il viaggio verso Win 10

Se guardiamo indietro scopriamo che nel 2011 MS aveva tre sistemi operativi da gestire:

• Windows 7 basato su NT,
• Windows Phone derivato da Windows CE con analogie rispetto a NT,
• Xbox 360 OS anch’esso di derivazione NT ma ottimizzato al gaming.

Queste tre piattaforme avevano i loro personali drivers, e avevano alle spalle 10 anni di sviluppo selvaggio dove ognuno ha sempre preso la propria strada senza mai potersi incontrare con gli altri due.

MS al tempo lavorava per avere Internet Explorer su tutte e tre le piattaforme e, per sua stessa ammissione, il riuscire nell’impresa è stato un bell’esercizio di ingegneria del software.

Non era possibile andare avanti così.
Non era possibile appoggiare questa complessità sugli sviluppatori e pretendere che tutto filasse liscio.
Soprattutto in un mondo in completa evoluzione sul fronte dei dispositivi.

Il primo risultato di questa riflessione è stato Xbox One lanciato nel 2013 (due anni dopo) che vedeva una parte di S.O. condiviso con Windows 8.

Ricordate la polemica sul fatto che l’hardware di Windows Phone 7.x non poteva essere usato su Windows 8.x?
Ecco i motivi.

Stavano uniformando l’hardware e una compatibilità verso il passato li avrebbe incastrati (volendo si può leggere senza in).  Hanno quindi dovuto fare delle scelte che consentissero di aprire a tutte le piattaforme future… la strada verso Win 10 era ormai tracciata.

 

Unità non significa conformità

Realizzare un S.O. unico non significa per forza avere la stessa UI !!
Sul telefono ho bisogno di una UI semplice, essenziale, che mi aiuti a gestire le operazioni mentre sono in mobilità.

Quando gioco con una Xbox invece, ho bisogno di un’interfaccia decisamente diversa, così come quando eseguo una App in una IoT.

Ogni dispositivo, ha quindi un suo hardware dedicato e un’interfaccia utente molto diversa dall’altro, ma se è un dispositivo conforme a Windows 10, può contare sullo stesso Core di S.O., stesse API, stessi drivers hardware, stesse librerie, stessi runtime, stessi linguaggi, stesso binario scaricabile dallo store!

Questo comporta che quando un programmatore scrive codice per Xbox, sa esattamente che può contare sulle stesse risorse (API) di quando si trova su Raspberry Pi o sul Telefono… deve tenere conto solo delle diverse peculiarità che ogni piattaforma è chiamata a gestire.

In teoria qualcuno ci ha provato a fare un nucleo operativo comune per tutti i device, ma senza il supporto pesante del S.O. il codice che ne deriva è difficile da manutenere (miliardi di #define in giro!!!)

Per supportare in modo adeguato i vari fattori di forma esistenti e futuri o anche per poter utilizzare hardware dedicato (pensiamo alla GPIO di Raspberry) o per sfruttare la potenza grafica di una Xbox, al sistema operativo Core vengono così aggiunti dei pezzi, delle parti che lo fanno funzionare nei vari contesti. (si chiamano Extension e per loro è dedicato un SDK)

In questo modo vengo anche gestite le varie SKU di Windows (Stock Keeping Unit, un modo per suddividere un prodotto in fasce commerciali… le versioni Home, Professional, Enterprise, sono esempi di SKU)

Con un Sistema operativo così componibile MS può decidere quali estensioni montare su Hololens, Desktop, Raspberry Pi 2 o Xbox, rispetto al Core che comunque esiste su tutti i sistemi.

Il programmatore in pratica deve quindi verificare la presenza di un determinato hardware prima di usarlo.

 

UAP – Universal Application Platform

UAP è una superficie API comune tra i dispositivi, non è un runtime.
In Windows 10, compilando il proprio programma (gestito o no) si compila per la UAP sottostante.
Non serve il runtime!

Non si ricicla il proprio software .NET senza toccarlo, questo no.
Una universal App gira infatti sopra ad un insieme di librerie e interfacce che vanno con il nome di .NET Nucleo che è una cosa diversa dal runtime .NET che conosciamo.

I propri sorgenti .NET quindi, per essere compatibili con UAP, devono essere adattati al .NET Nucleo che è un sottoinsieme del .NET attualmente utilizzato da Win7/8.x.

Come sempre, le conoscenze sugli strumenti (VS 2015) ed i linguaggi conosciuti (C#, BV.Net …), sono riutilizzabili e se la propria app è semplice allora la conversione a .NET Nucleo sarà altrettanto semplice.

Ma se la propria App utilizza molte risorse a basso livello oppure librerie di terze parti oppure pezzi di codice non compatibili con .NET Nucleo, siamo daccapo… tocca riscriverle.

 

 

 

Evoluzione di XAML

Directx e JavaScript sono supportati dalla UAP ma lo strumento principale per lo sviluppo di interfacce Windows è XAML.

XAML, ha subito nel tempo varie evoluzioni,; siamo passati dalla versione utilizzata in WPF alla versione usata per scrivere app Silverlight nelle due versioni: Web e Mobile (fino a WinPhone 7.x)

Un primo raggruppamento dei vari dialetti l’abbiamo visto con WinRT (Windows 8.x) e ora la stretta finale: Windows UI.

La nuova versione di Windows 10 utilizza Windows UI e porta con se nuovi controlli XAML come un nuovo menu start.

Anche la nuova suite Office 2015 è formata da un insieme di applicazioni UAP.

Uniformando quindi la superfice delle API (creando UAP), MS ha approfittato dell’occasione per uniformare anche le varie versioni di XAML facendole convergere nel nuovo namespace Windows.UI e introducendo nuovi controlli legati al concetto di Adaptive UI come come lo SplitView e il RelativePanel molto utili nelle App che devono funzionare su schermi da pochi pollici fino a 50 pollici, verticali o orizzontali senza difficoltà.

 

 

 

 

Valore per gli sviluppatori

Il vero vantaggio di questa nuova piattaforma non sta solo nel fatto di poter scrivere una App Universale che gira su N device, ma il poter utilizzare gli strumenti di diffusione come Windows Store per raggiungere gli utenti dove essi sono.

L’esperienza di deploy per lo sviluppatore è semplificata, così come l’esperienza utente nell’installare le App.

La monetizzazione della App è semplificata, il fatto di fare delle demo oppure di accedere al software AdWare senza avere troppa dimestichezza con il marketing sono davvero un’occasione per cercare di entrare in questo mondo anche da parte di giovani programmatori.

Nell’unico codice binario, è possibile inserire parti di codice che verranno abilitate solo in presenza di particolare hardware (ad esempio: questa funzione la attivo solo su Xbox, oppure solo su dispositivi Iot), oppure si può decidere se una app non debba essere presentata agli utenti Mobile… etc

 

Ci sono tante cose da considerare

Da un grande potere derivano grandi responsabilità.
UAP permette di scrivere applicazioni Windows che girano ovunque ma poi sta a noi far si che l’esperienza utente sia grande, in ognuno di questi.

MS ha introdotto in VS2015 strumenti di sviluppo e di diagnostica che consentono di testare la nostra App in moltissime situazioni con vari aspect-ratio, con diversi orientamenti anche senza avere il device a portata di mano.

Anche XAML mette del suo in questo. I nuovi controlli come RelativePanel consentono di creare un albero di componenti UI e di sistemarli in modo automatico sullo schermo al variare di queste situazioni (schermo verticale, orizzontale, grande, piccolo…)

Tutto va nella direzione di scrivere una sola app e di farla funzionare sul maggior numero di possibili piattaforme.

Si apre una nuova era.