Sync, sync, sync...

El panorama de los sistemas de sincronización ofrecidos por Microsoft ultimamente crece muy rápidamente lo que nos deja a los programadores con la duda de qué sistema escoger y si hemos hecho bien al escoger uno u otro. Desde siempre ha existido en Windows el servicio de replicación de ficheros, usado normalmente por los adminitradores de la red para replicar archivos relacionados con los perfiles de usuario y demás. Aunque es un servicio de replicación genérico, no es común verlo en otros escenarios.

En el caso de replicación de datos de una base de datos, SQL Server ofrece desde hace mucho tiempo sus propios mecanismos de replicación. Merge, que funciona en modo de publicador-suscriptor permite que un servidor publique datos y que otros se suscriban a los mismos para recibir copias de la información. Este mecanismo está disponible también para replicar datos a SQL Server Compact Edition (SQLCE) muy usado en dispositivos móviles. Funciona muy bien pero todo el control está en manos del administrador del servidor de base de datos lo que crea en algunos casos problemas con los desarrolladores. Por otro lado existe RDA (Remote Data Access), útil para replicar datos igualmente entre SQL Server y SQLCE. Es un sistema más ligero, que no requiere configuración especial del servidor de base de datos ya que a éste sólo se le pasan consultas, pero ofrece menos posibilidades que el anterior en cuanto a seguimiento de los datos y resolución de conflictos. Estos dos sistemas además tienen la pega de que sólo funcionan con SQL Server y no con ningún otro tipo de bases de datos.

Recientemente han aparecido otros dos nuevos mecanismos de replicación, orientados a los desarrolladores pricipalmente.

Sync Services for ADO.NET permite replicar datos entre dos sistemas para los que existan proveedores ADO.NET permitiendo por ejemplo la replicación de datos entre SQLCE y Oracle o cualquier otro escenario similar. La idea inicial de este entorno es la de sustituir RDA mejorándolo en muchos aspectos. Este entorno está ya disponible también para dispositivos móviles.

A continuación, y siguiendo la misma filosofía, aparece Sync Framework. Este es un entorno más general, que engloba al anterior, y cuyo objetivo es el de permitir la sincronización de cualquier fuente de datos, sean bases de datos u otra cosa. De hecho en su primera versión pública se incluye a "Sync Services for ADO.NET", a "Sync Services for File Systems" y a "Sync Services for FeedSync", permitiendo la sicronización respectivamente de dos fuentes cualquiera de bases de datos para las que tengamos un proveedor ADO.NET, la sincronización de ficheros entre dos puntos, o la sincronización de "feeds" RSS o ATOM entre dos puntos. Como se puede imaginar lo que se proporciona es un mecanismo mediante el cual, si disponemos de los proveedores adecuados, se podrá sincronizar cualquier cosa sincronizable. Microsoft proporcionará inicialmente unos proveedores pero se le deja al programador la libertad de programarse sus propios proveedores para sincronizar cualquier tipo de información.

Finalmente se acaba de anunciar el lanzamiento de Live Mesh, siendo uno de sus objetivos la sincronización de datos. Según la información publicada, incialmente es capaz de sincronizar archivos de forma muy similar a como lo hace Groove, conectando dos o más puntos a través de Internet de forma transparente. Pero según se comenta, toda la plataforma estará disponible para que los desarrolladores puedan crear aplicaciones que sean capaces de sincronizar cualquier tipo de datos de forma igualmente transparente con lo que podría usarse en principio como sustituto de los métodos mencionados anteriormente. Si esto es así, este mecanismo tiene una gran ventaja con respecto a los anteriores. En los anteriores es necesaria una conexión explícila entre los puntos que sincronizan que sea direccionable, es decir, necesito saber desde el origen la dirección IP de destino. En el caso de Mesh, la localización de los diferentes dispositivos es transparente y se podrían sincronizar datos entre equipos que estén localizados tras NATs y firewalls sin problema lo que proporciona muchas ventajas a la hora de sincronizar datos sobre todo para dispositivos móviles.

En fin, cada vez hay más y más opciones. Esperemos a las versiones finales a ver cómo se consolidan las diferentes ofertas de sincronización.

Al igual que el ejemplo anterior, ya están disponibles tanto la presentación (en formato de Office 2007) como la aplicación de ejemplo "eLoc" (proyectos de Visual Studio 2008) de la sesión impartida en el evento de Microsoft TechDays del martes pasado (26 de Febrero).

Este ejemplo muestra el uso del transporte WCF basado en Microsft Exchange 2007 tanto en un entorno de PC con .NET Framework 3.5 como en un entorno de Windows Mobile, con .NET Compact Framework 3.5.

Para aquellos que quieran probar los ejemplos, van a necesitar lo siguiente:

• Un servidor Exchange 2007 (si es SP1 mejor)
• Dos buzones creados, uno de ellos con acceso por ActiveSync
• Un terminal Windows Mobile (o emulador) con uno de los buzones anteriores configurado para su sincronización mediante ActiveSync
• Un PC en el que configurar la aplicación Windows Forms con acceso al servidor Exchange.
• Un certificado para SSL de comunicación con el servidor Exchange
• Configurar tanto el PC como el terminal Windows Mobile para que acepten el certificado raiz del certificado SSL. Si es un certificado comprado a Verisign o alguna entidad similar no será necesario hacer nada. Si es un certificado propio, el certificado raíz deberá estar configurado en el store de "Trusted Roots" del PC y del dispositivo Windows Mobile.
• Un dispositivo GPS/GSM si se quiere probar la funcionalidad en vivo. Si no, este dispositivo no es necesario y se puede probar WCF para Exchange simulando el mensaje de respuesta.

El escenario presentado por el ejemplo es el de poder localizar a un terminal GPS remoto (con capacidad de GSM) mediante un mensaje SMS (útil por ejemplo en el caso de un equipo de personas que trabajen en un servicio de emergencias). La solicitud de localización se puede enviar tanto desde la aplicación de la 'central' como desde el terminal Windows Mobile. El terminal GPS, una vez recibido el SMS, devuelve otro SMS al dispositivo Windows Mobile, quien, a su vez, envía un mensaje WCF mediante Exchange a la aplicación de la 'central', que mostrará la localización del terminal GPS en un mapa de Virtual Earth.

Existen diversos terminales de GPS/GSM en el mercado de forma que en el código no se ha incluido ningun mensaje específico para ninguno de ellos. Si el lector cuenta con uno de esos terminales tendrá que establecer el texto del SMS a enviar en la clase Localizador y configurar el código del MessageInterceptor en el formulario principal de la aplicación Windows Mobile para capturar los mensajes SMS recibidos.

Como no es común que se disponga de estos terminales, se puede probar la funcionalidad en la aplicación de Windows Mobile sin necesidad de tener uno de ellos ya que ésta dispone de un botón que pemite enviar una respuesta simulada.

Una vez configurado esto, la solución Visual Studio 2008 cuenta con tres proyectos:

• Un proyecto Web que dispone de dos páginas, una con un mensaje de espera y otra que muestra en un mapa la localización de un GPS encontrado. Esta aplicación Web se usará integrada en el cliente de la 'central'.
• Un proyecto .NET Compact Framework 3.5 que envía y recibe mensajes WCF mediante la conexión de ActiveSync.
• Un proyecto .NET Framework 3.5 que envía y recibe mensajes WCF mediante los servicios Web de Exchange 2007.

Para terminar de configurar el código, el lector deberá modificar los parámetros de cuentas de correo, usuarios y contraseñas y números de teléfono (si se va a usar el GPS real) en el código para adecuarlos a su entorno. Los parámetros son cadenas de texto encontradas en las clases 'MainForm' de cada uno de los proyectos.

Gracias a todos los asistentes su participación y espero que los ejemplos les resultasen interesantes.

Ya están disponibles la presentación (en formato de Office 2007) y la aplicación de ejemplo "LugaresVisitados" (proyectos de Visual Studio 2008) de la sesión práctica impartida en el evento de Microsoft TechDays del martes pasado (26 de Febrero).

La solución de Visual Studio de ejemplo consta de dos proyectos, una aplicación .NET Compact Framework 3.5 y una aplicación servidor basada en ASP.NET (con .NET Framework 3.5)

La aplicación cliente permite tomar una foto con la cámara de fotos de un terminal Windows Mobile, añadirle unas notas y, si hay un GPS conectado, asociarle a la foto unas coordenadas. Una vez tomada la foto y definidas las notas la aplicación, ésta puede ser subida al servidor Web donde quedará almacenada. Para quellos que se instalen el ejemplo, lo primero que han de hacer es modificar el archivo de configuración "config.txt" (en formato XML) para establecer un nombre de un puerto de serie correcto para el GPS y una URL válida de conexión al servicio Web.

La aplicación servidora es una aplicación ASP .NET que permite visualizar las fotos, taanto en una lista como individualmente y, para aquellas fotos que tengan asociadas coordenadas GPS, visualizarlas además en un mapa de Virtual Earth. En esta aplicación hay dos servicios Web WCF definidos. El primero permite subir las fotos al servidor (FotoUploader.svc) y el segundo permite obtener la lista de fotos que tienen coordenadas GPS asociadas (FotosCoordenadas.svc). Este último servicio existe para poder ser invocado desde JavaScript, desde la página que tiene el mapa de Virtual Earth obteniendo los datos en formato JSON.

Es conveniente revisar la presentación para ver qué parámetros de configuración de los servicios WCF se han establecido en el archivo Web.Config de la aplicación Web para configurar el sistema tal como funciona.

Por otro lado, para poder crear aplicaciones cliente en .NET Compact Framework para este tipo de servicios WCF, hay que recordar que es necesario instalarse los Power Toys para .NET Compact Framework 3.5, que incluyen, entre otras cosas, la utilidad "netcfsvcutil.exe" que es la que permite la generación del proxy que realiza la llamada al servicio Web.

Quiro agradecer a todos los asistentes su participación y espero que los ejemplos les resultasen interesantes.

He replicado un artículo que apareció originalmente en la revista PC World de Julio-Agosto de 2007 con el título original de "Desarrollando 'On the road' con Windows Mobile 6".

En este artículo se comentan las novedades incluidas en la plataforma y en los SDKs de Windows Mobile 6 y se desarrolla una pequeña aplicación paso a paso de la que el código está disponible para su descarga.

Podéis acceder al artículo completo aquí.

Se acaba de anunciar un nuevo modelo de teléfono de Sony-Ericsson, el XPERIA X1, que vendrá con Windows Mobile. Al parecer el terminal está fabricado por HTC (cómo no) y será el primero de una nueva línea de móviles de Sony Ericsson con este nuevo sistema operativo para ellos. El terminal parece bastante completo, e incorpora un nuevo UI que, si funciona como aparece en el vídeo promocional, quiere competir directamente con el UI del iPhone.

El movimiento resulta bastante interesante ya que Sony Ericsson es uno de los fabricantes que más apoya (apoyaba?) Symbian en su línea UIQ. Por lo que parece, de entre todos los fabricantes grandes de móviles, ya sólo falta Nokia por unirse al carro de Windows Mobile; aunque ha licenciado parte de sus tecnologías, eso sí.

Por experiencia os puedo decir que, desde el punto de vista del programador, nos ahorrarían muchos dolores de cabeza si lo hicieran.

Aquí tenéis una interesante aplicación gratuita (de momento) para los usuarios de Windows Mobile 5/6. Se trata de una utilidad que reemplaza en cierto modo al Home Screen de un Pocket PC, aunque no lo deshabilita. Visualmente es muy agradable con animaciones y transiciones muy interesantes (que me recuerdan mucho a FlowFX, la entrada presentada en el primer concurso de desarrollo de OpenNETCF Community). Desde el punto de vista del uso, está pensada para ser utilizada principalmente con el dedo, aunque funciona bien con las teclas de desplazamiento. Veremos cómo evoluciona ya que aún es un proyecto reciente, pero no tiene mala pinta.

Hasta ahora no había realizado más que pequeñas pruebas de LINQ, pero recientemente he cambiado de proveedor de hosting (al de momento magnífico discountASP) que ya proporciona soporte para .NET 3.5 y me he decidido a usarlo un poco más.

En concreto he creado una nueva página de links, donde he puesto de momento los links que tengo alojados en del.icio.us y mis elementos compartidos de Google Reader, que es el lector RSS que utilizo.

Tanto del.icio.us como Google Reader proporcionan acceso a los elementos públicos mediante una URL que ofrece un documento RSS en el primer caso (http://del.icio.us/rss/amezcua) y un documento ATOM en el segundo (http://www.google.com/reader/public/atom/user/06770480527490995101/state/com.google/broadcast).

Teniendo esto en cuenta, el funcionamiento de la página es realmente sencillo. Sin entrar en detalles los pasos realizados son:

1º Al cargar la página se obtiene un documento XML a partir de la URL para cada uno de los documentos anteriores. Esto es tan sencillo como:

XDocument xmlDoc = XDocument.Load(urlServicio);

2º Una vez se dispone del documento se obtiene, mediante una consulta LINQ, una colección de elementos extrayendo los datos deseados del XML original. Por ejemplo, para el caso de del.icio.us se quiere obtener una colección de objetos con dos campos, 'title' y 'url':

var itemList = from item in xmlDoc.Descendants("{http://purl.org/rss/1.0/}item")
select new { title = (string)item.Element("{http://purl.org/rss/1.0/}title"),
url = (string)item.Element("{http://purl.org/rss/1.0/}link")
};

3º Cuando se tiene la colección creada (itemList) se puede utilizar DataBinding para vincular esta lista de elementos a cualquier control. En mi caso lo he vinculado a un control DataList. En el control DataList simplemente se especifica que se quieren mostrar los campos 'title' y 'url' definidos antes:

dlDelIcioUsItems.DataSource = itemList;
dlDelIcioUsItems.DataBind();

Como se puede ver hay, sin contar el control de errores, 4 líneas de código para cargar un documento XML remoto y mostrarlo en una página Web, bastante impresionante, teniendo en cuenta que para hacer algo similar hasta ahora lo que hacía era disponer de una clase que defina la estructura del documento, cargar el XML remoto en un XmlReader, deserializar el documento a la clase y finalmente obtener la colección de items interna de esa clase.

Una de las cosas que hay que destacar es el uso de los namespaces de XML. Como se ve en la consulta LINQ, para acceder a cada uno de los elementos del documento hay que especificar el namespace XML en el que se encuentra

{http://purl.org/rss/1.0/}

lo que define completamente al elemento XML concreto. Esta sintaxis, tal como está en el ejemplo, no me acaba de gustar, así que se puede mejorar de la siguiente forma:

XNamespace deliciousNS = "http://purl.org/rss/1.0/";
var itemList = from item in xmlDoc.Descendants(deliciousNS
+ "item") select new {
title = (string)item.Element(deliciousNS + "title"),
url = (string)item.Element(deliciousNS + "link")
};

En este caso se define un objeto XNamespace con el namespace adecuado y se utiliza en todos aquellos sitios donde se necesite especificar el nombre completo del elemento. Como el tipo XNamespace sobrecarga el operador '+' se puede usar simplemente añadiendo entre comillas el nombre del elemento XML. Esto no se encuentra en la mayoría de los ejemplos publicados por ahí sobre LINQ to XML, donde se utilizan documentos XML sin definición de namespaces, cosa que no es muy habitual en el mundo real ¿no?

Desde hace tiempo existe una herramienta en .NET Framework llamada CLR Profiler que permite examinar el heap de memoria del recolector de basura de .NET de una forma gráfica con el objetivo de ayudar en la búsqueda de problemas relacionados con el uso de memoria en las aplicaciones.

Unai y yo enseñamos el uso de la herramienta en el último Code Camp en Huelva, entre otas cosas.

Esta utilidad se ha portado a .NET Compact Framework con la llegada de la nueva versión y está disponible como un Power Toy junto con otras herramientas.

Steven Pratschner acaba de publicar el primero de una serie de artículos dedicados a explicar con detalle el funcionamiento de la herramienta utilizando una aplicación de ejemplo como guía.

Si sospechas que tienes algún problema de consumo de memoria en tu aplicación .NET te recomiendo que leas estos artículos que te ayudarán a intentar localizar dónde está la causa.

Con las primeras betas de .NET Compact Framework 3.5 se incluían una serie de utilidades que han desaparecido de la distribución encontrada en Visual Studio 2008. Estas aplicaciones se distribuyen ahora en un paquete de instalación independiente y su versión definitiva saldrá cuando se libere Visual Studio 2008 (actualmente están en versión beta también). Estas herramientas son:

• Remote Performance Monitor, GC Heap Viewer y CLR Profiler. Permiten capturar métricas de rendimiento de aplicaciones para su análisis posterior así como capturas del estado de memoria de una aplicación .NET en un momento dado. Son muy útiles para verificar el uso de recursos por parte de las aplicaciones y depurar así su rendimiento, así como para capturar posibles problemas de leaks de memoria y similares.
• Application Configuration Tool (NetCFcfg.exe). Esta utilidad permite especificar la versión de .NET Compact Framework con la que se quiere que se ejecute una determinada aplicación .NET en caso de que se tengan varias versiones instaladas en el dispositivo. Por ejemplo se puede haber desarrollado una aplicación con .NET CF 2.0 pero se ha actualizado el sistema y se quiere forzar a que esa aplicación concreta se ejecute con la versión 3.5, aunque la 2.0 sigue instalada también. Esta herramienta se ejecuta directamente en el dispositivo.
• NETCF Service Metadata Tool. Con esta utilidad se pueden generar clases proxy para su uso con Windows Communication Foundation para .NET Compact Framework. Es el equivalente de svcutil.exe en el PC.
• Remote logging configuration tool. Esta herramienta permite configurar la creación de archivos de log que incluyan información la carga, errores, uso de interop, utilización de la red y ejecución de finalizadores de aplicaciones .NET. Estos logs son muy útiles para la detección de posibles problemas cuando una aplicación está en fase de pruebas.
• NETCF Network log viewer. Utilidad para la visualización de los logs de uso de red obtenidos con la herramienta anterior.

(obtenido del blog del equipo de desarrollo de .NET CF)

Los chicos de OpenNETCF acaban de abrir un nuevo sitio web orientado a la comunidad de desarrolladores para dispositivos basados en Windows CE / Windows Mobile / .NET Compact Framework. Son de los mayores expertos que hay en este tema con lo que el contenido que encontraréis será de calidad.

Inicialmente el sitio empieza con 3 puntos concretos:

1. Artículos técnicos. Artículos interesantes sobre desarrollo. Si queréis contribuir, se les pueden mandar artículos para su publicación.
2. Concursos de desarrollo. Organizan concursos de desarrollo cada mes con premios interesantes para los ganadores. Este mes se trata de presentar aplicaciones o componentes con interfaces de usuario atractivas. Los premios son una copia de Visual Studio y un dispositivo Windows Mobile a elegir de entre varios.
3. Un servidor basado en Subversion donde alojar proyectos Open Source. Ellos han colgado de momento varios de sus proyectos Open Source pero ponen el servidor a disposición de la comunidad para alojar otros proyectos relacionados con el desarrollo orientado a dispositivos.

La idea promete, así que estaremos atentos a ver cómo evoluciona.

Andrew Arnott, uno de los programadores de .NET Compact Framework, ha publicado una lista de las características de WCF (Windows Communication Foundation) que se van a incluir en la nueva versión de .NET Compact Framework (3.5), esperada junto con Visual Studio 2008. Como siempre (y lógicamente) .NET Compact Framework incorporará un subconjunto de las características de su hermano mayor. Pero en este caso, .NET Compact Framework incluye una funcionalidad diseñada en exclusiva para él que, según aparece en esa lista, podrá ser utilizada desde WCF en el PC y es la posibilidad de realizar mensajería entre aplicaciones utilizando Microsoft Exchange como transporte (ExchangeWebServiceMailBinding). Este transporte de WCF ofrece ciertas características bastante interesantes sobre todo en el caso de aplicaciones que se conectan esporádicamente a la red, ya que Exchange almacena los mensajes recibidos hasta que pueden ser descargados por el cliente cuando éste tenga conexión. He visto ejemplos de cómo funciona en dispositivos móviles pero no lo he visto funcionando en el PC, así que habrá que probarlo...