El alegre bandolero...

[Xamarin.iOS] Uso de DropBox Sync API con C#

José Miguel Torres — Fri, 08 Mar 2013 11:39:54 GMT

DropBox ha hecho público, durante esta semana, la API para la sincronización del servicio de archivos en la “nube” para las plataformas iOS y Android.

En el caso del SDK de iOS, pese a que está íntegramente orientada a la plataforma iOS nativa, es posible integrarla en proyectos Xamarin.iOS (desde Visual Studio o Xamarin Studio) a través de los Binding Projects. Para los que no estan familiarizados con este tipo de proyectos, los Binding Projects son un tipo específico de proyecto que permite en enlace de las librerias nativas tanto de Apple como de terceros, como es el caso de DropBox o las impresoras Zebra, para que puedan ser utilizadas desde código administrado.

En otras palabras, básicamente lo que hace es enlazar la definición de las interfaces, clases, delegados, métodos, propiedades, etc.. de la librería nativa en base a un archivo header .h a su homólogo en C#:

    @interface Widget : NSObject {
        @property (nonatomic, readwrite, assign) CGPoint center;
    }

por ejemplo a:

[BaseType (typeof (NSObject))]
    interface Widget {
        [Export ("center")]
        PointF Center { get; set; }
    }

En definitiva, prácticamente todas las API de terceros (o almenos las mas importatens) tienen su correspondiente binding en Xaxmarin.iOS y la nueva DropBox Sync API no es menos. La podéis descargar desde aquí. Si clonáis el repositorio público monotouch-bindings vereis, además, todas las librerias enlazadas con Xamarin.iOS, con ejemplos y documentación.

Para poder ejecutar el ejemplo y/o hacer uso de la libreria DropBoxAPISync.iOS teneis dos opciones. O crear un proyecto Xamarin.iOS Binding Project y añadir los archivos de datos que encontrareis en la carpeta binding del repositorio o bien ejecutar desde el Mac el siguiente comando:

$ cd /<<MiPath>>/monotouch-bindings/DropBoxSync/binding && make all

Esto generará la libreria DropBoxSync.iOS.dll y lo único que tendreis q hacer es referenciarla desde el ejemplo cargado en el Visual Studio. Ejecutar en el emulador o dispositivo físico y listos.

Anuncion oficial de Xamarin 2.0 ¡Ya está aquí!

José Miguel Torres — Wed, 20 Feb 2013 14:18:00 GMT

Después de meses y meses de trabajo continuo hoy sale a la luz una de las obras de ingenieria mas excepcional y complejas de las que he tenido el placer de participar y que pretende ser un antes y un después para las apps multiplataforma de la mano de Xamarín, una –aún- empresa start-up con sede en Boston y San Francisco con una comunidad actual de más de 230.000 desarrolladores y un crecimiento del ultimo año de entorno al 300%.

Xamarin es, hoy por hoy, la unica plataforma que está 100% enfocada a hacer de C# el lenguaje de desarrollo por escelencia para la construcción de apliaciones nativas en entornos no Microsoft como demuestran los múltiples casos de éxito de empresas y aplicaciones del sector.

¿Qué es Xamarin 2.0?

Xamarin 2.0 es la nueva oleada de productos de la plataforma Xamarin para desarrollar aplicaciones multiplataforma con Visual C# de los que cabe destacar:

Nuevo IDE Xamarin Studio. Se trata de un IDE 100% multiplataform centrada especialmente en la experiencia del usuario siendo aún más intuitiva, con una interfaz de usuario extraordinaria y mucho más!

¡¡Soporte de Visual Studio para desarrollo de aplicaciones iOS!!! Si, habéis leído bien. Xamarin ha lanzado el soporte oficial para el desarrollo de aplicaciones iOS desde Visual Studio 2010 y 2012. Ahora los usuarios de Xamarin.iOS podrán escribir código fuente desde Visual Studio y debugar y ejectura la aplicación desde el propio VS, en el emulador o dispositivo físico conectado al Mac donde está instalado Xamarin.iOS. Se trata de un producto que ha venido siendo solicitiado por los clientes y con esta primera versión se ha conseguido enlazar el compilador de Xamarin.iOS instalado en un Mac con Visual Studio centrandose especialmente en la experiencia del desarrollador.

Xamarin Component Store. Se trata de una librería de pre-built components multiplataforma que está presente tanto para Visual Studio como Xamarin Studio y que pretende ser una store de código para aplicaciones multiplataforma con toda clase de componentes (gratuitos y de pago) tanto librerias como componentes gráficos.

Edición Started Edition ¡totalmente grauita! para tod@s aquellos que quieran conocer la potencia de la plataforma Xamarin, esta versión te permitirá desarrollar aplicaciones en cualquier plataforma con la única limitación de que el tamaño máximo de la aplicación es de 32k (en IL).

¿Y ahora qué?

¡Pues a ahora a descargarselo y trastearlo! Aprovechate de las ventajas de la edición Started Edition, prueba la versión completa con la trial de 30 dias en cualquier momento y comprueba por tí mismo la ventaja que tiene el conocer el tu lenguaje de programación favorito para adentrarte en plataformas como iOS con Xamarin.iOS o Android con Xamarin.Android. ¿Aún necesitas más? Pues mira aqui:

Más aún:

Registrate al evento online que ofreceran Nat Friedman y Miguel de Icaza el 5 de Marzo. Más info aqui.
¿Quieres conocer a los Xamurais en persona? Ven al Evolve 2013 que tendrá lugar en Austin (TX) el 14-17 de Abril. Miguel de Icaza, Scott Hanselman, Nat Friedman y toda la plantilla de Xamarin estaremos por allí.

Si aún necesitas más info, no dudeis en contactarme. Prometo hablar largo y tendido sobre todo esto y más!

Ready in the back!!!

EVOLVE 2013, conferencia internacional de desarrollo móvil

José Miguel Torres — Sun, 20 Jan 2013 19:40:24 GMT

Para los que queráis estar al día en cuanto a desarrollo de aplicaciones móviles con Visual C# se refiere, el próximo mes de Abril tendrá lugar en Austin (Texas, EEUU) 4 días repletos de sesiones (2 de Training y otras 2 más de conferencias) de la mano de los mayores expertos en los productos Xamarin.

Speakers de la talla de Miguel de Icaza, Scott Hanselman o Nat Friedman se daran cita durante los dias 14, 15, 16 y 17 en el lujoso Hotel Hilton Austin del que será sin duda la conferencia anual de referencia para los desarrolladores de plataformas Android y iOS con la plaraforma Xamarin. Diseño de aplicaciones móviles, experiencia de usuario, movilidad en el mundo empresarial, App marketing y monetización o incluso las mejores prácticas para soluciones Cross-Platform son sólo un ejemplo de la temática que se tocará en Evolve 2013.

Tanto si estás interesado en adentrarte en el mundo de desarrollo de aplicaciones móviles con Visual C# para otras plataformas como Android o iOS o simplemente ya tienes experiencia y quieres aprender y estar al día de la mano de los mayores expertos, esta es tu gran oportunidad. Podéis registraros únicamente a la formación o a la conferencia o a ambas. Ah! y los 100 primeros inscritos tendran un descuento del 20%.

¡Nos vemos en Austin!

Más info | Evolve 2013

Nuevo curso de Mono for Android

José Miguel Torres — Tue, 16 Oct 2012 09:02:00 GMT

Hace ya poco más de dos meses que me incorporé en Xamarin, Inc. y me ha sorprendido gratamente la gran acogida que ha tenido y está teniendo, especialmente en USA, dos de los productos estrellas de MONO, Mono for Android y MonoTouch.

Por experiencia propia la habilidad de conocer Visual C# es una gran ventaja a la hora de adentrarse a desarrollar para otras plataformas, en las que además de tener que lidiar con la idiosincrasia de la propia plataforma tienes que hacer lo propio con el entorno de desarrollo y más importante con el lenguaje de programación. Y es que aunque no soy un gran conocedor de java u objective-c la potencia que tiene Visual C# respecto a sus competidores es, en mi honesta opinión, importante.

Para todos aquellos que ahora tengáis la oportunidad o necesidad de adentrarse en el desarrollo de dispositivos Android con Visual C#, además de la aclamada librería de documentación que mantenemos en Xamarín, los amigos de CampusMVP han lanzado un curso que nada tiene que envidiarla con la ventaja de que además está en español.

Se trata de un curso de divididos en 10 módulos que tratan el ciclo de vida de desarrollo de aplicaciones Mono for Android, desde los cimientos de MONO y su adaptación a Android hasta el despliegue de aplicaciones en el Marketplace pasando por todas la características de la plataforma, Actividades, Notificaciones, Menús, controles estándares y customizados… vamos un curso que no os podéis perder escrito por un excelente profesional como lo es Rubén Rubio.

Ahora si, ya tenemos material didáctico en español y además de la mano de CampusMVP.

Más info | Sitio oficial del curso

Bye, bye… MVP

José Miguel Torres — Mon, 26 Mar 2012 17:55:40 GMT

Como todo en esta vida, todo lo que empieza … acaba y ha llegado mi hora en el programa MVP. Probablemente el 2011 ha sido uno de los años más dificiles de mi vida y las comunidades han pasado a estar en un segundo plano, de hecho aún siguen estandolo pues tampoco las estoy disfrutando como hace 5 años, cuando empecé en el programa MVP.

Que me llevo…

Si tuviera que quedarme con algo del programa más allá “del titulo” y los viajes, sin dudarlo ni un solo segundo me quedo con toda la gente que he conocido y que espero poder mantener siempre y con los que he compartido programa desde el 2008, empezando por Alejandro Mezcua con el que compartí viaje a Seattle en mi primer MVP Summit en el 2008 y con el que tengo el privilegio de poder coger el teléfono y llamarlo que siempre está ahí. A Marino Posadas por las oportuniades que me ofreció en un momento muy delicado de mi vida. A Pep Lluis Baño, el padre de las comundiades y el “Papá” de muchos de nosotros –no lo digo por la edad, lo digo por la experiencia. A Hadi Hariri, el Che Guevara de la comunidad. Joder, ¡¡cuanto he aprendido de ti chaval!!! A mi muy mejor amigo, Roberto González, por las cervezas, la compañía y las risas, jamás olvidaré esas noches de Seattle. A Luis Fraile, porque siempre he acabado haciendo lo que él decía, y he de reconocer que siempre ha acertado. Al titán, Rodrigo Corral, por que pese a que haga regimen siempre será grande. A Unai Zorrila, por que es un cabrón y por que no hay ningúno como él, especialmente en lo profesional (de lo mejor sin duda). A Jorge Serrrano, creo que si alguien define el programa es él. A Lluis Franco del Hospitalete, mi otro yo, y el sabe porque lo digo (Cuanto te quiero chaval). A José Manuel Alarcón, como dice su paisano El Pazos, el so machi bum man, un currante como la copa del pino y el único que se atrevió a editarme el libro; gracias tio. A Juan Carlos González, uno de los MOSS men; tengo pendiente un viaje Cantabria, no lo olvides. A “El Ché El Bruno Capuano”, contigo aprendí q los argentinos sos grandes, tu el que más. A Marco Amoedo, mi compañero de habitación en mis últimos viajes con el he compartido más que habitación; no, no me refiero a eso, no seais mal pensados. A José Luis Latorre, con el que además de compartír patrón de nombre, comparto una buena amistad. Gracias por todo chaval y perdona si no he estado a la altura. A Toni Recio, al que le llamo con todo mi cariño y aprecio “El Follonero” y porque hace más de 3 años que le debo una comida (snif!!!!!) y pq ha sabido ver otra forma de ver las comunidades. A Marc Rubiño, al que veo a diario, por no darme más por saco con el Barça. Ah si, y por que si tengo dudas de ASP.NET, la daré la chapa a él. A Octavio Hernández, el único hombre que además del dominar el españo y el inglés, domina C#. A Julián Peris, porque es unico. De verdad, no hay nadie igual a él. Fue en su momento el alma matter de los MVP Summit. A Eduardo Ortega, el friki por excelencia. A David Nudelman, porque es unico en su especie porque, como su propio apellido indica, es español 100% .A los SolidQ boys: Eladio Rincón, Miguel de Egea, Salvador Ramos… la crem de la crem. A los chicos de Plain, desde Ibón Landa, “el Joseba” hasta Iván González. Gracias por cogerme el teléfono cuando he estado con problemas. Os debo una. A Juansa Llopis, “Palel” Pilar, Iñaki Ayúcar pq aun en la distancia nos mantenmos cercanos. Y como no, a la jefa, a Cristina González, por todo.

Ostia, me emocioné y no he podido evitar nombrar a tod@s los que me han venido a la cabeza y seguro que me olvido a alguien. Si es así no me lo tengais en cuenta; además nos volveremos a ver por ahí, un sarao sin El Alegre Bandolero, no es un sarao. :-)

Cuando nos volvamos a ver, que sea en los bares…

josemiguel

[ESTUDIOS] Los low-end Smartphones acapararán el mercado de telefonia móvil en el 2015

José Miguel Torres — Mon, 29 Aug 2011 13:30:08 GMT

Según un reciente estudio llevado a cabo por IHS iSuppli Mobile Handset Market Tracker el mercado de los smartphones pueden llegar a acaparar el mercado del e-commerce a nivel mundial en el año 2015.

Las previsiones estiman que más de 1.000 millones de unidades serán vendidas durante el año 2015, doblando los actuales 478 millones de este año 2011. El incremento se situa, por lo tanto, en un 54.4% muy por encima del 32.5% de este mismo año.

Esta subida será principalmente promovida por la aparición de los Low Cost Smartphones, términales móviles de características limitadas en términos de capacidad y memoria en relación a los Smartphones de altas prestaciones. Dentro de este mismo estudio se prevee que el crecimiento porcentual de la gama Low Cost se sitúe por encima del 115% mientras que la tasa de crecimiento de los Smartphones de media y alta gama permanecerán en un 16.4%.

La bajada de precio para el consumidor así como la irrupción de las denomiadas economías emergentes de paises como China, India, la zona del sur este asiático así como Africa catapultaran este tipo de terminales móviles.

Un ejemplo claro de lo que se puede esperar lo materializa la empresa Samsung gracias a la aparición de terminales de bajo coste en mercados como el de China o Latino América con un incremento en ventas muy superior al de resto de competidores.

Por su parte, y con la anunciada bajada de requisitos de hardware anunciada en el MIX del 2011, Windows Phone 7.1 “Mango” pretende ser la lanzadera perfecta para otro monstruo de la telefonía móvil como es la compañía finlandesa Nokia.

Se abre, por tanto, un periodo en el que una nuevo concepción de Smartphone pretende tomar las riendas del apetitoso mercado de Internet en téminos de ventas, telefonía y como no, e-commerce.

Más info | Smartphones to Account for Majority of Cellphone Shipments by 2015

REACTIVE-ando información de la DGT en Windows Phone 7 (y II)

José Miguel Torres — Tue, 12 Apr 2011 07:17:00 GMT

Lo prometido es deuda y ya está publicada la aplicación –bastante simple- de ejemplo en el Marketplace de Windows Phone 7, después de sortejar algún contratiempo en el proceso de validación, especialmente con la gestión del estado de la aplicación.

Decir que la aplicación se llama ViV Trafico (Visor Incidencia Viarias), y en esta primera versión proporciona una opción de filtrado por Autonomia, Carretera y Población. Evidentemente se le puede sacar mucho más provecho pero mientras, el tiempo que tengo para dedicar no me da para más.

La aplicación la podéis descargar haciendo click en el siguiente logo.

Por otro lado, también he compartido el código completo de la aplicación que está en el Marketplace, para vuestro interés. Está hospedado en http://vivtrafico.codeplex.com

Un saludo,

REACTIVE-ando información de la DGT en Windows Phone 7

José Miguel Torres — Mon, 21 Mar 2011 11:30:00 GMT

Desde hace algún tiempo he estado mirando y estudiando las posibilidades de las Reactive Extensions -Rx-, las cuales se encuentran actualmente en los Labs de Microsoft. Con la aparicición de Windows Phone 7, tenemos a nuestra disposición parte de estas extensiones dentro de los ensamblados Microsoft.Phone.Reactive y System.Observable. De hecho existe una versión específica de Rx para WIndows Phone 7 además de las que vienen instaladas en la ROM por defecto pero cuya instalación no está incluida en la ROM.

El caso es que durante el fin de semana se me ocurrió la idea de obtener la información que la Dirección General de Tráfico expone a través de un feed en XML de forma que pueda ser consultada por una aplicación WP7. Recordaba algunos ejemplos, básicamente orientados a la API de Twitter, en los que mostraba toda la potencia de la Rx en operaciones asincronas y manejo de eventos.

Lo que inicialmente se convirtió en un ejercicio de refresco y puesta en práctica de las Rx finalmente se ha convertido en una aplicación que publicaré en el marketplace de WP7 en breve. Además, compartiré el código íntegro de dicha aplicación en codeplex. Anunciaré tales novedades en este mismo blog.

Información de la DGT

Antes de entrar en profundidad vamos a ver que es lo ofrece la API de la DGT. La url es : http://dgt.es/incidencias.xml y el resultado:

Es decir que un elemento o incidencia tiene el siguiente formato XML:

   1: <incidencia>

   2:     <tipo>METEOROLOGICA</tipo>

   3:     <autonomia>ANDALUCIA</autonomia>

   4:     <provincia>JAEN</provincia>

   5:     <matricula>J</matricula>

   6:     <causa>LLUVIA</causa>

   7:     <poblacion>SANTA ELENA</poblacion>

   8:     <fechahora_ini>2011-03-12 19:48</fechahora_ini>

   9:     <nivel>VERDE</nivel>

  10:     <carretera>A-4</carretera>

  11:     <pk_inicial>245.0</pk_inicial>

  12:     <pk_final>288.0</pk_final>

  13:     <sentido>Ambos sentidos</sentido>

  14:     <hacia>Ambos</hacia>

  15: </incidencia>

Y la representación en C# es básicamente….

   1: public class Incidencia

   2: {

3:

   4:     public Incidencia()

   5:     { }

6:

   7:     public string Tipo { get; set; }

   8:     public string Autonomia { get; set; }

   9:     public string Matricula { get; set; }

  10:     public string Causa { get; set; }

  11:     public string Poblacion { get; set; }

  12:     public string FechaHora { get; set; }

  13:     public string Nivel { get; set; }

  14:     public string Carretera { get; set; }

  15:     public string Incial { get; set; }

  16:     public string Final { get; set; }

  17:     public string Sentido { get; set; }

  18:     public string Hacia { get; set; }

  19: }

En realidad, en el proyecto final aparecen un par de campos más utilizados para notificar informaciones a la pantalla, hablaremos de ello más adelante.

REACTIVEando la solución

Decidí utilizar las Rx para, por un lado englobar la operación WebRequest y posterior deserialización del XML en una colección IObservable y por otro lado utilizar las extensiones de Rx para que de forma reactiva consulte la información expuesta en el API de la DGT cada 3 minutos y notifique los cambios a un subscritor que no es más que una colección ObservableCollection enlazada a una aplicación Windows Phone 7.

Vayamos por partes. Un esquema aproximado seria el siguiente:

En primer lugar creamos la petición a la dirección URL donde se aloja el XML indicandole el método y el contenido.

   1: var webRequest =

   2:     WebRequest.Create(new Uri("http://dgt.es/incidencias.xml"));

3:

   4: webRequest.Method = "POST";

   5: webRequest.ContentType = "text/XML";

A continuación realizamos la llamada asíncrona mediante BeginGetResponse y EndGetResponse y es aqui dónde entra en escena las Rx. Utilizando el método Observable.FromAsynPattern<T> podemos convertir la función Begin/End a una función asíncrona de la siguiente forma:

   1: var peticion = Observable.FromAsyncPattern<WebResponse>(

   2:                     webRequest.BeginGetResponse,

   3:                     webRequest.EndGetResponse);

De esta forma obtenemos un delegado del tipo System.Func<System.IObservable<System.Net.WebResponse>> representado por la variable implícita peticion, vamos, una función de salida con un iterador del tipo IObservable. Ahora es el turno de LINQ –de ahí q en ocasiones se conozcan las Rx como LINQ to Events. Lo q vamos a hacer es seleccionar la respuesta Web y retornarla en forma de IEnumerable<Incidencias>. La sentencia LINQ tendria el siguiente aspecto:

   1: IEnumerable<Incidencia> res = from elemento in peticion()

   2:     .Select(respuestaWeb =>

   3:     {

   4:         using (var rs = respuestaWeb.GetResponseStream())

   5:         {

   6:             return rs.Deserialize(respuestaWeb.ContentLength);

   7:         }

   8:     })

   9:     select elemento;

La responsabilidad de transformar el Stream que contiene todo el XML en un IEnumerable<Incidencias> recae sobre el método extensor –de Stream- Deserialize. Básicamente lo que hace es obtener del stream todo el XML y mediante LINQ to XML “deserializarlo” –no es exactamente una deserialización- en una lista generica del tipo Incidendica tal y como se muestra a continuación:

   1: public static IEnumerable<Incidencia> Deserialize(this Stream objeto, long lenght)

   2: {

   3:     var readBuffer = new byte[lenght];

4:

   5:     IEnumerable<Incidencia> nuevasIncidencias = null;

6:

   7:     objeto.BeginRead(readBuffer, 0, readBuffer.Length,

   8:                         readAr =>

   9:                             {

  10:                                 var read = objeto.EndRead(readAr);

  11:                                 var readText = Encoding.UTF8

  12:                                     .GetString(readBuffer, 0, readBuffer.Length);

13:

  14:                                 nuevasIncidencias = from elemento in XDocument.Parse(readText)

  15:                                                         .Descendants("raiz").Descendants("incidencia")

  16:                                                     select new Incidencia

  17:                                                             {

  18:                                                                 Autonomia = elemento.Element(XName.Get("autonomia")).Value,

  19:                                                                 Carretera =

  20:                                                                     elemento.Element(XName.Get("carretera")).Value,

  21:                                                                 Causa = elemento.Element(XName.Get("causa")).Value,

  22:                                                                 FechaHora =

  23:                                                                     elemento.Element(XName.Get("fechahora_ini")).Value,

  24:                                                                 Final = elemento.Element(XName.Get("pk_final")).Value,

  25:                                                                 Hacia = elemento.Element(XName.Get("hacia")).Value,

  26:                                                                 Incial = elemento.Element(XName.Get("pk_inicial")).Value,

  27:                                                                 Matricula =

  28:                                                                     elemento.Element(XName.Get("matricula")).Value,

  29:                                                                 Nivel = elemento.Element(XName.Get("nivel")).Value,

  30:                                                                 Poblacion =

  31:                                                                     elemento.Element(XName.Get("poblacion")).Value,

  32:                                                                 Sentido = elemento.Element(XName.Get("sentido")).Value,

  33:                                                                 Tipo = elemento.Element(XName.Get("tipo")).Value

  34:                                                             };

  35:                             }, null);

36:

  37:     return nuevasIncidencias;

  38: }

Hasta aquí tenemos los puntos 1 y 2 del esquema resuelto. Todo esto deberíamos encapsularlo en un método de forma que podamos, posteriormente aplicarle algún tipo de comportamiento como por ejemplo exponerlo como Observable. Una forma de hacerlo seria apoyándonos en el método estático Defer de Observable tal y como se muestra a continuación.

   1: internal IObservable<IEnumerable<Incidencia>> PrepararPeticion()

   2: {

   3:     return Observable.Defer(() =>

   4:     {

   5:         var webRequest =

   6:             WebRequest.Create(new Uri("http://dgt.es/incidencias.xml"));

7:

   8:         webRequest.Method = "POST";

   9:         webRequest.ContentType = "text/XML";

10:

  11:         var peticion = Observable.FromAsyncPattern<WebResponse>(

  12:             webRequest.BeginGetResponse,

  13:             webRequest.EndGetResponse);

14:

  15:         return from elemento in peticion()

  16:             .Select(respuestaWeb =>

  17:             {

  18:                 using (var rs = respuestaWeb.GetResponseStream())

  19:                 {

  20:                     return rs.Deserialize(respuestaWeb.ContentLength);

  21:                 }

  22:             })

  23:             select elemento;

  24:     });

  25: }

Para facilitarnos el trabajo vamos a encapsular el método en una clase llamada DgtContexto y dentro del constructor de éste vamos a exponer la colección obtenida del Request y representada por el método PrepararPeticion() de la siguiente forma:

   1: public DgtContexto(int frecuencia)

   2: {

   3:     PrepararPeticion()

   4:         .ObserveOnDispatcher()

   5:         .Subscribe(incidencias =>

   6:                         {

   7:                            //TODO

   8:                         });

   9: }

Dentro de la clase DgtContexto debemos exponer una propiedad ObservableCollection que será la que posteriormente servirá como origen de datos para la aplicación Windows Phone 7.

   1: public class DgtContexto: INotifyPropertyChanged

   2: {

   3:     public ObservableCollection<Incidencia> Incidencias{ get; set; }

   4:     public DateTime Hora { get; set; }

5:

   6:     public DgtContexto() {}

7:

   8:     internal IObservable<IEnumerable<Incidencia>> PrepararPeticion() {}

9:

  10:     public event PropertyChangedEventHandler PropertyChanged;

11:

  12: }

Además creamos una propiedad Hora para conocer la fecha y hora de la información que nos hemos descargado y por útlimo implementamos, la interfaz INotifyPropertyChanged para propagar las modificaciones a la UI de la aplicación.

Ahora toca el turno a cómo relacionamos la lista IEnumerable<Incidencia> descargada del servidor de la DGT con la ObservableCollection de la clase DgtContexto. Esta operación se realizará en la subscripción a la colección retornada por el método PrepararPeticion(). Mediante expresiones lambda podemos obtener la acción onNext devuelta por el IObservable en forma de Action<IEnumerable<Incidencia>>, asignamos la lista iterativa IEnumerable<Incidencia> a la ObservableCollection y notificamos el cambio mediante la llamada a PropertyChanged de la interfaz INotifyPropertyChanged implementada anteriormente. Si, ya lo se, no es posible hacer un cast implícito de una colección IEnumerable<Incidencia> a una ObservableCollection<Incidencia> y para ello vamos a crear un método extensor que lo haga:

   1: public static ObservableCollection<T> ToObservableCollection<T>(this IEnumerable<T> enumerable)

   2: {

   3:     var col = new ObservableCollection<T>();

4:

   5:     foreach (var cur in enumerable)

   6:     {

   7:         col.Add(cur);

   8:     }

9:

  10:     return col;

  11: }

Finalmente modificamos la propiedad Hora y notificamos y en definitiva el constructor con la suscripción completa quedaría de la siguiente forma:

   1: public DgtContexto()

   2: {

   3:     PrepararPeticion()

   4:         .ObserveOnDispatcher()

   5:         .Subscribe(incidencias =>

   6:                         {

   7:                             Incidencias = incidencias.ToObservableCollection();

   8:                             NotifyPropertyChanged("Incidencias");

   9:                             Hora = DateTime.Now;

  10:                             NotifyPropertyChanged("Hora");

  11:                         });

  12: }

Tenemos creada la infraestructura pero no estamos sacando provecho –del todo- a las Rx. Si queremos que la aplicación esté monitorizando las modificaciones de la información de la DGT podriamos crear un Timer o un Thread progamado para que lo consulte cada 3 minutos, por ejemplo. Otra opción seria utilizar las extensiones de Rx, más concretamente con los métodos Timer y Select, conjuntamente. El primero temporizará un periodo de tiempo representado por valores long desde 0 hasta TimeSpan.FromMinutes(frecuencia) donde el valor pasado por defecto desde el constructor vacío es 3. Luego proyectamos todos los valores devueltos por PrepararPeticion() desde el XML de la DGT y lo transformamos la collección IObservable más reciente mediante el método Switch(), con lo que el constructor quedará de la siguiente forma:

   1: public DgtContexto(int frecuencia)

   2: {

3:

   4:     Observable.Timer(TimeSpan.Zero, TimeSpan.FromMinutes(frecuencia))

   5:         .Select(_ => PrepararPeticion())

   6:         .Switch()

   7:         .ObserveOnDispatcher()

   8:         .Subscribe(incidencias =>

   9:                         {

  10:                             Incidencias = incidencias.ToObservableCollection();

  11:                             NotifyPropertyChanged("Incidencias");

  12:                             Hora = DateTime.Now;

  13:                             NotifyPropertyChanged("Hora");

  14:                             System.Diagnostics.Debug.WriteLine(DateTime.Now.ToLongTimeString() + " " +

  15:                                                                 Incidencias.Count.ToString());

  16:                             IsDataLoaded = true;

  17:                         });

  18: }

Podreis encontrar la clase completa a final del post.

Enlace con la UI

Para enlazar con la UI, basta con crear un proyecto Pivot o Panorama. En este blog indicaré como crear los datos de ejemplo y como queda el XAML del MainPage.xaml con dos campos enlazados. Básicamente el enlace de datos es identico a como se hace normalmente. Además de lo comentado anteriormente unicamente hay que modificar el archivo App.cs. Por partes, el App.cs quedará así:

   1: public partial class App : Application

   2: {

   3:     private static DgtContexto viewModel = null;

4:

   5:     /// <summary>

   6:     /// A static ViewModel used by the views to bind against.

   7:     /// </summary>

   8:     /// <returns>The MainViewModel object.</returns>

   9:     public static DgtContexto ViewModel

  10:     {

  11:         get

  12:         {

  13:             // Delay creation of the view model until necessary

  14:             if (viewModel == null)

  15:                 viewModel = new DgtContexto();

16:

  17:             return viewModel;

  18:         }

  19:     }

20:

  21: //el resto idéntico....

  22: //NOTE: clase incompleta

  23: }

NOTA: Unicamente he utilizado un par de campos en modo de test para comprobar el comportamiento de las Rx más que de la propia pantalla

El archivo xml de muestra:

   1: <DGT:DgtContexto

   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:     xmlns:DGT="clr-namespace:desarrolloMobile.DGT;assembly=desarrolloMobile.DGT"

   5:     Hora="12/12/2011 12:00:00">

6:

   7:     <DGT:DgtContexto.Incidencias>

   8:         <DGT:Incidencia Autonomia="CAT" Carretera="A2"/>

   9:         <DGT:Incidencia Autonomia="MAD" Carretera="A1"/>

  10:     </DGT:DgtContexto.Incidencias>

11:

  12: </DGT:DgtContexto>

Y el XAML de MainPage:

   1: <phone:PhoneApplicationPage

   2:     x:Class="desarrolloMobile.DGTViewer.MainPage"

   3:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   4:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   5:     xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"

   6:     xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"

   7:     xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

   8:     xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

   9:     mc:Ignorable="d" d:DesignWidth="480" d:DesignHeight="768"

  10:     d:DataContext="{d:DesignData SampleData/MainViewModelSampleData.xaml}"

  11:     FontFamily="{StaticResource PhoneFontFamilyNormal}"

  12:     FontSize="{StaticResource PhoneFontSizeNormal}"

  13:     Foreground="{StaticResource PhoneForegroundBrush}"

  14:     SupportedOrientations="Portrait"  Orientation="Portrait"

  15:     shell:SystemTray.IsVisible="True">

16:

  17:     <!--Data context is set to sample data above and LayoutRoot contains the root grid where all other page content is placed-->

  18:     <Grid x:Name="LayoutRoot" Background="Transparent">

  19:         <Grid.RowDefinitions>

  20:             <RowDefinition Height="Auto"/>

  21:             <RowDefinition Height="*"/>

  22:         </Grid.RowDefinitions>

23:

  24:         <!--TitlePanel contains the name of the application and page title-->

  25:         <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">

  26:             <TextBlock x:Name="ApplicationTitle" Text="MY APPLICATION" Style="{StaticResource PhoneTextNormalStyle}"/>

  27:             <TextBlock x:Name="PageTitle" Text="page name" Margin="9,-7,0,0" Style="{StaticResource PhoneTextTitle1Style}"/>

  28:         </StackPanel>

29:

  30:         <!--ContentPanel contains ListBox and ListBox ItemTemplate. Place additional content here-->

  31:         <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">

  32:             <ListBox x:Name="MainListBox" Margin="8,-44,-20,44" ItemsSource="{Binding Incidencias}" SelectionChanged="MainListBox_SelectionChanged">

  33:                 <ListBox.ItemTemplate>

  34:                     <DataTemplate>

  35:                       <StackPanel Margin="0,0,0,17" Width="432">

  36:                           <TextBlock Text="{Binding Autonomia}" TextWrapping="Wrap" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

  37:                           <TextBlock Text="{Binding Carretera}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

  38:                       </StackPanel>

  39:                     </DataTemplate>

  40:                 </ListBox.ItemTemplate>

  41:             </ListBox>

  42:             <TextBox Height="80" Margin="0,0,181,8" TextWrapping="Wrap" Text="{Binding Ticks, Mode=OneWay}" VerticalAlignment="Bottom" DataContext="{Binding Hora.TimeOfDay, Mode=OneWay}"/>

  43:         </Grid>

  44:     </Grid>

45:

  46: </phone:PhoneApplicationPage>

La captura de pantalla de la aplicación funcionando mostrando un par de campos en modo de test:

NOTA: Imagen de la futura aplicación q colgaré en el MarketPlace a fecha de hoy y que implementa el código mostrado en este post.

Otros retoques

Por lo que he podido observar existen un promedio de más de 250 incidencias activas y ya q pretendo subir la aplicación al Marketplace he tratado q fuera algo más util. Es por ello que además vamos a filtrar las incidencias por carretera, autonomia y población.

La forma más sencilla de hacerlo es utilizando la propia información de la DGT, es decir hacer un SELECT DISTINCT de carreteras, autonomias y población de las 200 y pico incidencias y las muestro en un formulario de forma que el usuario seleccione el valor por el que filtrar. El código es el siguiente para cada una de los filtros:

   1: var context = (from incidencia in App.ViewModel.Incidencias

   2:                 select incidencia.Poblacion)

   3:                 .Distinct()

   4:                 .OrderBy(incidencia => incidencia);

Ahora, una vez mostrados por pantalla el usuario selecciona un valor, es decir, una carretera, una autonomia o una población. Sea cual sea lo que al final tenemos que hacer para mostrar los resultados filtrados es pasarle el valor de un predicado al método Where en el método Subscribe() del constructor DgtContexto de de la siguiente forma:

   1: public DgtContexto(int frecuencia, Func<Incidencia, bool> predicado)

   2: {

   3:     Predicado = predicado;

4:

   5:     Observable.Timer(TimeSpan.Zero, TimeSpan.FromMinutes(frecuencia))

   6:         .Select(_ => PrepararPeticion())

   7:         .Switch()

   8:         .ObserveOnDispatcher()

   9:         .Subscribe(incidencias =>

  10:                         {

  11:                             IncidenciasTotal = incidencias.ToObservableCollection();

  12:                             Incidencias = (incidencias

  13:                                 .Where(Predicado))

  14:                                 .ToObservableCollection();

  15:                             NotifyPropertyChanged("Incidencias");

  16:                             Hora = DateTime.Now;

  17:                             NotifyPropertyChanged("Hora");

  18:                             IsDataLoaded = true;

  19:                         });

  20: }

El tipo del predicado en los tres casos –esto es, filtro por autonomia, población o carretera- sera del tipo Func<Incidencia,bool>. Lo único q hacemos es crear una propiedad de ese tipo llamado Predicado en la clase DgtContexto que asignaremos cuando el usuario seleccione un valor del filtro:

   1: private void lstBoxAutonomia_SelectionChanged(object sender, SelectionChangedEventArgs e)

   2: {

   3:     ((TextBlock) lstBoxAutonomia.SelectedItem).FontSize -= 6;

   4:     App.ViewModel.Predicado = (incidencia => incidencia.Autonomia == ((TextBlock) this.lstBoxAutonomia.SelectedItem).Text);

   5:     NavigationService.GoBack();

   6: }

7:

   8: private void lstBoxPoblacion_SelectionChanged(object sender, SelectionChangedEventArgs e)

   9: {

  10:     ((TextBlock)lstBoxPoblacion.SelectedItem).FontSize -= 6;

  11:     App.ViewModel.Predicado = (incidencia => incidencia.Poblacion == ((TextBlock)this.lstBoxPoblacion.SelectedItem).Text);

  12:     NavigationService.GoBack();

  13: }

14:

  15: private void lstBoxCarretera_SelectionChanged(object sender, SelectionChangedEventArgs e)

  16: {

  17:     ((TextBlock)lstBoxCarretera.SelectedItem).FontSize -= 6;

  18:     App.ViewModel.Predicado = (incidencia => incidencia.Carretera == ((TextBlock)this.lstBoxCarretera.SelectedItem).Text);

  19:     NavigationService.GoBack();

  20: }

El resultado desde la interfaz gráfica es:

Y el resultado del filtro por COMUNIDAD_CANARIA:

Clase DgtContexto

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Collections.ObjectModel;

   4: using System.ComponentModel;

   5: using System.Linq;

   6: using System.Net;

   7: using Microsoft.Phone.Reactive;

8:

   9: namespace desarrolloMobile.DGT

  10: {

  11:     public class DgtContexto : INotifyPropertyChanged

  12:     {

  13:         public ObservableCollection<Incidencia> Incidencias { get; set; }

  14:         private ObservableCollection<Incidencia> IncidenciasTotal { get; set; }

15:

  16:         public DateTime Hora { get; set; }

17:

  18:         public DgtContexto()

  19:             : this(3, incidencia => true)

  20:         { }

21:

  22:         private Func<Incidencia, bool> _predicado;

  23:         public Func<Incidencia, bool> Predicado

  24:         {

  25:             get

  26:             {

  27:                 return _predicado;

  28:             }

  29:             set

  30:             {

  31:                 _predicado = value;

  32:                 if (Incidencias != null)

  33:                 {

  34:                     Incidencias = Incidencias

  35:                         .Where(Predicado)

  36:                         .ToObservableCollection();

  37:                     NotifyPropertyChanged("Incidencias");

  38:                     IsDataLoaded = true;

  39:                     NotifyPropertyChanged("Vacio");

  40:                 }

  41:             }

  42:         }

43:

  44:         public bool Vacio

  45:         {

  46:             get

  47:             {

  48:                 return !IsDataLoaded;

  49:             }

  50:         }

51:

52:

  53:         public DgtContexto(int frecuencia, Func<Incidencia, bool> predicado)

  54:         {

  55:             Predicado = predicado;

56:

  57:             Observable.Timer(TimeSpan.Zero, TimeSpan.FromMinutes(frecuencia))

  58:                 .Select(_ => PrepararPeticion())

  59:                 .Switch()

  60:                 .ObserveOnDispatcher()

  61:                 .Subscribe(incidencias =>

  62:                                {

  63:                                    IncidenciasTotal = incidencias.ToObservableCollection();

  64:                                    Incidencias = (incidencias

  65:                                        .Where(Predicado))

  66:                                        .ToObservableCollection();

  67:                                    NotifyPropertyChanged("Incidencias");

  68:                                    Hora = DateTime.Now;

  69:                                    NotifyPropertyChanged("Hora");

  70:                                    System.Diagnostics.Debug.WriteLine(DateTime.Now.ToLongTimeString() + " " +

  71:                                                                       Incidencias.Count.ToString());

  72:                                    IsDataLoaded = true;

  73:                                    NotifyPropertyChanged("Vacio");

  74:                                });

  75:         }

76:

  77:         public void Actualizar()

  78:         {

  79:             Incidencias = IncidenciasTotal;

  80:             NotifyPropertyChanged("Incidencias");

  81:             IsDataLoaded = false;

  82:             NotifyPropertyChanged("Vacio");

  83:         }

84:

  85:         internal IObservable<IEnumerable<Incidencia>> PrepararPeticion()

  86:         {

  87:             return Observable.Defer(() =>

  88:             {

  89:                 var webRequest =

  90:                     WebRequest.Create(new Uri("http://dgt.es/incidencias.xml"));

91:

  92:                 webRequest.Method = "POST";

  93:                 webRequest.ContentType = "text/XML";

94:

  95:                 var peticion = Observable.FromAsyncPattern<WebResponse>(

  96:                     webRequest.BeginGetResponse,

  97:                     webRequest.EndGetResponse);

98:

  99:                 return from elemento in peticion()

 100:                     .Select(respuestaWeb =>

 101:                     {

 102:                         using (var rs = respuestaWeb.GetResponseStream())

 103:                         {

 104:                             return rs.Deserialize(respuestaWeb.ContentLength);

 105:                         }

 106:                     })

 107:                        select elemento;

 108:             });

 109:         }

 110:

 111:         public bool IsDataLoaded

 112:         {

 113:             get;

 114:             private set;

 115:         }

 116:

 117:

 118:         public event PropertyChangedEventHandler PropertyChanged;

 119:         private void NotifyPropertyChanged(String propertyName)

 120:         {

 121:             var handler = PropertyChanged;

 122:             if (null != handler)

 123:             {

 124:                 handler(this, new PropertyChangedEventArgs(propertyName));

 125:             }

 126:         }

 127:

 128:         public void LoadData()

 129:         {

 130:             Incidencias = new ObservableCollection<Incidencia>

 131:                               {

 132:                                   new Incidencia

 133:                                       {

 134:                                           Autonomia = "---",

 135:                                           Carretera = "---"

 136:                                       }

 137:                               };

 138:         }

 139:     }

 140: }

[Windows Phone 7] Utilizar un certificado propio en Outlook

José Miguel Torres — Mon, 24 Jan 2011 05:49:13 GMT

Hace relativamente poco acabo de recibir mi dispositivo Windows Phone 7. Tras tatar de conectarlo al Exchange de la empresa empezé a tener errores del estilo “Certificado no valido. Pongase en contacto con el administrador”.

Pese que a priori no es solución muy elegante lo resolví de la siguiente forma. En primer lugar abrir el Office Web Application (OWA) y miré que certificado es el que estaba utilizando –Si conoceis el nombre del certificado este paso lo podeis obviar- . En mi caso no es un certificado válido puesto que no está ortorgado por ninguna Autoridad Certificadora.

Localicé el certificado en el snap in o complemento de Certificados, en el MMC del sistema operativo. Esto es:

Ejecutar mmc:

agregar complemento o SnapIn:

seleccionar Certificados o Certificates de “Mi Cuenta de Usuario”

Una vez detectado el certificado(*) dentro de la carpeta “Entidades de certificación raíz de confianza” hacemos botón derecho y seleccionamos Exportar en el menú opciones. Lo exportamos a DER binario codificado X.509 (.CER) tal y como se muestra en la siguiente imagen:

(*) Si accedemos al Outlook a través del Office Web Access (OWA) el propio Explorador Web nos dirá que certificado está utilizando.

Seguidamente nos enviamos el archivo .cer del certicado adjunto por correo electronico a una cuenta que tengamos previamente configurada desde el dispositivo WP7. La cuestión es que al no tener ni acceso al sitema de archivos ni a los cetificados del dispositivo, el correo electronico es la unica forma de hacerlo llegar el archivo.cer referente al certificado.

Cuando recibimos el correo electronico desde el dispositivo WP7 con el archivo.cer adjunto, lo descargamos y posteriormente lo ejecutamos. Nos pedirá confirmación explícitica de que realmente queremos instalar el certifiicado y ya está.

Ahora volvemos a tratar de sincronizar la cuenta de Outlook y si todo está bien, empezaremos a tener el correo sincronizado.

Espero que os sirva.

[OT] Foros MSDN sobre Windows Phone 7 en Español activos

José Miguel Torres — Wed, 19 Jan 2011 16:17:34 GMT

Se han abierto recientemente el foro sobre Windows Phone 7 en Español, del cual soy administrador, en la siguiente dirección:

http://social.msdn.microsoft.com/Forums/es-es/windowsphone7/threads?prof=required

Os animo a que compartáis tanto dudas como experiencias sobre desarrollo en Windows Phone 7.

Nos vemos!!

[Whitepaper gratuito] Comenzando con Open Data Protocol

José Miguel Torres — Thu, 02 Sep 2010 06:56:30 GMT

En el MIX de Las Vegas, ví las primeras demos y características de Open Data Protocol –OData- de la mano de nada más y nada menos que de Pablo Castro y quede gratamente sorprendido pues redireccionaban el camino equivocado tomado hacia unos meses con Astoria. La verdad es que la idea inicial de Astoria era algo alentadora, pero no la puestra en práctica. La coletilla o pretexto de que OData era una evolución de Astoria, no decia mucho a su favor, en principio, pero despues de haberlo puesto en práctica en algunos determinados escenarios en mi actual empresa, estoy francamente satisfecho.

Si bien es cierto que la idea subyacente de Astoria prometía, a la práctica no fue así. Los orígenes de datos expuestos eran propietarios. No puedo admitir que fuera ni un experto ni un fan, tanto de EF como de Astoria, pero lo cierto es que el poco contacto q tuve con ambas tecnologias simultáneamente admito que la experiencia no fue positiva.

Entonces, ¿Que ha cambiado con OData? En primer lugar, Microsoft anuncia a través de Microsoft’s Open Specification Promise (OSP) la estandarización de la tecnología. En segundo lugar tratar de dar solución a la exposición de orígenes de datos, relacionales o no, a través de un Servicio Web ejecutando operaciones con un lenguaje “estándar” basandose en:

La creación de una forma uniforme de representación de datos estructurados a través de Atom o JSON (JavaScript Object Notation)
La utilización de convenciones URL uniformes tanto para la navegación, filtrado, orden y paginación de datos (entre otros)
La creación de operaciones uniformes dirigidas por dirección mediante las acciones GET, POST, PUT y DELETE.

En definitiva no OData no es más que una estandarización de la creación y consumo de datos via Web que está construido sobre un conjunto de estándares de Internet, espcialmente Atom Publishing Protocol o AtomPub especificado en RFD 5023 quien a su vez está sontruido sobre Atom Syndication Format o Atom especificado en RFC4287.

En este whitepaper he tratado de introducir la problemática y necesidades de la exposición de orígenes de datos con las tecnologias Web actuales y cómo OData soluciona parte de esas problemáticas. OData ofrece una gran variedad de operaciones sobre un conjunto de datos que nos aportan una mayor flexibilidad y optimización y por otra parte una alta integración con todo tipo de clientes:

Cualquier explorador Web
Apps .NET Framework 3.5/4.0
Silverlight 3/4
Windows Phone 7
Java / JavaScript
PHP
AJAX
Excel 2010 PowerPoint
LINQPad
SQL Azure

Además de mostrar cómo crear un servicio OData muestro varios ejemplos básicos sobre algunos de los cliente enumerados arriba. En definitiva, un Whitepaper que pretende presentar de una forma práctica Open Data Protocol a cualquier desarrollador y empezar a valorar la utilidad de esta nueva apuesta para nuestros desarrollos.

Recursos

- PDF/Libro electrónico

- Lectura OnLine

- Sigue los comentarios en la página de Facebook de CampusMVP

-Colecciones del ObjectModel- Coleccionando objetos en .NET Framework (III)

José Miguel Torres — Wed, 07 Jul 2010 18:06:00 GMT

Introducción

Esta serie de artículos pretende mostrar las características y peculiaridades de las colecciones en .NET. El objetivo no es mostrar las situaciones en las que cada una de los diferentes tipos de colecciones pueden utilizarse en cada contexto sino la de conocer las mismas, ventajas y desventajas, para poder seleccionar el tipo de colección más apropiado en cada momento.

La serie cubre (entre corchetes el estado):

Colecciones No Genericas
Colecciones Genéricas System.Collections.Generic
Colecciones de System.Collections.ObjectModel (este post)
Colecciones nuevas en CLR 4.0 (no es definitivo además solo hay una)
Cota superior asintótica de las colecciones del CLI. aka Notación de Landau - O Grande- (en desarrollo)
Power Collections y C5 (por ahí andan)
Rx (si hay ganas y tiempo)

Colecciones System.Collections.ObjectModel

Todas las colecciones agrupadas bajo System.Collections.ObjectModel tiene como denominador común que todas y cada una de ellas pueden ser utilizadas como modelo de objetos en librerias públicas con la intención de ser extendidas.

Krzysztof Cwalina expone sus razones por las cuales algunas de estas clases han sido clasificadas bajo dicho espacio de nombres en el siguiente post. Básicamente, la gran mayoria de desarrolladores nos conformaremos con utilizar las colecciones expuestas tanto en System.Collections como en System.Collections.Generics dejando las expuestas en ObjectModel las utilizadas en menor medidad para otros usos no tan habituales como es la generacción de colecciones propietarias.

Dicho esto, lo que pretende este post es introducir las 5 clases con las que se presenta .NET Framework 4.0 y que son:

System.Collections.ObjectModel.Collection<T>
System.Collections.ObjectModel.KeyedCollection<TKey,TItem>
System.Collections.ObjectModel.ObservableCollection<T>
System.Collections.ObjectModel.ReadOnlyCollection<T>
System.Collections.ObjectModel.ReadOnlyObservableCollection<T>

System.Collections.ObjectModel.Collection<T>

Collection<T> se utiliza como clase base (pese a que no es abstracta) para la implementación de colecciones personalizadas. Para ello expone parte de sus métodos como virtuales, tales como ClearItems, InsertItem, RemoveItem y SetItem. Por lo tanto se recomienda que todo los desarroladores que pretendan generar una colección personalizada extiendan Collection<T> en lugar de crear una desde zero.

El propio .NET Framework hace un uso extensivo de Collection<T> en gran parte de las colecciones utilizadas:

System.Object
System.Collections.ObjectModel.Collection<T>
    System.Collections.ObjectModel.KeyedCollection<TKey, TItem>
    System.Collections.ObjectModel.ObservableCollection<T>
    System.ComponentModel.BindingList<T>
    System.ComponentModel.SortDescriptionCollection
    System.Net.IPEndPointCollection
    System.Net.Mail.AlternateViewCollection
    System.Net.Mail.AttachmentCollection
    System.Net.Mail.LinkedResourceCollection
    System.Net.Mail.MailAddressCollection
    System.Net.PeerToPeer.CloudCollection
    System.Net.PeerToPeer.Collaboration.PeerApplicationCollection
    System.Net.PeerToPeer.Collaboration.PeerContactCollection
    System.Net.PeerToPeer.Collaboration.PeerEndPointCollection
    System.Net.PeerToPeer.Collaboration.PeerNearMeCollection
    System.Net.PeerToPeer.Collaboration.PeerObjectCollection
    System.Net.PeerToPeer.PeerNameRecordCollection
    System.Security.Cryptography.CngPropertyCollection
    System.ServiceModel.Channels.BindingElementCollection
    System.ServiceModel.Channels.ChannelParameterCollection
    System.ServiceModel.Description.FaultDescriptionCollection
    System.ServiceModel.Description.MessageDescriptionCollection
    System.ServiceModel.Description.OperationDescriptionCollection
    System.ServiceModel.Description.PolicyAssertionCollection
    System.ServiceModel.Description.ServiceEndpointCollection
    System.ServiceModel.Dispatcher.MessageQueryCollection
    System.ServiceModel.Syndication.SyndicationElementExtensionCollection
    System.Web.DynamicData.DataControlReferenceCollection
    System.Web.Routing.RouteCollection
    System.Web.UI.DataVisualization.Charting.ChartElementCollection<T>
    System.Web.UI.ScriptReferenceCollection
    System.Web.UI.ServiceReferenceCollection
    System.Web.UI.UpdatePanelTriggerCollection
    System.Windows.ConditionCollection
    System.Windows.Forms.DataVisualization.Charting.ChartElementCollection<T>
    System.Windows.Forms.FileDialogCustomPlacesCollection
    System.Windows.Ink.StrokeCollection
    System.Windows.Input.StylusPlugIns.StylusPlugInCollection
    System.Windows.Input.StylusPointCollection
    System.Windows.Input.TouchPointCollection
    System.Windows.SetterBaseCollection
    System.Windows.TriggerCollection
    System.Workflow.ComponentModel.Compiler.ValidationErrorCollection

System.Collections.ObjectModel.KeyedCollection<TKey,TItem>

Se trata de una clases abstracta que como peculiaridad las claves estan incrustadas en sus valores. Tal y como se define en el MSDN Library, KeyedCollection<TKey,TItem> es un conjunto infinito de tipos abstractos ya que la implementación dependerá en gran medida de los tipos genericos representados por TKey y TItem.

La clase KeyedCollection<TKey, TItem> es un híbrido entre una colección basada en IList<T> y una colección basada en IDictionary<TKey, TValue> y por tanto puede ser accedida mediante índice y clave. La diferencia fundamental es que ésta no es una par clave/valor ya que el propio valor agrupa tanto el valor en sí como la clave. Su firma es:

public abstract class KeyedCollection<TKey, TItem> : Collection<TItem>

    protected KeyedCollection();

    protected KeyedCollection(IEqualityComparer<TKey> comparer);

    protected KeyedCollection(IEqualityComparer<TKey> comparer, int dictionaryCreationThreshold);

    public IEqualityComparer<TKey> Comparer { get; }

    public TItem this[TKey key] { get; }

    protected IDictionary<TKey, TItem> Dictionary { get; }

    public bool Contains(TKey key);

    public bool Remove(TKey key);

    protected void ChangeItemKey(TItem item, TKey newKey);

    protected override void ClearItems();

    protected abstract TKey GetKeyForItem(TItem item);

    protected override void InsertItem(int index, TItem item);

    protected override void RemoveItem(int index);

    protected override void SetItem(int index, TItem item);

Por ejemplo, KeyedCollection<int, Empleado> puede contener una clave “234449” que pertenece como propiedad al propio elemento Empleado (como por ejemplo el código del mismo) que se obtendría a través del método abstracto GetKeyForItem() de la siguiente forma:

public class Departamento : KeyedCollection<int, Empleado>

    public Departamento () : base(null, 0) {}

    protected override int GetKeyForItem(Empleado empleado)

        return empleado.Codigo;

     //Clase incompleta

System.Collections.ObjectModel.ObservableCollection<T>

http://msdn.microsoft.com/en-us/library/ms668604.aspx

Las colecciones ObservableCollection<T> fueron una de las caracterísitcas más importantes introducidas a raíz de WPF y Silverlight posteriormente debido a la capacidad que tiene de propagar una modificación sobre el conjunto de elementos de la colección, a través de un par de interfaces que veremos a continuación, y que sirve como base para el Data Binding con los elementos o vistas WPF/Silverlight, por ejemplo.

Si observamos la firma de ObservableCollection<T> vemos que además de implementar la clase abstracta Collection<T>, implementa INotifyCollectionChanged e INotifyPropertyChanged.

[Serializable]

public class ObservableCollection<T>

    : Collection<T>, INotifyCollectionChanged, INotifyPropertyChanged

...

Si vemos la definición de INotifyCollectionChanged:

public interface INotifyCollectionChanged

    event NotifyCollectionChangedEventHandler CollectionChanged;

Vemos que implementa un evento del tipo NotifyCollectionChangedEventHandler el cual notificará a los “subscriptores” – o listeners en inglés- ante cualquier modificación sobre el conjunto de elementos. Ojo, se utiliza la palabra subscriptores entre comillas pues no es una entorno publicador – subscriptor real. (Véase Observer Design Pattern with .NET)

Por otro lado, la interfaz INotifyPropertyChanged:

public interface INotifyPropertyChanged

    event PropertyChangedEventHandler PropertyChanged;

Es la que notificará las modificaciones, no sobre el conjunto de elementos, sino sobre los datos –Propiedades- de cualquier elemento de la colección. Las interfaces WPF/Silverlight basados en Data Bindings son los típicos clientes de esta interfaz y son los que representan la modificación de cualquier propiedad de cualquier elemento de una colección ObservableCollection<T> en el elemento enlazado de la interfaz.

Por ejemplo supongamos que tenemos la clase Empleado que pertenecerá a una ObservableCollection<T> y que posteriormente será enlazada a la interfaz de una aplicación WPF. En primer lugar debemos implementar la interfaz INotifyPropertyChanged para proveer de un mecanismo de notificación sobre las propiedades de la clase. Así, si la clase Empleado tiene dos propiedades llamadas Login y Nombre en ambos setters de la propiedad deberíamos ejecutar el evento PropertyChanged() tal y como se muestra a continuación:

public class Empleado : INotifyPropertyChanged

        public event PropertyChangedEventHandler PropertyChanged;

        private string _login;

        private string _nombre;

        public string Login

            get { return _login; }

set

                _login = value;

                PropertyChanged(this,

                    new PropertyChangedEventArgs("Login"));

        public string Nombre

            get { return _nombre; }

set

                _nombre = value;

                PropertyChanged(this,

                    new PropertyChangedEventArgs("Nombre"));

A partir de aquí, la clase Empleado debe residir dentro de una colección ObservableCollection<Empleado> y ser enlazada a un elemento cualquier, por ejemplo un datagrid. Una ejemplo trivial con una única grid y un boton que agregaría un nuevo empleado a la colección seria:

public partial class MainWindow : Window

    private readonly ObservableCollection<Empleado> users

        = new ObservableCollection<Empleado>();

    public MainWindow()

        InitializeComponent();

        datagrid1.DataContext = users;

    private void button1_Click(object sender, RoutedEventArgs e)

        users.Add(new Empleado()

            Login = "jmtorres",

            Nombre = "José Miguel"

});

En el XAML únicamente deberiamos hacer uso de los Data Bindings de WPF:

<Grid>

    <DataGrid Name="dataGrid1" ItemsSource="{Binding}" AutoGenerateColumns="False">

        <DataGrid.Columns>

            <DataGridTextColumn Binding="{Binding Login}" Header="Login" />

            <DataGridTextColumn Binding="{Binding Nombre}" Header="Nombre" />

        </DataGrid.Columns>

    </DataGrid>

    <Canvas>

        <Button Click="button1_Click" ></Button>

    </Canvas>

</Grid>

A continuación detallo enlaces que tratan de forma más específica los Data Bindings tanto en WPF como en Silverlight utilizando colecciones ObservableCollection<T>:

An Introduction to ObservableCollection in WPF | e-pedro.com

Working with ObservableCollection<T> – CodeProject

Silverlight Databinding – The Observable Collection - Joel Varty

Advanced Basics: The ObservableCollection Class - MSDN Magazine ...

System.Collections.ObjectModel.ReadOnlyCollection<T>

ReadOnlyCollection<T> es la versión Solo Lectura de la colección Collection<T>. Está especialmente para ser extendida en lugar de crear colecciones personalizadas desde zero y su peculiaridad, como su propio nombre indica es que carece de los 4 métodos que en la clase Collection<T> estaban declarados como virtuales y que se detallan a continuación:

protected virtual void ClearItems();

protected virtual void InsertItem(int index, T item);

protected virtual void RemoveItem(int index);

protected virtual void SetItem(int index, T item);

Por ultimo se detalla una relación de clases de .NET Framework que extienden las funcionalidades de ReadOnlyCollection<T>

System.Object
System.Collections.ObjectModel.ReadOnlyCollection<T>
    System.Collections.ObjectModel.ReadOnlyObservableCollection<T>
    System.Data.Metadata.Edm.ReadOnlyMetadataCollection<T>
    System.Security.Cryptography.ManifestSignatureInformationCollection
    System.ServiceModel.Channels.AddressHeaderCollection
    System.Windows.Input.StylusButtonCollection
    System.Windows.Input.StylusDeviceCollection

System.Collections.ObjectModel.ReadOnlyObservableCollection<T>

La descripción oficial que hace el MSDN Library acerca de esta clase es que: “ReadOnlyObservableCollection es un wrapper –una envoltura- de sólo lectura sobre una colección ObservableCollection”. La percepción que tengo yo al respecto, siempre desde el respeto y la ignorancia especialmente sobre esta clase, es que no tengo ni pajolera idea de cual es su utilidad real llegando incluso a dudar de que realmente la tenga, con lo que no indagaré más al respecto.

-Colecciones Genericas- Coleccionando objetos en .NET Framework (II)

José Miguel Torres — Tue, 15 Jun 2010 17:07:00 GMT

Introducción

La serie cubre (entre corchetes el estado):

Colecciones No Genericas
Colecciones Genéricas System.Collections.Generic (este post)
Colecciones de System.Collections.ObjectModel (en desarrollo)
Colecciones nuevas en CLR 4.0 (no es definitivo además solo hay una)
Cota superior asintótica de las colecciones del CLI. aka Notación de Landau - O Grande- (en desarrollo)
Power Collections y C5 (por ahí andan)
Rx (si hay ganas y tiempo)

Colecciones Genéricas

Sin lugar a dudas, uno de los conceptos que más provecho ha sacado de la genericidad han sido las colecciones. Practicamente todas las colecciones utilizadas hasta entonces tienen su equivalente dentro del espacio de nombre System.Collections.Generic además de la aparición de nuevas colecciones fruto de la flexibilidad que otorga los tipos generéricos.

En la siguiente tabla podemos ver algunas de estas colecciones (Fuente: Blog de Krzysztof Cwalina )

No Genericas                       Similares de tipo Generico
ArrayList                               List<T>
Hashtable                              Dictionary<TKey,TValue>
SortedList                             SortedList<TKey,TValue>
Queue                                   Queue<T>
Stack                                    Stack<T>
IEnumerable                          IEnumerable<T>
ICollection                            N/A (use IEnumerable<T> anything that extends it)
N/A                                      ICollection<T>
IList                                      IList<T>
CollectionBase                      Collection<T>
ReadOnlyCollectionBase      ReadOnlyCollection<T>
DictionaryBase                     N/A (just implement IDictionary<TKey,TValue>
N/A                                      SortedDictionary<TKey,TValue>
N/A                                      KeyedCollection<TKey,TItem>
N/A                                      LinkedList<T>

NOTA: No todas las colecciones genéricas se encuentran en el espacio de nombres System.Collections.Generic. Algunas las veremos en el siguiente post bajo el espacio de nombre System.Collections.ObjectModel.

De la misma forma que en la colecciones no genéricas, me gustaria empezar desgranando el núcleo de toda colección: el iterador/enumerador.

El Enumerador genérico

Como es de preveer existe una interfaz IEnumerator<T> dentro del espacio de nombres System.Collections.Generic cuya firma es:

public interface IEnumerator<out T> : IDisposable, IEnumerator

    new T Current { get; }

Por consiguiente, la interfaz IEnumerable<T> también tiene su equivalente genérico y se describe como:

public interface IEnumerable<out T> : IEnumerable

    new IEnumerator<T> GetEnumerator();

NOTA: La importancia y funcionamiento de ambas se describe en el post anterior.

En dichas firmas ya empezamos a ver las primeras pecualiridades y es que en ambos casos cada una de las interfaces implementa su equivalente no genérico para mantener la compatibilidad hacía las colecciones no genéricas. Por otro lado IEnumerator<T> implementa IDisposable. La razón nos la explica el propio Krzysztof Cwalina aqui y no es más que para contemplar determinados escenarios dónde la colección que implementa IEnumerator<T> pueda destruir recursos “externos” utilizados tales como conexiones en base de datos para la lectura de filas o manejadores de archivos para la iteración de ficheros. Por último ambas interfaces son covariantes a T en el CLR 4.0.

Uno de los cambios más importantes es la abstracción de ICollection<T>. Si nos fijamos en la tabla de equivalencias del inicio de este post veremos que ICollection no tiene ninguna equivalencia en la parte genérica de la mismo forma que ICollection<T> tampoco la tiene en la parte no genérica. Fijémonos en su firma:

ICollection<T>

public interface ICollection<T> : IEnumerable<T>, IEnumerable

    int Count { get; }

    bool IsReadOnly { get; }

    void Add(T item);

    void Clear();

    bool Contains(T item);

    void CopyTo(T[] array, int arrayIndex);

    bool Remove(T item);

Las unicas propiedades que tienen en común son CopyTo y Count. El método SyncRoot y la propiedad IsSynchronized se han eliminado y se han añadido los métodos Add, Contains, Clear y Remove. Queda evidente pues que lo único que comarten es el nombre ya que la abstracción es bien distinta.

NOTA: Krzysztof Cwalina lo argumenta diciendo que en realidad ICollection no tenia mucho sentido. .NET Framework no tenia ningún tipo de colección que representara una colección indexada de lectura y escritura; de ahí surge ICollection<T>.

En cuanto a las equivalencias de IList e IDictionary:

IList<T>

public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable

    T this[int index] { get; set; }

    int IndexOf(T item);

    void Insert(int index, T item);

    void RemoveAt(int index);

IDictionary<TKey,TValue>

public interface IDictionary<TKey, TValue> : ICollection<KeyValuePair<TKey, TValue>>,

                                             IEnumerable<KeyValuePair<TKey, TValue>>, IEnumerable

    TValue this[TKey key] { get; set; }

    ICollection<TKey> Keys { get; }

    ICollection<TValue> Values { get; }

    bool ContainsKey(TKey key);

    void Add(TKey key, TValue value);

    bool Remove(TKey key);

    bool TryGetValue(TKey key, out TValue value);

Podriamos afirmar, pues que ambas tienen su correspondencia en el espacio de nombre System.Collections.Generic pese a que IDictionary tiene algunas pecualiridades debido a la flexibilidad de los genéricos y que veremos más tarde. Por último siguen implementando la interfaz no genérica IEnumerable para mantener la compatibilidad con colecciones no genéricas.

Ahora veremos los diferentes tipos de colecciones en base a la interfaz que utilizan.

Colecciones Genéricas

Colecciones regulares (System.Collections.ICollection)

NOTA: Pese a que MSDN Library afirma que tanto Queue<T> y Stack<T> hacen uso de ICollection<T> esto no es cierto. Implementan ICollection.

Este tipo de colecciones también son conocidas como colecciones ordenadas o simplemente collecciones –me he permitido la libertad de denominarlas estándar o regulares para diferenciarlas de las específicas-. Hago hincapié en ello pues encontré varias formas de denomiarlas. De hecho, más allá de la colección Collection que como vimos anteriormente es abstracta y no es más que una evolución de CollectionBase utilizada en las versiones tempranas del CLR, existe un par de clases que podriamos catalogar dentro de este grupo y que vienen representadas por las clases Stack<T> y Queue<T>.

NOTA: Ambas guardan una estrecha relación ya que en ambos casos los elementos se almacenan según el orden de llegada. Nótese que el término “ordenación” utilizado anteriormente no es una ordenación lógica sobre una propiedad del conjunto de elemento; este tipo de elementos los veremos más adelante y podrían estar catalogados como colecciones especializadas.

La diferencia principal entre Stack<T> y Queue<T> reside en el orden en el que los elementos son obtenidos. En ambos casos almacenan elementos en estricto orden de llegada y mientras que en la clase Stack<T> responde a LIFO (Last Input First Output) en el caso de Queue<T> responde a FIFO (First Input First Output). Ambas clases derivan de ICollection e IClonable y cada una de ellas utiliza un método distinto para añadir y quitar un elemento de la colección. Push y Pull para Stack y Enqueue y Dequeu para Queue.

var queue = new Queue<string>();

var stack = new Stack<string>();

queue.Enqueue("A");

queue.Enqueue("B");

queue.Enqueue("C");

queue.Enqueue("D");

stack.Push("A");

stack.Push("B");

stack.Push("C");

stack.Push("D");

Console.WriteLine("Dequeue-ing...");

foreach (var elemento in queue)

    Console.WriteLine(elemento);

Console.WriteLine("Pop-ing...");

foreach (var elemento in stack)

    Console.WriteLine(elemento);

Colecciones (System.Collections.Generic.ICollection<T>)

LinkedList<T> es una colección de nodos enlazados que implementa, entre otros ICollection<T>. El nucleo central de LinkedList<T> es System.Collections.Generic.LinkedListNode<T> la cual es una clase cuya caracteristica fundamental es que almacena el nodo immediatamente posterior y anterior y portanto todos y cada uno de los nodos mantienen una referencia de orden. Más info: Wikipedia.

A partir de aquí el funcionamiento es relativamente sencillo. Lo que iremos almacenando son objetos del tipo LinkedListNode<T> de tipo T en una colección LinkedList<T>. Las ventajas que nos ofrece este tipo de listas que podemos insertar immediantamente antes o despues de un determinado nodo practicamente con un coste O(1) a través de los métodos AddBefore() y AddAfter(). Además podremos añadir un elemento al inicio o al final de la lista enlazada mediante AddFirst() y AddLast() respectivamente.

LinkedList<T> mantiene siempre tanto el primer como el último nodo a través de las propiedades First y Last siempre y cuando el objecto LinkedList<T> tenga más de 0 elementos (linkedList.Count => 1). En el siguiente ejemplo, aunque trivial, muestra alguna de las posibilidades de LinkedList<T>.

var linkedList = new LinkedList<string>();

//añadimos el que va a ser el primer elemento

linkedList.AddFirst("Alfa");

//mantenemos una instanacia al ultimo

//elemento insertado mediante linkedListNode

//NOTA: tambien podriamos utilizar linkedList.AddLast...

var linkedListNode = linkedList.AddAfter(linkedList.First, "Beta");

linkedListNode = linkedList.AddAfter(linkedListNode, "Eco");

linkedListNode = linkedList.AddAfter(linkedListNode, "November");

//como por ejemplo aqui

linkedList.AddLast("Romeo");

linkedList.AddLast("Zulu");

//insertamos despues de "Eco"

linkedListNode = linkedList.Find("Eco");

if (linkedListNode != null)

    linkedList.AddBefore(linkedListNode, "Delta");

foreach(var elemento in linkedList)

    Console.WriteLine(elemento);

//resultados...

//Alfa

//Beta

//Eco

//November

//Romeo

//Zulu

Colecciones específicas

Otro tipo de agrupamiento para las colecciones específicas (es decir, las que se extienden más allá de ICollection) es de colecciones de acceso por clave o por índice. A continuación veremos el conjunto de colecciones agrupadas por clave (a través de IDictionary<TKey, TValue>) y posteriormente las que son agrupadas por índice (a través de IList<T>) y por último aquellas colecciones que hacen uso tanto de las características de índice y de clave.

Derivadas de System.Collections.Generics.IList<T>

En el ejemplo con el que abríamos el primer post vimos un ejemplo con System.Array, un claro ejemplo de colección basado en índices, también conocido en inglés como zero-based indexed collection. System.ArrayList es otro claro ejemplo de colección indexada que surge de la necesidad de poder redimensionar el tamaño de una colección de forma dinámica, limitación encontrada en System.Array. De hecho, ArrayList podría ser descrita como un híbrido entre una colección y una matriz de elementos ya que los elemento siguen almacenándose en orden de llegada pese a que pueden ser obtenidos mediante el índice relativo de la propia colección.

System.Collections.Generics.List<T> es equivalente natural a ArrayList en la parte de genericos. Es en esencial un ArrayList mejorada en rendimiento, tamaño y velocidad. Es quizás la colección más utilizada y más adecuada a la gran mayoria de escenarios debido a su flexibilidad y características.

En cuanto a la capacidad, de la misma forma que en ArrayList, podemos indicársela en el constructor o bien no hacerlo y la propia colección irá redimensionándose. Debido al coste que tiene la operación de redimensionamiento, List<T> crece en bloques del doble de su capacidad, siendo 4 su capacidad inicial, si no se indica el tamaño por defecto. Esto significa que tras la instanciación de:

var list = new List<double> { 20.0d };

//list.Capacity = 4

//list.Count = 1

El objeto list poseerá una capacidad de 4 elementos, tres de ellos null. Tras ir añadiendo más elementos list siempre irá creciendo en orden de 4, 8, 16, 32, 64, … elementos dejando los no utilizados con el valor por defecto de cada tipo, esto es default(T), o más concretamente null para los tipos por referencia y 0 para los tipos por valor. Indentificaremos la capacidad total mediante la propiedad Capacity, siempre multiples de 4, y la cantidad de elementos no null/0 mediante Count.

Podemos exigir que un objeto List<T> tenga un tamaño fijo predefinido. Sin embargo, es muy común confundir esta limitación o característica con la cantidad de elementos que se le puede pasar por parámetro en el constructor de la clase List<T>. Otro error común es indicar una capacidad elevada en previsión de crecimiento. Si es cierto que esto es una buena practica si el numero de elementos a añadir es finalmente inferior a la capacidad inicial, no lo es si el numero de elementos final es superior puesto que el crecimiento de la ArrayList será multiple a la capacidad inicial. Es decir, por ejemplo, el siguiente ejemplo crea un List<T> con un tamaño predefinido de 100 elementos. Por un lado podemos ver como el objeto arrayList acepta 1000 elemento (10 veces más de lo inicialmente previsto) sin ningún problema. Sin embargo, tras el bucle podemos observar que la capcidad –Capacity- (no cantidad –Count- de elementos) es de 1600 y es debido a que el crecimiento ha sido de 100, 200, 400, 800 y 1600. O sea que tenemos un List<T> de 1600 elementos de capacidad y realmente se estan utilizando 1000.

var list = new List<string>(100);

for (int i = 0; i <= 1000; i++)

    list.Add(i.ToString());

//list.Capacity = 1600

//list.Count = 1000

Si hacemos la misma interación sin un tamaño predefinido, la capacidad final será de 1024.

var list = new List<string>();

for (int i = 0; i <= 1000; i++)

    list.Add(i.ToString());

//list.Capacity = 1024

//list.Count = 1000

Derivadas de System.Collections.Generics.IDictionary<T>

La diferencia fundamental entre SortedList<TKey,TValue> y List<T> es que mientras en List<T> se almacenan los elemento por orden de “llegada” en SortedList<TKey,TValue> se almacena una pareja valor/clave y tanto se puede acceder por clave como por índice.

Internamente, SortedList<TKey,TValue> mantiene dos objetos IList<T> internos, uno para el almacenamiento de claves y otro para el almacenamiento de valores la cuales se acceden mediante un objeto de la clase KeyValuePair<TKey,TValue>. Como su propio nombre indica, SortedList<TKey,TValue> mantiene el conjunto de elementos ordenados por clave. La clave puede ordenarse en función a una implementación específica de IComparer<T> o bien mediante la interfaz IComparable<T> que los propios tipos de las claves – de sus elementos - indican. En el siguiente ejemplo añadimos 4 elementos de tipo string y observamos el resultado. Fijémonos como el IComparer<T> por defecto es CaseSensitive es decir System.Collections.Generic.Comparer<T>.Default (ya que está utilizando la implementación IComparable<T> derivado de la clase String).

var sortedList = new SortedList<string,string>()

                                     {"Z", "Z"},

                                     {"A", "A"},

                                     {"a", "a"},

                                     {"B", "B"}

};

foreach (var elemento in sortedList)

    Console.WriteLine(elemento.Value);

//Resultado:

//a

//A

//B

//Z

Sin embarago, si utilizáramos un IComparer<T> propio y especificaramos explicitamente que la comparación sea Case Insensitive, obtendriamos un error ya que no es posible añadir dos elemento con la misma clave al tratar de la misma forma o valor las cadenas “a” y “A”:

public class CaseInsensitiveComparerSample<T> : IComparer<T>

    public int Compare(T x, T y)

        return ((new CaseInsensitiveComparer())

            .Compare(y, x));

//implementación

var sortedList = new SortedList<string,string>(

                new CaseInsensitiveComparerSample<string>()

                                     {"Z", "Z"},

                                     {"A", "A"},

                                     // Argument Exception

                                     {"a", "a"},// Item has already been added.

                                     // Key in dictionary: 'A'  Key being added: 'a'

                                     {"B", "B"}

};

Dictionary<TKey,TValue>

Dictionary<TKey, TValue> es un HashTable fuertemente tipado. La diferencia entre ambos se encuentra en como gestiona las colisiones de los codigos hash de sus elementos en el algoritmo hash. Mientras que HasTable realiza un sondeo cuando existe una colision reubicando el elemento en el siguiente cubo –bucket- libre mientras que Dictionary<TKey, TValue> realiza un encadenamiento de los elementos con un mismo codigo hash almacenándolos en una lista asociada a un mismo cubo –bucket-. Para obtener más información al respecto podeis consultar el post System.Collections.Generic Dictionary Capacity, Hashing, and Collisions.

Por lo demás y como comentamos antes el funcionamiento es en esencial el de un HashTable. Todos los elementos implementan de forma explícita o implícita un código Hash, a través, por ejemplo, de la clase base System.Object. Como peculiaridad, Dictionary<TKey,TValue> utiliza la también estructura KeyValuePair<TKey,TValue> en lugar de la estructura DictionaryEntry que utiliza HasTable. Un ejemplo sencillo seria:

var dictionary = new Dictionary<int,string>

                                    {616000, "Juan M."},

                                    {616100, "Rafael H."},

                                    {616200, "Joaquin A."},

                                    {616210, "Alberto P."}

};

foreach (KeyValuePair<int,string> elemento in dictionary)

    Console.WriteLine(

        string.Format("Key: {0} Value:{1}",

                        elemento.Key, elemento.Value));

SortedDictionary<TKey,TValue>

La colección que mezcla las capacidades del Dictonary<TKey, TValue> con un conjunto de claves ordenado como hacía SortedList<T> es SortedDictionary<TKey, TValue>. Aqui es dónde reside la mayoría de las preguntas que nos hacemos acerca de cuál tipo de colección utilizar.

Según información del MSDN Library, establece que:

Where the two classes differ is in memory use and speed of insertion and removal:

SortedList<TKey, TValue> uses less memory than SortedDictionary<TKey, TValue>.
SortedDictionary<TKey, TValue> has faster insertion and removal operations for unsorted data: O(log n) as opposed to O(n) for SortedList<TKey, TValue>.
If the list is populated all at once from sorted data, SortedList<TKey, TValue> is faster than SortedDictionary<TKey, TValue>.

Veamos las diferencias reales de los dos primeros puntos: memoria y rendimiento.

Memoria

Para tratar de hacer una comparativa del tamaño de memoria utilizado entre uno y otro vamos a ejecutar un código que lo único que hará es añadir 1.000.000 de elementos string de clave int.

NOTA: La inserción se hace de forma secuencias con lo que el coste en la operación de agregación será mucho menor en SortedList. Esto es una excepción puesto que por norma general el valor de la clave será desordenada y es en ese punto, cuando hablemos del rendimiento lo veremos, dónde SortedDictionary es mucho más rápido.

Lo realmente importante del siguiente código es el espacio en memoria que se utiliza para la manipulación de los dos objectos SortedList y SortedDictionary:

var sortedList =

    new SortedList<int, string>();

var sortedDictionary =

    new SortedDictionary<int, string>();

int items = 1000000;

for (int i = 0; i < items; i++)

        sortedList.Add(i,i.ToString());

for (int i = 0; i < items; i++)

    sortedDictionary.Add(i,i.ToString());

Tras la ejecución con CLRProfiler vemos el grafo de asignación de bytes en memoria de:

la SortedList:

y la representacción de SortedDictionary:

Como podemos comprobar el espacio asignado en memoria es superior en el caso de SortedDictionary.

Como curiosidad podemos apreciar como cada uno de los objetos trata de forma bien distinta la información en memoria. SortedList al final acaba generando dos Arrays, una de claves y otra de valores del tipo System.Int32[] y System.String[] respectivamente. Por otro lado, SortedDictionary hace uso de un tipo utilizado internamente llamado Generic.TreeSet. Este tipo es un arbol binario utilizado, como dije antes, de forma interna para la manipulación de objetos del tipo Dictionary. La razón por la cual no está expuesta como API pública es debido a que el enfoque de este mismo tipo seria muy diferente. Básicamente Microsoft decidió utilizar únicamente de forma interna y no exponerla como API pública. Además de Generic.TreeSet podemos ver un objeto System.String que es dónde almacena el valor del objeto SortedDictionary.

internal class TreeSet<T> : ICollection<T>, IEnumerable<T>, ICollection,

    IEnumerable, ISerializable, IDeserializationCallback

Rendimiento

Para trata de evaluar el rendimiento entre ambas colecciones vamos a realizar una prueba muy similar, pero no vamos a dar ventaja a SortedList añadiendo elementos ordenados y es por ello que vamos a substituir las claves del tipo int al tipo System.Guid generándose uno diferente cada vez de forma que SortedList tenga que ordenar la clave tras cada inserción.

El código podria ser algo tal que así:

var sortedList =

    new SortedList<Guid, string>();

var sortedDictionary =

    new SortedDictionary<Guid, string>();

int items = 100000;

for (int i = 0; i < items; i++)

        sortedList.Add(Guid.NewGuid(), i.ToString());

for (int i = 0; i < items; i++)

    sortedDictionary.Add(Guid.NewGuid(), i.ToString());

El resultado del Performance Profiling del VS 2010 es tal y como muestra la siguiente captura de pantalla.

La operación SortedList.Add ocupa más del 97% del tiempo total de ejecución del código mientras que SortedDictionary.Add apenas llega al 2% por lo tanto queda demostrado el rendimiento entre ambas clases en operaciones de inserción y eliminación.

Conclusión

Además de las nombradas en este post existen otras menos utilizadas dentro del espacio de nombre de colecciones genéricas.

Otras referencias

http://en.how-to.mobi/index.php?sd=es&id=221691

http://blogs.msdn.com/b/kcwalina/archive/2004/08/06/210297.aspx

-Colecciones No Genericas- Coleccionando objetos en .NET Framework (I)

José Miguel Torres — Tue, 08 Jun 2010 17:41:00 GMT

Introducción

La serie cubre (entre corchetes el estado):

Colecciones No Genericas (actual post)
Colecciones Genéricas de System.Collections.Generic (en desarrollo)
Colecciones de System.Collections.ObjectModel (en mi cabeza)
Colecciones nuevas en CLR 4.0 (no es definitivo además solo hay una)
Cota superior asintótica de las colecciones del CLI. aka Notación de Landau - O Grande- (en desarrollo)
Power Collections y C5 (por ahí andan)
Rx (si hay ganas y tiempo)

¿Que es una colección?

Se entiende como colección un conjunto de entidades lógicamente relacionadas –es decir que deberían tener algo en común-. Así una colección de objetos de tipo string podría ser declarada como un System.Array de la siguiente forma en C#.

var cadenas = new string[]

                        "A", "B"

};

Sin embargo, esta declaración tiene algunos matices como por ejemplo que en muy pocas ocasiones conocemos el tamaño fijo que tendrá y por lo tanto se convierte en una limitación del propio System.Array, por ejemplo. Básicamente, las características y comportamiento del tipo de colección a utilizar nos ayudará o limitará en mayor o menor medida.

Por lo tanto, primero de todo me gustaría empezar definiendo que es para .NET Framework una colección. Desde el punto de vista de .NET Framework, una colección es cualquier tipo que implemente System.Collections.ICollection, System.Collections.IDictionary o System.Collections.IList, sin embargo no siempre tenemos claro que otorga especialemente cada una de estas interfaces. Vayamos por partes.

El Enumerador

Si empezaramos a desgranar todos los tipos de colecciones disponibles en el CLR encontraríamos un denominador común “oculto”, la interfaz IEnumerator. Si para que una colección sea considerada como tal en .NET Fx debe implementar una de las 3 interfazes expuestas anteriormente, todas estas interfaces deben implementar IEnumerable la cual no hace más exponer un IEnumerator.

Podríamos empezar mostrando la firma tanto de ICollection:

[ComVisible(true)]

public interface ICollection : IEnumerable

    int Count { get; }

    object SyncRoot { get; }

    bool IsSynchronized { get; }

    void CopyTo(Array array, int index);

como de IDictionary

[ComVisible(true)]

public interface IDictionary : ICollection, IEnumerable

    object this[object key] { get; set; }

    ICollection Keys { get; }

    ICollection Values { get; }

    bool IsReadOnly { get; }

    bool IsFixedSize { get; }

    bool Contains(object key);

    void Add(object key, object value);

    void Clear();

    new IDictionaryEnumerator GetEnumerator();

    void Remove(object key);

como de IList.

[ComVisible(true)]

public interface IList : ICollection, IEnumerable

    object this[int index] { get; set; }

    bool IsReadOnly { get; }

    bool IsFixedSize { get; }

    int Add(object value);

    bool Contains(object value);

    void Clear();

    int IndexOf(object value);

    void Insert(int index, object value);

    void Remove(object value);

    void RemoveAt(int index);

Y para empezar nos encontramos con otra característica que seguro muchos no habíamos visto anteriormente y es que tanto IDictionary com IList implementan, a su vez ICollection.

Es aquí, en este punto, dónde empieza a avistarse la diferencia entre las tres interfaces y podemos catalogarlas en dos conjuntos: Colecciones estándar o regulares y Colecciones específicas. Es obvio que tras ver la firma de cada una de ellas podemos afirmar que IList y IDictionary son colecciones específicas (ambas extienden ICollection) e ICollection es una colección estándard o regular.

NOTA: Utilizo el térmio “específicas” no especializadas –Specialized- cuyas colecciones estan en el espacio System.Collections.Specialized y que veremos más tarde.

Primera pregunta que surge, ¿Conociendo que System.Collection.List es el principal “consumidor” de IList y que Collection hace lo mismo de ICollection, cuál de ellas deberíamos utilizar? La respuesta es relativamente sencilla. Collection, a diferencia de List es una clase abstracta y por tanto debe ser implementada para ser extendida. Esto nos da una pista que la solución reside en que Collection debe ser utilizada para ser expuesta a través de un API pública mientras que List implementa métodos de búsqueda y ordenación específicas listas para usar.

Volviendo al núcleo central del tema, es decir a IEnumerator, observamos que las tres interfaces además implementan IEnumerable con lo que es buen momento par aver la firma de la misma:

public interface IEnumerable

    IEnumerator GetEnumerator();

Tal y como se puede observar, y se ha comentado anteriormente, IEnumerable no hace más que retornar un IEnumerator. Es importante conocer y entender la figura de un enumerador/iterador pues es el que va a permitir la iteración sobre cada uno de los elementos de una colección. La sentencia foreach, por ejemplo, hace uso de él. IEnumerator únicamente permite la iteración, nunca la modificación del elemento. De hecho, si observamos su firma:

public interface IEnumerator

    object Current { get; }

    bool MoveNext();

    void Reset();

Podemos ver que, exluyendo Reset, tanto Current como MoveNext son métodos de navegación o iteración entre collecciones. El mecanismo es sencillo; Current indica un valor indefinido y por tanto se lanza una llamada a MoveNext. Si esta retorna True, Current contiene el primer elemento de la colección y así lo hará mientras el valor de MoveNext vaya siendo True. En el momento que éste sea False, Current indicará al último elemento de la colección.

NOTA: El método Reset se mantiene únicamente por compatibilidad COM con lo que queda fuera del alcance de este artículo.

Colecciones No Genéricas

Colecciones regulares (System.Collections.ICollection)

Este tipo de colecciones también son conocidas como colecciones ordenadas(*) o simplemente collecciones –me he permitido la libertad de denominarlas estándar o regulares para diferenciarlas de las específicas-. Hago hincapié en ello pues encontré varias formas de denomiarlas. De hecho, más allá de la colección Collection que como vimos anteriormente es abstracta y no es más que una evolución de CollectionBase utilizada en las versiones tempranas del CLR, existe un par de clases que podriamos catalogar dentro de este grupo y que vienen representadas por las clases Stack y Queue.

NOTA: (*) Ambas guardan una estrecha relación ya que en ambos casos los elementos se almacenan según el orden de llegada. Nótese que el término “ordenacióin” utilizado anteriormente no es una ordenación lógica sobre una propiedad del conjunto de elemento; este tipo de elementos los veremos más adelante y podrían estar catalogados como colecciones especializadas.

La diferencia principal entre Stack y Queue reside en el orden en el que los elementos son obtenidos. En ambos casos almacenan elementos en estricto orden de llegada y mientras que en la clase Stack responde a LIFO (Last Input First Output) en el caso de la cola responde a FIFO (First Input First Output). Ambas clases derivan de ICollection e IClonable y cada una de ellas utiliza un método distinto para añadir y quitar un elemento de la colección. Push y Pull para Stack y Enqueue y Dequeu para Queue.

var queue = new Queue();

var stack = new Stack();

queue.Enqueue("A");

queue.Enqueue("B");

queue.Enqueue("C");

queue.Enqueue("D");

stack.Push("A");

stack.Push("B");

stack.Push("C");

stack.Push("D");

Console.WriteLine("Dequeue-ing...");

foreach (var elemento in queue)

    Console.WriteLine(elemento.ToString());

Console.WriteLine("Pop-ing...");

foreach (var elemento in stack)

    Console.WriteLine(elemento.ToString());

//Resultado:

// Dequeue-ing...

// A

// B

// C

// D

// Pop-ing...

// D

// C

// B

// A

Son colecciones principalmente utilizadas, como es obvio, en contextos dónde el orden de llegada es altamente importante. A partir de aquí, la forma en la que se obtienen los elementos de la colección es la clave para decidir seleccionar una u otra clase.

Colecciones específicas

Otro tipo de agrupamiento para las colecciones específicas (es decir, las que se extienden más allá de ICollection) es de colecciones de acceso por clave o por índice. A continuación veremos el conjunto de colecciones agrupadas por clave (a través de IDictionary) y posteriormente las que son agrupadas por índice (a través de IList) y por último aquellas colecciones que hacen uso tanto de las características de índice y de clave.

Derivadas de System.Collections.IList

En el ejemplo con el que abríamos este artículo vimos un ejemplo con System.Array, un claro ejemplo de colección basado en índices, también conocido en inglés como zero-based indexed collection. System.ArrayList es otro claro ejemplo de colección indexada que surge de la necesidad de poder redimensionar el tamaño de una colección de forma dinámica, limitación encontrada en System.Array. De hecho, podría ArrayList ser descrita como un híbrido entre una colección y una matriz de elementos ya que los elementos siguen almacenándose en orden de llegada pese a que pueden ser obtenidos mediante el índice relativo de la propia colección.

En cuanto a la capacidad, podemos indicársela en el constructor o bien no hacerlo y la propia colección irá redimensionándose. Debido al coste que tiene la operación de redimensionamiento, ArrayList crece en bloques del doble de su capacidad, siendo 4 su capacidad inicial, si no se indica el tamaño por defecto. Esto significa que tras la instanciación de:

var arrayList2 = new ArrayList {20.0d};

//arrayList2.Capacity = 4

//arrayList2.Count = 1

El objeto arrayList poseerá una capacidad de 4 elementos, tres de ellos null. Tras ir añadiendo más elementos arrayList siempre irá creciendo en orden de 4, 8, 16, 32, 64, … elementos dejando los no utilizados con null. Indentificaremos la capacidad total mediante la propiedad Capacity, siempre multiples de 4, y la cantidad de elementos no null mediante Count.

Podemos exigir que un objeto ArrayList tenga un tamaño fijo predefinido. Sin embargo, es muy común confundir esta limitación o característica con la cantidad de elementos que se le puede pasar por parámetro en el constructor de la clase ArrayList. Otro error común es indicar una capacidad elevada en previsión de crecimiento. Si es cierto que esto es una buena practica si el numero de elementos a añadir es finalmente inferior a la capacidad inicial, no lo es si el numero de elementos final es superior puesto que el crecimiento de la ArrayList será multiple a la capacidad inicial. Es decir, por ejemplo, el siguiente ejemplo crea un ArrayList con un tamaño predefinido de 100 elementos. Por un lado podemos ver como el objeto arrayList acepta 1000 elemento (10 veces más de lo inicialmente previsto) sin ningún problema. Sin embargo, tras el bucle podemos observar que la capcidad –Capacity- (no cantidad –Count- de elementos) es de 1600 y es debido a que el crecimiento ha sido de 100, 200, 400, 800 y 1600. O sea que tenemos un ArrayList de 1600 elementos de capacidad y realmente se estan utilizando 1000.

var arrayList = new ArrayList(100);

for (int i = 0; i < 1000; i++)

arrayList.Add(i);

//arrayList.Capacity = 1600

//arrayList.Count = 1000

Si hacemos la misma interación sin un tamaño predefinido –es decir con tamaño por defecto igual a 4-, la capacidad final será de 1024.

var arrayList = new ArrayList(1);

for (int i = 0; i < 1000; i++)

arrayList.Add(i);

//arrayList.Capacity = 1024

//arrayList.Count = 1000

Otro error común es confundir tamaño predefinido o inicial con tamaño fijo. Un ArraList de tamaño fijo jamás admitirá la agregación o eliminación de elementos, pero si la modificación.

var arrayList = new ArrayList { 20.0d };

var arrayList2 = ArrayList.FixedSize(arrayList);

arrayList2.Add(145.0d); //NotSupportedException

// arrayList2.IsFixedSize = true

Identificaremos las ArrayList de tamaño fijo mediante la propiedad IsFixedSize y como vemos en el ejemplo la forma de generarlas es a través de un objeto del tipo ArrayList o IList existente. Por otro lado, IsReadOnly es una propiedad de lectura y escritura con lo que podremos controlar la restricción o no de escritura sobre el conjunto de elementos.

NOTA: ArrayList esta cayendo en desuso (si no lo ha hecho ya) desde la aparición de las colecciones genéricas.

La colección StringCollection forma parte de las colecciones especializadas agrupadas en el espacio de nombres System.Collections.Specialized. StringCollection está especialmente optimizada para la manipulación de elementos del tipo string; es en esencia un ArraList tipado para aceptar únicamente cadenas de texto. StringCollection es ideal para la manipulación de relativamente poca cantidad de datos de tipo string que son frecuentemente actualizados.

Derivadas de System.Collections.IDictionary

De la misma forma que tratávamos ArrayList como “tipo primitivo” para la implementación de IList, haríamos lo mismo para el tipo SortedList con la interfaz IDictionary.La diferencia fundamental es que mientras en ArrayList se almacenan los elemento por orden de “llegada” en SortedList se almacena una pareja valor/clave y tanto se puede acceder por clave como por índice.

Internamente, SortedList mantiene dos arrays, uno para el almacenamiento de claves y otro para el almacenamiento de valores la cuales se acceden mediante un objeto de la estructura DictionaryEntry. Como su propio nombre indica, SortedList mantiene el conjunto de elementos ordenados por clave. La clave puede ordenarse en función a una implementación específica de IComparer o bien mediante la interfaz IComparable que los propios tipos de las claves – de sus elementos - indican. En el siguiente ejemplo añadimos 4 elementos de tipo string y observamos el resultado. Fijémonos como el IComparer por defecto es CaseSensitive ya que está utilizando la implementación IComparable derivado de la clase String.

var sortedList = new SortedList()

                         {"Z", "Z"},

                         {"A", "A"},

                         {"a", "a"},

                         {"B", "B"}

};

foreach (var elemento in sortedList)

    Console.WriteLine(((DictionaryEntry)elemento).Value);

//Resultado:

//a

//A

//B

//Z

Sin embarago, si utilizáramos un IComparer propio y especificaramos explicitamente que la comparación sea Case Insensitive, obtendriamos un error ya que no es posible añadir dos elemento con la misma clave al tratar de la misma forma o valor las cadenas “a” y “A”:

public class CaseInsensitiveComparerSample : IComparer

    public int Compare(Object x, Object y)

        return ((new CaseInsensitiveComparer())

            .Compare(y, x));

//implementación

var sortedList = new SortedList(

    new CaseInsensitiveComparerSample ())

                            {"Z", "Z"},

                            {"A", "A"},

                            // Argument Exception

                            {"a", "a"},// Item has already been added.

                            // Key in dictionary: 'A'  Key being added: 'a'

                            {"B", "B"}

};

Otro tipo de colección basada en IDictionary es System.Collections.Hashtable. Hashtable implementa tanto ICollection como IDictionary y ha sido ampliamente utilizado como tipo de colección idónea para la gestión de grandes cantidades de elementos debido a su alto rendimiento. Exige que la clave de sus elementos aunque no el valor hash de cada uno de ellos. De hecho, la ordenación del conjunto de elemento vendrá dado por el valor hash. DictionaryEntry seguirá jugando el mismo papel que lo hacía con SortedList ya que en ambos casos se almacena un par clave/valor.

Hablando más específicamente cada objecto de la colección Hashtable obtiene el valor hash de la llamada al método GetHashCode() heredado de System.Object o bien una propia implementación a través de la interfaz IHashCodeProvider. Cuando un elemento es agregado éste se almacenará en un sector de almacenamiento o cubo –bucket en inglés- de forma que su posterior localización será mucho más óptima. No importa el valor real del objeto pues cada uno de ellos tendrá su propio codigo hash y de este modo se reduce considerablemente el número de comparaciones. Así, por ejemplo, Hasthable situará dos elementos de tipo string con valores “picnic” y “basket” en distintos cubos o búckets; sin embargo los dos elemento de tipo string con valores “stressed” y “desserts” probablemente tengan el mismo codigo hash y por tanto los situará en un mismo bucket o cubo.

Realmente, la funcionalidad de un Hashtable es muy similiar al que ofrecen otras colecciones derivadas de IDictionary pero la comprensión de cómo se gestiona internamente el almacenamiento a través de códigos hash nos permite entender por un lado porque Hashtable es la colección que mayor rendimiento otorga y por otro lado las problemáticas que pueden generar la coincidencia de códigos hash si el algoritmo utilizado no es óptimo.

Un típico ejemplo seria:

var hashtable = new Hashtable

                        {"616-000-000", "Juan M."},

                        {"616-000-100", "Rafael H."},

                        {"616-200-000", "Joaquin A."},

                        {"616-200-100", "Alberto P."}

};

foreach (DictionaryEntry elemento in hashtable)

    Console.WriteLine(

        string.Format("Key: {0} Value:{1}",

                        elemento.Key, elemento.Value));

NOTA: Hablaré más extensamente sobre el tema de los conflictos en colecciones Hashtable en el siguiente post cuando trate la colección Dictionary<TKey, TValue>

StringDictionary, por su parte, juega el mismo papel que lo hacía StringCollection, pero si éste último era ideal para relativamente poca cantidad de elementos y su acceso es por índice, StringDictionary, al implementar IDictionary es ideal para una mayor cantidad de elementos. En este caso, también, se trata de una colección de elementos tipados ya que únicamente se aceptan elementos de tipo String.

Conclusión

Unicamente he expuesto las colecciones más utilizadas relativas a las no genéricas que he creído conveniente por propia experiencia exponer. En el siguiente post hablaremos de las colecciones genéricas que presenta el BCL.

[OT] Hadi Hariri y cena aniversario de CatDotNet

José Miguel Torres — Mon, 10 May 2010 08:33:21 GMT

Buenas!!

Comentaros que mañana martes a las 19h tendremos el placer de tener con nostros a Hadi Hariri en la charla mensual de CatDotNet. Además, seguidamente nos desplazaremos a Capellades para celebrar la cena aniversario de CatDotNet dónde nos encontramos anualmente todos la gente de comunidad de la zona de Cataluña. Si estais por la zona, no dudes, en contactarnos!!!

Lugar?: Sala Ig-Nova Tecnospai. Av. Barcelona núm. 105 (Igualada)

Hora?: 19h de la tarde

Ver mapa más grande

Us hi esperem!!!!

¡¡Microsoft SQL Server Compact no ha muerto!!

José Miguel Torres — Wed, 14 Apr 2010 11:48:00 GMT

Después del impacto que ha tenido la presentación del nuevo modelo de desarrollo que traerá tras de sí la nueva apuesta de Microsoft para telefónos móviles con Windows Phone 7 Series, y después de que más de uno se haya enfundado el traje de negro y preparado ya los preparativos para el funeral de .NET Compact Framework he oído rumores de algunos desarrolladores que, ante la visible desinformación de Microsoft que rodea la aparición WP7S, han decidido incluir dentro del mismo funeral a Microsoft SQL Server Compact, y eso me duele ;-)

En primer lugar .NET Compact Framework NO VA A MORIR de la misma forma que no lo va a hacer Windows Mobile 6.5. Mientras WP7S se orienta hacía un claro público consumidor/productivo, WinMo 6.5, por su parte, se quedará dando cobertura al importante parque de aplicaciones empresariales/industriales. Microsoft no ha dicho oficialmente lo contrario por lo que cabe esperar tanto el soporte para WiMo 6.5 y .NET Compact Framework.

Microsoft SQL Server Compact 3.5 y Visual Studio .NET 2010

Con SQL Server Compact 3.1 Microsoft presentó una características importantísima a la menor de las ediciones de SQL Server al hacerla multiplataforma. Esto significa que desde entonces SQL Server Compact no se liga únicamente a entornos de desarrollo para dispositivos móviles sino para lo que se denomina , aplicaciones móviles desarrolladas con WPF o Windows Forms e incluso desde Silverlight.

Por lo tanto, y siguiendo la costumbre, Visual Studio 2010 .NET instala MS SQL Server Compact SP2 con las últimas caracterísitcas en mayoria relacionadas con MS Sync Framework.

Por qué Microsoft SQL Server Compact no debe morir

Porque SQL Server Compact en una –la única en Microsoft- base de datos in-process.
Porque SQL Server Compact es especialmente útil en aplicaciones del tipo Smart Client debido a su alta integración en entornos de sincronización o lo que se denomina base de datos caché.
Porque SQL Server Compact aporta una facilidad de despliegue que además es compatible con ClickOnce.
Porque hay escenarios en los que SQL Server Express no es el SGBD adecuado. En otros escenario no lo es SQL Server Compact. SQL Server Express NO es un rival de Compact.
Porque Microsoft esta adoptando SQL Server Compact como SGBD embebido.
Y por último y aunque sea el más trivial y menos importante, pq el Bandolero se pasó más de un año profundizando en el producto y materializandolo en loque fue su primer libro.

Conlusión

En definitiva, SQL Server Compact 3.5 SP2 seguirá siendo una opción válida ante cualquier nuevo desarrollo brindando todas las características anteriormente numeradas y que la hacen realmente única.

[CatDotNet] Dices tu de nServiceBus…

José Miguel Torres — Wed, 24 Feb 2010 22:33:36 GMT

Buenas!! Pues el próximo viernes 26 de febrero tendremos el placer de contar en Igualada con Sergio Bermudez quién nos presentará lo bueno y lo malo –si es que lo hay- de nServiceBus del amigo Udi Dahan, y cuyo pretexto utilizaremos para tomar, a posteriori, unos cacharros entre amigos y saber más sobre los ESB (ver foto).

Así que si estás por las cercanías, ¡¡te esperamos!!

Virtualización de Servicios con Managed Services Engines

José Miguel Torres — Thu, 04 Feb 2010 07:57:00 GMT

Desde mis primeras incursiones en el desarrollo de Servicios empresariales, básicamente desde la aparición de las primeras betas de WCF, ha habido un miedo escénico que me ha atormentado y es la programación déspota e incontrolada de servicios, servicios y más servicios, lo que deriva en la producción de 300 servicios, con 300 enlaces distintos (no más de 10 comunes), en 50 endpoints y cuyo valor operativo era equivalente a 50 servicios bien diseñados y gobernados. No concebía una arquitectura sólida de servicios sin una “torre de control” o una “cabina de mando” desde dónde poder ver, gestionar y modificar nuestros servicios.

Más adelante tuve la oportunidad de trabajar en una arquitectura SOA desarrollada en J2EE, dirigida por un ESB de Oracle y gestionada con herramientas de gobernabilidad SOA, que manejaban más de un centenar de servicios (proxy y legacy) y dónde la publicación y consumo de dichos servicios se realizaban a través de estrictas normas protocolarias (seguridad, documentación,…).

Ahora vuelvo, de nuevo, a tener la misma necesidad, diseñar una infraestructura de servicios y cuando hablo de infraestructura hablo de ese tipo de herramientas fundamentales para el control de todos y cada uno de los servicios. Pero ahora (en realidad hace ya un tiempo que existe) me encontré con un software, bajo licencia Microsoft Public License (Ms-PL) y código abierto, que adopta de forma práctica la idea de Virtualización de Servicios, llamado Managed Services Engine.

Virtualización de Servicios

La idea básica del patrón de Virtualización de Servicios es el de aislar la complejidad de los servicios expuestos del cliente que los consume ya que tras cada servicio se alberga una gran cantidad de aspectos tales como las localizaciones de los endpoints, las configuraciones de los enlaces, la aplicación de políticas, etc. Además muchas de las adopciones SOA a la practica no ofrecen soluciones sobre versionado de servicios, aplicación de políticas de seguridad o cambios operativos sin necesidad volver a codificar el servicio así como el cumplimiento del SLA entre el proveedor –nosotros- y el cliente.

Aparece la idea de Servicio Intermediario que desacopla el cliente de la implementación del servicio. Como tal, podemos ofrece varios servicios virtuales de una misma implementación para, por ejemplo, utilizarlo en distintos escenarios. Es aquí dónde encontramos la clave de la virtualización, en el servicio intermediario, pues todas las llamadas se realizaran a través de este y podremos modificar su comportamiento sin comprometer los modelos del servicio.

Managed Services Engine

Microsoft Services SOA Infraestructure ofrece una solución de virtualización de servicios a través de Managed Services Engine (MSE). Como cabe esperar, MSE está basado en la plataforma Windows, esto es, Windows Server 2003/2008, SQL Server 2005/2008 y .NET Framework 3.5, especialmente con Windows Communication Foundation para la interceptación de comunicaciones entre servicios virtuales y reales.

MSE puede integrarse tanto con MS Biztalk Server 2006 R2 / 2009 para proporcionar capacidades adicionales tales como la monitorización de las actividades de negocio (BAM), el Business Rules Engine o el ESB Toolkit, entre otros. Además también podemos utilizar los servicios Azure a través de Azure AppFabric, especialmente con .NET Service Bus.

MSE consiste, básicamente, en tres componentes:

Messenger: proporciona la normalización del mensaje de entrada a través de los servicios virtuales. Este componente soporta además la aplicación de políticas (de transformación por ejemplo, tanto de peticiones como de respuestas) así como el mapeo de protocolos.
Broker: este componente obtiene el mensaje normalizado y lo reconvierte a la operación (es decir la implementación de un método del servicio) y su respectiva versión (pues podemos tener más de una operación con distintas versiones).
Dispatcher: una vez se tiene el mensaje y la operación pertinente, dispatcher invoca el método del servicio y se transmite dicho mensaje.

Recalcar que estos tres componentes están totalmente desacoplados unos de otros con lo que podríamos distribuirlos de forma que obtendríamos una gran cantidad de tipologías del sistema. Todo esto es gracias a la catalogo del servicio (Service Catalog), también conocido como repositorio de metadata o simplemente repository o repositorio, ya que contiene todos los modelos de los servicios que hospeda el runtime del MSE –incorpora asistentes para la importación de servicios a través del WSDL y otros mecanismos para servicios POX o REST-. Como dije anteriormente, MSE contiene una implementación de WCF así que es fácil intuir que la comunicación entre ellos se realizan a través de canales de mensajería. El repositorio, por último, utiliza una base de datos SQL Server y la información puede ser publicada en un registry externo UDDI 2.0/3.0.

Por último, MSE contiene una interfaz para la administración de los servicios –MSE Model Viewer- así como una herramienta de test –MSE Universal Service Tester-.

En próximos posts hablaré de las diferentes posibilidades que ofrece MSE desde el punto del vista del rol (developer, IT, architect,…) y como familiarizarse MSE.

[CatDotNet] Eduard Tomàs hablando sobre ASP.NET MVC en Igualada? Comorrr?

José Miguel Torres — Tue, 26 Jan 2010 15:11:00 GMT

Pues sí, Eduard Tomàs, habitual y conocido de geeks.ms y de CatDotNet así como en presentaciones MSDN de Microsoft Ibérica , nos presenta este viernes en Igualada las bondades de ASP.NET MVC.

Si estáis por la zona no dudéis en asistir!!!

Lugar: Sala Ig-Nova Tecnospai. Av. Barcelona núm. 105 (Igualada) a las 19h.

Ver mapa más grande

Inicialización con System.Lazy en .NET Framework 4.0

José Miguel Torres — Thu, 21 Jan 2010 12:11:00 GMT

Una de las novedades de .NET Framework 4.0 es la presentación de la clase System.Lazy<T>. En programación, una inicialización Lazy (el término Lazy significa, literalmente, gandul o retardado) es un método de inicialización que permite que el objeto no se instancie hasta que se llame por primera vez, es decir hasta que sea utilizado. En el ciclo de vida de una aplicación, los métodos y propiedades de una clase que componen existen, es decir se instancian en memoria y permanecen ahí desde la creación hasta que la destrucción de la clase.

Una clase Customer dónde el constructor carga una lista genérica de Order –inicializa un objecto List<Order> – éste permanece en memoria pese a que incluso es posible que ni siquiera lo necesitemos. Hasta .NET Framework 4.0 la implantación de este tipo de inicializaciones se realiza mediante programación retrasando la inicialización de un objeto hasta que realmente se necesitara; en el caso de la clase Customer, por ejemplo, instanciaríamos el objeto List<Order> en un método LoadOrders() o GetOrders(), por ejemplo. En el caso de multithreading, la cosa se complica aún más y a veces el planteamiento o diseño de la clase no es suficiente.

Como novedad esta característica ya forma parte en .NET Framework 4.0 a través de System.Lazy<T> y aporta soporte Thread-Safety y una política de propagación de excepciones consistente para dar soporte al multithreading.

A partir de ahora nos olvidaremos de las técnicas anteriores y utilizaremos System.Lazy<T> para inicializaciones perezosas. Veamos un ejemplo:

   1: static void Main(string[] args)

   2: {

   3:     Lazy<string> cadena = new Lazy<string>(delegate

   4:                                                 {

   5:                                                     return "Ejemplo Lazy";

   6:                                                 });

7:

   8:     Console.WriteLine(string.Format("isValueCreated: {0}", cadena.IsValueCreated));

   9:     //podemos ejecutar cualquier acción y no se ejecutará hasta...

  10:     Console.WriteLine(string.Format("Value calling: {0}", cadena.Value));

  11:     //... que no llamemos al valor

  12:     Console.WriteLine(string.Format("isValueCreated: {0}", cadena.IsValueCreated));

13:

  14:     Console.Read();

  15: }

El constructor de System.Lazy<T> soporta las siguientes sobrecargas:

   1: public Lazy();

   2: public Lazy(Func<T> valueFactory);

   3: public Lazy(bool isThreadSafe);

   4: public Lazy(Func<T> valueFactory, bool isThreadSafe);

El parámetro isThreadSafe se establecerá a true cuando necesitemos utilizar el objeto de forma concurrente por multiples threads, con valor predeterminado a false.

El parámetro valueFactory es un delegado del tipo Func<T> y será el encargado de inicializar el valor del objeto Lazy. Un ejemplo, además del expuesto en el ejemplo anterior, podría ser:

   1: public class Order {}

2:

   3: public class OrderDb

   4: {

   5:     public static List<Order> GetOrdersBy(string idCustomer)

   6:     {

   7:         return new List<Order>

   8:                    {

   9:                        new Order(),

  10:                        new Order(),

  11:                        new Order()

  12:                    };

  13:     }

  14: }

15:

  16: public class Customer

  17: {

  18:     public Lazy<List<Order>> _orders;

19:

  20:     public Customer(string id)

  21:     {

  22:         //inicialización Lazy

  23:         _orders =new Lazy<List<Order>>(() =>  OrderDb.GetOrdersBy(id) );

  24:     }

  25: }

Con el siguiente programa de consola:

   1: class Program

   2: {

   3:     static void Main(string[] args)

   4:     {

   5:         Customer customer = new Customer("10");

6:

   7:         //pese a que customer se ha incializado la Lista de Orders aún no:

   8:         Console.WriteLine(string.Format("isValueCreated: {0}", customer._orders.IsValueCreated));

   9:         //Solicitamos las ordenes

  10:         Console.WriteLine(string.Format("calling Value.Count: {0}", customer._orders.Value.Count));

  11:         //Ahora si se han instanciado

  12:         Console.WriteLine(string.Format("isValueCreated: {0}", customer._orders.IsValueCreated));

13:

  14:         Console.Read();

  15:     }

  16: }

Cuya salida será:

Es importante tener en mente este tipo de inicializaciones sobre todo en procesos de mucho consumo de recursos, por ejemplo objetos de la capa de datos que almacenan datos binarios – imagen, video,- y que muchas veces no necesitamos que consuman memoria si no se van a utilizar. Como este ejemplo, muchos más…