Ott 2 / Igor Damiani

App UWP localizzate solo in italiano: qualche problema con MvvmLightLibs e CommonServiceLocator

Introduzione
Una volta mi impegnavo a scrivere i titoli dei miei post sul blog concisi ed efficaci: ormai ci ho rinunciato. Passiamo alle cose serie.

Ho avuto un grave problema mischiando i seguenti ingredienti:

  1. Blank App (Universal Windows) con Visual Studio 2015, quindi parliamo di UWP
  2. Aggiunta di MvvmLightLibs tramite NuGet (attualmente la versione è la 5.2.0)
  3. Impostazione nel Package.appxmanifest (file di manifest dell’app) della lingua “it-IT” (voglio che la mia app sia solo ed esclusivamente localizzata in italiano)

Compilando l’app così creata otteniamo immediatamente 4 warning:

  1. MakePRI : warning 0xdef00522: Resources found for language(s) ‘en-us’ but no resources found for default language(s): ‘it-IT’. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899
  2. MakePRI : warning 0xdef01051: No default or neutral resource given for ‘Microsoft.Practices.ServiceLocation.Properties.Resources/ActivateAllExceptionMessage’. The application may throw an exception for certain user configurations when retrieving the resources.
  3. MakePRI : warning 0xdef01051: No default or neutral resource given for ‘Microsoft.Practices.ServiceLocation.Properties.Resources/ServiceLocationProviderNotSetMessage’. The application may throw an exception for certain user configurations when retrieving the resources.
  4. MakePRI : warning 0xdef01051: No default or neutral resource given for ‘Microsoft.Practices.ServiceLocation.Properties.Resources/ActivationExceptionMessage’. The application may throw an exception for certain user configurations when retrieving the resources.

I warning riguardano la libreria Common Service Locator, dipendenza di MvvmLightLibs, che NON vedete nelle reference del progetto, ma che in realtà c’è eccome. Sostanzialmente ci viene detto che ci sono tre risorse che NON hanno una resource per la nostra lingua italiana. Ho sempre ignorato questi warning, fino al momento in cui ho creato il package della mia app UWP da inviare sullo Windows Store. Una volta terminato l’upload, infatti, lo Store chiede l’inserimento delle informazioni dell’app in due lingue: italiano ed inglese. Questo perchè il package in realtà contiene risorse un po’ in italiano (e fin qua tutto ok), ed un po’ in inglese (falso!!!), e quindi dobbiamo dare supporto ad entrambe le lingue. Grazie anche al mio amico Twitter Fela, che mi ha dato qualche dritta sull’utility “makepri”, che mi ha permesso di indagare più a fondo.

Per risolvere ho provato a rimuovere totalmente la libreria MvvmLightLibs, ed a importare direttamente i suoi file sorgenti, ed effettivamente la situazione si sblocca. Importando uno ad uno i file .cs di MvvmLightLibs (solo lo stretto necessario), la libreria Common Service Locator non viene più inclusa,  e quindi quei 4 warning non compaiono più. Ma la cosa non mi piaceva, per nulla.

Soluzione finale
La tattica risolutiva è la seguente: nel nostro progetto dobbiamo trovare il modo di aggiungere nelle reference la libreria MvvmLightLibs, escludendo la Common Service Locator (fonte del problema). Non possiamo affidarci a NuGet, purtroppo, perchè scaricando MvvmLightLibs da lì viene automaticamente aggiunta la Common Service Locator. La soluzione però è dietro l’angolo. Se abbiamo scaricato almeno una volta MvvmLightLibs significa anche che ce l’abbiamo in locale sul nostro hard-disk, ovvero sul nostro PC. Nel caso specifico, essa si trova nel path:

%userprofile%\.nuget\packages\MvvmLightLibs\5.2.0\lib\net45

Perciò basta aggiungerla direttamente da qui, saltando NuGet e compagnia bella. In questo modo la Common Service Locator è automaticamente esclusa, non avrete più quei warning e una volta uploadato il package sullo Store avrete a che fare con un’app interamente e solamente italiana.

image

 

Vinto!

Send to Kindle
Set 9 / Igor Damiani

App UWP, Cortana ed attivazione vocale

Windows 10 include l’assistente vocale Cortana, comparso per la prima volta in Windows Phone. Attraverso Cortana possiamo comandare il PC a voce, con tutta una serie di comandi predefiniti di sistema. Come sviluppatori Universal Windows Platform, inoltre, possiamo configurare tutta una serie di frasi che il sistema operativo può riconoscere. Quando lo fa, attiva la nostra app, e la nostra app può intercettare questo evento e reagire di conseguenza.

Vediamo passo passo come ottenere questo obiettivo.

Implementazione
La prima cosa da fare è modificare il file App.xaml.cs, e nell’override del metodo OnLaunched aggiungere le righe seguenti:

Task.Run(async () =>
{
var storageFile = await StorageFile.GetFileFromApplicationUriAsync
(new Uri("ms-appx:///VoiceCommands.xml"));
await VoiceCommandDefinitionManager.
InstallCommandDefinitionsFromStorageFileAsync(storageFile);
});

In pratica, viene utilizzato il file VoiceCommands.xml – ovviamente incluso nel progetto come Content e “Copy if newer” – e registrato a livello di sistema operativo. In questo modo, Windows 10 riconoscerà le frasi specificate nel file XML, anche quando la nostra app UWP è chiusa.

Come è composto questo file XML? Ecco un esempio:

<?xml version="1.0" encoding="utf-8" ?>
<VoiceCommands xmlns="http://schemas.microsoft.com/voicecommands/1.1">
<CommandSet xml:lang="it-IT" Name="VoiceCommands">
<CommandPrefix> Nome App, </CommandPrefix>
<Example> Chi ha vinto la medaglia di bronzo ? </Example>
<Command Name="medal">
<Example> Chi ha vinto la medaglia di bronzo ? </Example>
<ListenFor> Chi ha vinto la medaglia di {medal} </ListenFor>
<Feedback> Chi ha vinto la medaglia di {medal} </Feedback>
<Navigate/>
</Command>
<PhraseList Label="medal">
<Item> bronzo </Item>
<Item> argento </Item>
<Item> oro </Item>
</PhraseList>
</CommandSet>
</VoiceCommands>

Grazie a questo XML, possiamo chiedere a Windows 10 ed alla nostra app chi ha vinto un certo tipo di medaglia. Il riconoscimento di questa frase – ripeto – avviene a livello di sistema operativo. Una volta eseguite le righe di codice C# indicate qui sopra, possiamo:

  1. Premere Win+C per avviare Cortana in modalità ascolto (oppure attivare Cortana con la voce pronunciando “Hey Cortana”, se questa funzionalità è stata preventivamente configurata ed attivata)
  2. Pronunciare ad esempio “Nome App, Chi ha vinto la medaglia di argento?”

Windows riconosce la frase ed avvia automaticamente l’app. Quando la nostra app viene attivata da un comando vocale come in questo caso, si passa dal metodo OnActivated della classe App (e non da OnLaunched) che si trova in App.xaml.cs.

protected override void OnActivated(IActivatedEventArgs e)
{
if (e.Kind == ActivationKind.VoiceCommand)
{

}
}

Il parametro e espone una proprietà Kind che ci dice il tipo di attivazione a cui siamo soggetti. Quando è di tipo ActivationKind.VoiceCommand, sappiamo che si tratta di un comando vocale. Giunti a questo punto, possono esserci due strade differenti:

  1. la nostra app è già aperta in foreground
  2. la nostra app è chiusa

Anche nel caso (1) l’esecuzione passa sempre e comunque da OnActivated. Nel caso (2), invece, la nostra app è completamente chiusa, perciò sta a noi decidere quale page visualizzare. Questo è il codice che ho utilizzato in una mia app reale:

protected override void OnActivated(IActivatedEventArgs e)
{
if (e.Kind == ActivationKind.VoiceCommand)
{
var commandArgs = e as VoiceCommandActivatedEventArgs;
var speechRecognitionResult = commandArgs.Result;
var textSpoken = speechRecognitionResult.Text;

if (this.rootFrame == null)
{
// App chiusa
rootFrame = new Frame();
Window.Current.Content = rootFrame;
this.rootFrame.Navigate(typeof(MainPage), textSpoken);
Window.Current.Activate();
}

// Invio un messaggio che verrà intercettato dal MainViewModel
// sia ad app già aperta, che appena avviata dal comando vocale
Messenger.Default.Send<TellMeMedalWinnerMessage>
(new TellMeMedalWinnerMessage(textSpoken));
}
}

Notare che ho spostato la dichiarazione dell’oggetto rootFrame a livello di classe, al contrario di quello che fa il template di base, che invece lo dichiara in modo locale al metodo OnLaunched.

Se l’oggetto rootFrame è null, significa che l’app era chiusa, quindi creo il frame, scateno la navigazione, imposto Window.Current.Content, etc. etc. Se invece rootFrame è diverso da null, significa che la mia app è già aperta. Per evitare di scrivere tutta la logica di riconoscimento in App.xaml.cs – davvero brutto – ho adottato questa soluzione: sia in un caso che nell’altro, grazie al Messenger di MvvmLight spedisco un messaggio di tipo TellMeMedalWinnerMessage. Questo è un passaggio molto importante. Il messaggio viene di conseguenza intercettato dal viewmodel che governa la UI, in questo modo:

// Nel costruttore
Messenger.Default.Register<TellMeMedalWinnerMessage>(this, GetMedalWinner);

// Funzione
private async void GetMedalWinner(TellMeMedalWinnerMessage message)
{
// invoco un servizio?
}

Nel costruttore del viewmodel registro quel messaggio, ed imposto il delegate da eseguire quando quel particolare messaggio viene ricevuto. La logica è tutta contenuta nel metodo GetMedalWinner: non fa altro che riceve in input un oggetto di tipo TellMeMedalWinnerMessage, che è una classe anemica implementata in questo modo:

class ScoreboardPositionMessage : BaseMessage
{
public string Phrase { get; set; }

public ScoreboardPositionMessage(string phrase)
{
this.Phrase = phrase;
}
}

Questa classe contiene solamente il testo della frase pronunciata dall’utente della nostra app. Adesso sta a noi decidere cosa farne. Possiamo elaborarla sul client Windows 10, oppure possiamo invocare un servizio remoto che elabora la stringa, consulta un database e restituisce un risultato al client.

Ci sono altre considerazioni da fare (grammatica, come gestire frasi libere oppure comandi più precisi, gestire più lingue): saranno tema di un prossimo post che scriverò nei prossimi giorni.

Alla prossima!!

Send to Kindle
Set 7 / Igor Damiani

Impostazioni di un’app UWP

Ho scritto in questi giorni una semplice classe SettingsHelper che permette di leggere od impostare un valore di un setting relativamente ad una Universal Windows App per Windows 10.

Il codice è il seguente:

static class SettingsHelper
{
public static T GetValue<T>(string name, T defaultValue)
{
return GetValue<T>(ApplicationData.Current.LocalSettings, name, defaultValue);
}

public static T GetValue<T>(ApplicationDataContainer container, string name, T defaultValue)
{
object obj = null;
T result = default(T);

bool canRead = container.Values.TryGetValue(name, out obj);

if (canRead)
{
result = (T)obj;
}

return result;
}

public static void SetValue(string name, object value)
{
ApplicationData.Current.LocalSettings.Values[name] = value;
}

public static void SetValue(ApplicationDataContainer container, string name, object value)
{
container.Values[name] = value;
}
}

L’utilizzo è molto semplice. E’ statica e quindi non va istanziata. Dal punto di vista del consumatore della classe la cosa avviene in modo molto trasparente. Se un certo setting esiste, allora ne viene restituito l’effettivo valore, altrimenti viene restituito un valore di default preventivamente passato in input all’atto della chiamata. Ad esempio:

// Get
var autoUpdate = SettingsHelper.GetValue<bool>("AutoUpdate", false);
int page = SettingsHelper.GetValue<int>("Page", -1);
int hs = SettingsHelper.GetValue<int>(
ApplicationData.Current.RoamingSettings,
"HighScore", 0);
SettingsHelper.GetValue<DateTime>(
ApplicationData.Current.RoamingSettings,
"LastUpdate", DateTime.MinValue);

// Set
SettingsHelper.SetValue("AutoUpdate", true);
SettingsHelper.SetValue("Page", 9);
SettingsHelper.SetValue(ApplicationData.Current.RoamingSettings, "OrderCriteria", "4");
SettingsHelper.SetValue(ApplicationData.Current.RoamingSettings, "AutoSave", true);

L’utilizzo dei generics evita casting sparsi un po’ ovunque. E grazie all’utilizzo di questa SettingsHelper possiamo evitarci l’utilizzo di TryGetValue, potenziali valori null nel caso in cui un certo setting non esiste, if e test.

Ho scritto anche degli overload sia per il SetValue che per il GetValue, perchè di default la classe accede ai LocalSettings dell’app, mentre così è possibile accedere anche ai RoamingSettings.

Chiaccherata sui LocalSettings e RoamingSettings

Colgo l’occasione per ricordare che i LocalSettings sono impostazioni locali dell’app, salvate sul dispositivo Windows che stiamo utilizzando. I RoamingSettings invece sono impostazioni dell’app che vengono automaticamente replicate su tutti gli altri nostri device a cui accediamo con lo stesso Microsoft Account. Diciamo che possiamo definire i LocalSettings come impostazioni per-device, mentre i RoamingSettings sono per-user.

A cosa possono servire? Nelle app che ho pubblicato negli anni scorsi, per Windows Phone e Windows, ho utilizzato i LocalSettings per memorizzare tutti quei settings che possono cambiare da un device all’altro, chiaramente per la stessa app. Ad esempio, impostazioni relative a grafica o performance. Vi faccio un esempio. Supponiamo di avere un’app che permetta di vedere la traccia di un volo aereo; questa traccia può essere più o meno precisa in base alla densità dei punti che si decide di scaricare da Internet e successivamente di renderizzare sullo schermo. Quindi su un device a basse performance potrei decidere di sacrificare precisione ed accuratezza per avere più velocità e consumi minori. Su un desktop potrei decidere invece di vedere la traccia di volo con la massima precisione possibile. I LocalSettings sono proprio lo strumento più adatto per scenari di questo tipo: supponendo che la precisione sia espressa con un setting chiamato “FlightLogTraceAccuracy”, di tipo int, questo andrebbe memorizzato nei LocalSettings, in modo che su smartphone abbia un valore, sul desktop un altro. Oppure, ancora, l’utente potrebbe decidere di attivare le push notification su un device mentre su un altro no, e quindi ancora una volta i LocalSettings sono il posto migliore.

Nei RoamingSettings, d’altro canto, andrei a memorizzare tutti questi settings indipendenti dal device, ma associati all’app. Ad esempio, il mio nome, la mia data di nascita, il peso, il punteggio massimo di un gioco, e così via. Indipendentemente dal device che sto utilizzando, quelle informazioni sono sempre le stesse.

Send to Kindle
Set 6 / Igor Damiani

TinyTake: cattura schermate e registrazione video

L’altra sera mi sono accorto che per dimostrare l’efficacia della Adaptive UI di Windows 10 era molto meglio registrare un breve video, giusto per mostrare cosa accadesse alla UI quando la finestra veniva ridimensionata. Uno screenshot non rende l’idea. Così ho navigato un po’ alla ricerca di un software freeware per registrare un video del mio schermo, allo scopo di uploadarlo su YouTube e poi di renderlo visibile attraverso il mio blog. Di strumenti di questo tipo ce ne sono tanti, ma l’altro giorno mi sono imbattuto in TinyTake, ottimo freeware scaricabile da qui.

tiny_take

Pro:

  • ha una bella UI, che non guasta mai
  • cattura immagini da: porzioni dello schermo, finestre, full-screen o webcam
  • registra video del vostro deskop o dalla vostra webcam
  • pubblica direttamente e senza troppi sforzi su YouTube, previo login ed autorizzazione

Contro:

  • richiede la creazione di un account TinyTake
  • video di massimo 5 minuti (se c’è bisogno di più tempo dovete invitare amici e fare in modo che questi si logghino davvero)
  • non è possibile registrare un video senza la componente audio (io ho impostato un microfono e nelle opzioni di Windows ho messo a zero tutto il volume)

Direi che fa al caso mio. Promosso!

Send to Kindle
Set 6 / Igor Damiani

La parte server dell’invio di una push notification con una tile ed un’immagine dinamica

Nei giorni scorsi mi sono imbattuto in un problema che mi ha fatto perdere tantissimo, ma davvero tantissimo tempo, problema che non ho visto risolto da nessuna parte. Spero con questo articolo di aiutare tutti coloro che in futuro potranno ricadere nello stesso scenario.

Sto parlando di inviare tramite push notification una nuova tile relativa ad un’app Windows 10, quindi UWP. Ma facciamo un passo indietro.

Il blocco XML più semplice che un server deve inviare al client per poter aggiornare una tile è:

<tile>
<visual version="2">
<binding template="TileWide310x150Image">
<image id="1" src="http://server/nomeimmagine.png"/>
</binding>
</visual>
</tile>

Ci sono tanti template da poter utilizzare, chiaramente. Questo è il template TileWide310x150Image, che invia al client le informazioni minime per aggiornare solo la tile rettangolare 310×150. Il parametro src indicato nell’XML è semplicemente l’url della nuova immagine. Nulla di particolarmente complicato. Invio un’immagine ogni volta diversa, e quindi la tile su ogni client si aggiorna.

Il problema arriva quando invece di puntare ad un’immagine fissa (jpg o png, per esempio), voglio puntare un qualche url che invece è una Action di ASP.NET MVC, Action che restituisce un’immagine sotto forma, ovviamente, di binario.

Immaginate di avere ad esempio un codice server simile al seguente:

public ActionResult RandomBackground()
{
MemoryStream ms = new MemoryStream();
Image image = new Bitmap(320, 240);

using (Graphics drawing = Graphics.FromImage(image))
{
Random rnd = new Random((int)DateTime.Now.Ticks);
int r = rnd.Next(0, 256);
int g = rnd.Next(0, 256);
int b = rnd.Next(0, 256);
Color c = Color.FromArgb(255, r, g, b);
drawing.Clear(c);

image.Save(ms, System.Drawing.Imaging.ImageFormat.Png);
}

return File(ms.ToArray(), "image/png");
}

Questa è una Action di ASP.NET MVC, quindi stiamo ragionando sulla parte server dell’invio di una push notification. Questa Action risponde ad un url simile al seguente…

http://server/controller/RandomBackground

e non fa altro che restituire ogni volta un’immagine 320×240 di colore diverso, ad ogni colpo di F5. Supponiamo quindi di inviare una push notification come questa:

<tile>
<visual version="2">
<binding template="TileWide310x150Image">
<image id="1" src="http://server/controller/RandomBackground"/>
</binding>
</visual>
</tile>

Sui dispositivi Windows 8 / 8.1 / 10 questa push notification ha un comportamento ben particolare. La prima volta la notifica arriva, il device la riceve ed aggiorna la tile. Fin qua nulla di strano. Dalla seconda volta in poi la tile non si aggiorna più. Perchè? Deduco, dopo infinite prove & test, perchè l’url della tile è sempre lo stesso, e quindi il device reputa che sia inutile aggiornarla, perchè interpreta che sia sempre la stessa tile. Peccato, per il ragionamento di cui sopra, che in realtà l’url punti ad un contenuto dinamico generato server-side, e quindi DEVE aggiornarla, anche se l’url è lo stesso.

Sono inoltre giunto alla conclusione che il meccanismo di ricezione di push notification sul client ignori tutti i parametri passati in querystring, così url come questi sono esattamente gli stessi:

http://server/controller/RandomBackground?index=534543
http://server/controller/RandomBackground?a=blablabla
http://server/controller/RandomBackground?guid=589353985u39835u49

Per risolvere, bisogna effettivamente puntare ad un url differente. La firma della Action insomma deve diventare qualcosa del genere:

public ActionResult RandomBackground(string id)
{
// codice
}

Il parametro id non ci serve, ma a questo punto noi possiamo invocare l’Action in questo modo:

http://server/controller/RandomBackground/34
http://server/controller/RandomBackground/aaaa
http://server/controller/RandomBackground/fkldglkdfm34
http://server/controller/RandomBackground/;ert;54353

Gli url qui puntano alla Action RandomBackground, passando diversi valori nel parametro id, valori che vengono bellamente ignorati, ma che semplicemente servono a scatenare effettivamente l’aggiornamento della tile. Cosa significa questo? Significa che server-side, in fase di preparazione dell’XML da inviare a ciascun client, l’url deve essere generato ogni volta diverso, quindi giocare con System.Random per fare una cosa del genere:

string tileUri = string.Format("http://server/controller/RandomBackground/{1}",
new Random((int)DateTime.Now.Ticks).Next(1, 999999));

L’url della tile, insomma, viene generato random ogni volta, mandato al client, che lo aggiorna senza farsi troppe domande. Ok, primo step risolto.

Ulteriori complicazioni

Fin qua, volendo, è tutto semplice, perchè la Action RandomBackground che abbiamo ipotizzato negli esempi qui sopra non ha bisogno di veri parametri di input. Supponiamo che la generazione della tile abbia a che fare con il meteo, e che la Action debba restituire l’immagine di una tile contenente le previsioni della provincia passata in input fra i parametri. Ad esempio:

http://server/controller/Meteo/Lodi
http://server/controller/Meteo/Roma
http://server/controller/Meteo/Lecce
http://server/controller/Meteo/Ancona

Ma torniamo ai discorsi di prima. Se inviassi questo url ad un device Windows 10, la prima volta la tile verrebbe aggiornata, dalla seconda volta in poi no. E quindi dobbiamo generare url ogni volta sempre diversi, accodando un secondo parametro fittizio come qui sotto:

http://server/controller/Meteo/Lodi/5437534
http://server/controller/Meteo/Roma/989
http://server/controller/Meteo/Lecce/1123
http://server/controller/Meteo/Ancona/9043

Ovviamente i numeri sono sparati a caso. Per ottenere questo, bisogna modificare le regole di routing di ASP.NET MVC, per indicare che nell’url possiamo indicare un parametro aggiuntivo opzionale. Quindi quello che ho fatto è stato andare nel file RouteConfig.cs e scrivere quanto segue:

public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}/{key}",
defaults: new { controller = "Home", action = "Index",
id = UrlParameter.Optional,
key = UrlParameter.Optional }
);
}

Cioè: tutti gli url possono contenere un parametro {key} opzionale. Di conseguenza, la firma della nostra Action Meteo diventa:

public ActionResult Meteo(string id, string key)
{
// Codice
}

All’interno del parametro id avremmo la provincia passata. All’interno del parametro key arriverebbe un secondo parametro, generato ogni volta casualmente, bellamente ignorato, inserito al solo scopo di avere un url ogni volta differente.

Conclusioni

Direi che è tutto. Bel problema, non c’è che dire.

Finalmente risolto, e le mie tile arrivano puntuali e precise.

Send to Kindle
Set 4 / Igor Damiani

App Control Panel per UWP

Seguendo il gruppo Sviluppatori Windows Italia su Facebook, mi sono ritrovato nell’intento di voler ricreare una specie di Pannello di Controllo di Windows 10, applicando Adaptive UI per fare in modo che la visualizzazione cambi da griglia a lista, esattamente come fa il pannello di controllo nativo del sistema operativo. Perciò ho creato questo. Che ne dite?

Vedete come ridimensionando la finestra, la griglia si adatti in modo opportuno, e quando la dimensione della finestra scende al di sotto dei 600 pixel, la visualizzazione passa in modalità lista.

Passiamo alla parte tecnica. La visualizzazione a griglia è rappresentata dal seguente XAML:

   1: <GridView ItemsSource="{Binding Items}" VerticalAlignment="Center"

   2:     HorizontalAlignment="Center" x:Name="ControlPanelGrid">

   3:     <GridView.ItemsPanel>

   4:         <ItemsPanelTemplate>

   5:             <ItemsWrapGrid Orientation="Horizontal" />

   6:         </ItemsPanelTemplate>

   7:     </GridView.ItemsPanel>

   8:     <GridView.ItemTemplate>

   9:         <DataTemplate>

  10:             <Grid Width="200" Height="200" Padding="16" Margin="2">

  11:                 <Grid.RowDefinitions>

  12:                     <RowDefinition Height="Auto" />

  13:                     <RowDefinition Height="Auto" />

  14:                     <RowDefinition Height="Auto" />

  15:                 </Grid.RowDefinitions>

  16:                 <TextBlock Text="{Binding Icon}" Foreground="Olive" FontFamily="Segoe UI Symbol"

  17:                            FontSize="50" FontWeight="ExtraLight" TextAlignment="Center"

  18:                            TextWrapping="Wrap" Grid.Row="0" VerticalAlignment="Bottom" />

  19:                 <TextBlock Text="{Binding Name}" Foreground="Black" FontSize="18"

  20:                            FontWeight="ExtraLight" TextAlignment="Center" TextWrapping="Wrap"

  21:                            Grid.Row="1" VerticalAlignment="Bottom" />

  22:                 <TextBlock Text="{Binding Description}" Foreground="DarkGray"

  23:                            FontWeight="ExtraLight" FontSize="14" TextAlignment="Center"

  24:                            TextWrapping="Wrap" Grid.Row="2" VerticalAlignment="Top" />

  25:             </Grid>

  26:         </DataTemplate>

  27:     </GridView.ItemTemplate>

  28: </GridView>

La visualizzazione a lista invece è la seguente:

   1: <GridView ItemsSource="{Binding Items}" x:Name="ControlPanelList"

   2:           HorizontalContentAlignment="Stretch">

   3:     <GridView.ItemTemplate>

   4:         <DataTemplate>

   5:             <Grid Margin="2" HorizontalAlignment="Stretch" Padding="4" BorderThickness="1">

   6:                 <Grid.ColumnDefinitions>

   7:                     <ColumnDefinition Width="60" />

   8:                     <ColumnDefinition />

   9:                 </Grid.ColumnDefinitions>

  10:                 <Grid.RowDefinitions>

  11:                     <RowDefinition />

  12:                     <RowDefinition />

  13:                 </Grid.RowDefinitions>

  14:                 <TextBlock Grid.RowSpan="2" Text="{Binding Icon}" Foreground="Olive"

  15:                            FontFamily="Segoe UI Symbol" FontWeight="ExtraLight" FontSize="32"

  16:                            Grid.Row="0" VerticalAlignment="Bottom" Margin="8 0 0 0" />

  17:                 <TextBlock Text="{Binding Name}" Grid.Column="1" Foreground="Black"

  18:                            FontWeight="ExtraLight" FontSize="20" Grid.Row="0"

  19:                            VerticalAlignment="Bottom" Margin="8 0 0 0" />

  20:                 <TextBlock Text="{Binding Description}" Grid.Column="1" Foreground="DarkGray"

  21:                            FontWeight="ExtraLight" FontSize="16" TextWrapping="Wrap"

  22:                            Grid.Row="1" VerticalAlignment="Top" Margin="8 0 0 0" />

  23:             </Grid>

  24:         </DataTemplate>

  25:     </GridView.ItemTemplate>

  26:     <GridView.ItemsPanel>

  27:         <ItemsPanelTemplate>

  28:             <ItemsStackPanel Orientation="Vertical" />

  29:         </ItemsPanelTemplate>

  30:     </GridView.ItemsPanel>

  31:     <GridView.ItemContainerStyle>

  32:         <Style TargetType="GridViewItem">

  33:             <Setter Property="HorizontalContentAlignment" Value="Stretch" />

  34:         </Style>

  35:     </GridView.ItemContainerStyle>

  36: </GridView>

Notare che in ambedue i casi si tratta sempre di una GridView, solo che nel secondo caso (modalità lista) ho cambiato il pannello di default, impostandolo su:

   1: <GridView.ItemsPanel>

   2:     <ItemsPanelTemplate>

   3:         <ItemsStackPanel Orientation="Vertical" />

   4:     </ItemsPanelTemplate>

   5: </GridView.ItemsPanel>

In questo modo, pur trattandosi di una GridView, in realtà gli Items internamente vengono visualizzati con uno StackPanel, e quindi verticalmente. Perchè questo?

L’effetto di “OnMouseOver” di una GridView renderizza il bordo dell’elemento, come si vede nel video, e questo è proprio l’effetto che fa il pannello di controllo di Windows, ed è quello che volevo. La ListView, invece, renderizza il backgrund dell’elemento, e non è l’effetto che cercavo. Quindi: GridView in tutti e due i casi, solo che la modalità a lista utilizza uno StackPanel verticale. Più semplice di così si muore.

Ma arriviamo al sodo. Come ho utilizzato gli AdaptiveTrigger per switchare da una modalità all’altra? Con questo blocco di XAML:

   1: <VisualStateManager.VisualStateGroups>

   2:     <VisualStateGroup x:Name="VisualStateGroup">

   3:         <VisualState x:Name="VisualStateNarrow">

   4:             <VisualState.StateTriggers>

   5:                 <AdaptiveTrigger MinWindowWidth="0" />

   6:             </VisualState.StateTriggers>

   7:             <Storyboard>

   8:                 <DoubleAnimation Duration="0"

   9:                     Storyboard.TargetProperty="Opacity"

  10:                     Storyboard.TargetName="ControlPanelGrid"

  11:                     To="0" d:IsOptimized="True" />

  12:                 <ObjectAnimationUsingKeyFrames Duration="0"

  13:                     Storyboard.TargetProperty="(UIElement.IsHitTestVisible)"

  14:                     Storyboard.TargetName="ControlPanelGrid">

  15:                     <DiscreteObjectKeyFrame KeyTime="0" Value="False" />

  16:                 </ObjectAnimationUsingKeyFrames>

  17:             </Storyboard>

  18:         </VisualState>

  19:         <VisualState x:Name="VisualStateWide">

  20:             <VisualState.StateTriggers>

  21:                 <AdaptiveTrigger MinWindowWidth="600" />

  22:             </VisualState.StateTriggers>

  23:             <Storyboard>

  24:                 <DoubleAnimation Duration="0"

  25:                     Storyboard.TargetProperty="Opacity"

  26:                     Storyboard.TargetName="ControlPanelList"

  27:                     To="0" d:IsOptimized="True" />

  28:                 <ObjectAnimationUsingKeyFrames Duration="0"

  29:                     Storyboard.TargetProperty="(UIElement.IsHitTestVisible)"

  30:                     Storyboard.TargetName="ControlPanelList">

  31:                     <DiscreteObjectKeyFrame KeyTime="0" Value="False" />

  32:                 </ObjectAnimationUsingKeyFrames>

  33:             </Storyboard>

  34:         </VisualState>

  35:     </VisualStateGroup>

  36: </VisualStateManager.VisualStateGroups>

Nel Visual State Manager ho definito due viste: VisualStateNarrow e VisualStateWide.

La prima interviene con una Width minima di 0 pixel, ed attiva la visualizzazione degli elementi a lista, quindi modalità verticale. La seconda interviene con una Width minima di 600 pixel, ed attiva la visualizzazione degli elementi a griglia. Due note importanti:

  • per visualizzare o nascondere utilizzo la proprietà Opacity delle due GridView
  • di conseguenza ho dovuto impostare anche IsHitTestVisible a False, per fare in modo che un oggetto che nel visual tree compare “sopra” un altro, in realtà non partecipi all’intercettazione degli eventi di input. Uao, che frase complicata. Se non andassi ad impostare IsHitTestVisible a False, il controllo ControlPanelGrid non funzionerebbe come voluto, perchè davanti ci sarebbe il ControlPanelList (nonostante la sua Opacity a 0). Non è frutto del mio sacco, ho visto l’utilizzo di questa proprietà in Template 10, ed in effetti è una bella comodità

Direi che è tutto.

Il codice sorgente di questo progetto è su GitHub, e lo trovate qui.

Send to Kindle
Set 3 / Igor Damiani

UWP e la Adaptive UI

Dunque, partiamo da qualche presupposto tecnologico.

Con Windows 8 e Windows 8.1 TUTTE le Windows Store App venivano disegnate per essere visualizzate “solo” in full-screen. Il “solo” l’ho messo tra virgolette perchè c’era un altra casistica: quando le app venivano snappate sul lato sinistro o destro dello schermo. E siccome stiamo parlando di app per Windows bisognava pensarle per tutte le risoluzioni possibili ed immaginabili. E bisognava pensarle sia in landscape che portrait. In ogni caso, l’utente non aveva la possibilità di ridimensionare l’app, perchè di fatto non c’era alcuna finestra con nessun bordo.

Con Windows 10 le cose sono un po’ diverse. Innanzitutto esiste la Modalità Tablet, che se attivata fa agire le nuove Universal Windows App (UWP) esattamente come sotto Windows 8/8.1. Partono in full-screen, possiamo snapparle, etc. etc. Quando la Modalità Tablet è spenta, le UWP vengono inserite in una finestra, al punto che l’utente visivamente non le distingue più dalle classiche applicazioni desktop. L’utente può ridurre ad icona l’app, può spostare la finestra e soprattutto può ridimensionarla.

E qui arriva il tema della Adaptive UI offerta dall’SDK di Windows 10. Non è scopo di questo post raccontare tutti gli aspetti della Adaptive UI, anche perchè io stesso ho ancora un po’ di confusione in testa. Lo scopo di per sè è piuttosto semplice:

Permettere ad una Universal Windows App di adattare il proprio contenuto in base a risoluzione & dimensione.

Ricordo, punto fondamentale, che un’app UWP gira ovunque sia presente Windows 10: desktop, portatile, mega-schermo, in futuro smartphone, XBOX, e via dicendo. Quindi, sostanzialmente, significa adattare il contenuto in base alla risoluzione/dimensione e fare in modo che il tutto sia sempre fruibile nel migliore dei modi. E quindi parliamo di schermi che vanno dal 10” di un ultrabook al 22” di un desktop, al 5” di uno smartphone (e la cosa divertente è che magari la risoluzione è sempre Full-HD).

Ecco una serie di articoli che trattano meglio questo argomento:

A Developer’s Guide to Windows 10: (07) Adaptive UI

Windows 10 Universal Apps – Adaptive Triggers

Template 10

Parlando di Template 10 mi sono guardato e studiato questa MainPage.xaml inserita nel progetto Sample. E’ un ottimo esempio di come la view possa reagire in base alla dimensione della finestra.

snip

Analizzando questa view, da cui sono partito, vi propongo una mia soluzione, che illustro in questo post. Esso utilizza ovviamente l’SDK di UWP, AdaptiveTrigger, Model-View-ViewModel con MvvmLight, e qualche altra nozione indispensabile.

Introduzione
Supponiamo di avere un’app UWP che mostra un elenco di automobili.

Ecco la nostra “bellissima” UI:

image

Qui abbiamo un MainViewModel che governa l’intera interfaccia. Questo viewmodel espone una proprietà Cars di tipo ObservableCollection<Car>. I dati sono stati inseriti manualmente nel costruttore. La UI è composta da un Hub con 3 HubSection al suo interno, uguali uno all’altro, sia nell’aspetto che nei dati visualizzati:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"
    DataContext="{StaticResource vm}">
    <Hub Grid.Row="1" x:Name="HorizontalView">
        <HubSection x:Name="CarsList1" Header="car list 1" Width="512"
                    HorizontalContentAlignment="Stretch"
                ContentTemplate="{StaticResource CarsListTemplateWide}" />
        <HubSection x:Name="CarsList2" Header="car list 2" Width="512"
                HorizontalContentAlignment="Stretch"
                ContentTemplate="{StaticResource CarsListTemplateWide}" />
        <HubSection x:Name="CarsList3" Header="car list 3" Width="512"
                HorizontalContentAlignment="Stretch"
                ContentTemplate="{StaticResource CarsListTemplateWide}" />
    </Hub>
</Grid>

Il contenuto di ciascun HubSection è prelevato dal DataTemplate CarsListTemplateWide.

In questo momento la nostra UI non è assolutamente adattiva. Se lanciamo l’app e ridimensioniamo la finestra, la UI non reagisce in alcun modo: al massimo ottenete ScrollBar verticali o orizzontali per permettere all’utente di scorrere e vedere tutto il contenuto.

Ciò che ci permettono di fare gli Adaptive Trigger di UWP è quello di intercettare i cambiamenti delle dimensioni e reagire in modo opportuno. Il tutto in modo dichiarativo usando lo XAML, senza scrivere alcuna linea di codice C#.

Concettualmente, quindi, possiamo andare a cambiare il ContentTemplate di ciascuno di quei 3 HubSection, switchando da CarsListTemplateWide a, per esempio, CarsListTemplateSmall. E supponiamo di adattare la UI dicendo: se la nostra finestra si stringe fino ad un certo limite, allora facciamo in modo che l’elenco delle automobili si adatti, rimuovendo alcune informazioni che decidiamo essere superflue.

Questa è la seconda visualizzazione che implementa questa logica. Stringendo la finestra, due colonne ad un certo punto scompaiono (quelle relative al modello e all’anno di immatricolazione).

image

Questo grazie al seguente blocco di XAML:

<VisualStateManager.VisualStateGroups>
	<VisualStateGroup x:Name="VisualStateGroup">
		<VisualState x:Name="VisualStateWide">
			<VisualState.StateTriggers>
				<AdaptiveTrigger MinWindowWidth="600" />
			</VisualState.StateTriggers>
			<VisualState.Setters>
				<Setter Target="CarsList1.ContentTemplate"
					Value="{StaticResource CarsListTemplateSmall}" />
				<Setter Target="CarsList2.ContentTemplate"
					Value="{StaticResource CarsListTemplateSmall}" />
				<Setter Target="CarsList3.ContentTemplate"
					Value="{StaticResource CarsListTemplateSmall}" />
				<Setter Target="CarsList1.Width" Value="300" />
				<Setter Target="CarsList2.Width" Value="300" />
				<Setter Target="CarsList3.Width" Value="300" />
			</VisualState.Setters>
		</VisualState>
		<VisualState x:Name="VisualStateVeryWide">
			<VisualState.StateTriggers>
				<AdaptiveTrigger MinWindowWidth="1024" />
			</VisualState.StateTriggers>
			<VisualState.Setters>
				<Setter Target="CarsList1.ContentTemplate"
					Value="{StaticResource CarsListTemplateWide}" />
				<Setter Target="CarsList2.ContentTemplate"
					Value="{StaticResource CarsListTemplateWide}" />
				<Setter Target="CarsList3.ContentTemplate"
					Value="{StaticResource CarsListTemplateWide}" />
				<Setter Target="CarsList1.Width" Value="512" />
				<Setter Target="CarsList2.Width" Value="512" />
				<Setter Target="CarsList3.Width" Value="512" />
			</VisualState.Setters>
		</VisualState>
	</VisualStateGroup>
</VisualStateManager.VisualStateGroups>

Vengono definiti 2 VisualState: uno è VisualStateWide, l’altro è VisualStateVeryWide. Il primo è valido dai 600 pixel in su, il secondo dai 1024 pixel in su. Giocando con i Setter del Visual State Manager vado a cambiare alcune proprietà degli oggetti sulla UI, principalmente due:

  • la larghezza degli HubSection (300 pixel oppure 512)
  • Il ContentTemplate degli HubSection (CarsListTemplateSmall oppure CarsListTemplateWide)

Il Setter agisce in modo immediato, e la UI si aggiorna come stabilito.

Conclusioni

Questa soluzione è molto carina da vedere in esecuzione. In forma statica, qui sul blog, rende molto poco l’idea. E soprattutto ha molto più senso in un’applicazione reale complessa, con molte informazioni da mostrare: in un esempio semplice come questo non risaltano bene le potenzialità. Pian piano, forse, l’Adaptive UI mi entra in testa!

Send to Kindle
Set 2 / Igor Damiani

SignalR e notifiche di allarmi su diversi tipi di client, desktop e mobile

Introduzione
E’ da molto tempo che volevo studiare, almeno superficialmente, SignalR. Sebbene non segua molto le tecnologie Web, ogni tanto nella mia testa suona una specie di campanello di allarme (o di notifica, meglio), che mi dice: “Ok, quella cosa riguarda il Web, ma sento che potrebbe essere utile anche a me“. Anche perchè, parliamoci chiaro, io del Web odio solamente l’HTML ed i browser: la parte più stupida del client, insomma: passatemi questa definizione. SignalR è uno di quei topic che hanno fatto suonare quel campanello, senza mai trovare davvero il tempo e le risorse da dedicarci. Fino alla settimana scorsa, quando mio fratello Omar, improvvisamente, senza alcun input da parte mia, mi manda un bel sample proprio su SignalR. Uno di quei sample perfetti, di quelli che apri con Visual Studio, premi F5, compila e parte tutto, capisci alla perfezione, e poi passi ad analizzare il codice. Ecco, è andata proprio così. E quindi, grazie a quel sample ed all’intervento di mio fratello, è nato questo post.

Di cosa parliamo?
La settimana scorsa mi sono messo ad implementare un piccolo prototipo, che poi ho pubblicato sul mio account GitHub, che implementa la seguente struttura:

WP_20150902_10_26_09_Pro

In parole povere, abbiamo i seguenti componenti:

  • un device fisico, rappresentato a sinistra, cioè un dispositivo di qualche tipo (un sensore di temperatura? un frigorifero? un’auto? una caldaia? oppure…un razzo?). Questo dispositivo, tra le altre cose, è in grado di rilevare i suoi allarmi interni (temperatura alta, fuori traiettoria, perdita liquido refrigerante, motore fuori servizio), e di comunicarli a qualcuno
  • questo “qualcuno” è un dispatcher, rappresentato al centro, che nel mio caso è un server implementato con SignalR, server che ho pubblicato su Azure, quindi raggiungibile in modo globale. Qual è il suo compito? Ogni volta che riceve un allarme, avvisa tutti i client che risultano connessi, inviando loro un messaggio (leggesi: una classe DTO)
  • I client di qualsiasi tipo, rappresentati a destra, ricevono il messaggio ed avvisano l’utente nel modo più consono ed opportuno. Ciascun client all’avvio si collega al server SignalR implementato nel punto precedente di questo elenco

Trovate qui il progetto: https://github.com/VivendoByte/AlarmNotifier.

E’ importante che la cosa sia il più possible in real-time, ed è per questo che ho deciso di studiare e di passare attraverso SignalR.

Qualche dettaglio tecnico in più
Diamo un’occhiata al Solution Explorer che vi trovate nel momento in cui aprite la solution che ho pubblicato. Eccolo qui:

solution_explorer

  • C’è una solution folder denominata Client, al cui interno ho messo 4 tipi diversi di progetto: Console, Universal App per Windows 10, Windows Phone 8.1 e classica applicazione desktop in WPF. Questi progetti rappresentano i tipi diversi di client che possono ricevere la notifica di allarme
  • C’è una solution folder denominata Dispatcher, al cui interno ho messo 2 tipi diversi di progetto: Console e Web. Questi due progetti rappresentano il dispatcher degli allarmi. Uno è console e quindi apre un server SignalR sul vostro PC. L’altro è un progetto di tipo Web, ed è lo stesso che ho pubblicato su Azure
  • Infine, ci sono altri due progetti: uno è VivendoByte.AlarmNotifier.Messages, una class library di tipo Portable, che contiene solo una piccola classe DTO per poter inviare e ricevere il messaggio. L’altro progetto è VivendoByte.AlarmNotifier.RocketDevice, che rappresenta il nostro device fisico capace di generare allarmi: è un po’ una cosa brutta, effettivamente, ma l’ho implementato come applicazione WPF, così è possibile premere un bottone e simulare lo scatenarsi di un allarme

Parte Server – Il Dispatcher
Vediamo per prima cosa la parte server di SignalR. il punto focale è l’Hub, che io ho chiamato NotifierHub e che ho implementato come segue:

[sourcecode language='csharp'  padlinenumbers='true']
public class NotifierHub : Hub
{
	public void RaiseAlarm(AlarmMessage notification)
	{
		Clients.All.SendNotification(notification);
	}
	public override Task OnConnected()
	{
		return base.OnConnected();
	}

	public override Task OnDisconnected(bool stopCalled)
	{
		return base.OnDisconnected(stopCalled);
	}
}
[/sourcecode]

Il metodo RaiseAlarm che vedete implementato qui sopra viene invocato dal device (lo vediamo dopo), nel nostro caso il razzo. Ogni volta che il razzo segnala un allarme, si entra nel metodo RaiseAlarm; l’istanza di AlarmMessage che arriva come parametro contiene tutti i dettagli sull’allarme: data/ora, gravità, descrizione, eccetera. Quello che fa SignalR è rigirare l’allarme a tutti i client che risultano connessi in quel momento, con quella semplice linea di codice. Il dispatcher fa solo questo: riceve un allarme e lo rimanda ai client. Da notare due cose:

  • la proprietà All è di tipo dynamictooltip
  • il metodo SendNotification, che qui chiamiamo internamente al dispatcher, viene poi invocato anche sui client: lo vedremo più tardi

Il device fisico – Il Razzo

Adesso vediamo in breve il dispositivo fisico. Questo è il device capace di segnalare gli allarmi. Come dicevo prima, l’ho scritto in WPF, così ha un’interfaccia utente per poter premere un bottone e scatenare un allarme. Il code-behind è piuttosto semplice. Per prima cosa, ho implementato un metodo chiamato Connect:

[sourcecode language='csharp' ]
public MainWindow()
{
    InitializeComponent();
    this.Connect();
}

private async void Connect()
{
    Connection = new HubConnection(ServerURI);
    HubProxy = Connection.CreateHubProxy("NotifierHub");

    try
    {
        await Connection.Start();
    }
    catch (HttpRequestException)
    {
        return;
    }
}
[/sourcecode]

Questo metodo viene eseguito dal costruttore della finestra. In questo modo il nostro razzo si connette immediatamente al server SignalR, e ci mettiamo nella condizione di poter comunicare gli allarmi. Notate che il parametro del metodo CreateHubProxy, di tipo stringa, deve corrispondere al nome della classe Hub definita server-side. Quando nel razzo si scatena un allarme (ripeto: nell’esempio dobbiamo premere manualmente un bottone) accade quanto segue:

[sourcecode language='csharp' ]
private void SendAlarm_Click(object sender, RoutedEventArgs e)
{
    AlarmMessage a = new AlarmMessage();
    HubProxy.Invoke("RaiseAlarm", a);
}
[/sourcecode]

Molto semplice, direi. Costruisco un’istanza di AlarmMessage e la mando al server SignalR di cui abbiamo parlato prima. Il nome del metodo RaiseAlarm è espresso tramite una stringa, ed è quello che abbiamo visto implementato prima nel NotifierHub.

Ovviamente, in produzione un device comunicherebbe un allarme nel momento in cui si scatena realmente, e non c’è alcun utente a premere un bottone.

Parte Client – I diversi tipi di client

La parte client è l’ultima parte di tutto questo giro. Nel progetto su GitHub ne ho implementati quattro tipi diversi, qui parliamo solo della Console Application perchè è la più semplice da trattare. E’ importante dire che il codice per la connessione al server SignalR è lo stesso: diverso semmai è il comportamento che il cliente assume nel momento in cui riceve l’allarme, perchè ogni client ha un’interfaccia diversa e quindi comunica all’utente in modo diverso.

Ecco il codice:

[sourcecode language='csharp' ]
static void Main(string[] args)
{
    Connect();
}
static async void Connect()
{
    Connection = new HubConnection(ServerURI);
    HubProxy = Connection.CreateHubProxy("NotifierHub");

    HubProxy.On<AlarmMessage>("SendNotification", (notification) =>
        {
            System.Console.WriteLine(notification);
        }
    );

    try
    {
        Connection.Start();
    }
    catch (HttpRequestException)
    {
        return;
    }

    System.Console.WriteLine("Console Client started!!!");
    System.Console.ReadKey();
}
[/sourcecode]

Il metodo Connect crea un’istanza di HubProxy, specificando “NotifierHub” come parametro. Si sottoscrive alla ricezione del messaggio AlarmMessage. Il tutto viene gestito in questo caso tramite un anonymous method: quando viene ricevuto un allarme, la Console Application non fa nient’altro che scriverlo sulla console. Nel caso di applicazioni più complesse, come ad esempio un’applicazione WPF, potremmo aggiungere l’oggetto AlarmMessage ad una ListBox, oppure mostrare un balloon di notifica sullo schermo. Il primo parametro del metodo On è “SendNotification”, ed è quello che abbiamo specificato sul server SignalR; il secondo parametro è un Action<T>, dove T nel nostro caso è AlarmMessage.

Conclusioni

SignalR, come recita il sito ufficiale, è una libreria per sviluppatori ASP.NET in grado di implementare con poco sforzo una comunicazione real-time alle nostre applicazioni. E per citare… “What is “real-time web” functionality? It’s the ability to have your server-side code push content to the connected clients as it happens, in real-time”. Direi che è uno scenario perfetto per la comunicazione di allarmi, ma anche per applicazioni di chat, o di videogiochi, o per tutto quello che ci passa per la testa.

Per chiudere, fate clone dal mio repository su GitHub e provate a dargli un’occhiata.

Send to Kindle
Ago 22 / Igor Damiani

Windows 10 e Remote Desktop

Ho migrato entrambi i miei PC a Windows 10, ed ho avuto difficoltà ad effettuare connessioni con Remote Desktop. Il motivo è che di default la connessione di rete che Windows 10 imposta (cablata o WiFi che sia) è di tipo pubblico, e quindi connessioni RDP su questo tipo è negata.

Per risolvere è sufficiente seguire questi passi:

  1. cliccare con il destro sull’icona della connessione di rete e raggiungere il Centro connessioni di rete

    rete01

  2. Cliccare su Gruppo Home in basso a sinistra
  3. Cliccare il tipo di rete da Pubblico a Privato, evitando – se non serve – di connettersi ad un Gruppo Home come viene suggerito di fare

    rete02

  4. Non appena il tipo di rete cambia e diventa privata, Windows vi propone di andare alla ricerca sulla vostra LAN di tutti i dispositivi di rete, come stampanti e TV. Accettate se vi fa comodo

Fatto questo, le connessioni RDP dovrebbero funzionare regolarmente.

Il link originale da cui ho tratto questo post, e grazie al quale ho risolto il problema, è il seguente : http://www.tenforums.com/tutorials/3982-rdc-connect-remotely-your-windows-10-pc.html.

Send to Kindle
Ago 1 / Igor Damiani

Lancio Windows 10, io c’ero!

Lo scorso 29 Luglio ero nella sede Microsoft Italia di Peschiera Borromeo per partecipare insieme ad  un sacco di gente al lancio dell’ultimo sistema operativo di casa Microsoft. Una bellissima giornata. Un sacco di chiaccherate, un sacco di gente nuova, un grande casino, una fetta di torta, qualche gadget veramente figo. Felice di aver conosciuto, tra le altre persone, anche Evita Barra, sorella di Francesca, persone che seguo sui social da un po’ di tempo per motivi differenti (la prima – evidentemente – lavora in Microsoft; la seconda – invece – è scrittrice/giornalista/presentatrice di fama nazionale, di cui compro libri, mi appassiona il suo lavoro, ed ho redatto la sua pagina Wikipedia). Effetto strano quello di aver reincontrato in quel contesto alcuni dei ragazzi del progetto Skills4You a cui ho partecipato come docente.

WP_20150729_13_43_54_Pro__highres

Detto questo, la mia storia d’amore da Windows Insider con Windows 10 è cominciata maluccio, perchè le prime build proprio non mi convincevano.

WP_20150729_13_46_40_Pro__highres

Ma man mano che si avvicinava il 29 Luglio, vedevo le cose migliorare, fino ad arrivare alla versione attuale decisamente più funzionale ed adatta alla distribuzione in tutto il mondo.

Sono stato anche intervistato, insieme ad altri amici della community, per la mia esperienza da Windows Insider. Il video è su YouTube ed è visibile qui.

Felicissimo di essere stato uno dei protagonisti di questa magnifica giornata!!!!

Send to Kindle