OnDeserialized/OnSerialized Attributes

In .NET we can serialize and deserialize objects for saving state from memory to storage or for transfering complex structures through the Internet.
DataContractAttribute and SerializableAttribute are the options that we have to achieve this goal. The basic differences between them are that DataContract is WCF technology and Serialization is older than DataContract. A great feature of DataContract is that it can serialize private fields. (FYI : In Windows Phone it cannot)
Private fields or private properties or non-serializable fields could be a problem for us. Fortunately, we have OnDeserializedAttribute / OnDeserializingAttribute and OnSerializedAttribute / OnSerializingAttribute that when applied to a method, specifies that the method is called immediately after / during  deserialization or serialization of an object.
Here, there are the examples from MSDN


[OnSerializing()] internal void OnSerializingMethod(StreamingContext context) {

member2 = "This value went into the data file during serialization.";

}

[OnSerialized()] internal void OnSerializedMethod(StreamingContext context) {

member2 = "This value was reset after serialization.";

}

[OnDeserializing()] internal void OnDeserializingMethod(StreamingContext context) {

member3 = "This value was set during deserialization";

}

[OnDeserialized()] internal void OnDeserializedMethod(StreamingContext context) {

member4 = "This value was set after deserialization.";

}

More information

OnDeserializingAttribute Class

OnDeserializedAttribute Class

OnSerializingAttribute Class

OnSerializedAttribute Class

Anuncis

Play music and sounds a Windows Phone 8

Amb Windows Phone 8 tenim diverses maneres de poder fer sonar música o sons pel dispositiu.
Amb XAML tenim MediaElement que permet carregar un fitxer de música i poder-lo reproduir en qualsevol moment ja sigui per codi o per triggers.
El seu avantatge és la facilitat d’ús que té i lo fàcil que és pel programador començar a reproduir música.
L’inconvenient és que només pot sonar una melodia alhora. En el moment que un altre MediaElement s’activa l’anterior deixa de sonar.
Amb Blend tenim el PlaySoundAction que el seu avantatge és que es pot activar a través d’un trigger d’una manera més senzilla que el MediaElement i es pot declarar dins del mateix Trigger. L’inconvenient és que no es carrega l’arxiu de so fins que no s’activa el trigger i això pot suposar un petit retard la primera vegada que volem que soni i també té el mateix inconvenient que el MediaElement, en quant en zona un altre l’anterior deixa de sonar.
L’alternativa i la manera més adequada de produir sons que puguin ser múltiples al mateix moment és el SoundEffect o el MediaPlayer que són classes del Framework XNA, que per cert, ja no és compatible amb Windows 8 i és un projecte tancat. Però de moment amb WP8 penso que no tenim altra alternativa.

 

LINQ a XML

Dejadme que os hable un poco de Linq a XML porque Linq es un tipo de lenguaje que personalmente me gusta mucho y creo que siempre estoy hablando de el para acceder a base de datos pero nunca para acceder a documentos XML.

Hasta el Framework 3.5 SP1 para poder trabajar con documentos XML utilizabas la clase System.Xml.XmlDocument que construía en memoria una representación del archivo en modo de árbol. Este árbol tenía sus nodos – clase XmlNode – que podían ser de distintos tipos – System.Xml.XmlElement, Sys-tem.Xml.XmlText, System.Xml.XmlAttribute, … -. La forma de trabajar de estas clases no era compleja – pues para realizar una búsqueda de un nodo o atributo dentro de esta estructura usabas XPath – pero si que complicaba un poco el construir la estructura en si.

Linq a Xml permite ejecutar consultas Linq en estructuras XML, que al igual, residen en memoria y trabajan bien con XPath pero con operadores específicos que permiten la navegación – Descendants, Ancestors, Siblings – como si fuera una expresión XPath.

Las clases que se utilizan en Linq a Xml son System.Xml.Linq.XDocument, System.Xml.Linq.XElement y System.Xml.Linq.XAttribute, System.Xml.Linq.XName y algunos otros más.

Las claves

Linq a Xml permite cargar documentos XML desde ficheros o directamente desde cadenas de texto con formato y permite a su vez serializar el contenido a ficheros o stream. La creación de los arboles XML en memoria se hacen de una forma simple y rápida. La manipulación de la estructura es en memoria y soporta las consultas Linq.

XElement y XAttribute

Los elementos y los atributos están representados por estas dos clases XElement y XAttribute usando una sintaxis muy natural para poder construir los nodos. Los constructores utilizan XName como parámetro que implícitamente se crea con una cadena de texto. XName provee de un fácil uso de los identificadores del espacio de nombres.

En el siguiente ejemplo ves como crear la estructura XML

<br /><br />&lt;Person KeenOnGolf=”true”&gt;<br /><br />&lt;Name&gt;Steve&lt;/Name&gt;<br /><br />&lt;Age&gt;52&lt;/Age&gt;<br /><br />&lt;/Person&gt;<br /><br />

es

C#

<br /><br />var e = new XElement("Person",<br /><br />new XAttribute("KeenOnGolf", true),<br /><br />new XElement("Name", "Steve"),<br /><br />new XElement("Age", 52));<br /><br />

Los elementos XML se pueden construir de otras formas:

Usando un XmlReader

<br /><br />var e1 = XElement.Load(xmlReader);<br /><br />

Usando un fichero

<br /><br />var e2 = XElement.Load(@"c:\miDocumento.xml");<br /><br />

Usando una cadena de texto

<br /><br />var e3 = XElement.Parse(@"&lt;Person KeenOnGolf='true'&gt;<br /><br />&lt;Name&gt;Steve&lt;/Name&gt;<br /><br />&lt;Age&gt;52&lt;/Age&gt;<br /><br />&lt;/Person&gt;");<br /><br />

Aplicando Linq a XElement

Cuando aplicas consultas Linq a este tipo de estructuras el resultado es un IEnumerable de XElement. El trato debe ser el mismo que en colecciones internas con la particularidad de que aquí estás tratando con elemento de tipo XElement.

El siguiente ejemplo se muestra como recuperar la persona que es aficionado al golf (KeenOnGolf a true). Para ello se utiliza una estructura XML definida como:

<br /><br />var people = new XElement("Persons",<br /><br />new XElement("Person",<br /><br />new XAttribute("KeenOnGolf", true),<br /><br />new XElement("Name", "Steve"),<br /><br />new XElement("Age", 52)),<br /><br />new XElement("Person",<br /><br />new XAttribute("KeenOnGolf", false),<br /><br />new XElement("Name", "Peter"),<br /><br />new XElement("Age", 30)),<br /><br />new XElement("Person",<br /><br />new XAttribute("KeenOnGolf", false),<br /><br />new XElement("Name", "John"),<br /><br />new XElement("Age", 44)),<br /><br />new XElement("Person",<br /><br />new XAttribute("KeenOnGolf", false),<br /><br />new XElement("Name", "Mike"),<br /><br />new XElement("Age", 50))<br /><br />);<br /><br />

La consulta Linq seria:

<br /><br />var query= from p in people.Elements("Person")<br /><br />where bool.Parse(p.Attribute("KeenOnGolf").Value)==true<br /><br />select p; foreach (XElement person in query) {<br /><br />}<br /><br />

Construyendo elementos XML De la misma forma que puedes consultar los valores de los elementos de una estructura en XML también puedes crear nuevas estructuras usando Linq. Este es una de las características que ya he hablado en este libro de Linq – permitir crear estructuras nuevas a partir de otras en una consulta -. Así pues en el ejemplo siguiente ves como puedes crear otros elementos XElement.

<br /><br />var query2 = from p in people.Elements("Person")<br /><br />where bool.Parse(p.Attribute("KeenOnGolf").Value) == false<br /><br />select new Xelement("PersonsNonKeen",<br /><br />new Xelement("Name",p.Element("Name").Value),<br /><br />new XElement("Age",p.Element("Age").Value));<br /><br />foreach (XElement person in query2) {}<br /><br />

El resultado seria la estructura siguiente:

<br /><br />&lt;PersonsNonKeen&gt;<br /><br />&lt;Person KeenOnGolf=”false”&gt;<br /><br />&lt;Name&gt;Peter&lt;/Name&gt;<br /><br />&lt;Age&gt;30&lt;/Age&gt;<br /><br />&lt;/Person&gt;<br /><br />&lt;Person KeenOnGolf=”false”&gt;<br /><br />&lt;Name&gt;John&lt;/Name&gt;<br /><br />&lt;Age&gt;44&lt;/Age&gt;<br /><br />&lt;/Person&gt;<br /><br />&lt;Person KeenOnGolf=”false”&gt;<br /><br />&lt;Name&gt;Mike&lt;/Name&gt;<br /><br />&lt;Age&gt;50&lt;/Age&gt;<br /><br />&lt;/Person&gt;<br /><br />&lt;/PersonsNonKeen&gt;<br /><br />

Más información

Para más información puedes comprar mi libro Guia Práctica de Asp.net

Threading Considerations for Binding and Change Notification in XAML

I read a very similar article about how to work with MVVM and multithreading aspects. The problem is well known; in XAML’s Binding features, if you want to communicate any change to UI through Binding object, you need to implement INotifyPropertyChanged on model class, this interface has an event named PropertyChanged that is needed to update the UI, however in multithreading scenarios, you could have secondary threads modifying the model and this implies that the PropertyChanged event will be caught on a secondary thread and then you will the following exception:

Threads other than the UI thread are not allowed to access or manipulate UI objects

In this article you can read how to solve the problem in Silverlight (for WPF and WP as well) but it is not suitable for Portable Library scenarios. In Portable Library we have neither the Deployment class or even the Dispatcher class, so we have to take the SynchronizationContext class.

Implementation is really easy, you need to declare a global class field as follows

private SynchronizationContext _context = SynchronizationContext.Current;

Now, you have in _context the thread which created the class, you need to ensure that this is the same as controls’ thread: Thread UI

The next step is :


protected virtual void OnPropertyChanged(string propertyName)

{

PropertyChangedEventHandler handler = this.PropertyChanged;

if (handler != null)

{

var e = new PropertyChangedEventArgs(propertyName);

if (SynchronizationContext.Current == _context)

{

handler(this, e);

}

else

{

_context.Post(obj =>

{

handler(this, e);

}, null);

}

}

}

_context.Post is called only if the current thread is not the same as the creator thread.

System.Runtime error en WP8 y librerías portables

Un caso raro es cuando usamos librerías portables y Microsoft.Bcl no da un error de compilación System.Runtime. En un primer momento no tenemos muy claro de que se trata y tampoco nos da ninguna pista de que puede ser.

Después de buscar y buscar resulta ser un bug de NuGet en que te pone una redirección en el archivo app.config

 

<dependentAssembly>

<assemblyIdentity name=”System.Runtime” publicKeyToken=”b03f5f7f11d50a3a” culture=”neutral” />

        <bindingRedirect oldVersion=”0.0.0.0-2.6.3.0″ newVersion=”2.6.3.0″ />

</dependentAssembly>

 

De modo que debes eliminar esa línea para que todo funcione correctamente otra vez.

<dependentAssembly>

<assemblyIdentity name=”System.Runtime” publicKeyToken=”b03f5f7f11d50a3a” culture=”neutral” />

</dependentAssembly>

Llibreries portables i Thread UI

Amb .NET 4 apareixen les llibreries portables que penso que són fantàstiques per poder fer una programació completament reutilitzable en les diferents tecnologies que tenim disponibles amb Microsoft .NET : Windows Apps, Windows 8 Store, Windows Phone i Silverlight.

Hem de saber però que aquest tipus de llibreries utilitzen un subconjunt de les característiques que poden tenir en comú les diferents tecnologies i abans de posar-nos a fer res hem de consultar quines funcionalitats ens permeten fer les llibreries portables.

Hi ha un aspecte que sempre ens trobem que és com fem referència al Thread UI de l’aplicació. El Dispatcher no el podem fer servir des de les llibreries portables. Tenim la clase SynchronizationContext per fer-ho.

De fet, l’ús és molt senzill, declarem una variable a nivell de classe com aquesta

#región Fields

private SynchronizationContext _context = SynchronizationContext.Current;

#endregion

 

I llavors sempre que vulguem assegurar-nos que una funció s’executi al mateix thread que ha creat la classe llavors:

if (SynchronizationContext.Current == _context)

{

/*Do something */

}

else

{

/*El thread actual no és el mateix */

_context.Post(obj =>

{

/*Do something */

},null);

}

Fixa’t que el que mira és si el thread actual és el mateix que ha creat la classe, per tant l’únic que ens hem de preocupar és que el Thread UI creí la classe.
Més informació:

Portable Class Library and ObservableCollection, updating UI Thread

Portable class library equivalent of Dispatcher.Invoke or Dispatcher.RunAsync

 

 

 

Thread to sleep in Windows Phone

wp8

I am excited to work in Windows Phone. I think that Windows Phone has an amazing future because it’s very easy to transform application in Windows 8 to Windows Phone and vice versa.

If you work in Windows Phone, you will know that Silverlight is the technology behind of it and the same time is a subset of WPF.

If we want to use Task, await, async (.NET 4.5 features) in Windows Phone, we will have to install Microsoft.Bcl.Async.

In this case, WP8 isn’t able to sleep a thread with the classic method Thread.Sleep(). Microsoft says that you have to use Task methods to control the behavior of threads.

But, WP8 doesn’t have the Task.Delay method (.NET 4.5 feature), then we need to install de Microsoft.Bcl.Async package and use TaskEx.Delay()