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.

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.

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

Hace un par de días he recibido mi copia de libro Microsoft Mobile Development Handbook editado por Microsoft Press del cual tuve el placer de revisar algunos capítulos mientras lo estaban escribiendo.

El libro lo han escrito Andy Wigley, Daniel Moth y Peter Foot, tres conocidos MVPs en desarrollo para dispositivos cuando iniciaron el libro aunque ahora Daniel Moth ha dejado de serlo ya que ha pasado a ser empleado de Microsoft en el área de movilidad.

Es un libro bastante completo (más de 600 páginas) que cubre casi todo lo relacionado con desarrollo para dispositivos Windows Mobile, centrándose en .NET Compact Framework 2.0 y ofreciendo una introducción a .NET Compact Framework 3.5 que vendrá con Visual Studio 2008, tratando temas de pruebas unitarias, LINQ y WCF para dispositivos.

En su primera parte se centra en lo 'esencial' del desarrollo de aplicaciones móviles, aunque muchos de los temas se pueden aplicar a cualquier otro entorno .NET; en concreto el capítulo 4 sobre pruebas de las aplicaciones y gestión de excepciones.

La segunda parte trata temas más concretos sobre los retos que presentan las aplicaciones móviles hablando sobre temas de red, threading, seguridad y criptografía, acceso a datos, gráficos, controles, etc...

Existe un capítulo, el capítulo 5, dedicado al rendimiento de .NET Compact Framework que explica bastante bien cómo funciona, entre otras cosas, el recolector de basura de .NET Compact Framework y cómo usar las herramientas existentes para medir el rendimiento de las aplicaciones. Este capítulo, aparte del interés que tiene para los desarrolladores de aplicaciones móviles, también puede ser de especial interés para los desarrolladores de juegos basados en XNA ya que esta plataforma se basa en .NET Compact Framework.

En definitiva Microsoft Mobile Development Handbook es un libro bastante recomendable para todos aquellos que quieran desarrollar aplicaciones para dispositivos Windows CE o Windows Mobile usando .NET Compact Framework escrito por gente que conoce bastante bien la plataforma.

Siguiendo la línea que os comentaba en el post anterior donde se mostraba un ejemplo que nos contaron en el pasado MVP Summit (en ese caso acerca de SQL CE Sync Services del que, por cierto, se ha publicado la segunda parte), Mark Prentice publica ahora un ejemplo que nos mostraron sobre WCF para .NET Compact Framework 3.5.

WCF para Compact Framework se va a suministrar con dos canales de comunicación, uno basado en HTTP (ó HTTPS) y otro basado en Exchange Server. Se pueden usar  las versiones 2003 SP2 o 2007 de Exchange La versión 2007 dispone de algunas características adicionales, como la posibilidad de usar aplicaciones de escritorio que 'hablen' con el servidor Exchange mediante Servicios Web para mandar mensajes a los dispositivos. En este caso la comunicación con los dispositivos usará entonces el correo electrónico como base. El dispositivo recibirá un correo mediante Server ActiveSync con un formato determinado que la aplicación podrá capturar, no apareciendo así el mensaje en el buzón de correo del usuario. Esto causó bastantes preguntas ya que no todo el mundo dispone de Exchange y las necesidades de la gente pueden variar bastante, como, por ejemplo, ¿qué hacer si se quieren usar diversas direcciones de email para diferentes aplicaciones cuando ActiveSync sólo permite disponer de una cuenta configurada contra Exchange?

Si ninguno de estos canales nos sirve para nuestra aplicación, siempre se puede extender el sistema y usar el mecanismo de comunicación que nos interese/inventemos. La ventaja que tendremos es que desde el punto de vista del código cliente la utilización será similar, escondiéndose la implementación del canal para que sea transparente.