The launch of the new Dynamics AX is imminent. Join the Virtual Launch Event on March 9^th 2016 by registering here!

At BETT 2016 I spent some catching up with news from Microsoft Partner Capita. It was good news, too. They were delighted to have won a BETT Award – ‘Best ICT Tool for Teaching, Learning and Assessment’ no less – for their ‘SIMS Assessment’ product which, especially in combination with their ‘Teacher App’, which is available for Windows, considerably eases the process of classroom assessment.

At BETT 2016 I spent some catching up with news from Microsoft Partner Capita. It was good news, too. They were delighted to have won a BETT Award – ‘Best ICT Tool for Teaching, Learning and Assessment’ no less – for their ‘SIMS Assessment’ product which, especially in combination with their ‘Teacher App’, which is available for Windows, considerably eases the process of classroom assessment.

• Root Cause: Initial root cause was due to a new feature that was introduced and we disable it to mitigate the issue.  We will provide the underlying root cause as soon as it is available.

Initial Update: Wednesday, 2 March 2016 20:47 UTC

We are actively investigating issues with Service Hooks. Some customers may notice exceptions issues setting up service hook triggers. We are working to resolve this issue and apologize for any inconvenience.

Sincerely,
Manjunath

Developing for Continuum means building an adaptive Universal Windows Platform (UWP) app that runs on any screen size, powered by a phone.

There are a handful of considerations for developers as they think about Continuum. Some of these considerations are integral to your success on our platform, and some are more advanced and therefore optional. The following blog take you through the 4 key stages of developing an continuum supported app and looks at factors and constraints you should be aware of when building an experience which goes from a small phone to a large screen.

Required:

1. Adaptive Apps

2. App packaging

Optional:

3. Scaling Assets

4. Multi-screen experiences

1. Adaptive Apps

When a user is interacting with our feature, we generally expect that they should see “phone optimized” UI on the phone, and “big screen optimized UI” on the big screen.

If a user is interacting with a windows app targeting the universal device family, they will see the same UI they would see on a Windows desktop machine on the big screen.

If the user is interacting with a mobile only app, they will see mobile UI reflowed to fit the big screen.

Using Effective Pixel Sizes

You design a UWP app in effective pixels, not physical pixels this enable you to focus on the actual perceived size of a UI element without worrying about pixel density or viewing distance. A 1” x 1” element will appear to be 1” on all devices . This might correlate to 150x150 physical pixels on a phone, or 200x200 on a large screen, but you need only design once in effective pixels

Responsive design is key!

If you app is designed for a phone, it might look sparse on a large screen. A phone might have a camera or GPS. Navigation on bottom of screen is better for phones, while navigation at top is better for mouse.

When you optimize your app's UI for specific screen widths, we say that you're creating a responsive design. Here are six responsive design techniques you can use to customize your app's UI.

1. Resize

Given a windows size change, your app should resize to any screen.

You can optimize the frame size by adjusting the margins and size of UI elements. This could allow you, as the example here shows, to augment the reading experience on a larger screen by simply growing the content frame.

One way to help resize content is to use percentage-based layouts

In this view: three main UI elements

A photo takes up 100% of the screen width along the top

A personal feed takes up 1/3 of the screen width on the bottom left

An info card takes up 2/3 of the screen width on the bottom right

Also note that all text is right or left justified in each UI element. Text has well defined location

2. Reflow

Change the flow of UI elements based on device and orientation for optimal content display

Large screen – makes sense to switch to larger containers, add columns, and generate list items differently

Example – single column of vertically scrolling content on a phone can reflow on a larger screen to two columns

WrapGrid style controls can be used for text, images, and any other grid-like set of assets.

3. Reveal

You can reveal or hide content based on screen real estate, or when a device supports additional functionality (such as new input types), specific situations, or preferred screen orientations.

In this example with tab, the middle tab with the camera icon might be specific to the app on a phone, but not applicable on larger devices.

It is common for PCs to demonstrate more robust controls due to larger screen size and more powerful device capabilities

Phone – show minimal metadata

PC – show more metadata

In an email app, you can display the user's avatar.

In a music app, you can display more info about an album or artist.

In a video app, you can display more info about a film or a show, such as showing cast and crew details.

In any app, you can break apart columns and reveal more details.

In any app, you can take something that's vertically stacked and lay it out horizontally. When going from phone or phablet to larger devices, stacked list items can change to reveal rows of list items and columns of metadata.

4. Replace

This technique lets you switch the user interface for a specific device size-class or orientation.

In this example, the nav pane and its compact, transient UI works well for a smaller device, but on a larger device tabs might be a better choice.

5. Reposition

You can alter location and position of app UI for optimum use of screen space.

In this example, the portrait view on phone or phablet necessitates a scrolling UI because only one full frame is visible at a time.

When the app translates to a device that allows two full on-screen frames, whether in portrait or landscape orientation, frame B can occupy a dedicated space.

If you're using a grid for positioning, you can stick to the same grid when UI elements are repositioned.

6. ReArchitect

You can collapse or fork the architecture of your app to better target specific devices. In this example, going from the left device to the right device demonstrates the joining of pages.

You might also want to tear down and re-architect your apps entire navigation model and layout.

You may even have separate views for different device families or screen sizes. This is a very advanced scenario.

Here you can see that on large screens this UI has two distinct columns. Below a set screen width, the app collapses into a single column view.

You can collapse or fork the architecture of your app to better target specific devices. In this example, going from the left device to the right device demonstrates the joining of pages.

BreakPoints

The number of device targets and screen sizes across the Windows 10 ecosystem is too great to worry about optimizing your UI for each one.

Instead, we recommended designing for a few key widths (also called "breakpoints"): 320, 720, and 1024 epx.

Tip  When designing for specific breakpoints, design for the amount of screen space available to your app (the app's window). When the app is running full-screen, the app window is the same size of the screen, but in other cases, it's smaller.

“phone optimized UI” when the screen width is < 800x600, and big screen UI >= 800x600

This is general guidance, and you should feel free to base UI decisions off of other triggers, such as input.

Design adaptive UI in XAML with adaptive panels and controls

StackPanel

StackPanel is a layout panel that arranges child elements into a single line that can be oriented horizontally or vertically.

   1:<StackPanel Margin="20"> 

   2:<Rectangle Fill="Red" Width="50" Height="50" Margin="5" /> 

   3:<Rectangle Fill="Blue" Width="50" Height="50" Margin="5" /> 

   4:<Rectangle Fill="Green" Width="50" Height="50" Margin="5" /> 

   5:<Rectangle Fill=“Yellow" Width="50" Height="50" Margin="5" /> 

   6:</StackPanel>

VariableSizedWrapGrid

VariableSizedWrapGrid is layout panel that supports arranging child elements in rows and columns. Each child element can span multiple rows and columns.

The VariableSizedWrapGrid class make it easy to wrap pictures and text in a grid according to window size.

   1:<VariableSizedWrapGrid> 

   2:<Image Name="MyBigImage"

   3:      VariableSizedWrapGrid.ColumnSpan="2"                              VariableSizedWrapGrid.RowSpan="2"

   4:      ... 

   5:     /> 

   6:     ... 

   7:</VariableSizedWrapGrid>

Relative Panel

Use the RelativePanel class to ensure that UI elements are correctly positioned relative to each other and the container across all screen sizes.

Using this class with percentage-based layouts and wrap grid controls will allow you to build an adaptive app that reflows automatically to any screen size

The RelativePanel class allows you to anchor UI elements relative to each other and the container such that they reflow to any screen size.

   1:<RelativePanel BorderBrush="Gray" BorderThickness="10"> 

   2:<Rectangle x:Name="RedRect" Fill="Red" MinHeight="100" MinWidth="100"/> 

   3:<Rectangle x:Name="BlueRect" Fill="Blue" MinHeight="100" MinWidth="100"

   4:             RelativePanel.RightOf="RedRect" /> 

   5:<!-- Width is not set on the green and yellow rectangles. 

   6:         It's determined by the RelativePanel properties. --> 

   7:<Rectangle x:Name="GreenRect" Fill="Green" MinHeight="100" Margin="0,5,0,0"             RelativePanel.Below="RedRect"

   8:         RelativePanel.AlignLeftWith="RedRect"                             RelativePanel.AlignRightWith="BlueRect"/> 

   9:<Rectangle Fill="Yellow" MinHeight="100"

  10:         RelativePanel.Below="GreenRect"

  11:         RelativePanel.AlignLeftWith="BlueRect"                             RelativePanel.AlignRightWithPanel="True"/> 

  12:</RelativePanel>

SplitView

Here's a SplitView control with an open Pane appearing inline next to the Content.

The SplitView class can be used to create a top-level navigation experience, adjusted according to window size.

   1:<SplitView IsPaneOpen="True"

   2:        DisplayMode="Inline"

   3:        OpenPaneLength="296"> 

   4:<SplitView.Pane> 

   5:<TextBlock Text="Pane"

   6:         FontSize= "24"

   7:         VerticalAlignment="Center“

   8:         HorizontalAlignment="Center"/>     

   9:</SplitView.Pane> 

  10:  

  11:<Grid> 

  12:<TextBlock Text="Content" 

  13:         FontSize="24" 

  14:         VerticalAlignment="Center" 

  15:         HorizontalAlignment="Center"/> 

  16:</Grid> 

  17:</SplitView>

VisualStateManger

The VisualStateManager allows you to adapt the visual state of your app in response to changes in Window size or some other state trigger.

StateTriggers define a threshold at which a visual state is activated, which then sets layout properties as appropriate for the window size that triggered the state change.

Let’s talk about how a few common state triggers might apply to Continuum. You can use adaptive triggers to resize, reveal, hide, or reposition UI at specific snap points.In this example, a developer wants to change the style of button they use above a set screen width. For large screens, with a width greater than 800 effective pixels, the developer will to show a “wide” button.Narrow button is triggered when the wide button trigger (>800) is no longer satisfied

Note, that snap points are not always related to screen width - you could use primary input method, device family, or some custom trigger

Sometimes you don’t want to use screen width as your main trigger.

UserInteractionMode

UserInteractionMode is another option,this API gives you context about the form factor of the display your app is running on. 

It returns “mouse” when the device UI is optimized for mouse input, and “touch” when the device UI is optimized for touch input.  These returns do not describe the current input method, but rather what input method the shell your app is running in is optimized for.

With Continuum, “touch” will always be returned when your app is on the mobile device, and “mouse” will always be returned when your app is on the connected display. 

UserInteractionMode will only change when your app is moved between screens.  UserInteractionMode does not send events – you’ll need to query this API upon receiving a SizeChanged event.  Note that UserInteractionMode is also used to inform developers when a desktop device is in tablet mode – Continuum is not the only use case.

Here is an example of how you might use UserInteractionMode in C# to switch between a mobile view and a desktop view for Continuum.

point: navigating to specific page based on size rather than device family

DisplayInformation

The DisplayInformation class monitors and controls physical display information.  This class provides events to allow clients to monitor changes in the display an app view is running on.  You can use DisplayInformation to tailor experiences based on display properties.  For example, if you want your app to adapt based on the physical screen size of the device (as an estimate for form factor), you can use the DiagonalSizeInInches property as a trigger.

There are two view states

The first is the “wideView”

Triggered when window wise is 720 pixels or more in width, using AdaptiveTriggers

Arranges best rated games panel to the right of, and aligned with the top of top free games, using relativepanel class

The 2nd view is the “NarrowView”

Triggered when window wide view trigger is not longer satisfied, using AdaptiveTriggers

Arranges best rated games panel below and aligned with the left of top paid games, using relativepanel class

2. App packaging

The best thing you can do is build a windows app and package it in a universal app package.

This means that your app will be packaged and deployed across all windows device families.If you are doing this, we assume that you have used the adaptive principles we discussed to ensure your app dynamically reflows to any screen size. You’re already doing everything you need to do to work on continuum.

A universal app package is a great aspiration, but we understand that a lot of developers are coming from a mobile-only background and intend to stay mobile-only.This is fine! If you build your mobile app with fluid, responsive, and/or tailored UI, you should get some basic reflow and adaption for free.That being said, you may not be happy with the basic reflow that you get for free.

Use adaptive techniques to make app look better

If you have a desktop view available from a separate desktop app, pull it in and trigger the use of it when appropriate. You can use adaptive triggers or UserInteractionMode for this, if you find yourself wanting to do a lot of optimizations for Continuum, we suggest considering converting to a universal windows app.

By building a universal windows app, all of your optimizations will be realized across all Windows platforms including desktop and Xbox. If your mobile app isn’t ready for Continuum right away, no worries.  Simply add the following lines to your manifest to block your app on the connected display.  Making this change will cause your app tile to be greyed out on the connected display’s Start menu until it is enabled.

Add namespace to package tag

Set “true/false” restriction value in your application

When your app is ready for Continuum, simply set RestrictToInternalScreen to “false” and submit an update!

If your mobile app isn’t ready for Continuum right away, no worries. 

Simply add the following lines to your manifest to block your app on the connected display.  Making this change will cause your app tile to be greyed out on the connected display’s Start menu until it is enabled.

-Add namespace to package tag

-Set “true/false” restriction value in your application

-When your app is ready for Continuum, simply set RestrictToInternalScreen to “false” and submit an update!

3. Scaling Assets

Reference resources with a URI, leaving out the "scale-xxx". 
The platform does the rest for you.

"ms-appx:///Assets/Logo.png"

"ms-appx:///desktop.png"

An image tag in XAML could look like this:

4. Multi-screen experiences

CAST API - Cast media content to the connected display

ProjectionManager API -  Create two fully-customizable views, one on each display

i hope this has provide a good introduction to the opportunity of developing Windows UWP apps which support Windows Continuum for Windows Phone.

For more details on window development see http://dev.windows.com

For more technical resources on continuum see https://msdn.microsoft.com/en-us/library/windows/hardware/dn917883(v=vs.85).aspx

こんにちわ。テクニカルエバンジェリストの渡辺です。

2/27（土）に、筑波大学附属駒場中・高等学校で開催された中学・高校の教職員向けセミナー「第2回 Visual Basic で進めるプログラミング学習」に参加してきました。

このセミナーは、中学・高校の技術・家庭科の教職員の方を対象としたセミナーです。学校現場の技術・情報科の教員の方々とIT企業、教科書会社がプログラミング学習研究会で、長年にわたり研究を重ねた成果として、教育図書から「Visual Basic 教えて学ぶプログラミング」が出版されています。こちらの教科書の紹介を兼ねたセミナー（＆ワークショップ）となっています。

第1部では、筑波大学の市川道和先生から、「プログラミング学習のIndispensability」という題で、講演がありました。市川先生には、Imagine Cup 2010 日本代表（筑駒の学生さんのチーム）のメンターとしても大変お世話になっています。"Indispensability" （絶対必要なこと）というタイトルからわかる通り、現在の我々の仕事、生活、社会は、プログラミング（その成果としてのソフトウエア）が支えているという仮説から出発して、プログラミング学習を必要不可欠な技術教育として実施していくことの重要性を提言されていました。

第2部、第3部では、「プログラムとは」という題で、まず、日本マイクロソフトの冨沢高明より、チューリングマシンの解説からスタートするプログラムの原理と仕組みについての講演があり、続いて、テックステートの杉田和久様より、プログラミング言語 Visual Basic を活用したプログラミングについての講演がありました。

第4部は、筑波大学附属駒場中学校の渡邉隆昌先生を講師として、実際に、ライントレースカーをVisual Basicで制御するワークショップが行われました。筑波大学附属駒場中学校の学生さんが使っている環境（デスクトップPC）で、実際にVisual Studioを起動し、Visual Basicのコードを記述してライントレースカーを動かしていきます。

自分が書いたプログラム（コード）によって、目の前のライントレースカーが動き出す。これを体験することは、想像以上に楽しいものです。プログラミング学習とは、この楽しさを通じて、学生さん達の知的好奇心を駆り立てることに尽きるのではないでしょうか？

日本の全ての中高生の皆さんに、ぜひ、このカリキュラムを使った授業を受けて欲しいと思った有意義な一日でした。

Questo post è stato scritto da Matteo Pagani, Windows AppConsult Engineer in Microsoft

La sincronizzazione dei dati delle applicazioni sta diventando, nel mondo mobile, un'esigenza sempre più frequente. Sono molteplici, infatti, i device con cui un utente interagisce quotidianamente: smartphone, tablet, pc, ecc. Spesso, anche se in contesti diversi, utilizziamo la stessa applicazione su ognuno di questi dispositivi e ci aspettiamo che i nostri dati e le nostre attività siano sempre sincronizzati.

I client di posta sono un ottimo esempio di questo scenario: la loro utilità sarebbe molto ridotta se, dopo aver letto una serie di mail sul telefono, le trovassimo ancora marcate come da leggere spostandoci sul PC o sul tablet.

Nel mondo delle Universal Windows app per Windows 10 questo scenario è ancora più frequente: la stessa applicazione, infatti, è in grado di girare sul telefono, sul desktop, sul tablet, ecc., quindi la sincronizzazione dei dati non è più una funzionalità facoltativa, ma diventa uno dei requisiti fondamentali da implementare.

La soluzione più efficiente per gestire questo requisito è sicuramente quello di affidarsi alle Mobile App di Azure. Tra le varie funzionalità, offre anche la possibilità di mantenere un database nel cloud, i cui dati vengono automaticamente sincronizzati in locale (sfruttando SQLite) tra le varie applicazioni mobile. I vantaggi delle Mobile App sono molteplici:

1. Supporto cross-platform: esiste un SDK per tutte le principali piattaforme mobile. Ciò ci permette di sincronizzare i nostri dati non solo all'interno della stessa Universal Windows app che gira su molteplici device, ma anche tra le eventuali versioni della nostra app per Android e iOS.
2. Gestione dei conflitti: l'SDK si fa carico, in automatico, di risolvere le principali tipologie di conflitti che si possono verificare negli scenari di sincronizzazione dati.
3. Supporto all'offline: l'SDK è in grado di funzionare anche in mancanza di connettività. I dati saranno semplicemente mantenuti nel database SQLite locale, per poi essere sincronizzati con il database nel cloud appena la connettività sarà ripristinata.

Per alcuni scenari, però, le Mobile App di Azure possono essere fin troppo potenti rispetto ai nostri requisiti. Ad esempio, a volte non ci serve implementare una vera e propria sincronizzazione dati, ma semplicemente offrire delle funzionalità di backup e ripristino, per permettere all'utente di non perdere i dati nel caso in cui cambi telefono o debba fare un reset di quello attualmente in suo possesso.

In questo caso, possiamo trovare un valido alleato in OneDrive, il cloud storage di Microsoft. In una Universal Windows app, infatti, possiamo darne praticamente per scontata la disponibilità: per poter usufruire, infatti, di tutti i servizi offerti da Windows e poter installare applicazioni dallo Store è necessario un Microsoft Account, che include anche l'accesso a OneDrive.

Il team di OneDrive, recentemente, ha introdotto un nuovo modello di sviluppo, basato su un set di API REST facilmente utilizzabili da qualsiasi piattaforma. Inoltre, sono stati realizzati una serie di SDK specifici per le piattaforme principali, come Windows, Android e iOS, che ne semplificano l'utilizzo all'interno di un'applicazione. Uno dei punti di forza di queste nuove API è la maggiore flessibilità rispetto alla precedente Live SDK; se avete già avuto modo di utilizzarle in passato, ricorderete che non erano particolarmente adatte per scenari di sincronizzazione, in virtù del fatto che, ad ogni accesso a OneDrive, era richiesta una esplicita autorizzazione all'utente tramite un popup.

Ora, invece, questo vincolo è stato rimosso: l'utente dovrà autenticarsi solo la prima volta, dopodiché l'SDK potrà essere utilizzata in maniera "silente". C'è di più: in una Universal Windows app avremo la possibilità di sfruttare direttamente il Microsoft Account del dispositivo, senza dover richiedere all'utente di effettuare manualmente il login.

Ma andiamo per gradi e vediamo come sfruttare l'SDK di OneDrive in una Universal Windows app per gestire alcune funzionalità base: login, creazione di cartelle, upload e download di file. Come esempio, realizzeremo una semplice applicazione in grado di effettuare l'upload di un'immagine contenuta all'interno del progetto Visual Studio e, successivamente, di scaricarla nuovamente in una cartella scelta dall'utente.

In uno scenario reale di backup & ripristino, al posto di un'immagine avremmo un database SQLite o un file JSON o XML memorizzato nello storage locale. Le API che andremo ad utilizzare, però, sono le medesime e non sono legate alla posizione e alla tipologia di file che vogliamo caricare o scaricare da OneDrive.

Installare l'SDK e configurare l'applicazione

Per quanto riguarda il mondo Windows, l'SDK C# è disponibile sotto forma di Portable Class Library, pubblicata come progetto open source su GitHub all'indirizzo https://github.com/onedrive/onedrive-sdk-csharp

Per semplificare l'installazione l'SDK è disponibile anche come pacchetto NuGet: l'identificativo da cercare nella schermata di NuGet è Microsoft.OneDriveSDK.

Una volta installata, siamo pronti per iniziare a utilizzarla. Uno dei concetti base delle API di OneDrive è l'autenticazione: per motivi di sicurezza, l'applicazione deve essere opportunamente configurata per poter utilizzare le API. L'obiettivo è quello di evitare che eventuali tentativi di hacking (ad esempio, intercettazione del traffico di rete) possano consentire semplicemente ad altre applicazioni o utenti di accedere al vostro account OneDrive.

Per poter utilizzare le API, perciò, la vostra Universal Windows app deve essere registrata sul Dev Center, sfruttando l'opzione Associate app with the Store che trovate all'interno del menu Store che compare facendo clic con il tasto destro sul progetto in Visual Studio. Completando la procedura guidata, l'applicazione sarà registrata sullo Store e, di conseguenza, potrà accedere a tutta una serie di servizi che richiedono l'autenticazione (ad esempio, uno di questi sono le notifiche push).

Ora che abbiamo compiuto questa operazione, siamo pronti per iniziare la fase di login, così da chiedere all'utente l'autorizzazione ad accedere al suo account OneDrive.

L'autenticazione

In caso di utilizzo all'interno di una Universal Windows app non dovremo fare alcuna operazione particolare per gestire l'autenticazione. Il grosso del lavoro, infatti, verrà svolto dall'SDK, che si farà carico di gestire tutto il processo. Esistono due modalità per gestire l'autenticazione:

1. Tramite OnlineIdAuthenticator: con questo approccio, l'utente sarà automaticamente loggato con il Microsoft Account del device e dovrà solamente, al primo tentativo di login, confermare l'autorizzazione.
2. Tramite WebAutenthicationBroker: con questo approccio viene proposto all'utente un popup, all'interno del quale, tramite una WebView, gli verrà chiesto di confermare le sue credenziali.

Per ora ci concentreremo sul primo approccio, più semplice per lo sviluppatore e per l'utente finale. Questo approccio ha però un limite: può essere utilizzato solamente se la nostra applicazione prevede di utilizzare le API di OneDrive in foreground, ovvero mentre l'applicazione è in esecuzione. Se vogliamo poter sfruttare queste API anche all'interno di un background task (ad esempio, per effettuare delle sincronizzazioni periodiche in automatico), dovremo usare il secondo metodo di login, che tratteremo più avanti nel corso del post.

Partiamo perciò dal primo approccio, basato sull'OnlineIdAuthenticator. In questo caso, la configurazione da fare è veramente minima: tutte le informazioni relative all'applicazione che si dovrà autenticare saranno prese in automatico dallo Store, grazie all'associazione che abbiamo fatto in precedenza.

L'unica cosa che dobbiamo definire sono gli scope, ovvero quali funzionalità esposte dall'SDK di OneDrive vogliamo utilizzare: le troviamo elencate all'indirizzo https://dev.onedrive.com/auth/msa_oauth.htm#authentication-scopes.

Gli scope più comunemente utilizzati sono:

• wl.signin, che ci permette di sfruttare il single sign-on.
• wl.offline_access, che ci permette di interagire con OneDrive senza richiedere continuamente l'autorizzazione all'utente.
• onedrive.readwrite, che ci garantisce la possibilità di scrivere e leggere file sull'account dell'utente.

Una volta che abbiamo definito gli scope che vogliamo utilizzare, dobbiamo includerli all'interno di un array di stringhe, come nell'esempio seguente:

privatereadonlystring[] Scopes = new[] { "wl.signin", "wl.offline_access", "onedrive.readwrite" };

Tale array è il parametro che dobbiamo passare al metodo di autenticazione che, nel caso di una Universal Windows app, viene reso disponibile dalla classe OneDriveClientExtensions e si chiama GetClientUsingOnlineIdAuthenticator(). Il suo utilizzo è molto semplice, come possiamo vedere nell'esempio seguente:

privateasyncvoid OnOneDriveLogin(object sender, RoutedEventArgs e)

{

IOneDriveClient client = OneDriveClientExtensions.GetClientUsingOnlineIdAuthenticator(Scopes);

await client.AuthenticateAsync();

}

A questo punto all'utente comparirà una finestra di dialogo, nella quale dovrà confermare di voler autorizzare l'applicazione ad accedere a OneDrive e sfruttare i permessi richiesti con lo scope. Sarà la prima e ultima volta che l'utente vedrà questa schermata: da questo momento in poi, qualsiasi successiva chiamata al metodo AuthenticateAsync() verrà eseguita in maniera silenziosa, senza richiedere nuovamente il permesso all'utente.

Il punto di forza di questo approccio è che tutto il meccanismo di autenticazione richiesto dalle API REST sarà a noi completamente trasparente. Ciò che conta è che ora siamo in possesso di un oggetto di tipo IOneDriveClient valido, che ci permetterà di effettuare tutte le operazioni base con lo storage di OneDrive.

Gestire file e cartelle

L'SDK di OneDrive ricalca la struttura delle API REST, offrendo una serie di classi e metodi che richiamano l'utilizzo dei comandi del protocollo HTTP, come POST, GET, PUT, ecc. Una classe fondamentale che dovremo imparare a conoscere è Item, che rappresenta qualsiasi elemento memorizzato su OneDrive, indipendentemente che sia un file o una cartella. Potremo capire la tipologia di elemento grazie alla proprietà Folder: se questa è null, significa che si tratta di un file; in caso contrario, è una cartella. Oltre a Folder, la classe Item contiene molte altre proprietà che ci permettono di recuperare informazioni dettagliate sull'elemento, come identificativo (Id), descrizione (Description), data di creazione e ultima modifica (CreatedDateTime e LastModifiedDateTime) e così via.

Il punto di partenza per lavorare con questi oggetti è la proprietà Drive, che rappresenta lo storage OneDrive dell'utente; da lì possiamo sfruttare la proprietà Root, che identifica la radice dello storage, quella che contiene tutti i file e le cartelle dell'utente.

Un'operazione fondamentale per il nostro scenario è la creazione di cartelle: come impostazione predefinita, infatti, non avremo la possibilità di scrivere file direttamente nella root dello storage OneDrive. Nell'ottica, perciò, di offrire funzionalità di sincronizzazione o di backup e restore dei dati della nostra app, dovremo creare una cartella, all'interno della quale memorizzare il (o i) file di backup.

Abbiamo detto che una cartella non è altro che un oggetto di tipo Item con la proprietà Folder valorizzata. Ecco, perciò, come appare la definizione di una nuova cartella:

Item newItem = newItem

{

Name = "OneDrive Sample",

Folder = newFolder()

};

A questo punto possiamo crearla sull'account OneDrive dell'utente:

Item newItem = newItem

{

Name = "OneDrive Sample",

Folder = newFolder()

};

await _client.Drive.Root.Children.Request().AddAsync(newItem);

Ogni cartella su OneDrive espone una proprietà di nome Children, che permette di accedere agli elementi figli, come file e sottocartelle. La cartella speciale Root non fa eccezione, perciò ne sfruttiamo la proprietà Children per interagire con gli elementi al suo interno.

Quello che vedete è un classico esempio di utilizzo dell'SDK di OneDrive: dopo aver identificato l'elemento con cui vogliamo interagire, creiamo la richiesta tramite il metodo Request(), che ci mette poi a disposizione i vari metodi (che, solitamente, combaciano con quelli del protocollo HTTP) per effettuare le operazioni vere e proprie. In questo caso, l'aggiunta di un nuovo elemento (la cartella) viene effettuata tramite il metodo AddAsync(), che richiede come parametro l'oggetto Item che rappresenta l'elemento da creare.

Possiamo già mettere alla prova il lavoro svolto finora: se eseguissimo questo blocco di codice, troveremmo all'interno del nostro account OneDrive una nuova cartella di nome OneDrive Sample.

Upload di file

Vediamo ora come gestire la procedura di backup, ovvero come caricare su OneDrive il file che contiene i dati della nostra applicazione: potrebbe essere un database SQLite, un file XML o JSON, ecc.

In questo esempio, ipotizziamo di caricare all'interno della cartella creata in precedenza un'immagine, che abbiamo incluso all'interno del progetto di Visual Studio. Ecco come fare:

privateasyncvoid OnUploadFile(object sender, RoutedEventArgs e)

{

StorageFile file = awaitPackage.Current.InstalledLocation.GetFileAsync("Wallpaper.png");

using (Stream stream = await file.OpenStreamForReadAsync())

{

await _client.Drive.Root.ItemWithPath("OneDrive Sample/Wallpaper.png").Content.Request().PutAsync<Item>(stream);

}

}

Il primo passo è recuperare un riferimento all'oggetto di tipo StorageFile (la classe base della Universal Windows Platform che rappresenta i file) che vogliamo caricare su OneDrive. In questo esempio, utilizziamo la classe Package.Current.InstalledLocation, che rappresenta la cartella in cui viene installata l'applicazione, la quale coincide con la struttura del nostro progetto Visual Studio. Se fosse stato un file nello storage locale (scenario molto probabile se stiamo effettuando il backup dei dati dell'applicazione), avremmo usato la classe ApplicationData.Current.LocalFolder.

Indipendentemente dalla posizione del file, una volta che lo abbiamo recuperato dobbiamo elaborarne il contenuto sotto forma di oggetto di tipo Stream tramite il metodo OpenStreamForReadAsync(): l'SDK di OneDrive, infatti, lavora con questo formato per gestire il trasferimento di dati. Dopodiché, introduciamo un nuovo metodo per recuperare l'accesso ad un elemento specifico: il metodo ItemWithPath(), che accetta in ingresso il percorso completo del file, incluse eventuali sotto cartelle. Si tratta dell'approccio migliore per il nostro scenario, dato che sappiamo a priori qual è la posizione del file dove vogliamo salvare i nostri dati.

Come possiamo notare nell'esempio di codice, il file non deve necessariamente esistere già: in caso contrario, l'operazione di upload provvederà a crearlo. Non è sufficiente, però, creare il file: dobbiamo anche "riempirlo" con i nostri dati, ovvero con lo stream che abbiamo recuperato in precedenza. Il contenuto viene esposto da una proprietà chiamata Content della classe Item. Da lì, possiamo inizializzare la richiesta tramite il metodo Request() e sfruttare il metodo PutAsync<T>(), che accetta in ingresso proprio lo stream con cui "riempire" il file. Il gioco è fatto: ora su OneDrive sarà presente un nuovo file, chiamato Wallpaper.png, all'interno della cartella OneDrive Sample. Il contenuto del file sarà esattamente l'immagine che abbiamo precedentemente incluso all'interno del progetto di Visual Studio.

Download del file

Esattamente come per effettuare l'upload, per poter scaricare all'interno dell'applicazione un file presente su OneDrive dobbiamo prima recuperare l'oggetto di tipo Item che lo rappresenta. L'approccio da utilizzare è lo stesso che abbiamo visto in precedenza:

Stream stream= await _client.Drive.Root.ItemWithPath("OneDrive Sample/Wallpaper.png").Content.Request().GetAsync()

Si sfruttano nuovamente il metodo ItemWithPath() (dato che conosciamo a priori posizione e nome del file) e la proprietà Content, che ci permette di accedere allo stream del contenuto. In questo caso, però, non dobbiamo effettuare un upload, ma un download: dopo aver creato la richiesta con il metodo Request(), perciò, usiamo il metodo GetAsync(), al posto di PutAsync<T>().

Ora che abbiamo recuperato l'oggetto Stream con il contenuto del file, possiamo manipolarlo nel modo che reputiamo più adatto. Ad esempio, il seguente blocco di codice sfrutta la classe FileSavePicker per proporre all'utente di salvare l'immagine scaricata sul proprio dispositivo. In uno scenario di backup e restore, avremmo utilizzato nuovamente le API per accedere allo storage locale (ApplicationData.Current.LocalFolder) per salvare il file con i nostri dati, sovrascrivendo quello esistente.

using (Stream stream = await _client.Drive.Root.ItemWithPath("OneDrive Sample/Wallpaper.png").Content.Request().GetAsync())

{

FileSavePicker picker = newFileSavePicker();

picker.FileTypeChoices.Add("Pictures", newList<string> { ".png" });

picker.SuggestedFileName = "Wallpaper.png";

picker.SuggestedStartLocation = PickerLocationId.PicturesLibrary;

StorageFile destinationFile = await picker.PickSaveFileAsync();

using (Stream destinationStream = await destinationFile.OpenStreamForWriteAsync())

{

await stream.CopyToAsync(destinationStream);

await destinationStream.FlushAsync();

}

}

Dopo aver recuperato l'oggetto di tipo StorageFile che rappresenta il file di destinazione dei nostri dati, chiamiamo il metodo OpenStreamForWriteAsync(), che ci dà accesso al contenuto del file sotto forma di Stream. In questo caso, si tratta di uno stream vuoto, per cui sfruttiamo il metodo CopyToAsync() per copiare lo stream originale (quello scaricato da OneDrive) nello stream di destinazione.

Anche l'operazione di download è terminata: ora, all'interno dello storage locale (o, come nell'esempio, nella cartella scelta dall'utente), troveremo una copia del file scaricato da OneDrive.

Effettuare il backup in background

Fino ad ora abbiamo visto come effettuare operazioni di download e upload mentre l'applicazione è in esecuzione. In alcuni scenari, però, potrebbe essere utile effettuare queste attività anche mentre l'applicazione non è in esecuzione. Per questo motivo possiamo sfruttare i background task, ovvero progetti di tipo Windows Runtime Component che contengono blocchi di codice che possono essere eseguiti anche quando l'applicazione non è in esecuzione. I background task sono legati ai trigger, ovvero eventi che ne scatenano l'esecuzione. In scenari di backup automatico uno dei più utili risulta essere il TimeTrigger, che permette di eseguire il task ad intervalli di tempo predefiniti (con un limite minimo di 15 minuti).

Il problema, però, è che le API di autenticazione che abbiamo visto in precedenza non sono in grado di funzionare all'interno di un background task, in quanto fanno uso di API che interagiscono con l'interfaccia utente. Ci serve, perciò, sfruttare un altro approccio, che ci permetta di autenticarci in maniera silente.

Per questo scopo, la classe OneDriveClient espone il metodo GetSilentlyAuthenticatedMicrosoftAccountClient() che, però, presuppone che l'utente si sia già autenticato e loggato in precedenza e che, di conseguenza, abbia già specificato le informazioni sul suo Microsoft Account. Uno dei parametri richiesti, infatti, si chiama refresh token e ci viene restituito nel momento in cui viene effettuata la prima autenticazione con successo. Tale token ha validità un anno e ci permette di effettuare operazioni con le API di OneDrive senza dover richiedere nuovamente all'utente le sue credenziali.

Se ricordate l'inizio del post, abbiamo detto però che non siamo in grado di sfruttare l'Online Authenticator Id nel caso in cui la nostra applicazione faccia uso di un background task. Questo perché tale approccio si fa carico di gestire in automatico (e, quindi, di nascondere) tutta la logica di autenticazione richiesta dalle API e, perciò, non ci permette di recuperare il refresh token e di salvarlo per usi futuri.

Dobbiamo, perciò, sfruttare l'autenticazione tramite WebAuthenticationBroker che, invece, ci darà accesso a tutte le informazioni che ci servono. Lo svantaggio è che la procedura di login non sarà più automatica come prima, ma l'utente dovrà confermare il suo Microsoft Account inserendo username e password, oltre a dover confermare l'autorizzazione. Il flusso, perciò, sarà il seguente:

1. L'utente farà login nell'applicazione principale, sfruttando il WebAuthenticationBroker.
2. Una volta che il login è andato a buon fine, otterremo un oggetto di tipo IOneDriveClient con, al suo interno, il refresh token che ci serve. Lo salveremo nello storage locale, sfruttando la classe ApplicationData.Current.LocalSettings.
3. Il background task, quando sarà eseguito, recupererà dallo storage locale il refresh token e lo sfrutterà per effettuerà il login tramite il metodo GetSilentlyAuthenticatedMicrosoftAccountClient().

Questo approccio richiede però un'informazione che, fino a questo momento, avevamo tralasciato: l'application id, ovvero l'identificativo univoco dell'applicazione che ci viene assegnato dai servizi Microsoft per l'autenticazione. Il login tramite WebAuthenticationBroker, infatti, sfrutta questa informazione che, in precedenza, veniva gestita in maniera trasparente dall'Online Id Authenticator.

Per recuperarlo, dobbiamo collegarci al Dev Center (http://dev.windows.com), accedere alla nostra dashboard ed entrare nel dettaglio della nostra applicazione (anche se non l'abbiamo ancora pubblicata, la troveremo comunque in quanto all'inizio del posto ne abbiamo riservato il nome).

Tra le voci disponibili nel menu a sinistra troveremo la voce Services: clicchiamo su Push Notifications e, nella schermata che compare, clicchiamo sulla voce Live Services site. Verremo portati al sito dedicato alla registrazione di tutte le applicazioni che interagiscono con i servizi di Microsoft. Qui dovremo effettuare due operazioni:

1. Nella sezione API Settings, dovremo impostare su Yes alla voce Mobile or desktop client app.
2. Nella sezione App Settings, dovremo prendere nota del parametro Client ID: ci servirà in fase di login.

Ora possiamo iniziare il processo di autenticazione all'interno dell'applicazione usando un altro metodo della classe OneDriveExtensions, ovvero GetClientUsingWebAuhtenticationBroker().

privateasyncvoid OnOneDriveWebViewLogin(object sender, RoutedEventArgs e)

{

IOneDriveClient client = OneDriveClientExtensions.GetClientUsingWebAuthenticationBroker("00000000481837EF", Scopes);

await client.AuthenticateAsync();

refreshToken = client.AuthenticationProvider.CurrentAccountSession.RefreshToken;

ApplicationData.Current.LocalSettings.Values["RefreshToken"] = refreshToken;

}

Con questa modalità sfrutteremo il classico processo di autenticazione basato sul protocollo oAuth: l'utente, invece di inserire i suoi dati personali direttamente nell'applicazione (e, quindi, essere facilmente trafugabili dallo sviluppatore), li inserirà all'interno di una pagina web, controllata dal fornitore del servizio (in questo caso, Microsoft). Se l'autenticazione va a buon fine, lo sviluppatore riceverà un token (completamente anonimo) che dovrà essere incluso in tutte le chiamate successive.

Come potete notare dall'esempio, il metodo GetClientUsingWebAuthenticationBroker() richiede un ulteriore parametro oltre agli scope, ovvero l'application id: si tratta del Client ID che abbiamo recuperato in precedenza dal Dev Center. Chiamando il metodo AuthenticateAsync() comparirà una finestra di dialogo, nella quale l'utente dovrà confermare le credenziali di accesso del suo Microsoft Account. Una volta che l'autenticazione è andata a buon fine, tramite la proprietà AuthenticationProvider.CurrentAccountSession della classe IOneDriveClient siamo in grado di accedere al refresh token di cui abbiamo parlato in precedenza, tramite la proprietà RefreshToken. Dato che tale informazione ci servirà anche all'interno del background task, la salviamo nello storage locale, sfruttando la classe ApplicationData.Current.LocalSettings.

Ora abbiamo tutti gli strumenti per sfruttare le API di OneDrive anche all'interno del background task. Non entrerò in questo post nei dettagli su come creare e configurare un background task, in quanto è già stato trattato numerose volte in questo blog. Potete fare riferimento alla documentazione ufficiale all'indirizzo https://msdn.microsoft.com/en-us/library/windows/apps/mt299100.aspx

È sufficiente sapere che un background task è un progetto, di tipo Windows Runtime Component, che contiene una classe che implementa l'interfaccia IBackgroundTask. Ciò ci obbligherà a definire il metodo Run(), che viene invocato nel momento in cui viene eseguito il background task. All'interno di questo metodo andremo ad includere il codice che si autenticherà, in maniera silente, con OneDrive e effettuerà l'upload del file con i dati della nostra applicazione.

Ecco un esempio di codice completo di un background task:

publicsealedclassUploadTask: IBackgroundTask

{

privatereadonlystring[] Scopes = new[] { "wl.signin", "wl.offline_access", "onedrive.readwrite" };

publicasyncvoid Run(IBackgroundTaskInstance taskInstance)

{

var deferral = taskInstance.GetDeferral();

if (ApplicationData.Current.LocalSettings.Values.ContainsKey("RefreshToken"))

{

string refreshToken = ApplicationData.Current.LocalSettings.Values["RefreshToken"].ToString();

string returnUrl = WebAuthenticationBroker.GetCurrentApplicationCallbackUri().ToString();

IOneDriveClient client = awaitOneDriveClient.GetSilentlyAuthenticatedMicrosoftAccountClient("00000000481837EF", returnUrl, Scopes,

refreshToken);

StorageFile file = awaitPackage.Current.InstalledLocation.GetFileAsync("BackgroundWallpaper.jpg");

using (Stream stream = await file.OpenStreamForReadAsync())

{

await client.Drive.Root.ItemWithPath("OneDrive Sample/BackgroundWallpaper.png").Content.Request().PutAsync<Item>(stream);

}

}

deferral.Complete();

}

}

Il primo passo è controllare la presenza nello storage locale del refresh token, tramite il metodo ContainsKey() esposto dalla collezione ApplicationData.Current.LocalSettings.Values. La seconda informazione che ci serve è l'url di callback, ovvero l'url che i servizi di OneDrive devono richiamare nel momento in cui l'autenticazione è stata complicata. Questa informazione, in realtà, non è necessaria per un'applicazione mobile: viene sfruttata, infatti, soprattutto negli scenari web, in quanto identifica la pagina del nostro sito che dovrà elaborare il risultato dell'operazione di login. La possiamo recuperare tramite la classe WebAuthenticationBroker che, grazie al metodo GetCurrentApplicationCallbackUri(), ci restituisce un URL valido per la nostra applicazione.

Ora siamo in possesso di tutti gli strumenti necessari per effettuare l'autenticazione silente tramite il metodo GetSilentlyAuthenticatedMicrosoftAccountClient() esposto dalla classe OneDriveClient. Le informazioni richieste sono, nell'ordine:

1. Il Client ID dell'applicazione, che abbiamo recuperato in precedenza dal Dev Center.
2. L'url di callback
3. Gli scope
4. Il refresh token

Il gioco è fatto: ora abbiamo in mano un oggetto di tipo IOneDriveClient autenticato, che ci permetterà di usare le API di OneDrive allo stesso modo di come abbiamo fatto nell'applicazione principale. L'esempio di codice precedente recupera un'altra immagine presente all'interno del nostro progetto Visual Studio (chiamata BackgroundWallpaper.jpg) e la carica su OneDrive, anche quando l'applicazione non è in esecuzione. In uno scenario reale, avremmo effettuato l'upload del file che contiene i dati della nostra applicazione, presente nello storage locale.

Se avete registrato correttamente il task in background e volete testarne il corretto funzionamento, potete sfruttare il menu a tendina presente in Visual Studio Lifecycle events. Al suo interno, oltre a trovare le opzioni per simulare il ciclo di vita dell'applicazione, troveremo anche il nome del nostro task: premendolo, simuleremo l'esecuzione del task, senza dover attendere che il trigger ad esso collegato venga scatenato.

Maneggiare con cura

Come avete visto, l'SDK di OneDrive è molto potente e ci permette di implementare velocemente soluzioni di sincronizzazione o di backup e ripristino dei dati nelle nostre applicazioni. È importante, però, fare una serie di considerazioni prima di sceglierla come soluzione principale per la sincronizzazione dati:

1. L'SDK di OneDrive lavora con file e cartelle e, di conseguenza, siete costretti ogni volta ad effettuare l'upload e il download completo del file di dati. Nel caso, perciò, in cui il database della vostra applicazione possa raggiungere dimensioni importanti è meglio affidarsi alle Mobile App di Azure: dato che lavorano direttamente con il database, è possibile sincronizzare solo i dati che sono stati effettivamente modificati rispetto all'ultima volta, minimizzando perciò il trasferimento di dati.
2. Per lo stesso motivo, la risoluzione dei conflitti è più complessa e presenta maggiori limiti: non abbiamo modo di risolvere i singoli conflitti, ma possiamo solamente capire eventualmente qual è la versione più recente del file e scegliere se dare la priorità. Di conseguenza, in scenari limite, ci sono maggiori probabilità di perdita di dati.

In conclusione

Nel corso di questo post abbiamo visto come sfruttare l'SDK di OneDrive per effettuare operazioni di download e upload di dati, che possiamo sfruttare per aggiungere alla nostra applicazione funzionalità di backup e ripristino o di sincronizzazione dati. È importante, però, tenere a mente le considerazioni fatte nel corso del post, per capire se si tratta della soluzione migliore per il nostro progetto o se è il caso, invece, di scegliere soluzioni differenti.

Potete trovare la soluzione descritta nel post sul mio repository GitHub all'indirizzo https://github.com/qmatteoq/OneDriveSDK-Sample Unico accorgimento: la proprietà ClientId sarà vuota, in quanto deve essere sostituita l'informazione relativa ad una vostra applicazione, che deve essere stata registrata sullo Store utilizzando il vostro account sviluppatori.

Happy coding!

This year, the E2 Educator Exchange will feature live streaming, allowing those of you joining online the chance to interact with the speakers and other online participants, ask questions, and walk away having been inspired to immediately implement what you've learned into your classroom.

This year, the E2 Educator Exchange will feature live streaming, allowing those of you joining online the chance to interact with the speakers and other online participants, ask questions, and walk away having been inspired to immediately implement what you've learned into your classroom.

With the help of #MIEExpert Emma Hicks, we recently published a new eBook which looks at the uses and benefits of using OneNote for Education. In Chapter 4 we'll take a closer look at how OneNote can provide a way to organise and store assessment for learning from both inside and outside of the classroom.

With the help of #MIEExpert Emma Hicks, we recently published a new eBook which looks at the uses and benefits of using OneNote for Education. In Chapter 4 we'll take a closer look at how OneNote can provide a way to organise and store assessment for learning from both inside and outside of the classroom.

With the help of #MIEExpert Emma Hicks, we recently published a new eBook which looks at the uses and benefits of using OneNote for Education. In Chapter 4 we'll take a closer look at how OneNote can provide a way to organise and store assessment for learning from both inside and outside of the classroom.

Hi all,

The SQL Server 2016 RC0 will be out anytime soon. A preview for the SSIS community here

Below is the specific improvements we added for RC0:

1. SSIS Hadoop connector now supports ORC format.
2. SSIS SSDT multi-version support targeting SQL versions 2012, 2014 and 2016 (One Designer)

1. SQL 2016 Project connection manager UI is used when switching to 2014. Create project level connection manager in 2014, Switch target server version to sql server 2016, then switch back to SQL server 2014, the project connection manager UI is still using 2016 UI where it should have used 2014 UI.
2. Script component doesn’t work after switching target server version if script fails to build.
3. Debug in 64 bits mode in SSDT 2015 doesn’t work if target server version is set to SQL server 2012/2014.
4. Script editor in VS2013 will crash when SSDT-BI 2013 and SSDT 2015 are installed on the same machine 

Recently, Premier Developer Consultant Marius Rochon posted this article on his blog regarding changing passwords in Azure AD that may be helpful to those of you facing this specific scenario in your applications:

1. You use Azure AD for some applications (e.g. Office365), but...
2. ...one of your applications does NOT use Azure AD (yet). It has its own authentication store and method (e.g. forms authn).
3. However, you want to keep the application's credentials in sync with AAD. Basically, allow same signon (not single signon) to both your application and AAD managed applications. You want to keep username/pwds in-sync between your application and AAD. You want to ensure that whenever the user changes his/her password in the custom store, it is also changed in Azure AD.

If this is something you are facing, read the rest of Marius’ article here for the solution, including a code sample:

http://blogs.msdn.com/b/mrochon/archive/2016/02/12/changing-user-password-in-azure-ad-using-graphapi.aspx

• Root Cause: As part of the effort to improve build performance, we created a new pool that would improve our VM performance but forces us to move to a different region.  Unfortunately, there’s a quite number of heavy users that require significant network traffic across data center and causes our average build time to increase, which eventually lead for our build queue to pile up..
• Chance of Reoccurrence: Low, further analysis will be done before switching to the new pool. 

Initial Update: Thursday, 3 March 2016 03:34 PM UTC

We are actively investigating issues with Hosted Build in North Central US region. Customers may experience builds stuck in Queue state for a longer than normal.

We are working to resolve this issue and apologize for any inconvenience.

Next Update: 2hrs

 Sincerely,
 Veeranjaneya

[Cross posting from dev.office.com]

We are excited to announce availability of open source Responsive UI Package for SharePoint on-premises. This package is designed to transform your SharePoint on-premises deployment responsive where needed and it supports both SharePoint 2013 and SharePoint 2016 version.

Package is available from GitHub and it changes the native behavior of your SharePoint deployment by adding support for three different rendering options depending on the device screen size. You can deploy the package to any on-premises SharePoint site by simply using the provided PowerShell scripts. User interface changes are automatically applied based on the device screen size accessing the SharePoint site.

Actual implementation is NOT using custom master pages, we rather embed the needed styling definitions and JavaScript files to the site using so called JavaScript embed pattern, which is explained in MSDN. This means that the responsiveness can be applied even if the sites are still using out-of-the-box master pages, which is the recommended options around UI customizations, where possible.

Here’s a screenshot of the normal desktop view.

Here’s how the same page will look like in table view or in general when the screen size is smaller than suitable for the desktop view. Notice that the navigation is automatically hidden based on the screen size and shown when clicked again.

Here’s same page in phone view or smaller device view. In similar ways as with table view, the navigation elements are automatically hidden, but shown when needed.

In the following video Paolo Pialorsi (Piasys.com) from the PnP Core team shows how to use the package and how it changes the user interface behavior based on the display resolution.

Video at Channel 9.

Resources

• Responsive package in the PnP-Tools GitHub repository– Includes detailed step-by-step setup instructions and other details for using this in your deployment in the readme file.
• Responsive package introduction at PnP Channel 9 video blog– Demonstrates how to use the available resources to make your on-premises SharePoint deployment responsive.
• PnP PowerShell CommandLets– Open source extension CmdLets to automate operations for SharePoint on-premises or SharePoint Online
  
  

Can I use this in my deployments and how is it supported?

All assets released under the PnP initiative are open source and available for you to reuse anyway you want in your own deployments. Technical approach and implementation is fully supported by Microsoft, but since this is released under the open source approach, we do not have specific support available for this from the Premier support.

If there’s any technical challenges around the implementation or you’d like to get support around using it, we would suggest to use the Office Dev PnP Yammer group at http://aka.ms/OfficeDevPnPYammer for contacting Microsoft and community members who can provide you assistance or input around the possible questions you have.

If you find any issues on the provided package, please use the GitHub tooling to report issues or to submit directly pull requests to further enhance the provided capability. This package is provided as open source solution, so all contributions from the community are more than welcome.

What is SharePoint Patterns and Practices (PnP) initiative

This is a sibling initiative for the Office 365 Developer Patterns and Practices (PnP) initiative. We will be releasing more on-premises related solutions and scripts under the SharePoint PnP umbrella. We are also looking into providing these solutions for the community using more easily approachable channels, but the actual source code for the scripts and solutions will be located in the GitHub under OfficeDev organization.

What about SharePoint Online?

We have already previously released a similar package for SharePoint Online in the PnP Partner Pack. You do not need to deploy the full PnP Partner Pack to your environment to take advantage of these capabilities, you can rather just benefit from the provided provisioning template around the responsive user interface. Please see following resources around the PnP Partner Pack and responsive package support for SharePoint Online.

• PnP Web Cast – Introduction to PnP Partner Pack
• Provisioning template in PnP Partner Pack for responsive UI for the SharePoint Online
  

Thanks for your interest on the PnP initiate. If you have any questions, feedback or comments around the PnP, please use the PnP Yammer group at http://aka.ms/OfficeDevPnPYammer.

Sharing is caring!

Vesa Juvonen, Senior Program Manager, Office 365, Microsoft - 3rd of March 2016

The article was originally published for iamwire.com which is a leading startup information portal in India - Here is the link to it. 

The entrepreneurial ecosystem within India and around the world is growing leaps and bounds. Not only do we see start-ups mushrooming everywhere trying to solve a business problem, but also the entire support system of Accelerators, Incubators, Angel Networks, Venture Capitalists etc. stepping up to offer their advice and funds to make these start-ups successful. With a lean, mean organization, new approach to business, operations, marketing etc, we have seen some phenomenally successful start-ups that can be called as “Unicorns” of India, such as Flipkart, SnapDeal, Zomato that built their brands and businesses and also grew in-organically thru acquisitions. It is indeed heartening to note some of these young entrepreneurs, making it as global leaders in their respective ideas and giving their bigger competitors a run for their monies. However, behind the so many successes, there are many more that haven’t quite made it.

Y Combinator, an American seed accelerator and one of the best in world states that, out of 511 companies selected to receive seed funding and mentorship, only 40 startups were able to succeed in next 3 years. This shows that even with proper funding and mentoring startup success rate is less than 10%.

Some successful startup founders and industry legends often say that if you are 100 % determined to your startup then it will be successful someday. But many times, it’s not about determination and perseverance but it is about being practical and realistic, learn from this experience and move on to another one. There can be multiple reasons like negative or stagnant customer growth, inability to raise capital, difficulty in retaining team / top talent etc. for startup failure. People whose startups have failed to launch would comprehend my statement that quitting is not easy. It requires startups to accept that they will never be at apex at least with this startup idea/team.

But then as someone said “If you accept failure as an opportunity to learn, it will change your whole perspective.” So, I am going to focus my thoughts on “recognizing signs which tells that it is time to quit your start-up”.

My personal start-up journey helped me gain a lot of valuable experience, but I took the hard decision of shutting down within 8 months of operation. My startup Deliver5 was into FoodTech space on sharing economy model. I implemented all the best practices and built an independent process driven model. Eventually, after 5 months of operation, I realized that we never focused on profitability and we were scaling up without thinking about any real business. Once reality stuck and we came out of fantasy world of scale at any expense, we realized that with our model, it will be impossible to achieve profitability ever. We tried changing the model and faced stiff resistance from market. Finally, after failing to raise another round of funding, we closed the operation in May 2015. It wasn’t an easy move but Hitting Rock Bottom isn’t so bad. When we lose everything, then only we can start afresh in our journey.

From my experience with Deliver5, I realized that the first rule of entrepreneurship is to be practical in approach and focused towards the problem at hand. Keeping a practical view is important for continuous process of evolution and success. It’s very important to know the appropriate time to quit and move forward becauseWinners sometimes quit but only at certain things which were holding them to get successful.

Here are some basic principles for entrepreneurs and its employees to contemplate when they are planning to exit:

• Balance between family and work – If startup is growing at a rapid pace and showing great future growth prospects, then involved parties never think too much of what they are sacrificing. But, if there are no indications of growth and you are struggling to balance your personal and professional life then it is time to move on. By not investing time in your personal life you are sacrificing what I refer to as “human emotional capital.“ Human emotional capital encompasses the emotional support that one receives from their family and friends.

So, put on your financial planner hat and do a cost-benefit analysis. Is your startup worth disrupting the equilibrium that you have established with your family and friends? If the answer is No- then it is time to shut the shop and move on to a newer idea or job, a live a healthy and balanced life. If the answer is Yes, then by all means, continue on your journey!

• Cash, Cash and Cash –  If you see your cash stocks / savings dwindling and dipping every single day and can’t find way to turn around the cash-flow or raise/loan money, then it’s time to move on. You must’ve heard stories of successful startups where their founders and employees tried hard to keep it afloat for long and then they tasted success. Please be aware that only success stories are printed, not failure stories. Here are facts to help you understand better – out of every 1000 startups, 930 shut their shop in very first year, 28 survived till third year and 11 get funding via angels or VC. Think wise and think through for financials.

• Self-Realization – Trust your instinct- If you have stopped recommending your product to your friends or you don’t feel comfortable recruiting the best people or you can’t inspire people around you anymore and eventually yourself then it’s time to take the plunge.

• Milestones – Give yourself and your startup team a clear set of milestones and then accordingly set some dates to achieve them. If you are not able to meet the milestones like revenue, users, MoM growth, key team recruitments, angel or VC funding or similar things which are extremely important for you, then you should be on the exit path

• Negative or Stagnant Growth – There have been multiple startups who gain traction and then find it really difficult to grow at a steady pace or their growth rate starts declining. If your startup has reached this point then analyze whether you can turn the tide, pivot and grow at a rapid pace again. If not, let go. After all “Giving up doesn’t always mean you’re weak, sometimes it just means you are strong enough to let go.”

To conclude I would like to use sport analogy that coaches always use before a game – “Go Big or Go Home.”Your startup could be the Next Big thing just makes sure that you have a contingency plan with principles outlined.  

I’ll let you read fo the full details on the Visual Studio site, but here are my highlights..

Work Item Deletion

Replacing the “Removed” state, you can now actually delete a work item.  Better yet, it goes to a recycle bin for recovery later if needed.

Gated Check-in for TFVC in New Build

Enough said.. enjoy!

Support for Marketplace Extensions

If you use VSTS, then you know what I mean.  You can now browse, download, and install extensions from the Visual Studio Marketplace.  These extensions enhance and augment capabilities in TFS!

Test results in build

There are a ton of new ways to visualize and analyze test results that were run as part of a build.

Again, there are plenty of other fun enhancements for you to check out.  Enjoy!