Como comenté el otro día he estado jugueteando con el desarrollo .NET para Smartphone y lo cierto es que me he encontrado con cosas, al parecer básicas, pero de las que no sabía nada. Por ejemplo de algo tan tonto como los menús.

La aplicación de ejemplo que quería hacer era un pequeño editor de texto que guardara el contenido cifrado (primera sorpresa: nada de System.Security.Criptography en Smartphones, hubo que buscarsela vida). Añadí un formulario, un campo de texto multilínea, código para ajustar su tamaño (nada de docking tampoco) y un menú de Abrir, Guardar, Salir y este tipo de cosas...

El entorno no se quejaba pero en cuanto ejecutaba la "aplicación" recibía una excepción del tipo NotSupportedException. Para más "INRI", la línea en la que lo indicaba era una tontería (asignaba el título del formulario sin más). ¡Misterio!

Bueno, el caso es que al final el error estaba en otro lugar (error de VS2003 marcando su ubicación, pasa bastante a menudo) y tenía que ver con la forma de construir los menús.

Los menús en aplicaciones Smartphone deben cumplir unas ciertas normas o seproduce una excepción en tiempo de ejecución. Estas normas, a saber, son las siguientes:

• No puede haber más de dos menús de primer nivel aunque VS te permita más. Lógico pues sólo tenemos dos botones de acción disponibles.
• El primer menú de estos dos no puede tener submenús. ¿¿¿Por qué??? Ni idea. En otros lenguajes de Smartphone no existe esta limitación. Es decir, sólo puede haber submenús (o menús hijo) en el segundo menú de primer nivel, o sea, en el botón de la derecha del teléfono.

Fue cambiar el menú de sitio y todo comenzó a funcionar de maravilla. La verdad es que es de coña el asunto...

Por cierto, hay otra restricción tonta: no puedes quitar submenús del menú de la derecha desde código en tiempo de ejecución o tendrás otra excepción. Así que no queda otra que desactivarlos (propiedad Enabled = false) y, como mucho, para que no aparezcan asigar una cadena vacía a su propiedad Text. Esto es lo que recomienda Microsoft pero desde mi punto de vista queda horroroso (aparece el numerito con un espacio vacío al lado)

¿Tan dificil era hacer esto mismo con una propiedad Visible que hiciese lo mismo y guardase internamente el valor del texto para restaurarlo? Yo creo que no, así que he hecho una clase MenuOcultable que lo implementa. Es muy sencillita y un experimento, pero puede ahorrar trabajo...

Este es el aspecto de la aplicación antes de ocultar el menú:

y después de ocultarlo (¿es feo o no?):

Tiene una pega y es que si sustituyes el menú original por el que yo he hecho heredado de la clase MenuItem y luego cambias algo en el formulario, Visual Studio se carga el menú ocultable, así que lo mejor es tener una copia del código en un "Snippet" para estos casos.

En el archivo MenuOcultable.zip (50 KB) tienes el código completo. Necesitarás el SDK de Smartphone para ejecutarlo, claro aunque puedes copiar el '.exe' a tu teléfono para probarlo.

Cuando tenga un rato intentaré hacer lo mismo pero usando la API para tratar de ocultar el menú del todo, a ver si es posible. Imagino que no será posible o los chicos de Microsoft lo habrían hecho, pero intentarlo seguro que es divertido.

He de reconocerlo: nunca he desarrollado nada para ejecutarse en Smartphones.

Sin embargo últimamente y dado que existe desde hace tiempo un SDK para .NET y Visual Studio 2003, he estado haciendo unas pruebecillas tontas para cogerle el puntito al desarrollo en esta plataforma.

La verdad es que estoy bastante desilusionado. El desarrollo desde .NET para Smartphone es bastante limitado y desde luego ofrece un soporte mucho menor de .NET que la Compact Framework (CF) de un PocketPC. Para casi todo hay que recurrir a P-Invoke y llamar a la API, el soporte de controles es muy reducido, etc... La documentación del SDK para la CF no es que sea para echar cohetes tampoco, la verdad :-(

La versión 2.0 de la Compact Framework unifica el desarrollo en ambos sistemas. Ahora está en fase beta (con VS 2005) y está muchísimo mejor, pero claro sólo sirve para terminales con Windows Mobile 5.0. En Pocket PC existe la posibilidad de descargar l a beta de la CF 2.0 y todo listo, pero los Smartphone requieren que la CF resida en ROM y no se pueden actualizar a menos que el fabricante saque una actualización completa de la ROM que normalmente será también del propio Sistema Operativo, cosa poco probable.

Me fastidia porque me compré hace nada (dos o tres meses) un Smartphone con Windows Mobile 2003 y ahora me aguantaré con él bastante. A menos que saquen al mercado algún modelo con la última versión a un precio reducidito, algo que de momento me parece ciencia-ficción :-(

Estos días os contaré algunas cosillas interesantes que he aprendido al darme de tortas con el SDK de Smartphone para Visual Studio 2003.

Antes de nada gracias a las miles de visitas que haceis cada mes a este blog.

Lo reconozco. Hace quince días o así que tengo el blog abandonado.

En esta ocasión tengo una buena disculpa: estuve varios días de viaje y, justo el día que volví (el pasado viernes 17) tuve un accidente de moto que me envió al hospital.

Me acaban de "soltar" hace un par de dias pero, aparte de esguinces, raspazos y golpes varios, tengo una mano rota. Ello me complica bastante hacer cualquier cosa y más en concreto escribir con el ordenador (la "sana" también está algo magullada y con rascazos), así que.... imagino que publicaré menos que de costumbre pues me supone bastante esfuerzo. En fin... Si puedo pondré cosillas en breve, incluso algo hoy mismo, que ya me apetece.

Por cierto, por si a alguien le intriga; el accidente NO FUE CULPA MIA. Estaba con la moto parado en un semáforo en rojo y me embistió un conductor despistado (de coche) por detrás:  ¡a volaaaar!.

Tuve mucha suerte, así que podré seguir poniendo cosillas por aquí.

De acuerdo, se trata de un tarea bastante básica si sabes cómo hacerlo, claro, pero lo cierto es que es una pregunta que me hacen de vez en cuando amiguetes, visitantes, y demás....

Cuando te pones a buscar en las clases de entrada y salida de datos algo sobre renombrar un archivo, seguramente buscas algo así como un método Rename o similar. No existe tal método. El truco es que para renombrar un archivo lo que hay que hacer es... ¡moverlo!. Al mismo sitio pero con otro nombre. Así de tonto.

Sabiendo esto la función renombrar sale directa:

private static void RenameFile(string sFileFullPath,string sNewFileName)
 {
  File.Move(sFileFullPath, Path.Combine(Path.GetDirectoryName(sFileFullPath), sNewFileName));
 }

Lo único que se hace es mover el archivo poniendo como destino la misma carpeta (se obtiene con Path.GetDirectoryName) pero un nombre diferente.

;-)

Haz una prueba.... Crea un servicio web sencillo (sumar dos números por ejemplo), y en IIS desactiva la casilla de autenticación anónima, dejando marcada alguna de las que exigen autenticación Windows. A continuación llama al servicio web desde un cliente cualquiera...  ¡Moooc!

Falla, como es lógico, porque al contrario que al usarlo desde un navegador, no aparece un diálogo de autenticación que te solicite las credenciales. Entonces, ¿cómo hacemos?

Lo normal es que queramos pasarle automáticamente las credenciales del usuario actual, para así validarlo y hacer la autorización en los métodos del servicio web en función de los roles a los que pertenezca. En realidad es muy sencillo conseguirlo, sólo hay que usar el siguiente código:

servicioWeb.Credentials= System.Net.CredentialCache.DefaultCredentials;

Esto hace que se le pasen las credenciales por defecto usando para ello un objeto de la clase NetworkCredential.

Por cierto mucho cuidado al usar esto desde ciertos tipos de cliente del servicio web. Por ejemplo en el caso de una aplicación ASP.NET las credenciales que se le pasarán dependerán de la combinación de sistema operativo, ajustes de web.config, tipo de autenticación de IIS, etc... que se hayan elegido, ya que en cada caso se suplanta a un usuario diferente como bien saben los que han asistido al curso gratuito de "Seguridad avanzada en  IIS" en campusMVP.

En esos casos hay que pasarle las credenciales de un usuario concreto.

Pero... ¿y si necesito pasarle un nombre de usuario y contraseña concretos?

Entonces hay que dar alguna vuelta más, pero tampoco es algo complicado en exceso. Lo que hay que hacer es crear un objeto de la clase NetworkCredential con las credenciales que nos interesan y para la URL del servicio Web, y añadirlo a la cahé de credenciales antes de pasarlo al proxy de nuestro servicio web. Sería algo así:

//Se crea una instancia de la caché de credenciales
CredentialCache cache = new CredentialCache();

//Se crea una nueva credencial con los datos apropiados
NetworkCredential credencial = new NetworkCredential("Usuario", "Clave", "Dominio");

//Y se añade a la caché asociándola con la URl del servicio web
cache.Add( new Uri(servicioWeb.Url), "Negotiate", credencial);

//y ahora se asocia la caché a las credenciales del servicio web: voilâ!
servicioWeb.Credentials = cache;

Creo que es un tema muy interesante para conseguir una securización básica de los servicios web sin recurrir a extensiones como WSE 2.0.

¿Te has preguntado alguna vez esto?

Cuando en Internet Information Server tenemos activado el acceso anónimo a una aplicación Web, al ejecutar páginas ASP clásicas, éstas se ejecutan bajo el contexto de seguridad de una cuenta especial llamada IUSR_Nombremaquina, siendo "Nombremaquina" el nombre de red del servidor en el que está instalado IIS. Bueno en realidad esto es así cuando se usa el tipo de aislamiento bajo para la aplicación en las propiedades del servidor virtual de IIS. En caso de usar aislamiento medio o alto, la cuenta suplantada para el usuario anónimo se llama IWAM_NombreMaquina.

En ASP.NET se suplanta por defecto al usuario ASPNET en Windows XP, o al usuario Servicio de Red en Windows Server 2003. Pero, con autenticación anónima en IIS, si se incluye en web.config lo siguiente:

<identity impersonate="true">

Entonces el comportamiento es exactamente el mismo que el de ASP 3.0 clásico para el caso de accesos anónimos, es decir, se usan los usuarios IUSR_ e IWAM_.

Si quieres conocer todo esto explicado más a fondo matricúlate en el curso gratuito de seguridad de IIS en campusMVP.

A qué venía todo esto...

Bueno, aparte de para refrescar conceptos, todo lo anterior venía a cuento de que he escrito un pequño script que, automatizando el acceso a la metabase de IIS, permite averiguar las contraseñas que el sistema le ha asignado a estas cuentas especiales. Esto es algo que no se sabe normalmente y que, en realidad, sólo tiene utilidad en casos muy muy puntuales. Sin embargo creo que es lo suficientemente interesante como para ponerlo aquí, aunque sea por curiosidad.

El script lo he escrito para el curso de IIS de campusMVP que mencionaba. Aparte de en el propio curso lo puedes descargar pulsando aquí.

¡Qué te sea útil!

Dese hace una temporadita está disponible para todo el mundo la Beta 2 de Visual Studio 2005. Se pude descargar desde MSDN, se incluye en CDs y DVDs de revistas y por lo tanto se está utilizando mucho.

El problema con ella viene si la queremos instalar para sustituir a una beta anterior a una versión CTP. No se puede instalar tan alegremente sino que es necesario desinstalar primero los componentes anteriores que hubiese en el equipo. Y no vale hacerlo de cualquier forma. Es indispensable hacerlo en el orden correcto o podríamos tener muchos problemas. El orden adecuado de desinstalación es el siguiente (puedes saltarte lo que no tengas instalado):

1. La versión anterior de Visual Studio 2005.
2. SQL Server 2005 Express Edition
3. SQL Server 2005 Tools
4. SQL Native Client
5. Visual Studio 64-bit prerequisites Beta (de ser el suerto que tiene un equipo de 64 bits)
6. MSDN Express Library 2005 beta
7. Visual Studio Tools for Office System 2005 Runtime Beta
8. Devie Emulator 1.0 Beta
9. .NET Compact Framework 2.0 Beta
10. SQL Mobile 2005 Development Tools
11. Visual J# Redistributable Package 2.0 Beta
12. .NET Framework 2.0 Beta

¡Casi nada!

Si te da un error el paso 11, entonces ejecuta msiexec /x {9046F10C-F5E7-4871-BED9-8288F19C70DF} desde la línea de comandos.

Si te da un error el paso 12 ejecuta msiexec /x {71F8EFBF-09AF-418D-91F1-52707CDFA274} desde la línea de comandos.

Información extraida de http://lab.msdn.microsoft.com/vs2005/uninstall/

El primer post de este blog lo hice justamente el 3 de Junio del pasado año 2004. Así que hoy ¡cumple 1 año!.

Al contrario de lo que se suele decir en estos casos a mi me parece que ha pasado más tiempo que un año. Y la verdad es que mantener un blog como este da su trabajo, no te vayas a pensar...
Hasta la fecha he publicado (sin contar este, claro) 148 posts en total. Esto hace una media de casi uno día si, día no, lo cual creo que es un ritmo bastante importante.

La historia de JASoft.org es mucho más larga que un año, sin embargo. El dominio como tal empezó a finales del siglo pasado, en 1.999, por lo que tiene ya casi seis años (ahora sí que me parece que hace mucho más tiempo). Antes de tener este dominio la página colgaba de un espacio Web de Arrakis, y comenzó dedicada a VB en el año 1.997. Puedes ver la historia completa aquí.

En definitiva: son casi ocho años de historia que espero que puedan llegar a ser el doble por lo menos ;-)