Continúo la serie de scroll infinito. En la implementación del artículo anterior, usaba un LoadItemsResult para devolver la carga asíncrona de la fuente de datos. Sin embargo, hay ocasiones en que esto se nos queda corto, como por ejemplo cuando ocurre una excepción en la carga o queremos limitar los elementos que se van cargando. Es por ello que crearemos un nuevo tipo que implemente IAsyncOperation<LoadMoreItemsResult> que nos permita tener más control sobre lo que devolvemos. Esta interfaz dispone de un método y una propiedad:
La idea es sencilla. Anteriormente teníamos un método que se encargaba de obtener los datos. Ahora nosotros vamos a hacer ese método a través de esa interfaz, permitiendo el control absoluto de lo que queremos devolver. Tendremos un método asíncrono que es el encargado de obtener los datos y añadirlos al IncrementalSource (que recordemos, es una ObservableCollection) tal que así:
Code Snippet
- private async void LoadItems(IncrementalSource<T> source, uint count)
- {
- try
- {
- var result = await SourceManager.Load(count);
- foreach (var item in result)
- {
- source.Add(item);
- }
-
- results.Count = count;
- asyncStatus = AsyncStatus.Completed;
- if (Completed != null)
- this.Completed(this, asyncStatus);
- }
- catch (Exception ex)
- {
- // Gesti?n de excepciones
- }
- }
Básicamente lo que hacemos es cargar los datos y cuando ya lo están:
-
Notificar cuántos elementos se han cargado.
-
Lanzar el evento Completed para notificar que la carga se ha completado. Le el objeto actual como sender y un parámetro de AsyncStatus que lo asignamos como Completed, lo cual notifica al subscriptor del evento que la parte asíncrona ya ha terminado. El resto de la clase sería así:
Code Snippet
- public class DataAsyncLoader<T> : IAsyncOperation<LoadMoreItemsResult>
- {
- private AsyncStatus asyncStatus = AsyncStatus.Started;
- private LoadMoreItemsResult results;
-
- public DataAsyncLoader(IncrementalSource<T> source, uint count)
- {
- LoadItems(source, count);
- }
-
- public AsyncOperationCompletedHandler<LoadMoreItemsResult> Completed { get; set; }
-
- public LoadMoreItemsResult GetResults()
- {
- return results;
- }
-
- public AsyncStatus Status
- {
- get { return this.asyncStatus; }
- }
- }
Y por último y recordando el artículo anterior, en el método dentro de IncrementalSource que teníamos la carga de elementos debemos cambiarlo por:
Code Snippet
- public IAsyncOperation<LoadMoreItemsResult> LoadMoreItemsAsync(uint count)
- {
- return new DataAsyncLoader<T>(this, count);
- }
Y ya está. Con esto estamos externalizando la carga de elementos y teniendo un control absoluto de lo que ocurre antes, durante y después de la carga.
Una de las mayores bazas de una interfaz de usuario es cómo se muestran los elementos y cómo se van cargando. En el caso de Windows 8 (y Windows Phone) disponer de elementos en un ListView es algo común. Pero cuando llegamos al final de la lista, podemos adoptar dos alternativas:
- Colocar un botón tipo “Cargar más elementos”
- O hacer que automáticamente cargue los elementos según lo necesite. Evidentemente, este es el caso que vamos a comentar.
En primer lugar tenemos un ListView con un ItemSource asociado a un ObservableCollection<T>. Para detectar si hay más elementos, el ListView dispone de una propiedad llamada IncrementalLoadingTrigger. Esta propiedad por defecto está ajustada a Edge. Si queremos que no haya ningún tipo de carga incremental, hay que ajustarla a None.
En segundo lugar, tenemos que lograr que los datos nos indiquen cuándo es necesario obtener más elementos. Como hasta ahora usamos un ObservableCollection<T> como binding, necesitamos cambiarlo un poco. En este punto se introduce la interfaz ISupportIncrementalLoading, que se encargará de notificar al destino del binding si hay más elementos disponibles para cargar y un método para cargar los datos en función de la cantidad de elementos previamente cargados:
HasMoreItems: Indica si hay más elementos para cargar.
LoadMoreItemsAsync: Carga asíncrona de los nuevos elementos.
Partiendo de lo anterior, necesitamos crear un nuevo tipo que implemente la interfaz ISupportIncrementalLoading y la ObservableCollection<T> para poder bindear los datos. Veamos un ejemplo que yo he llamado IncrementalSource:
Code Snippet
- public class IncrementalSource<T> : ObservableCollection<T>, ISupportIncrementalLoading
- {
- private int VirtualCount { get; set; }
-
- public IncrementalSource()
- {
-
- }
-
- #region ISupportIncrementalLoading
-
- public bool HasMoreItems
- {
- get { return this.VirtualCount > 0; }
- }
-
- public IAsyncOperation<LoadMoreItemsResult> LoadMoreItemsAsync(uint count)
- {
-
- }
- #endregion
- }
Sólo tenemos que rellenar el método de LoadMoreItemAsync., que devuelve un IAsyncOperation de LoadMoreResultItems. Esta estructura tiene un único campo Count que indica la cantidad de elementos que han sido cargados. De este modo se va notificando al destino del binding qué elementos se van cargando de forma asíncrona para que los vaya obteniendo y renderizando. Voy a adjuntar un ejemplo teórico de cómo se podría rellenar ese método:
Code Snippet
- public IAsyncOperation<LoadMoreItemsResult> LoadMoreItemsAsync(uint count)
- {
- return Task.Run<LoadMoreItemsResult>(
- async () =>
- {
- var result = await SourceManager.Load(count);
- foreach(var items in result)
- {
- this.Add(result);
- }
- return new LoadMoreItemsResult() { Count = (uint)result.Count };
- }).AsAsyncOperation<LoadMoreItemsResult>();
- }
Y si el ListView está dentro de un ScrollViewer, ya tendremos el scroll infinito funcionando.
Si queremos añadir un servicio WCF habilitado para AJAX, podemos hacerlo desde Añadir un nuevo item y seleccionar el elemento correspondiente:
Esto añade el servicio a nuestro proyecto. Sin embargo, cuando lo arrancamos podemos ver un mensaje que indica que la publicación de metadatos está desactivada para ese servicio. La página del servicio nos sugiere que añadamos lo siguiente a nuestro fichero de configuración, que en efecto sirve para habilitar los metadatos sin mayor problema:
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceTypeBehaviors" >
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
Lo añadimos pero sigue sin habilitarse los metadatos Incluso muestra un mensaje de error indicando que el fichero de configuración es incorrecto. Si observamos el fichero de configuración (normalmente web/app.config) veremos que faltan algunos datos por configurar. Aquí voy a mostrar cómo debe quedar el .config para que la publicación de metadatos sea efectiva.
El error que nos muestra indica que la definición del servicio no incluye la dirección del endpoint. Por ello:
1 – Lo primero que hacemos es añadir el behaviour de nuestro servicio en la sección que indiqué anteriormente y añadirle la etiqueta para que reconozca los metadatos y habilitarla.
<behaviors>
<serviceBehaviors>
<behavior name="TestWCFAjax.Service1AspNetAjaxBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
2 – Fijémonos en la definición del servicio que ha creado por defecto:
<service name="TestWCFAjax.Service1">
<endpoint address="" behaviorConfiguration="TestWCFAjax.Service1AspNetAjaxBehavior"
binding="webHttpBinding" contract="TestWCFAjax.Service1" />
</service>
Lógicamente no encuentra un endpoint similar y ahí se produce el error. Pero, ¿dónde está? Fijémonos que anteriormente teníamos definido un behaviour y dentro un endpoint que hacía referencia a nuestro servicio. Ahora al cambiar esto, es nuestro servicio como tal quien tiene un behavior asociado y no su endpoint:
<service name="TestWCFAjax.Service1" behaviorConfiguration="TestWCFAjax.Service1AspNetAjaxBehavior">
<endpoint address="" binding="webHttpBinding" contract="TestWCFAjax.Service1" />
Con esto nuestro servicio ya arrancará con los metadatos habilitados.
Considero que desarrollar algo, por simple que sea, requiere el máximo cuidado y esmero. Sin embargo si estamos hablando de incluir las prácticas de paralelización, debemos ser mucho más cuidadosos y conocer mejor el problema que tratamos resolver. Resolver algo de forma paralela no es trivial en ningún caso.
No obstante, .NET nos ofrece una serie de ayudas a través del framework para paralelizar nuestro código. Vamos a empezar viendo un bucle y un código muy simple:
Code Snippet
- for (int i = 0; i < itemList.Count(); i++)
- {
- //Console.WriteLine(i);
- itemList[i] += (int)Math.Cos(i);
- }
Tenemos un array de N elementos y a cada uno de ellos vamos a sumarle el coseno i-ésimo. Para paralelizar esto, tenemos que tener en cuenta el coste de la paralelización. Ese coste está derivado del esfuerzo que hay que hacer para lanzar y mantener los hilos o las tareas. Si este coste es demasiado alto (por ejemplo para bucles u operaciones muy pequeñas) compensa más usar siempre la versión secuencial. Vamos a ver cómo podemos paralelizar esto, empleando Parallel.For.
Parallel.For (y Parallel.ForEach) están incluidos dentro de Parallel-LINQ (PLINQ) por lo que no tenemos que instalar nada extra para poder usarlos. La sintaxis en este caso es sencilla:
Code Snippet
- var parallelResult = Parallel.For(0, itemList.Count(), (i) =>
- {
- itemList[i] += (int)Math.Cos(i);
- });
Pese a que actualmente dispone de 12 sobrecargas, muestro por ahora la más sencilla:
- Primero indicamos el índice de origen para la primera iteración del bucle.
- Después hasta dónde queremos llegar, de forma exclusiva.
- Por último, definimos un Action. El action es lo que se ejecutará.
Traduciendo, lo que queremos hacer es un bucle paralelo que vaya de 0 a itemList.Count() y que ejecute el coseno ié-simo de cada elemento. Fíjese como no tenemos dependencias ni variables compartidas. Más tarde veremos este punto. Nótese además como Parallel.For devuelve una variable de tipo ParallelLoopResult, que nos indica cuándo el bucle ha terminado de ejecutarse y cuando se ha roto la iteración antes de romper el bucle. Para obtener la medición de los tiempos que se muestran a continuación he usado un sencillo StopWatch y para medir la parte paralela, he usado el IsCompleted del ParallelLoopResult que me ha permitido esperar la ejecución paralela y poder cuantificar el tiempo trascurrido.
Code Snippet
- while (parallelResult.IsCompleted == false) ;
Por ahora comparemos resultados. Para ello simplemente he ejecutado el código anterior con distintos tamaños de lista, desde 1 elementos hasta 10.000.000. Para obtener mediciones un poco más precisas he ejecutado cada sección 4 veces y he hecho la media de los resultados, puesto que en algunos casos el resultado de las operaciones puede ser trivial debido a su bajo coste:
Y aquí tenemos la representación gráfica de los resultados, donde se puede apreciar mejor la diferencia de valores:
Podemos apreciar como en valores de un bucle con pocos elementos, el coste de paralelo normalmente es superior al de secuencial. Esto es debido al coste necesario para el mantenimiento de las task que forman la ejecución de la parte paralela. Pero a su vez notamos que en el momento en que el orden de los elementos va creciendo, el coste de la parte secuencial se vuelve exponencial mientras que la parte paralela, pese a que crece, dispone de un coste cercano al lineal.
Este artículo nace de una curiosidad que me pasó el otro día al trabajar con un DataContractSerializer. Para empezar, tengamos como ejemplo la siguiente clase:
Code Snippet
- public class ExampleClass
- {
- public int A;
- public int B;
- public int C;
- }
Serializar algo así, no es complicado. Como son tipos básicos, ni siquiera tenemos que añadir atributos a las propiedades. Así pues, escribiendo este código XML permitirá instanciar una clase de tipo ExampleClass empleando un XMLSerializer:
Code Snippet
- <ExampleClass>
- <C>3</C>
- <A>1</A>
- <B>2</B>
- </ExampleClass>
Code Snippet
- {ConsoleApplication.ExampleClass}
- A: 1
- B: 2
- C: 3
Usando el XMLSerializer, comprobaremos que se instancia una clase ExampleClass donde el valor de C es 3, el de A es 1 y el de B es 2. ¿Sencillo, no? Bueno, pues ahora vamos a hacer lo mismo pero con un DataContractSerializer. Lo único que tenemos que hacer es modificar el XML para añadirle los atributos de forma que sean compatibles con el esquema de DataContract. Una vez hecho esto, simplemente lo deserializamos y esto es lo que ocurre:
Code Snippet
- {ConsoleApplication.ExampleClass}
- A: 0
- B: 0
- C: 3
Podemos ver que sólo ha serializado el valor de la propiedad C, que es la primera que aparece en el XML y del resto ha pasado de largo. Esto ha ocurrido porque el serializador coge la primera propiedad y busca las siguientes a partir de la primera, en estricto orden alfabético. Es decir, si en el XML lo cambiamos del siguiente modo, veremos como efectivamente asigna la B y la C, pero no la A:
Code Snippet
- <ExampleClass xmlns="http://schemas.datacontract.org/2004/07/ConsoleApplication" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
- <B>2</B>
- <C>3</C>
- <A>1</A>
- </ExampleClass>
Y esta es la salida que obtenemos:
Code Snippet
- {ConsoleApplication.ExampleClass}
- A: 0
- B: 2
- C: 3
Bien, podemos hacer una cosa. Para evitar tener problemas al deserializar, podemos primero instanciar una clase del tipo que queramos trabajar y serializarla. Luego ya podemos trastear con el XML y asignarle los valores necesarios sin ningún tipo de problemas. Pero claro, eso no soluciona nuestro problema. Si lo que quiero es crear XML rápidos de prototipados y a mano (sí, soy un temerario, ¿y qué? 
) , con una gran cantidad de campos es muy fácil que me confunda y que alguno no se cargue. O muchos de ellos. Y sí, esto es una limitación del DataContractSerializer. Los campos deben estar ordenados alfabéticamente. ¿Hay algún modo de paliarlo? Vamos a verlo.
La primera opción la tenemos en el parámetro Order del atributo DataMember. De este modo, podemos indicarle a la propiedad en qué lugar aparece el elemento en el fichero XML. Es la opción recomendable cuando por algún motivo, no se sigue el orden por defecto (alfabético) para serializar.
Code Snippet
- [DataMember(Order = 2)]
- public int C;
Otra opción es usar el XMLSerializer de toda la vida. No hay forma, por lo menos por ahora, que un DataContractSerializer asigne los elementos a las propiedades sin un orden establecido.
A continuación muestro las aplicaciones que tengo actualmente publicadas en Windows Phone Marketplace
Desde el pasado lunes 25 al jueves 28 de julio impartí, con Rodrigo Díaz el curso de desarrollo de aplicaciones móviles con .NET. El temario consistió en lo siguiente:
-
Windows Phone.
-
Introducción a C# 4.0
-
Aplicaciones para Windows Phone, con MVVM, Databinding e IsolatedStorage
-
Juegos con XNA para Windows Phone.
-
Cómo publicar tus aplicaciones/juegos en el Marketplace.
Así pues, antes de nada me gustaría dar las gracias a todas las personas que han asistido al curso, a La Seu de la Nucía por permitirnos usar sus instalaciones y a todas las personas que de un modo u otro han logrado que este curso haya podido realizarse.
Además, dentro de unos días (en cuanto disponga un rato) publicaré en el blog los apuntes para los alumnos.
Tenemos el siguiente escenario: Una aplicación (en este caso en WPF) que tiene varias ventanas modales. Cada ventana contendrá un UserControl único, que a su vez se construirá mediante una serie de parámetros determinados dependientes de lo que requiera el propio control.
El primer enfoque, que lo podemos llamar a fuerza bruta, sería crear una ventana por cada control de usuario que tenga. El segundo enfoque, algo más fino, sería crear el UserControl antes de la ventana y ajustarlo mediante una propiedad para que lo cargue en el contenedor que le digamos a la ventana. No es lo más elegante, pero estamos instanciando el UserControl en casos particulares y no es algo muy genérico.
El tercer enfoque, que es el que propongo aquí, sería usar Reflection para que la propia ventana sea quien instancie el UserControl y nosotros sólo nos ocupemos de crear la ventana con los parámetros adecuados. Así no tenemos que estar pendiente de la creación del control en sí, sino simplemente de crear la ventana, decirle qué queremos mostrar y mostrarla al usuario.
Para ello, en primer lugar creamos una ventana en WPF. Luego, en el constructor insertaremos los siguientes parámetros:
- Primero, el tipo del control que se instanciará.
- Y después, un listado de parámetros:
- 1: public ModalPropertyWindow(Type childrenType, params object[] logicObject)
- 2: {
- 3: InitializeComponent();
- 4: }
Luego, lo que tenemos que hacer es instanciar el control que queremos con los parámetros que se requieran. Usaremos Activator.CreateInstance, que creará esa instancia con una serie de parámetros. Internamente recorre esa clase y busca un constructor que tenga la disposición de parámetros que le indicamos. Si no lo encuentra, evidentemente producirá una excepción:
- this.stackPanel2.Children.Add(Activator.CreateInstance(childrenType, logicObject) as UIElement);
Nótese que directamente añadimos la instancia creada a un StackPanel.
Por último, sólo tenemos que llamar a la ventana e instanciarla con el control que queramos:
- ModalPropertyWindow window = new ModalPropertyWindow(typeof(ClientControl), this.currentCliente, this.loggedUser);
- window.ShowDialog();
Y así para todas las ventanas que queramos. En resumen: una única ventana modal, todos los controles que queramos y no nos tenemos que preocupar de instanciar cada uno de forma particular.
Este verano participaré junto con Fernando Llopis y Rodrigo Díaz en un curso destinado a explicar las bases de la programación de videojuegos enfocadas en la plataforma Windows Phone 7. Será del 25 al 28 de Julio en la Seu Universitària de La Nucìa, en Alicante.
En el cursillo veremos desde una introducción a C#, hasta cómo programar en 2D y 3D para Windows Phone 7 y el sistema de publicación. De este modo tendremos una visión global de lo que significa hacer el desarrollo de un videojuego, desde la idea inicial hasta la publicación en un Marketplace.
Aquí tenéis la página del curso para que quien quiera, pueda asistir.
El pasado mes de Noviembre se organizó en Madrid una Codecamp para 150 personas con el objetivo de desarrollar en dos días un juego para Windows Phone 7, a la que acudí como “experto”. Previamente se creó un contenido de formación para todos los asistentes, y en mi caso me ocupé del primer webcast que sirvió de Introducción a XNA para Windows Phone 7:
El contenido se compone de los siguientes puntos:
-
Introducción a Windows Phone 7 desde el punto de vista del terminal.
-
Creando juegos para WP7: Explico las principales características de WP7 que soporta XNA.
-
Demo básica: Crear un proyecto desde cero y trastear con la orientación del teléfono.
-
Demo PeterBeer: Minijuego de ejemplo
-
Demos de Creators: Demos de ejemplo descargadas desde Creators para demostrar las capacidades de WP7
-
SlugKiller: Comentaré brevemente el juego que hice en la CodeCamp anterior.
-
Consejos: Dada la experiencia de la codecamp anterior, daré una serie de consejos bastante recomendables para que los asistentes a la codecamp logren llevar su proyecto al éxito.
Si quieres verlo, puedes hacerlo a través del siguiente enlace.
Escenario: Tengo dos entidades relacionadas. La entidad A se relaciona con la entidad B a través de un identificador. Y lo que quiero es bindear eso, pero de modo que yo disponga en la interfaz de un combobox –o cualquier tipo de selección- que permita seleccionar todos los elementos. Entonces tenemos las siguientes tareas:
-
Bindear los datos del campo con el identificador de la identidad.
-
Pero yo no quiero ver un número. Yo quiero ver el nombre del objeto que relaciono. Por lo tanto, tendré un combobox que rellenar y bindear con respecto al identificador anteriormente citado.
-
Y claro, para hacerlo bueno, bonito y barato, nada de hacerlo en el código. Todo debe ir en el XAML.
El primer enfoque puede ir dirigido a un binding normal. Es decir, obviamente tenemos que tener en cuenta el ID de la entidad A, puesto que ese será el valor elegido a mostrar. Y como quiero rellenar todo el combobox con el resto de entidades B, usaremos un Converter:
- <ComboBox ItemsSource="{Binding Converter={StaticResource ResourceKey=Converter}}" />
De este modo ya podemos ver todos los valores de la entidad B. Y además, en el converter podemos declarar cómo queremos mostrar cada Item:
- public class MyIDConverter : IValueConverter
- {
- public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
- {
-
- List<ComboBoxItem> list = new List<ComboBoxItem>();
- foreach (B b in B.All())
- {
- ComboBoxItem comboItem = new ComboBoxItem();
- comboItem.Content = b.Name;
- comboItem.Tag = b;
- list.Add(comboItem);
- }
- return list;
-
- }
-
- public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
- {
- return null;
- }
- }
Ahora lo que falta es enlazar el ID de A para que el combobox tenga como seleccionado el item de B correspondiente. Dentro del primero enfoque, sería usar otro converter para ello, pero tenemos un problema: necesito obtener el combobox para indicarle SelectedItem. De acuerdo, podemos declarar un parámetro en el Converter y le pasaremos el propio combobox del siguiente modo:
- <ComboBox ItemsSource="{Binding Converter={StaticResource ResourceKey=Converter}, ConverterParameter={RelativeSource Mode=Self}}" />
Pero esto directamente no compila. ¿Por qué? Porque los parámetros que se pasan al Converter deben ser constantes y no objetos variables. Es decir, le puedo pasar binding de propiedades como objetos ya que las considera “constantes”, pero el propio objeto comboBox (que al bindearlo se convierte en un puntero this) va cambiando. Una solución a esto es añadir manualmente dicho combobox como un DependencyProperty propio de la clase. Y otra solución es escribir el código necesario para que esto funcione en el codebehind. Pero recuerdo que el objetivo de esto es usar únicamente el XAML
¿Solución? El segundo enfoque. Simplemente consiste en añadir, además del primer Converter para rellenar el comboBox, otro que se dedique a bindear el contenido del combobox con el identificador de la entidad A. Se implementa la interfaz IMultiValueConverter que permite bindear a la vez varios elementos sobre una misma propiedad. De este modo, bindearemos la propiedad identificador de B que aparece en A como relación junto con el propio ComboBox. Y lo bindearemos al SelectedIndex de ComboBox, para que cargue el objeto B apropiado y además, que al seleccionar otro, modifique el identificador que corresponda.
Veamos el código:
- <DataTemplate>
- <ComboBox>
- <ComboBox.ItemsSource>
- <Binding Converter="{StaticResource ResourceKey=MyIDConverter}">
- </Binding>
- </ComboBox.ItemsSource>
- <ComboBox.SelectedIndex>
- <MultiBinding Converter="{StaticResource ResourceKey=MyIDtoIDConverter}" UpdateSourceTrigger="PropertyChanged">
- <MultiBinding.Bindings>
- <Binding Path="BID" Mode="TwoWay"></Binding>
- <Binding RelativeSource="{RelativeSource Mode=Self}" Path="."></Binding>
- </MultiBinding.Bindings>
- </MultiBinding>
- </ComboBox.SelectedIndex>
- </ComboBox>
- </DataTemplate>
Y ahora la implementación del IMultiValueConverter
- public class MyIDtoIDConverter : IMultiValueConverter
- {
- private ComboBox combo;
- public MyIDtoIDConverter()
- {
- combo = null;
- }
-
- public object Convert(object[] values, Type targetType, object parameter, System.Globalization.CultureInfo culture)
- {
- this.combo = values[1] as ComboBox;
- ComboBoxItem comboItem = null;
- int index = 0;
- foreach (ComboBoxItem item in combo.Items)
- {
- OperationType operationType = item.Tag as OperationType;
- if (operationType.Id == values[0] as int?)
- {
- comboItem = item;
- combo.SelectedIndex = index;
- }
- index++;
- }
-
- return combo.SelectedIndex;
- }
-
- public object[] ConvertBack(object value, Type[] targetTypes, object parameter, System.Globalization.CultureInfo culture)
- {
- ComboBoxItem comboItem = this.combo.Items[(int)value] as ComboBoxItem;
- B b = comboItem.Tag as B;
- return new object[] { b.ID };
- }
- }
El Converter almacena el comboBox para que después al hacer el ConvertBack, tenga la referencia del estado de los items. De este modo, tenemos las entidades bindeadas con las propiedades de los elementos de WPF y además manteniendo sus relaciones.
Normalmente para depurar cualquier website se suele emplear el propio puerto 80. En el caso de Azure, podemos tener el inconveniente de forzar el rol a que vaya en ese puerto pero por estar ocupado, se le asigna otro: 81, 82, y los siguientes.
Nuestro primer problema será liberar el puerto 80. Y para eso no hay nada como averiguar qué está ocupando dicho puerto. Lo primero es abrir la consola de comandos y escribir el siguiente comando que nos indicará qué puertos están actualmente a la escucha y el proceso asociado:
netstat –ab
Una vez viendo esto, podemos buscar el proceso a través del Administrador de Tareas y cerrarlo. El problema aquí puede ser lo que se aprecia en la imagen: no podemos ver qué proceso está ocupando el puerto 80. Evidentemente algo hay (es un proceso de sistema: podemos aplicar el comando netstat –anno para saber exactamente qué proceso es el que está ocupando el puerto), pero no nos indica nada. Y no hay ningún modo de saberlo.
Un modo de arreglarlo a fuerza bruta sería cancelar todos los servicios hasta que se libere el puerto. Pero es más fácil en nuestro contexto sin contamos con SQL Server. Simplemente, tenemos que deshabilitar los siguientes servicios y programas:
Y ahora empieza lo bueno, deshabilitando los siguientes servicios:
Con esto, ya tenemos liberado el puerto 80 totalmente para nosotros:
Este error me ha surgido al abrir mis antiguos proyectos para Windows Phone 7, incluso después de instalar todas las últimas actualizaciones de las Windows Phone Tools y reiniciar contínuamente. ¿La solución? Pues la encontré en el foro de desarrolladores.
Lo único que hay que hacer es volver a enlazar la dll de Design.Platform de nuevo a Visual Studio, para ello:
- Abrir la consola de comandos en modo administrador
- Ir hasta c:\ProgramFiles\Microsoft SDKs\Windows\v7.0A\bin\NETFX4.0. Si estás con Windows de 64 bits, entonces tienes que ir hasta ProgramFiles(x86).
- Ejecutar el siguiente comando: - gacutil /i "%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.Windows.Design.Platform.dll" /f. Del mismo modo que antes, si estamos con 64 bits debemos especificar la carpeta ProgramFiles(x86)
- Verificar que al ejecutar el comando, pone: "Assembly successfully added to the cache”.
Aquí dejo una captura de pantalla:
Durante el desarrollo de algunas herramientas es necesario generalizarlas para poder reutilizarlas posteriormente, pero manteniendo siempre una funcionalidad concreta. En el caso que nos ocupa, quiero poder listar una serie de atributos genéricos y poder operar con ellos en la precisión deseada, pero partiendo de la premisa anterior. Es decir, no tendré una clase que disponga de algo similar:
- public class A
- {
- int a;
- float b;
- int c;
- UInt16 x;
- }
Esto es muy costoso de mantener en futuros proyectos, puesto que estaría obligado a cambiar manualmente todos los atributos del objeto y sus nombres pese a que el comportamiento puede estar definido, puesto que sólo me interesa poder operar con los números.
¿Solución? Pues muy sencillo. Por un lado, vamos a almacenar únicamente el nombre de atributo junto con su tipo y valor, todo con string. Posteriormente usaremos reflection para cargar el tipo de forma dinámica. Hasta aquí todo es correcto, nuestro mayor problema será que el evidentemente esos objetos dinámicos no son tipados y el compilador no sabrá qué son salvo que lo especifiquemos explícitamente mediante un casting. Es por ello que aquí entran los tipos dinámicos.
Los tipos dinámicos (o dynamic type, en inglés) es una nueva feature de C# 4.0. Recomiendo la lectura de la documentación para no caer en el error de confundirlos con los tipos anónimos. Debemos tener en cuenta que lo que queremos es operar con ellos en tiempo de ejecución, por lo que toda operación no soportada en tiempo de compilación por un tipo no nos servirá. De ahí que los tipos anónimos no sirva para el siguiente ejemplo, ya que no puedo operar entre objetos sin especificar explícitamente qué quiero hacer.
Es por ello que una vez tenemos el tipo deseado a instanciar mediante Reflection, podemos asignarle el valor y el tipo a la variable dinámica. Y podremos operar con ellos como si se tratase de tipos compilados previamente. Veamos un ejemplo:
- class Program
- {
- static void Main(string[] args)
- {
- string uno = "1";
- string dos = "2,5";
-
- dynamic a = Convert.ChangeType(uno, Type.GetType("System.Single"));
- dynamic b = Convert.ChangeType(dos, Type.GetType("System.Single"));
-
- Console.Out.WriteLine(a);
- Console.Out.WriteLine(b);
- Console.Out.WriteLine(a+b);
- Console.Out.WriteLine(a-b);
- Console.Out.WriteLine(a*b);
- Console.Out.WriteLine(a/b);
- Console.ReadLine();
- }
- }
A través de Type.GetType() uso Reflection para cargar el tipo que quiero instanciar. Con Convert.ChangeType asigno un valor a un tipo, y todo ello a una variable dinámica. De este modo podremos operar con los números como si se tratasen de floats.