La semana pasada y parte de la anterior he estado realizando una serie de entrevistas con emprendedores (11 en total) para conocer y ayudar en la arquitectura de sus aplicaciones. Esta tarea forma parte de los servicios que se ofrecen dentro del programa "Microsoft Pre-Incubation Program", un programa impulsado en este caso por Microsoft, Barcelona Activa y Osborne Clark.

Barcelona Activa es una iniciativa del ayuntamiento de Barcelona para impulsar la creación de empresas de todo tipo. Disponen de espacios de encuentro de libre uso, formación y asesoramiento gratuito en todos los ámbitos de creación de empresa y espacio de oficinas a costes MUY competitivos durante los primeros años de funcionamiento de la empresa. Las oficinas se encuentran dentro de la ciudad con muy buen acceso de transporte público.

Microsoft Pre-Incubation Program es un programa que ofrece diferentes servicios de tutorías, formación y consultoría tecnológica (donde yo entro), así como la integración en el programa BizSpark para aquellos emprendedores cuyo foco de empresa sea más tecnológico.

Dentro de estos programas, una vez que un emprendedor dispone de un plan de negocio viable, se le ofrece la posibilidad de ponerse en contacto con inversores para que intenten conseguir la financiación necesaria para arrancar su proyecto.

En mi opinión, esta combinación de iniciativas promueve muy claramente la creación de empresas y de empleo potencialmente de calidad. Por un lado, el propio centro de Barcelona Activa da trabajo a un buen número de personas, personal administrativo y técnicos en diversos campos. Luego, personal externo ofrece formación y consultoría de manera temporal muy concreta. Finalmente, aquellas empresas que consiguen arrancar, emplean inicialmente a sus fundadores y, si funcionan, ofrecerán trabajo a un número indeterminado de personas. Además, aunque las empresas no funcionen o no consigan arrancar, la formación que los emprendedores adquieren es muy válida para comenzar otros proyectos empresariales teniendo gran parte del camino ya andado.

Ahora que estamos inundados todo el día con noticias sobre la crisis, creo que se debería gastar dinero público en la creación de centros de este estilo, uno por provincia no estaría mal, para potenciar las economías locales con empleos y formación de calidad, poniendo la vista en proyectos de larga duración con un gran potencial de crecimiento.

Ya es oficial. Desde hace un tiempo se vienen oyendo rumores de que se estaba desarrollando un nuevo navegador para Windows Mobile; ayer se anunció en el TechEd en Barcelona.

El nuevo navegador se llama "Internet Eexplorer Mobile 6" y estará disponible en los nuevos dispositivos que vayan saliendo a la venta (según los fabricantes vayan actualizando la plataforma). Desgraciadamente no se puede descargar e instalar sin más, como nos gustaría que pasase a muchos.

Como novedades a destacar, han sustituido completamente el núcleo de la aplicación y es capaz de "pintar" las páginas de forma completa, con capacidad de zoom y de desplazamiento con el dedo. Se ha incluido JScript 5.7 (heredado de IE 8) y dispone de Adobe Flash Lite 3.1 (toma ya iPhone!! ) para poder ver clips de Flash incrustados en las páginas.

Aunque que yo sepa todavía no hay terminales con esta versión cargados, ya están disponibles los emuladores para probarlo.

Yo por mi parte quiero probar cómo funciona, o si es del todo posible que funcione, alojado en una aplicación .NET Compact Framework...

Alex Yakhnin (antiguo MVP, ahora consultor en Microsoft) acaba de publicar en CodePlex un modelo de patrón MVC para aplicaciones .NET Compact Framework. Lleva bastante tiempo con el tema, escribiendo sobre ello y refinando el código. Yo la última versión publicada aún no la he probado, pero los ejemplos anteriores si y tienen buena pinta...

Si has programado algún cliente WCF en .NET Compact Framework, habrás visto que, por el momento, el único binding admitido es el básico (basicHttpBinding) con lo que se están tratando esencialmente servicios Web.

Para usarlos desde .NET Compact Framework lo habitual es crear una clase proxy que facilite el acceso al servicio. Para ello se utiliza la herramienta "netcfsvcutil.exe" que funciona de manera similar a la utilidad de "Agregar referencia web" de Visual Studio. Se apunta la herramienta al WSDL del servicio y ésta genera el código necesario para utilizarlo.

En este caso, "netcfsvcutil" generará dos ficheros que hay que incluir en los proyectos. Uno llamado CFClientBase y otro con el nombre del servicio, que será la clase proxy a usar y que a su vez hereda de CFClientBase.

Al usarlos en el código, habrá que crear una instancia de la clase generada como proxy que incorpora todas las operaciones disponibles en el servicio que serán los métodos marcados en el servicio WCF como "OperationContract" y los datos exportados, marcados como "DataContract".

Su uso final es muy simple ya que sólo hay que crear un objeto del tipo del proxy y llamar a la función generada correspondiente, pero de tan sencillo que es, se oculta mucha funcionalidad que puede ser necesaria en algún momento y no está accesible.

En un caso reciente quise obtener la cabecera "Date" de la respuesta HTTP del servicio WCF, pero esta información no está presente en el proxy en ningún sitio. Después de indagar bastante di con la solución. En la clase CFClientBase generada hay un método llamado "getReply". Este método devuelve un objeto de tipo System.ServiceModel.Channels.Message, que contiene el mensaje devuelto por el servicio WCF. Este mensaje a su vez incluye una colección llamada "Properties". Dentro de estas propiedades hay una llamada "httpResponse" (accesible como message.Properties["httpResponse"]) que es de tipo HttpResponseMessageProperty. Una vez ahí se dispone de toda la respuesta http y, en concreto, están accesibles las cabeceras HTTP como una colección llamada "Headers".

En mi caso, modifiqué la clase CFClientBase para exponer el mensaje de respuesta como una propiedad y tenerlo accesible así desde mi código de una forma cómoda. Hay que recordar que si se vuelve a generar el proxy mediante netcfsvcutil se perderán esos cambios y habrá que volver a incorporarlos.

Mi código final para acceder a la fecha de la respuesta HTTP queda algo así (una vez he expuesto la propiedad ReplyMessage en el proxy y sin control de errores):

string fechaHeader = 

 ((HttpResponseMessageProperty)

 proxy.ReplyMessage.Properties["httpResponse"]).Headers["Date"];

DateTime fecha = DateTime.Parse(fechaHeader);

El problema que le veo a todo esto es que la respuesta Http venga como una propiedad indexada de esa forma, lo que no me da mucha confianza en que esta funcionalidad se pueda perder en futuras versiones de .NET Compact Framework, ya veremos...

Recientemente, trabajando con .NET Compact Framework 3.5 en un terminal en español, al producirse una excepción en el código  me he encontrado con el siguiente error:

Hay un mensaje de error disponible para esta excepción, pero no se puede mostrar porque estos mensajes son opcionales y no están instalados en este dispositivo. Instale ‘NETCFv35.Messages.ES.wm.cab’ para Windows Mobile 5.0 y posterior, o  ‘NETCFv35.Messages.ES.cab’ para otras plataformas. Reinicie la aplicación para ver el mensaje.

El mensaje parece claro, faltan las Dll's de mensajes de error que están en los cabs indicados, con lo que parece que si instalación debería solucionarlo; pero la instalación de cualquiera de esos cabs no lo soluciona, siguiendo el error y la imposibilidad de saber rápidamente la razón de ser de la excepción.

Después de darme un par de veces (o tres) con la cabeza en el monitor encontré la solución buscando en Google el nombre del archivo .cab pero en su versión en inglés (NETCFv35.Messages.EN.wm.cab). Por mucho que se instale el cab no se va a solucionar el problema, pero si se descomprime el cab en cualquier sitio del PC, se toma el archivo 'SYCCFA~1.001' y se renombra a 'System.SR.dll' y luego en el proyecto en el que se esté trabajando se hace una referencia a esta dll, los mensajes de ayuda de la excepción volverán a aparecer correctamente.

Espero que os sea útil.

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í.