Principales novedades de VS Orcas para dispositivos móviles

Hola amig@s,


Mientras apuro mi última hora de la jornada laboral, instalando VS 2003 para pelearme con unos webparts de WSS que necesariamente deben hacerse en ASP.NET 1.1 y sintiéndome como Michael J. Fox en “Regreso al futuro”, me propongo a dar un repaso a las principales novedades que nos comenta el amigo Daniel Moth sobre VS Orcas en lo referido a programación para dispositivos móviles, ya que es algo que por estos lares venía echando en falta (no sé si por desconocimiento o por inexistencia, pero no he encontrado nada al respecto)…


Al margen de las novedades que conlleva el NETCF 3.5, hay también un montón de mejoras en el IDE, de las cuales me gustaría destacar las siguientes:

1. Pruebas unitarias para dispositivos móviles
A destacar que esto también funciona para proyectos de dispositivos v2.0 en Orcas!


2. Nueva ventana de proyecto


3. Emulador de dispositivos v3


Esta nueva versión mantiene todo “lo bueno” de la v2.0, y además permite ser automatizada via COM (echar un vistazo al DEMComInterface.idl en el directorio de instalación del Device Emulator)


4. Device Configuration Manager & Device Certificate Manager


Antes conocido como powertoy for WM5. Para verlo en acción, debemos seleccionar “Device Security Manager” desde el menú de Herramientas de Orcas.



 5. Windows Mobile 5 SDKs y .NET Compact Framework v2.0 SP2 vienen “de serie”. Ahórrate descargas adicionales! [;)]


Que viene el jefe… Publicar y ALT+F4 ya!

Un ejemplo "curioso" de fisicas en WPF

Hola!


El amigo Lee Brimelow ha creado un ejemplo que hace uso de físicas en WPF, basado en el ejemplo en XNA de Chris Cavanagh, que podéis encontrar aquí.


El ejemplo en cuestión es un tanto curioso, podéis explorarlo vosotros mismos, tiene unos excelentes efectos gráficos y de sonido. Además, el proyecto es totalmente compatible con la Web 2.0


No os digo más, disfrutadlo [;)]

Dentro de la maquina virtual de .net

Hola amig@s,


En este post voy a hacer una revisión a nivel de pila de lo que sucede en nuestra máquina virtual de .net y el CLR cuando llevamos a cabo una serie de acciones bastante frecuentes.


Antes que nada, comentaros que he optado por usar ejemplos de código en C#, lo cual espero que me perdonen aquellos adeptos de VB.net, jeje.


En primer lugar, vamos a ver cuál es el estado inicial de la pila de ejecución de un programa justo antes de invocar a un método que hemos denominado M1:


 


Una vez que comienza la ejecución de M1, su prólogo reservará espacio en la pila para las variables locales, como podemos ver a continuación:


 


En la siguiente instrucción de M1, se invoca a otro método, M2, pasándole la variable local “name”, creada anteriormente, como argumento. Podemos observar que también se apila la dirección de retorno, es decir, la dirección a la que deberá volver el PC (contador de programa) cuando finalice la ejecución del método M2:



Al comenzar la ejecución del método M2, su prólogo reserva espacio para las variables locales del método en la pila, de manera análoga a lo que previamente hizo el método M1.



Al finalizar la ejecución de M2, se devuelve el control al método M1, haciendo uso de la dirección de retorno que le habíamos indicado anteriormente.



Finalmente, M1 finaliza su ejecución y devuelve el control al método desde el que había sido invocado.



Aspectos particulares del CLR:


Consideremos la siguiente declaración…



internal class Employee {



public Int32 GetYearsEmployed () {…}


public virtual String GetProgressReport () {…}


public static Employee Lookup (String name) {…}


}


internal sealed class Manager : Employee {



public override String GetProgressReport () {…}


}


Un programa en ejecución está a punto de llamar a M3, la pila y el heap ya han sido creados.



El compilador Just-In-Time (de ahora en adelante, JIT) compila M3 a código nativo. Se consultan las cabeceras de los ensamblados de los tipos Employee, Int32, Manager y String, y se crean las estructuras para representarlos (no se muestran las de Int32 y String):



Todos los objetos del heap contienen al menos dos miembros: un puntero a un objeto de tipo (type object) y un índice usado para sincronización de hilos de ejecución (sync bloc index). Los objetos de tipo Employee contienen, por tanto, ambos. También incluyen espacio para los campos estáticos de cada tipo y una tabla con los métodos definidos.


Ya está todo listo, sigamos con la ejecución del código nativo M3… [;)]



El prólogo de M3 reserva espacio en la pila para las variables locales, CLR las inicializa a NULL o a cero automáticamente.


Se crea en el heap una instancia del tipo Manager. Este objeto contiene todas las variables de instancia del tipo Manager y de todas sus clases base.



CLR inicializa un puntero al tipo del objeto y todas las variables de instancia a NULL o a cero. Después se llama al constructor del tipo y, finalmente, se guarda en la variable ‘e’ la referencia al objeto.



Llamada a un método estático


Consideremos el siguiente código:



internal class Employee {



public Int32 GetYearsEmployed () {…}


public virtual String GetProgressReport () {…}


public static Employee Lookup (String name) {…}


}


internal sealed class Manager : Employee {



public override String GetProgressReport () {…}


}


CLR busca en la tabla del tipo Employee el método Lookup. El método se compila (si es necesario) con el compilador JIT y se invoca el código resultante.



Supongamos que Lookup construye un nuevo objeto de tipo Manager en el heap y devuelve su dirección. El primer objeto Manager se convierte en un objeto obvio para el recolector de basura…


Llamada a un método de instancia no virtual


Sea el siguiente código de declaración:



internal class Employee {



public Int32 GetYearsEmployed () {…}


public virtual String GetProgressReport () {…}


public static Employee Lookup (String name) {…}


}


internal sealed class Manager : Employee {



public override String GetProgressReport () {…}


}


 


El CLR buscaría en el objeto de tipo Employee, por ser el tipo de ‘e’. Si Employee no definiera el método, iría descendiendo por la jerarquía de tipos buscándolo.


Llamada a un método virtual


Dada la siguiente declaración:



internal class Employee {


public Int32 GetYearsEmployed () {…}


public virtual String GetProgressReport () {…}


public static Employee Lookup (String name) {…}


}


internal sealed class Manager : Employee {


public override String GetProgressReport () {…}


}


El CLR seguiría la dirección de ‘e’ hasta el objeto del heap y desde éste llega al tipo real del objeto, Manager, y al objeto.



Si el método Lookup hubiera devuelto un objeto del tipo Employee, uno de los punteros habría sido distinto y la llamada a GetProgressReport habría ejecutado la implementación de Employee, en lugar de la de Manager.


Los punteros a objetos de tipo de los propios objetos de tipo apuntan a un objeto especial creado para el tipo System.Type. Los objetos de tipo Manager y Employee son “instancias” de este tipo.



El método GetType de System.Object devuelve la dirección almacenada en el puntero a objeto del tipo del objeto correspondiente. Así puede determinarse el tipo real de cada objeto.


Y por hoy nada más, que sino te ahogas [:P]


Espero que haya sido de vuestro agrado, y gracias a los que habéis aguantado hasta aquí… que no es poco!!


Un saludo [:)]

Evento de Gusenet: WPF y Team System

Hola a todos,

Ya tenemos la agenda para la próxima reunión del Gusenet:


Viernes 25 de Mayo

– 16:00 / 16:30 Bienvenida y registro
16:30 / 17:30 WPF (Recursos y UserControls). Novedades de Beta 1 de ORCAS
– 17:30 / 17:45 Descanso
17:45 / 19:45 Team Sytem para DBAs












Lugar: Clave Informática
Galileo Galilei, 12 – Elche Parque Industrial
03203 Torrellano – Elche – Alicante


Plano del lugar: Pincha aqui

Aquí tenéis el link a MSDN para el registro en el evento.
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032340755&Culture=es-ES


Esperamos veros por allí [:)]

Programando en WPF a través del MSN Messenger

¿Cuántos de nosotros nos hemos pasado horas y horas peleándonos con nuestro código XAML para que algo funcione y hemos tenido que dejarlo a medias al final de la jornada?


¿Nunca te has vuelto para casa en el coche pensando en “eso que te ha faltado por probar en tu código y que tal vez sea la solución que andabas buscando”?


Cuando llegas a casa, te sientas frente a tu monitor y le cuentas tu problema a un amigo a través del Messenger… y entonces tienes dos alternativas:



  1. Le envías un fichero con el código para que él lo pruebe…

  2. Copias y pegas tu código XAML en la ventana de conversación… con el consiguiente daño a la vista que ello supone…

Tal vez sería mejor poder compartir ese XAML a través del messenger de otra forma, poder visualizar el aspecto resultante, permitir a tu amigo modificar ese código y que también él pueda ver el resultado, incluso si se trata de imágenes, vídeos, animaciones… ¿¿¿no sería genial???


Te presento ChatBlender (de nuestro gran amigo Robert):



Happy programming friends! [:)]