Solución original : Añadir un DependencyProperty propio a un control

IC210095

Trabajando con Windows Phone 8 y concretamente con el control de mapas y el Toolkit de Windows Phone, que por cierto ahora es distinto que con Windows Phone 7 y 7.5, me he encontrado con el problema de que al momento de colocar Pushpins de forma dinámica usando una lista la propiedad ItemsSource de MapItemsControl no es Bindable.

Ante este problema una solución es asignar la lista directamente por código y con eso acabamos. Solución rápida y simple.

Pero si buscamos ser coherentes con lo que es o son las aplicaciones WPF de separar lo que es la lógica de la interfaz de usuario (XAML) y que por eso existe el patrón MVVM esta solución no es pura 🙂

Encontré una solución original que no solo sirve en este caso sino que también en cualquier otro. Crear tu propio propiedad Bindable y asignarlo a cualquier control como si fuera nativo.

El enlace lo encontráis al final de este post pero yo os lo cuento un poco por encima.

Si creas una clase estática con un Dependency Property luego puedes usar esa propiedad (que también debes hacerla estática) en cualquier control WPF. El truco está en programar el método que se debe ejecutar cuando cambia la propiedad Dependecy Property.

Aquí tienes la sintaxis del MSDN:


public static DependencyProperty Register(
string name,
Type propertyType,
Type ownerType,
PropertyMetadata typeMetadata,
ValidateValueCallback validateValueCallback
)

De esta forma puedes conseguir leer las propiedades del control al cual te “hospedas” y asignar valores en código.


private static void OnPushPinPropertyChanged(DependencyObject d,
DependencyPropertyChangedEventArgs e)
{
UIElement uie = (UIElement)d;
var pushpin = MapExtensions.GetChildren((Map)uie).OfType<MapItemsControl>().FirstOrDefault();
pushpin.ItemsSource = (IEnumerable)e.NewValue;
}

 

Aquí tenéis el ejemplo completo: MVVM Windows Phone 8 – adding a collection of pushpins to a map

Si teneis alguna duda me lo preguntáis.

String resources in Windows Store Apps

Microsoft technologies are changing constantly and without pause. This is good for us (developers), it keeps us busy 🙂

Resources in .Net always were files with .resx extension and easily usable from code through static class that is not available in Windows Store Apps. Why? I don’t know.

In Windows Store Apps exists files with resw extension. In this file you can put string resources only, remember in resx you could put any kind of resources (files, string, audio, images)

Luckily, using in XAML is easier now. Look an example:


<TextBlock x:Uid="/Errors/AlreadyRegistered"></TextBlock>

Where:

Errros : is the name of resw file. Unique in all solution. Complete path isn’t possible

AlreadyRegisteres : Is the string resource in resw file

In the other hand, using in code is more difficult or maybe less intuitive. Look an example:


var res =  Windows.ApplicationModel.ResourceLoader('Errors');
res.GetString('AlreadyRegistered');

Loading strings from libraries, controls, or software development kits (SDKs).

However, loading resources from another library seems easier in Windows Store than old platforms. Oh my gosh, I said old? 🙂

ResourceLoader R = new Windows.ApplicationModel.Resources.ResourceLoader(“ContosoControl/Resources”);
R.getString(“loadingStr”); // which came from ContosoControl’s Resources.resw

Where :

ContosoControl : External library name

Resources : resw file name

loadingStr : string resource

More information:

How to load string resources (Windows Store apps using C#/VB/C++ and XAML)

 

 

DataContractSerializer no deserialitza correctament

Hi poden haver moltes raons perquè el DataContractSerializer no deserialitzi bé. Però he pensat que era el millor títol que podia donar ja que en realitat és un problema que sembli exactament el que diu: Que no deserialitza correctament.

Però en realitat no és així, el problema està en què no sabem a vegades com funciona del tot.

Aquesta és la instrucció:


Countries = MVVMUtils.DataContractDeserializeObject<Countries>(e.Result.ToString());

I aquesta és la classe Countries


[CollectionDataContract(Namespace="")]
public class Countries : List<Country> { }

[DataContract(Namespace = "")]
public class Country {
[DataMember]
public string cty_key { get; set; }

[DataMember]
public string cty_code { get; set; }

[DataMember]
public string cty_idd_code { get; set; }
}

I aquest el fitxer XML que volem deserialitzar


<Countries xmlns="">
<Country>
<cty_key>8C445CE2-5AF6-48B6-BDDA-B10B77724566</cty_key>
<cty_code>United States</cty_code>
<cty_idd_code>1</cty_idd_code>
</Country>
<Country>
<cty_key>18227E69-725D-4A17-8245-4E2683094ED0</cty_key>
<cty_code>Canada</cty_code>
<cty_idd_code>1</cty_idd_code>
</Country>
<Country>

Si observes bé les propietats no estan ordenades alfabèticament. Aquest XML s’ha extret d’un altre sistema de serialització. Si s’hagués fet amb el DataContractSerializer estarien completament ordenades.

Aquest és el problema.DataContractSerializer necessita que les propietats estiguin ordenades i quan això no és possible llavors hem de indicar un atribut més al model : Order

Per tant el model hauria de ser:


[CollectionDataContract(Namespace="")]
public class Countries : List<Country> { }

[DataContract(Namespace = "")]
public class Country {
[DataMember(Order=1)]
public string cty_key { get; set; }

[DataMember(Order = 2)]
public string cty_code { get; set; }

[DataMember(Order = 3)]
public string cty_idd_code { get; set; }
}

Més informació:
Why needs DataContractSerializer alphabetically sorted XML?

Aspectos fundamentales de la programación ASP.NET (parte 5)

Quinta y ultima parte del bloque que hablo de Aspectos fundamentales de la programación ASP.NET. Primero sería bueno leer la primer parte,la segunda, la tercera y la cuarta.

Ejecución de una página ASP.NET

Parte fundamental para entender como funciona ASP.NET y como puede afectar esto a tu forma de programar tus aplicaciones web. Ya he dicho antes que ASP.NET se planteó que la programación fuera “Event driven” que significa que cada página genera eventos.

Entender cual es el orden de generación de los eventos es esen-cial para programar correctamente.

Para verlo hablamos del ciclo de vida de la página. Aquí vas a encontrar un resumen del ciclo. Cuando llega una petición :

Construir el árbol de controles

Verás que las páginas en ASP.NET utilizan controles de servidor y esos controles están ordenados en forma de árbol tal y como ya pasa en las aplicaciones Winforms.

Evento Init

El primer evento que se ejecuta en una página es el Init. Tienes creados los controles pero estos aún no tienen los valores.

Cargar el estado y los datos recibidos

Aquí es donde se guardan los datos en los controles. En el caso que la petición sea un submit de un formulario previamente enviado también se guardaran estos valores nuevos.

Evento Load

El evento más comúnmente utilizado. Es donde tienes acceso a los valores en los controles. Aquí es importante no hacer inicializaciones sin antes comprobar que no se está realizando una petición Postback. Postback es la forma que tenemos para llamar las peticiones que envían información al servidor. Es decir, las llamadas creadas mediante una acción del usuario. No son Postback cuando la petición es directa mediante la barra de navegación del explorador o mediante un link simple (etiqueta a) de la página.

Evento acción del usuario / evento cambios en controles

Si se trata de una petición Postback quiere decir que el usuario ha realizado una acción, como por ejemplo el clic de un botón, esta acción es un evento que se debe tratar. También pueden ocurrir otros eventos que no tienen por que ser acciones de botones. Pueden ser eventos producidos por el cambio en una lista, el cambio en un texto. Este tipo de eventos también se tratan.

Evento LoadComplete

El evento anterior a procesar la página para su entrega al cliente.

Guardar el estado

Una de las características del ASP.NET es la utilización en cada página de una variable de estado denominada ViewState que permite recuperar el estado en que se ha enviado inicialmente la página. Fíjate que sin el ViewState no podrías saber que eventos de modificación se han producido.

Renderizar los controles

Otra característica de ASP.NET es la utilización de controles de servidor. Estos controles se caracterizan por empezar en “asp:”, tener un ID y un runat=”server”. Estos controles no pueden ser interpretados por ningún navegador ya que ellos solo interpretan Html. Por eso antes de enviar necesitas transformar los controles de servidor en Html.

Evento Unload

Ultimo evento en el ciclo. Se pueden liberar recursos ocupados en el proceso.

La siguiente tabla tienes todos los eventos que se generan en el ciclo de ejecución de una página. Al lado tienes los que se generan en cada uno de los controles.

aspnet cycle

Más cosas de los eventos

Los eventos producidos por cambios en los controles siempre se ejecutan cuando hay un Postback. Recuerda que un Postback es cuando llega una solicitud al servidor producido por una acción del cliente. Esta acción puede ser la pulsación de un botón como también la selección de otro elemento de una lista.

Algunos controles tienen una propiedad AutoPostBack que poniéndola a cierto provocas que cualquier cambio produzca esta acción.

Puedes tener varios controles en una misma página que generen eventos de modificación. El orden en el servidor no esta establecido y por tanto es aleatorio.

Como ya te he dicho antes sin el ViewState no se pueden generar eventos de modificación. El ViewState en los controles se puede deshabilitar. Páginas que sean demasiado pesadas puedes quitarle este peso deshabilitando el ViewState de algunos controles o incluso de toda la página.

Brattack

tile159x159
Brattack is here!
Our new game Brattack for Windows Phone is available on Windows Phone Store. http://bit.ly/1jWhEyE
A game designed to improve your finger’s agility over touch screens while having fun. Check it now! It’s free!  Coming soon Brattack for iPhone, iPad & Surface.
Subscribe your email for receiving alerts when those apps become available at : http://bit.ly/1db961J
Follow us on Facebook, Twitter and LinkedIn

Millorar ObservableCollection

A StackOverflow s’ha publicat un exemple de com es pot fer un ObservableCollection més efectiu.

ObservableCollection és una llista genèrica que implementa INotifyPropertyChanged i per tant avisa a la UI dels canvis que hi ha dins la llista. Bàsicament si s’afegeix o es borra algun element.

El problema és que no és Thread safe ni tampoc Thread Affinity. Per tant, quan un Thread que no és l’UI actualitza aquesta llista es genera una excepció.

El segon, és que per cada operació d’afegir o borrar es llencen els events corresponent per notificar a UI del canvi sense l’opció de poder-los agrupar i que només es faci una vegada la notificació després d’un conjunt d’operacions.

Consulteu l’exemple que és força interessant.

Fast performing and thread safe observable collection

 

 

Aspectos fundamentales de la programación ASP.NET (4rta parte)

Cuarta parte del bloque que hablo de Aspectos fundamentales de la programación ASP.NET. Primero sería bueno leer la primer parte,la segunda y la tercera.

ASP.NET Modelo en objetos

Muchos son los objetos utilizados en el procesado de ASP.NET pero hay uno que siempre tiene que estar presente en tu memo-ria ya que lo trae prácticamente todo. HttpContext es la clase que representa una petición y su res-puesta a un recurso de la web. Context es la propiedad de la clase Page que te permite tener acceso a la instancia de la clase generada por la petición. También puedes acceder por la pro-piedad estática Current de la clase HttpContext.

Page.Context HttpContext.Current

El objeto Current tiene propiedades tan importantes y utiliza-das como:

  • Request : Representa la petición. Es una instancia de HttpRequest. Puedes acceder a la cadena Url como a las cookies.
  • Response: Representa la respuesta que debe generar el servidor. Es una instancia de la clase HttpResponse. Dispone de métodos de redireccionamiento a otras UR-L’s y métodos de escritura directa por el canal de salida.
  • User: Representa el usuario autentificado que realiza la consulta. Es la implementación de una interfaz genérica IPrincipal que puedes consultar el nombre de usuario y el rol asociado.
  • Server: Representa el servidor. Es una instancia de HttpServerUtility. Encuentras métodos para transferir la solicitud a otra página y para recuperar la dirección físi-ca dentro del disco de un recurso.
  • Session: Objeto que puedes guardar valores que sirven para mantener el estado entre peticiones.
  • Profile: Objeto que te permite leer y guardar valores que sirven para mantener el estado entre sesiones.
  • Items: Diccionario de objetos que se guardan durante la solicitud.
  • Application: Diccionario global en todas las solicitudes a la aplicación. Compartido por todos los usuarios.

Web.config

El archivo de configuración de las aplicaciones web. Este ar-chivo se encuentra en la raíz de la aplicación y es básico para el correcto funcionamiento. En este archivo que esta estructurado en formato XML se en-cuentran cosas tan importantes como:

  • Cadenas de conexiones: Las cadenas de conexión a las bases de datos que utiliza la aplicación web.
  • Autorizaciones: Permisos aplicados a carpetas o re-cursos de la aplicación web.
  • Autenticaciones: Como se deben autenticar los usua-rios. También puede contener usuarios y contraseñas encriptadas.
  • Propiedades de configuración de la aplicación: Una colección de claves y valores que se utilizan en la aplicación.
  • Perfiles: Para mantener el estado entre sesiones.
  • Proveedores de usuarios: ASP.NET tiene su propio gestor de usuarios. Puedes modificarlo para adaptarlo.
  • Proveedores de roles: ASP.NET tiene su propio ges-tor de roles. Puedes modificarlo para adaptarlo.

La herencia en web.config

webconfig

Los ficheros de configuración pueden estar en cualquier sub-carpeta de la misma. Posibilita así una herencia de configura-ciones donde se puede romper en cualquier momento e incluso sobreescribirlo. Así podrías tener una carpeta completamente pública y dentro una carpeta completamente privada. El archivo base del web.config es el machine.config. Este ulti-mo tiene su ámbito en todo el servidor. Uno de los cambios en-tre ASP.NET 3.5 y 4.0 es que web.config reduce significativa-mente su tamaño ya que la mayoría han pasado al machi-ne.config. Naturalmente puedes sobreescribirlo añadiéndolo en el web.config.