Month: July 2012

Community Day sul .Net Micro Framework : slide e demo

3603.netmf_6452121A

Con parecchio ritardo (e me ne scuso), ho caricato su SkyDrive le slide ed il codice delle demo relativi al Community Day del 2 Marzo 2012 che ho tenuto con i miei amici del DotNetCampania …. argomento ? … ovviamente .Net Micro Framework !

Spero possano tornarvi utili !

Advertisements

Core Connectivity : disabilitare la security

Chi utilizza le Core Connectivity al posto di ActiveSync per eseguire il debug sulle applicazioni in esecuzione su un target con Windows CE, sa benissimo che dopo aver avviato il ConmanClient2.exe, è necessario eseguire anche il CMaccept.exe il cui compito è quello di permettere l’accesso al target disabilitando il meccanismo di sicurezza sul device.

Poiché le Core Connectivity si utilizzano molto spesso durante lo sviluppo ma non sul campo, può essere utile evitare il secondo passo disabilitando il meccanismo di sicurezza mediante un valore DWORD con valore 1 e nome CoreConOverrideSecurity nella chiaveHLKM\System.

Ovviamente…il tutto da usare con cautela !

Rilasciato .Net Micro Framework 4.2 RTM (QFE2)

E’ stata rilasciata la versione 4.2 del .Net Micro Framework sviluppata ormai in modalità open source su CodePlex. Tra le novità principali :

  • supporto per il driver WinUSB;
  • Analog Output;
  • supporto per il compilatore GCC nel Porting Kit;
  • miglioramento delle performance del file system;
  • wear leveling per le memorie FLASH;
  • miglioramento performance Microbooter e TouchScreen;

Sono state inoltre risolte tutta una serie di segnalazioni aperte su CodePlex :

– Work Item: 1590 – Decrease boot time
– Work Item: 1636 – File.Exists returns true for unexisting file
– Work Item: 1656 – Problems with bad blocks handling in Wear Leveling Driver
– Work Item: 1701 – StreamReader.cs – IndexOutOfRangeException
– Work Item: 1109 – FAT32 File System issue with filenames
– Work Item: 1721 – VolumeInfo.Format() locks volume.
– Work Item: 1633 – SerialPort.Read’s behaviour is different from .Net
– Work Item: 1580 – Negative array index issue
– Work Item: 1585 – Issue in Microbooter prevents usage in Cortex M3 STM32 port
– Work Item: 1586 – Broken firmware on device reset during Microbooter FW update
– Work Item: 1635 – Substring issue in 4.2 RC4
– Work Item: 1659 – Bug in StringBuilder.Append (thanks to Julius Friedman)
– Work Item: 1672 – Wrong long to hex conversion
– Work Item: 1373 – MDK targets problems

A breve sarà reso disponibile il download.

ioProgrammo : realizziamo un sistema di allarme temperatura con il Netduino Plus

8666.4-177g_468EB7EF

Anche questo mese nella rivista “ioProgrammo” (n. 177, Agosto 2012) c’è un mio articolo sul .Net Micro Framework e la sua applicazione con Netudino Plus.

Sfruttando la funzionalità Ethernet della scheda, viene realizzato un sistema di allarme temperatura configurabile via RESTful APIs che invia una mail quando la soglia impostata viene superata.

Anche questa volta…mi raccomando…non perdetevelo !

MessageBox dal ViewModel senza violare il pattern MVVM

Nel momento in cui decidiamo di realizzare un’applicazione, ad esempio per WP7, utilizzando il pattern MVVM ma senza adottare uno dei framework a disposizione (vedi MVVMLight,Caliburn Micro, …) ci dobbiamo aspettare di dover risolvere alcuni problemi per garantire sempre e comunque il disaccoppiamento tra UI e logica di presentazione e di business che il pattern stesso ci permette di ottenere.

Uno di questi problemi può essere ad esempio la necessità di visualizzare una MessageBox, quindi un componente della UI, a partire da un metodo del ViewModel corrispondente alla pagina nella quale ci troviamo. Tala problematica può essere risolta implementando un servizio che verrà “iniettato” nel ViewModel e che avrà il compito di visualizzare la MessageBox su richiesta.

Poiché dobbiamo garantire che non ci siano dipendenza strette tra il ViewModel e l’implementazione del servizio in questione, bisogna ragionare in termini di interfacce. Possiamo definire, quindi, un’interfaccia per tale servizio in modo da dare la possibilità di implementarla di volta in volta in maniera diversa; nel nostro caso l’implementazione che realizzeremo farà uso della MessageBox dalla quale prendiamo spunto per definire i metodi dell’interfaccia.

public interface IDialogService
{
    DialogResult Show(string messageText);

    DialogResult Show(string messageText, string caption, DialogButton button);
}

L’interfaccia IDialogService espone gli stessi metodi della classe MessageBox (nella quale però sono statici) mentre DialogResult e DialogButton, definiscono rispettivamente i possibili valori restituiti dalla dialog box a seguito dell’interazione con l’utente ed i bottoni che vogliamo visualizzare al suo interno. Per semplicità, sono stati definiti con due enumerativi uguali a quelli corrispondenti per la classe MessageBox (MessageBoxResult e MessageBoxButton).

public class DialogService : IDialogService
{
    #region IDialogService...

    public DialogResult Show(string messageText)
    {
        MessageBox.Show(messageText);
        return DialogResult.OK;
    }

    public DialogResult Show(string messageText, string caption, DialogButton button)
    {
        return this.MessageBoxToDialogResult(MessageBox.Show(messageText, caption, this.DialogToMessageBoxButton(button)));
    }

    private DialogResult MessageBoxToDialogResult(MessageBoxResult messageBoxResult)
    {
        return (DialogResult)messageBoxResult;
    }

    private MessageBoxButton DialogToMessageBoxButton(DialogButton dialogButton)
    {
        return (MessageBoxButton)dialogButton;
    }

    #endregion
}

L’implementazione DialogService non solo implementa i metodi esposti dall’interfaccia ma utilizza due metodi privati per mappare i DialogResult e DialogButton sui corrispondenti MessageBoxResult e MessageBoxButton. In questo caso, la mappatura è banalmente un cast per come abbiamo definito gli enumerativi; in altri casi potrebbe essere più complessa.

L’utilizzo di questo servizio sarà possibile iniettandolo nel ViewModel attraverso il costruttore.

private IDialogService dialogService;

public ViewModel(IDialogService dialogService)
{
    this.dialogService = dialogService;
}

Infine, sarà utilizzabile direttamente in un qualsiasi metodo del ViewModel.

this.dialogService.Show("Messaggio da visualizzare");

XAML e Binding : l’utilità della proprietà UpdateSourceTrigger

Supponiamo di voler effettuare il binding tra la proprietà Text di una TextBox della nostra UI ed una proprietà di tipo String definita nel ViewModel associato alla nostra pagina. Impostando la modalità di binding a TwoWay, ci rendiamo subito conto che il set della proprietà del ViewModel avviene solo ed esclusivamente quando il campo di testo perde il fuoco (quindi sul lost focus).

<TextBox x:Name="MyTextBox" Text="{Binding MyText, Mode=TwoWay}"/>

 

public string MyText
{
get { return this.myText; }
set
{
if (this.myText!= value)
{
this.myText= value;
this.OnPropertyChanged("MyText");
}
}
}

Talvolta questo non è il comportamento desiderato ed abbiamo la necessità che la nostra proprietà del ViewModel venga aggiornata ogni qual volta cambia il testo all’interno del campo.

La spiegazione di questo comportamento sta nel valore di default che la proprietàUpdateSourceTrigger del binding assume nel caso di una TextBox. LaUpdateSourceTrigger determina il momento in cui la sorgente del binding (binding source) viene aggiornata dalla destinazione del binding (binding target) nel caso di modalità two-way. Nel nostro caso il binding source è la proprietà del nostro ViewModel (ossia MyText) mentre il binding target è la proprietà Text della nostra TextBox (ricordiamo che è la proprietà di default del binding in una TextBox, ecco perchè non compare nella markup expression dell’esempio).

I possibili valori dell’enumerativo assegnabili alla UpdateSourceTrigger sono :

  • Default : il binding source è aggiornato quando il valore del binding target cambia;
  • Explicit : il binding source è aggiornato solo quando viene invocato in maniera esplicita il metodo BindingExpression.UpdateSource();

Per ogni controllo della UI il valore è tipicamente Default e nel caso della TextBox, in particolare, significa che il corrispondente binding source verrà aggiornato al lost focus.

Per cambiare il comportamento basta specificare nella markup expression di binding l’UpdateSourceTrigger ad Explicit.

<TextBox x:Name="MyTextBox"
         Text="{Binding MyText, Mode=TwoWay, UpdateSourceTrigger=Explicit}"
         TextChanged="MyTextBox_TextChanged"/>

Come si evince dallo XAML è però necessario un ulteriore passo ossia quello di registrare l’evento di TextChanged della TextBox ed all’interno dell’event handler ricavere la binding expression per invocare su di essa l’esplicito aggiornamento del binding source.

private void MyTextBox_TextChanged(object sender, TextChangedEventArgs e)
{
    this.MyTextBox.GetBindingExpression(TextBox.TextProperty).UpdateSource();
}

Da codice, attraverso il metodo GetBindingExpression() sul controllo della UI è possibile ricavare l’espressione di binding per una specifica dependecy property (nel nostro caso la proprietà Text). Sull’espressione è poi possibile forzare l’aggiornamento del binding source attraverso il metodo UpdateSource().