ComputerLand

Tu sei qui: Articoli MSDN

Notizie dal web

Start Something! Tour ++ Windows Azure per sviluppatori ASP.NET

E-mail Stampa PDF

In questo post potete trovare l'elenco dei laboratori dedicati a Windows Azure per sviluppatori ASP.NET:

Requisiti per la partecipazione:

I laboratori richiedono di arrivare con il proprio portatile configurato e una sottoscrizione aperta per Windows Azure. Potete attivare una sottoscrizione a Windows Azure, in uno dei seguenti modi:


read full article

Start Something! Tour ++ Ora anche Windows Azure e Web

E-mail Stampa PDF

 

imageDa oggi lo Start Something! Tour si arricchisce di laboratori gratuiti dedicati a Windows Azure per sviluppatori ASP.NET. I laboratori saranno organizzati nelle città di Milano, Roma, Bari, Napoli, Catania, Venezia/Mestre da Microsoft in collaborazione con le comunità degli sviluppatori.

La partecipazione richiede delle competenze di sviluppo su ASP.NET perchè verrano proposti esercizi volti all'utilizzo delle API della piattaforma Windows Azure e all'utilizzo di applicazioni ASP.NET all'interno di Windows Azure. Inoltre il lab è un ottimo momento per fare domande specifiche sulla propria realtà aziendale.

Iscrizione alle giornate di Milano

Le tappe complete del Tour verranno segnalate nei prossimi giorni, ma per ora potete iscrivervi a una delle prime due giornate a Milano, a vostra scelta e a Napoli.

< strong>Requisiti per la partecipazione:

I laboratori richiedono di arrivare con il proprio portatile configurato e una sottoscrizione aperta per Windows Azure. Potete attivare una sottoscrizione a Windows Azure, in uno dei seguenti modi:

  • Se siete iscritti al programma Bizspark
  • Se avete una sottoscrizione MSDN;
  • Se non rientrate in nessuna delle opzioni precedenti, potete attivare una free trial da 90 giorni.
  • Laptop personale con installato il Windows Azure SDK e SQL Server 2008  R2 Express (necessario per i laboratori)

Vi aspettiamo.


read full article

Windows Phone SDK 7.1.1: adattare le nostre applicazioni ai nuovi device di fascia bassa

E-mail Stampa PDF

Guest Post di Matteo Pagani, MVP Windows Phone

In un recente articolo ho presentato la nuova versione dei tool di sviluppo, la 7.1.1, che introduce il supporto ai device di nuova generazione rivolti ad un mercato più economico e dotati perciò, tra le altre cose, di 256 MB di RAM contro i 512 MB solitamente disponibili sui terminali Windows phone.

Nel corso dell'articolo ho introdotto la nuova modalità con cui, da codice, siamo in grado di determinare la tipologia di device su cui sta girando la nostra applicazione: ora vedremo in concreto i casi da gestire a seconda della quantità di memoria disponibile.

Identificare il tipo di device usando la classe IsolatedStorageSettings

Si può evitare di utilizzare Il codice mostrato nel post precedente per identificare il tipo di device tutte le volte che è necessario: si tratta infatti di un tipo di informazione che possiamo richiedere all'avvio dell'applicazione e poi mantenere in memoria o, ancora meglio, salvare nello storage e riutilizzarla per le esecuzioni successive. E' decisamente improbabile, infatti, che un device dotato di 256 MB di RAM possa essere aggiornato e montare un quantitativo di memoria superiore.

Per fare questo, possiamo sfruttare la classe IsolatedStorageSettings, che chi sviluppa applicazioni per Windows Phone dovrebbe già conoscere bene: si tratta infatti di un'astrazione dello storage dell'applicazione per leggere e scrivere in maniera semplice e veloce informazioni identificate da una chiave univoca (concettualmente, si tratta di un Dictionary). Il vantaggio è che, basandosi sullo storage, queste informazioni verranno memorizzate in maniera permanente, perlomeno fino a quando l'utente non disinstalle rà l'applicazione.

Ecco un esempio:

        private bool isLowMemoryDevice;
 
        public bool IsLowMemoryDevice
        {
            get
            {
                if (IsolatedStorageSettings.ApplicationSettings.Contains("IsLowMemDevice"))
                    isLowMemoryDevice = (bool)IsolatedStorageSettings.ApplicationSettings["IsLowMemDevice"];
                else
                {
                    object memory;
                    DeviceExtendedProperties.TryGetValue("ApplicationWorkingSetLimit", out memory);
                    if (memory == null || (long)memory > 94371840)
                    {
                        IsolatedStorageSettings.ApplicationSettings["IsLowMemDevice"] = false;
    
0;                   isLowMemoryDevice = false;
                    }
                    else
                    {
                        IsolatedStorageSettings.ApplicationSettings["IsLowMemDevice"] = true;
                        isLowMemoryDevice = true;
                    }
                }
                return isLowMemoryDevice;
            }
        }
 

Con questo semplice meccanismo ci basterà recuperare in qualsiasi momento il valore della proprietà IsLowMemoryDevice, che ci restituirà true se si tratta di un device con 256 MB di RAM, in caso contrario false. Il vantaggio è che non andremo ad interrogare tutte le volte la classe DeviceExtendedProperties: verrà fatto solo alla prima richiesta, dopo di che il valore verrà recuperato direttamente dallo storage.

Background agents

I background agents di tipo periodico (ovvero i Periodic task e i Resource Intensi ve tasks) sono l'unica feature di Windows Phone 7.5 che non è disponibile sui device con 256 MB di RAM: questo perchè, a causa della ridotta quantità di memoria disponibile, l'utilizzo di servizi in grado di girare in background potrebbe avere un impatto considerevole sulle prestazioni delle applicazioni in uso.

Se la vostra applicazione fa uso di un background agent, vi trovate nella situazione in cui dovete identificare la quantità di memoria disponibile nel device: se cercate infatti di aggiungere allo ScheduledActionService (la classe che rappresenta il gestore dei task in background in Windows Phone) un PeriodicTask o un ResourceIntensiveTask si scatenerà un'eccezione di tipo SchedulerServiceException con codice di errore 80040200.

clip_image002

Sfruttando la proprietà che abbiamo definito prima, il nostro codice dovrebbe diventare qualcosa del genere:

            if (!IsLowMemoryDevice)
            {
                PeriodicTask task = new PeriodicTask("Task")
                    {
                        Description = "D
escription of the task"
                    };
                ScheduledActionService.Add(task);
            }

Qualche considerazioni sui giochi

I giochi sviluppati con XNA sono sicuramente quelli che possono soffrire di più di questo limite, dato che tradizionalmente sono le applicazioni che richiedono maggiore memoria a causa dell'utilizzo di grafica 3D, suoni, musica, texture, ecc.

Alcuni consigli per ridurre il consumo di memoria ci arrivano direttamente dalla documentazione Microsoft:

· Valutare bene la qualità dei sample audio che si utilizzano. I giochi per Windows Phone vengono utilizzati in device dotati di una potenza di riproduzione audio inferiore rispetta a quella di una console, ad esempio: non sempre è necessario perciò utilizzare la massima qualità possibile.

· Limitare il numero di sample audio utilizzati, cercando di riutilizzare il più possibile quelli già allocati in memoria.

· Ricordarsi di effettuare il dispose degli oggetti di tipo SoundEffect una volta che si è terminato di usarli.

In questo ambito vi segnalo alcuni articoli interessanti disponibili in rete dedicati specificatamente all'ottimizzazione delle performance in ambito videoludico per Windows Phone:

· Compressing Vertex Data

· Performance Considerations for Applications in Windows Phone

· Texture Compression

Qualche considerazione sulle applicazioni

Le applic azioni "tradizionali" (tipicamente basate su Silverlight) possono soffrire meno di questa limitazione, dato la minore necessità di risorse: questo non significa però che non si debba stare attenti alle performance, soprattutto nell'utilizzo di alcuni controlli o in presenza di una grande quantità di dati da manipolare e visualizzare.

In particolare, i controlli Web Browser e Bing Maps possono avere un impatto non indifferente sulla quantità di memoria utilizzata, perciò se li utilizzate all'interno della vostra applicazione assicuratevi che non ci siano problemi anche con i device dotati di 256 MB di RAM. In caso affermativo, una possibile soluzione è quella di utilizzare i launcher appositi (WebBrowserTask e BingMapsTask) che, demandando l'operazione alle applicazioni native di Windows Phone, non vanno ad incidere sulla quantità di memoria utilizzata dalla vostra applicazione.

Un'altra considerazione è relativa alle liste: è facile rischiare di saturare la memoria se la nostra lista contiene una grande quantità di dati, o utilizza un template che mostra molte informazioni (magari anche complesse come immagini).

Il consiglio in questi casi è di ridurre al minimo indispensabile le informazioni mostrate nel template (delegandole magari alla pagina di dettaglio) e, eventualmente, implementare un meccanismo di paginazione, in modo che in memoria vengano mantenuti solamente i dati correntemente visualizzati.

Come testare le performance?

L'SDK di Windows Phone ci mette a disposizione due tool per ottimizzare le performance e capire l'effettivo consumo di memoria della nostra applicazione:

· Windows Phone Performance Analysis è un tool integrato nell'SDK a partire dalla versione 7.1 ed è un profiler molto potente che permette di valutare il consume effettivo di memoria, CPU e risorse di sistema della nostra applicazione. L'utilizzo è molto semplice: dopo aver collegato il nostro device, c i basta andare da Visual Studio nel menu Debug e scegliere l'opzione Start Windows Phone Performance Analysis. A questo punto potremo scegliere il tipo di analisi (relativa all'esecuzione o all'uso di memoria) e lanciare il profiler: l'applicazione verrà lanciata sul telefono e noi dovremo utilizzarla come se fossimo un utente normale. Una volta terminato, possiamo premere il pulsante Stop profiling in Visual Studio: il profiler elaborerà i dati raccolti e ce li presenterà sotto forma di grafico. Nell'immagine qui sotto potete vedere un esempio di profiling della memoria utilizzata da un'applicazione di test:

clip_image004

Vi suggerisco il seguente post sul blog del team di Windows Phone per approfondire l'argomento.

· Il Marketplace Test Kit: sempre a partire dalla versione 7.1 dei tool di sviluppo l'SDK include il Marketplace Test Kit, ovvero lo strumento utilizzato dal team di certificazione del marketplace per effettuare tutt i test automatici che precedono la validazione di un'applicazione. Tra questi test c'è anche quello relativo al consumo della memoria: l'approccio è simile a quello del profiler spiegato in precedenza. Cliccando con il tasto destro su un progetto, possiamo accedere al tool dalla voce Open Marketplace Test Kit: da lì possiamo accedere ai Monitored Test e, dopo aver collegato un device, lanciare il tutto con il p ulsante Start Application. Anche in questo caso dovremmo utilizzare l'applicazione normalmente, per poi terminare il test con il pulsante Close Application. La differenza sarà che come risultato avremo semplicemente il consumo massimo di memoria raggiunto dall'applicazione, come nell'immagine seguente:

clip_image006

E se non posso ridurre il consumo di memoria?

Ci possono essere particolari tipologie di applicazioni per cui non è possibile in alcun modo ridurre il consumo di memoria sotto i 90 MB: un gioco particolarmente elaborato, oppure un'applicazione fortemente legata all'utilizzo di background agent e che, senza di questi, perderebbe di valore.

In questi casi, abbiamo la possibilità di specificare nel file di manifest (WMAppManifest.xml) che la nostra applicazione utilizza più di 90 MB di RAM, evitando così che chi ha un device con 256 MB di RAM possa scaricarla dal Marketplace.

Per farlo, vi basta aggiungere il seguente blocco all'interno del nodo App del file WMAppManifest.xml (contenuto all'interno della cartella Properties di un progetto Windows Phone):

    <Requirements>
      <Requirement Name="ID_REQ_MEMORY_90" />
    </Requirements>

Se siete sicuri che la vostra applicazioni utilizzi più di 90 MB di RAM, è molto importante che vi ricordiate di aggiungere questa dichiarazione: in caso contrario, anche gli utenti con 256 MB di RAM potranno scaricarla e magari lasciarvi delle recensioni negative perchè sperimentano problemi di crash che non sono legati a bug della vostra applicazione, ma al quantitativo di memoria usata.


read full article

Guest Post: Introduzione a Web API

E-mail Stampa PDF

Questo Guest Post è stato scritto da Ugo Lattanzi, MVP ASP.NET

Introduzione

Con la nuova versione (in beta) di ASP.NET MVC 4, Microsoft ha rilasciato un'interessante novità chiamata Web API, che offre l'opportunità di esporre dei servizi web senza l'utilizzo di WCF o SOAP ma semplicemente basandosi su chiamate REST.

Con il diffondersi dei social network questo approccio ha preso il largo: le API di Twitter e Facebook funzionano in questo modo, ed oggi è possibile implementare qualcosa del genere riducendo drasticamente la pipeline della richiesta web.

In realtà questo framework era già presente nel mondo .NET, veniva hostato tramite Windows Comunication Foundation, e prendeva il nome di WCF Web API.

Purtroppo questo tipo di approccio risultava un po' macchinoso, ed in ogni caso richiedeva la conoscenza di WCF (attributi, configurazione etc); per questo motivo Microsoft ha deciso di spostare questo framework su ASP.NET.

Installazione

Se avete installato Visual Studio 2011 Beta non dovete far nulla, al suo interno è infatti contenuto ASP.NET MVC 4 e di riflesso il Web API. Al contrario potete scaricare il framework tramite il Web Platform Installer oppure la versione standalone da questo link.

Utilizzo

Essendo il Web API una parte di ASPNET MVC, è necessario selezionare quest'ultimo come template di progetto da Visual Studio e poi da lì scegliere Web API, come mostrato dallo screenshot seguente:

image

Una volta premuto "OK", Visual Studio provvederà a creare la struttura di folder necessaria alla nostra applicazione e, come potrete vedere dal Solution Explorer, questa non si discosta molto da quella creata tipicamente per un'applicazione ASPNET MVC.

La prima cosa da notare è la presenza di un controller chiamato ValuesController che, a differenza dei comuni controller MVC, eredita da una classe chiamata ApiController.

Al suo interno troviamo un set di Action (GET, POST, PUT e DELETE) che, a differenza delle action MVC, non sono mappate in base al nome della Action, ma in base alla loro azione.
Prima di addentrarci di più nel codice è necessario che sia ben chiaro questo concetto, quindi andiamo a vedere come le API vengono mappate all'interno del routing:

image

Con la WebAPI è stato introdotto un nuovo metodo per la classe RouteCollection, che ci consente di registrare le "rotte" - passatemi il termine - per i nostri ApiController.
A differenza del classico MapRoute potete notare l'assenza della action all'interno del routeTemplate; questo avviene perché il nome delle action invocate segue una rigida naming convention, che segue i metodi HTTP GET/POST/PUT/DELETE.

Questo vuol dire che, per un controller che dovrà gestire gli utenti, avremo un set di action come il se guente:

Action

http Method

Relative Uri

Recupera la lista di utenti

Get

Api/User/

Recupera uno specifico utente

Get(int id)

Api/User/Id/

Crea un nuovo utente

Post(User user)

Api/User

Aggiorna un utente

Put

Api/User/Id/

Cancella un utente

Delete

Api/User/Id/

Tradotto in codice, l'implementazione dello UserController potrebbe essere più o meno così:

image

A questo punto non vi resta che testare l'applicazione e, solo per le chiamate in GET, vi basterà digitare l'url direttamente nella finestra del browser http://localhost:1386/api/user/1 per verificare la risposta:

image


read full article

Guest Post: Introduzione a Windows Phone SDK 7.1.1 CTP

E-mail Stampa PDF

Guest Post di Matteo Pagani, MVP Windows Phone

Pochi giorni fa il team di Windows Phone ha rilasciato una nuova versione dei tool di sviluppo di Windows Phone, caratterizzata dal numero di versione 7.1.1.

Nota bene! La versione attuale dell'SDK 7.1.1 è in CTP (ovvero non è definitiva) e non ha la licenza go live: ciò significa che non potete pubblicare sul Marketplace applicazioni compilate con questa versione. Se volete perciò iniziare a fare esperimenti, vi consiglio di installare la nuova SDK su una macchina di test.

Non si tratta di una major release: l'unica novità è il supporto per i nuovi device low cost (come ad esempio il Nokia Lumia 610 presentato a Barcellona) che usciranno sul mercato, caratterizzati, oltre che da processori di potenza inferiore e da fotocamere con un numero ridotto di Mpixel, dalla presenza di 256 MB di RAM contro i 512 MB di cui sono dotati tutti i device attualmente in commercio.

La presenza di poche novità non significa che si tratti di una release di poco conto: la disponibilità di questi nuovi device apre infatti una serie di nuovi scenari, sia per gli utenti finali (questa strategia potrà sicuramente favorire una maggiore diffusione dei device Windows Phone) che per gli sviluppatori (che dovranno imparare a tenere conto del fatto che la loro applicazione potrà girare su device meno potenti).

In questo post vedremo come i tool e il sistema operativo si sono aggiornati per supportare questa nuova generazione di device.

L'emulatore

Per poter testare le nostre applicazioni su entrambe le tipologie di device senza doverli fisicamente possedere la nuova versione dei tool di sviluppo include un nuovo emulatore, in grado di simulare la presenza di 512 o 256 MB di RAM.

L'utilizz o è molto semplice: avete presente il menu a tendina incluso in Visual Studio che vi permette di specificare il target del deploy tra Windows Phone Device e Windows Phone Emulator? Questo menu è stato modificato, per supportare, oltre ovviamente al device, anche le due nuove tipologie di emulatore, come potete vedere nell'immagine:

clip_image001

Una volta lanciato l'emulatore, questi si comporterà come se avesse il limite di memoria che avete scelto, restituendo perciò un'eccezione nel momento in cui lo superate oppure nel caso in cui stiate usando qualche funzionalità non consentita sui device di fascia bassa.

Come identificare il tipo di device da codice

La strada migliore per poter supportare qualsiasi tipo di device è quella di migliorare il più possibile le performance della nostra applicazione, stando attenti agli sprechi e a consumi eccessivi che potrebbero essere risolti magari semplicemente con una progettazione migliore.

Ci sono però alcuni casi in cui proprio non è possibile ridurre il consumo di memoria, ad esempio perchè state utilizzando elementi multimediali (audio, video, immagini, ecc.) ad alta qualità. Quello che possiamo fare perciò, ad esempio, è non caricare determinate elementi oppure utilizzane degli altri di qualità inferiore. In questo caso ci serve però un meccansimo per riconoscere su che tipo di device è in esecuzione la nostra applicazione e, proprio per questo motivo, Microsoft ha aggiunto una nuova proprietà che ci restituisce la quantità massima di RAM disponibile all'applicazion e stessa.

Per ottenere questa informazione dobbiamo usare la classe DeviceExtendedProperties, disponibile sin dalla prima versione di Windows Phone, che ci permette di estrarre tutta una serie di dati riguardo al device come, ad esempio, l'ID univoco del device, la versione del firmware, ecc. (potete leggere questo post per approfondire l'argomento).

Nell'ultimo aggiornamento del sistema operativo è stata inclusa una nuova proprietà, chiamata ApplicationWorkingSetLimit, che rappresenta la massima quantità di memoria utilizzabile da un'applicazione. Tale valore sarà sempre inferiore ai 90 MB per i device con 256 MB di RAM: vi basta perciò recuperare questa proprietà per capire la tipologia di device. Vediamo come fare:

long memory = (long)DeviceExtendedProperties.GetValue("ApplicationWorkingSetLimit");

Questa istruzione vi restituirà la massima quantità di memoria utilizzabile dall'applicazione espressa in byte: il valore di riferimento è 94371840, che corrisponde a 90 MB (vi ricordo infatti che 1 KB corrisponde a 1024 byte, perciò non si tratta di un mulitplo preciso di 10).

La proprietà ApplicationWorkingSetLimit è disponibile però solo sui device che hanno già ricevuto l'update all'ultima versione di Windows Phone: può verificarsi perciò che la riga di codice riportata sopra restituisca un'eccezione di tipo ArgumentOutOfRangeException. In questa situazione avrete la certezza di trovarvi in presenza di un dispositivo con 512 MB di RAM (dato che i device di nuova generazione dotati di una quantità di RAM inferiore usciranno già in commercio con la versione più recente del sistema operativo). Per gestire questa casistica, la classe DeviceExtendedProperties espone un metodo TryGetValue, che accetta un ulteriore parametro in out. Cosa signific a? Che il metodo proverà a recuperare l'informazione richiesta e, in caso non si verifichino errori, andarà a salvarne il risultato nella variabile che abbiamo contrassegnato come out. In caso contrario, non si verificherà alcuna eccezione ma semplicemente il metodo restituirà false e la variabile indicata come out sarà impostata a null. Il codice seguente fa esattamente questa cosa: dopo aver dichiarato preventivamente una variabile di nome memory, cerchiamo di recuperare il valore della proprietà ApplicationWorkingSetLimit. Se il valore della variabile memory è a null oppure superiore a 94371840, allora siamo in presenza di un device dotato di 512 MB di RAM; in caso contrario, si tratta di uno dei nuovi device da 256 MB.

 object memory;
            DeviceExtendedProperties.TryGetValue("ApplicationWorkingSetLimit", out memory);
            if (memory == null || (long)memory > 94371840)
            {
                MessageBox.Show("Device con 512 MB di RAM");
            }
            else
            {
                MessageBox.Show("Device con 256 MB di RAM");
            }

Come ottimizzare la nostra applicazione?

Nel prossimo post vedremo l'impatto di questi nuovi device sulle nostre applicazioni: come ottimizzare l'uso della memori a, quali limiti dovremo gestire e come comportarci in caso non sia possibile ridurre in alcun modo il consumo di memoria da parte della nostra applicazione.


read full article

Intervista ad Alessandro Del Sole : Visual Basic MVP of The Year 2012

E-mail Stampa PDF

imageSono molto contento di pubblicare una breve intervista al mitico Alessandro Del Sole, nominato MVP of The Year per il terzo anno consecutivo!

Q: "Ciao Alessandro e complimenti per il terzo award consecutivo come MVP Of The Year per Visual Basic. Puoi spiegarci come avviene questa nomina?"

A: "Ciao a tutti e grazie per l'ospitalità! La nomina a MVP Of The Year avviene a seguito di una votazione fatta dagli MVP di tutto il mondo nell'ambito dell'expertise di appartenenza e da personale di Microsoft che segue l'expertise stessa. Si viene quindi premiati per i contributi di community relativi all'anno precedente, quindi per il 2011 in questo caso."

Q: "Sei l'unico italiano ad essere stato premiato per tre volte, per giunta di seguito e probabilmente uno dei pochi al mondo come numero di volte. Cosa vuol dire per te essere MVP Of The Year e più in generale un Microsoft MVP?"

A: "Indubbiamente è un grandissimo onore oltre che una profonda soddisfazione, perchè l'award arriva a seguito di ciò che viene espresso dai propri pari di tutto il mondo e quindi lo ritengo un grande attestato di stima e apprezzamento verso le mie attività, soprattutto quelle in inglese anche perchè non è la mia madre lingua. Ho avuto la possibilità di conoscere di persona S. Somasegar, Jason Zander e altri nomi noti a chi sviluppa con Visual Studio, più in generale attraverso il programma MVP ho avuto la possibilità di stringere tante amicizie sincere che vanno oltre l'aspetto tecnico e per me questo è il lato più importante. Il tutto chiaramente ha, alla base, la vita di community. Continuo a sostenere che se Visual Basic Tips & Tricks (nel mio caso) non fosse esistita, e se tante persone non vi fossero state coinvolte anche solo nei forum, non avrei sicuramente raggiunto determinati risultati. Io, poi, ho solo messo la stessa passione e lo stesso entusiasmo di sempre. E' quindi alla community che va il mio primo ringraziamento, a cui segue quello a tutti coloro che hanno riposto in me questa fiducia."

Q: "Hai da poco pubblicato il libro Visual Studio LightSwitch Unleashed. Quali sono i tuoi prossimi progetti?"

A: "Il rilascio della Beta di Visual Studio 11 mi mette già in condizione di pensare alla prossima edizione del libro su Visual Basic, sempre per la serie Unleashed di SAMS, e sicuramente in cantiere c'è lo sviluppo di app Metro per Windows 8, rigorosamente XAML + VB!"

Un in bocca al lupo ad Alessandro da parte di tutto il team MSDN, siamo veramente orgogliosi!!!

-Lorenzo


read full article

Vieni a scoprire le novità di Windows 8 al Creativity Day di Milano

E-mail Stampa PDF

image

Anche quest'anno Microsoft sarà presente al Creativity Day, una giornata gratuita di seminari e workshop con ospiti nazionali ed internazionali a Milano il 9 marzo e a Roma il 28 marzo.

Con l'occasione dell'uscita della Consumer Preview di Windows 8, potrai conoscere le novità di Windows 8 e della nuova interfaccia Metro per sviluppare le tue prossime applicazioni. Potrai anche toccare con mano i nuovi device, grazie alla collaborazione con Samsung che porterà alcuni esemplari della Serie 5 e 7!

Inoltre, alle 12.30 Roberto Cavallini terrà una sessione sul linguaggio Metro per lo sviluppo di Apps da Windows Phone a Windows 8.

Ulteriori informazioni e iscrizioni su http://www.insidesrl.it/creativityday/2012/index.cfm

Ci vediamo venerdì a Milano e se non potete, il 28 marzo a Roma!

Francesca


read full article

19 e 20 marzo, Milano: Windows 8 Developer Events

E-mail Stampa PDF

image

È con molto piacere che ti invitiamo al primo evento tecnico, in italiano e gratuito, su Windows 8, fatto da Microsoft. Il 19 marzo, al Microsoft Innovation Campus di Peschiera Borromeo, potrai toccare con mano i nuovi device, comprendere i principi dello sviluppo METRO, parlare con esperti italiani e internazionali ed essere tra i primi a sviluppare per Windows 8!

Quindi, se stai pensando di sviluppare per Windows 8 e vuoi essere tra i primi ad avere una app sul marketplace, questo è l'evento da seguire! I posti a sedere sono limitati, iscriviti oggi stesso a questo link!

A seguire questo evento teorico di una giornata, il 20 marzo si terrà un laboratorio pratico e molto interattivo in cui potrai iniziare a sviluppare le applicazioni Windows 8 supportati da esperti di Microsoft e delle Community. I posti nel lab sono poche decine, per cui se sei *davvero* interessato a sviluppare un'app da m ettere sul marketplace, iscriviti anche qui!

clip_image001

Ma le novità non finiscono qui! Gli eventi per gli sviluppatori sono in tutta Italia... Sul nostro nuovo sito START SOMETHING! è possibile consultare l’elenco degli eventi disponibili e iscriversi direttamente.

Tutti gli eventi sono gratuiti, ma i posti sono limitati. Ti chiediamo quindi di iscriverti se sei interessato ad essere i primi a pubblicare la tua App sul nuovo Windows Store e pensi di partecipare!

Buon Windows 8!
Francesca

 


read full article

Pagina 21 di 49

 
 
 
 
Certificazioni