.NET o no .NET, esa es la cuestión : C#

Llamando al API de WinRT desde aplicaciones de escritorio normales en C#

Rafael Ontivero — Sat, 02 Feb 2013 14:09:00 GMT

NOTA IMPORTANTE:

Esta entrada está obsoleta porque lo que describo más abajo no funciona tal y como está contado. Es un mea culpa en toda propiedad por no haber probado antes lo que escribía, pero es que la entrada original es bastante creíble.

Eso me llevó a crear un nuevo artículo, esta vez verificado, que se puede leer aquí:

Llamando al API de WinRT desde aplicaciones de escritorio normales en C#

******************************************************

El otro día twiteé un enlace que tenía apuntado por ahí y que no había leído hasta el momento del twitt, como me pasa con una docena más, que tengo en la lista de encontrar tiempo y tranquilidad para leerlos en detalle.

Y como creo que debería estar en castellano, os voy a contar de qué va la cosa.

Todos sabemos que ahora hay dos Windows 8. El tradicional de toda la vida y el RT. A ver, son el mismo, pero a la vez diferentes. El RT es la versión para tabletas, que en teoría permite desarrollar usando sólo un subconjunto de Win32 y de .NET, pese a que por debajo sigue estando el Windows de toda la vida.

La otra versión es la normal, la del escritorio pleno y funcional a la que estamos acostumbrados, que a su vez usa el API tradicional, ya sea el nativo Win32 o el de .NET.

Y si bien está prohibido usar el API completo en las aplicaciones RT, lo contrario no es así ya que en el escritorio tenemos plena libertad para utilizar cualquier cosa, incluyendo el API de Windows RT. Lo que ocurre es que el soporte directo para ello está ausente en las versiones de Visual Studio.

Pero se puede hacer editando el texto plano del fichero de nuestro proyecto: <proyecto>.csproj. Ahí dentro debemos añadir las líneas

</propertygroup>

Y a partir de ahí, una vez recargado el mismo, podremos usar el API de Windows RT con sólo añadir las referencias adecuadas según se vayan necesitando. El mayor problema es que tenemos que saber cuáles son y añadirlas a mano.

Workaround para Windows Phone ListBox/LongListSelector y ScrollIntoView() cuando los elementos tienen diferente tamaño

Rafael Ontivero — Fri, 11 Jan 2013 13:34:35 GMT

En Windows Phone 7.5 hay un bug bastante asqueroso que sólo se presenta cuando quieres mostrar un elemento en un ListBox o en un LongListSelector llamando a ScrollIntoView() y los elementos contenidos tienen diferentes tamaños. El bug también está presente en Windows Phone 8, pero sólo en el componente ListBox. LongListSelector está construido de otra forma y, según Microsoft, ya no presenta el problema.

Como es habitual en la empresa, y aparte de ser un problema conocido desde hace tiempo, no se va a solucionar. Personalmente podría entender que no se haga en las versiones actuales ya que requeriría que luego los fabricantes reconstruyeran sus propias plataformas, pero me resulta completamente inaceptable que siga estando en el nuevo Windows Phone 8, y encima conociéndolo de antemano.

En fin, es lo que hay, y encima tampoco existe ningún workaround oficialmente sancionado para resolver el problema. En otras palabras, si tienes un programa en el que te ocurre eso, básicamente te jodes y bailas.

Pero no, aquí está RFOG que te va a sacar las castañas del fuego. Como sabéis llevo unos meses currando en Yuilop para Windows Phone, y también debéis saber que me toca mucho las narices que te digan eso no se puede hacer y similares. Y por supuesto, a tu jefe tampoco le agrada mucho que le digas: es un bug y no tiene solución.

Para descargo propio he de deciros que la solución es un poco chorra y que sólo había que pensar un poco, pero tenéis que reconocerme que debo de darme algo de bombo y platillo.

***

Bueno, ahora la parte técnica.

En el ejemplo que anexo más abajo, cuando se pulsa el botón de Insert… se genera un elemento de tres posibles mediante Code Behind. Los tres tienen como elemento base un Grid, pero el interior es diferente y por tanto su altura. Dos de ellos contienen una imagen y el tercero, un texto.

En cada elemento creado, se llama a ScrollIntoView() sobre el citado, para que se visualice adecuadamente.

Conforme vamos creando elementos, llega un momento en el que uno de ellos se queda cortado a medias como en la captura:

El comportamiento adecuado debería ser que se mostrara completo, mostrando la parte inferior. Ese es el problema: cuando los elementos tienen diferente altura, termina ocurriendo esto mismo. Y según Microsoft, no se va a solucionar. Las apuestas suben cuando hay campos de edición y cambios de orientación: con total seguridad te quedará el elemento cortado.

El código que genera los elementos es:

        private void Button_Tap(object sender, GestureEventArgs e)
        {
            switch (s_rnd.Next(0,3))
            {
                case 0:
                    var itemText = new ListBoxItemText("Hola mundo");
                    ListBox.Items.Add(itemText); 
                    ListBox.ScrollIntoView(itemText);
                    break;
                case 1:
                    var itemImgBien = new ListBoxItemImage(StaticResources.ImageBien);
                    ListBox.Items.Add(itemImgBien);
                    ListBox.ScrollIntoView(itemImgBien);
                    break;
                case 2:
                    var itemImgMal = new ListBoxItemImage(StaticResources.ImageMal);
                    ListBox.Items.Add(itemImgMal);
                    ListBox.ScrollIntoView(itemImgMal);
                    break;
            }
        }

Fijaos en el detalle. Dependiendo de un número aleatorio creamos uno de tres. Eso debería funcionar bien, pero como podéis comprobar vosotros en vuestra casa, no lo hace en el momento en el que empiezan a aparecer elementos con el texto y con una de las dos imágenes.

***

Como ya os he dicho, la solución es bastante sencilla. Os pego el código:

        private void ButtonNoBug_Tap(object sender, GestureEventArgs e)
        {
            switch (s_rnd.Next(0, 3))
            {
                case 0:
                    var itemText = new ListBoxItemText("Hola mundo");
                    ListBox.Items.Add(itemText);
                    ForceScrollListBox();
                    break;
                case 1:
                    var itemImgBien = new ListBoxItemImage(StaticResources.ImageBien);
                    ListBox.Items.Add(itemImgBien);
                    ForceScrollListBox();
                    break;
                case 2:
                    var itemImgMal = new ListBoxItemImage(StaticResources.ImageMal);
                    ListBox.Items.Add(itemImgMal);
                    ForceScrollListBox();
                    break;
            }
        }

Y el truco del almendruco:

        private void ForceScrollListBox()
        {
            var fake = new Grid();
            ListBox.Items.Add(fake);
            ListBox.ScrollIntoView(fake);
        }

Sí, señores. El truco consiste en crear un nuevo elemento del mismo tipo base pero completamente vacío, añadirlo y llamar a ScrollIntoView() sobre él. El uso de memoria es mínimo porque el componente no debe ocupar muchos bytes ya que está vacío, y tampoco se visualiza, pero en general el sistema empuja hacia arriba al elemento que queremos mostrar.

No obstante, creo haber detectado que no siempre funciona, al menos en el emulador, pero de momento la gente de QA de Yuliop todavía no me ha protestado. [Aplausos de fondo].

En el ejemplo tenéis tres botones. En el primero hacemos inserciones con el bug, en el segundo sin él y con el tercero corregimos si tenemos un elemento a medio mostrar o nos vamos abajo del todo si estamos a medias.

Finalmente, el código fuente de todo esto está aquí:

https://github.com/rfog/InsertInListboxproblem_Solution

Sed buenos y hasta otra.

Repetid conmigo mil veces:

Rafael Ontivero — Tue, 18 Dec 2012 15:26:00 GMT

Los elementos del DataTemplate en un FrameworkElement con DataBinding deben ser propiedades.

...

O en otras palabra, cuando uses el modelo MVVM (al menos en Windows Phone) los elementos de binding en la plantilla de datos deben ser propiedades aunque sean del tipo genérico.

Es decir en

<ListBox.ItemTemplate>

<Grid.RowDefinitions>

</Grid.RowDefinitions>

</Grid>

</DataTemplate>

</ListBox.ItemTemplate>

</ListBox>

tanto Name como Number deben ser propiedades y públicas.

Me da igual si está documentado en algún lado o no, pero me ha costado sudores darme cuenta. El objeto que se va a enlazar en la colección puede ser una clase o una estructura, pero debe ser pública sí o sí.

Ya os imagináis por qué estoy poniendo esta entrada, ¿no? :-P

Cross Threading en MVVM y Windows Phone 8 (y también 7)

Rafael Ontivero — Wed, 05 Dec 2012 10:42:07 GMT

Os cuento una rápida que seguro os va a solucionar un montón de quebraderos de cabeza y que me ha traído loco un rato hasta que me he dado cuenta del pufo.

Todo viene cuando estás usando el patrón MVVM y varías algún dato que se está mostrando en algún componente visual. Todos los tutoriales te dicen que heredes de ObservableCollection y que implementes el método NotifyPropertyChanged(). Y te ponen el típico ejemplo:

public event PropertyChangedEventHandler PropertyChanged;
private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
{
    var handler = PropertyChanged;
    if (null != handler)
    {
      handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

Hasta aquí nada extraño. Cuando una propiedad cambia su valor, quien quiera que esté observando tu colección se enterará del mismo y actuará en consecuencia. Eso si alguien está observando tu colección, que no siempre ocurre, sobre todo si hay algún converter de por medio (ya hablaré largo y tendido sobre esto).

Pero el problema viene cuando ese cambio se produce fuera del hilo principal de la aplicación, como suele pasar a poco que estés haciendo algo medianamente serio. No veo yo bloqueando tu aplicación mientras un servicio web o lo que sea se baja lo que se tenga que bajar, aparte de que en Windows Phone la mayoría de llamadas a todo eso son asíncronas.

Si haces un cambio en un hilo que no sea el de la UI, en Windows Phone 7.5 no pasa nada. Simplemente se ejecuta el código y en general tu colección cambia de valor y a veces, sólo a veces, la visualización cambiará. O no.

En Windows Phone 8 ocurre otra cosa no muy diferente. Recibes dos first chance de dos excepciones diferentes, el IDE no te captura nada a no ser que cambies la configuración de captura de excepciones y el hilo en el que se esté ejecutando el código se muere silenciosamente. Y por supuesto no se cambia nada en la parte visual de tu aplicación.

Vale. Tonto si no pones un bloque try/catch en cada hilo. Pero aquí estamos hablando de otro combate.

¿Cómo puñetas puedo actualizar eso de forma automática? Es decir, ¿tengo que hacer un BeginInvoke() cada vez que asigne algo? La respuesta corta es que sí. La larga es lo siguiente.

Primero tienes que crearte una propiedad nueva en la clase App que vas a llamar UiDispatcher (o como te salga de los OO):

internal static Dispatcher UiDispatcher=Current.RootVisual.Dispatcher;

Y luego cambia el código de arriba por el siguiente:

        public event PropertyChangedEventHandler PropertyChanged;
        private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
        {
            var handler = PropertyChanged;
            if (null != handler)
            {
                if (App.UiDispatcher.CheckAccess())
                    handler(this, new PropertyChangedEventArgs(propertyName));
                else
                    App.UiDispatcher.BeginInvoke(() => handler(this, new PropertyChangedEventArgs(propertyName)));
            }
        }

Ahora, si os fijáis, si el cambio de vuestra propiedad se realiza dentro del hilo principal, se llamará directamente, y si lo hace desde otro lo hará dentro del Dispatcher de la UI.

¿Por qué una propiedad y no llamar siempre a Current.RootVisual.Dispatcher? Pues porque podría interesarnos tener diferentes dispatchers para otras cosas, pero esa es otra guerra que hay que combatir en otro momento.

ReSharper para Visual Studio

Rafael Ontivero — Sat, 17 Nov 2012 12:55:10 GMT

Esta es una historia un tanto extraña porque ni en mis más locos sueños hubiera yo decidido usar este complemento en Visual Studio. No porque no me guste la empresa, ni porque piense que el producto sea malo.

Simplemente porque no soy yo mucho de añadir complementos a mi herramienta de trabajo más allá de las cosas imprescindibles, más que nada porque los tiempos de carga se alargan en extremo, y la estabilidad de Visual Studio decae en picado.

Por ejemplo, si ya la versión 2010 de VS anda algo inestable, con vahídos extraños, cuando le añades el SDK de Windows Phone la cosa empeora y te encuentras con que a veces el compilador se encuentra errores fantasma que sólo él ve, o simplemente el IDE se queda autista.

Añádele alguna herramienta más y eres un firme candidato a lanzar tu ordenador por la ventana y dedicarte a criar setas en el sótano de tu abuelo.

Sin embargo Visual Studio 2012 parece más estable, y he estado como dos semanas usándolo sin que hiciera cosas raras, incluso tras añadirle el citado SDK, que es imprescindible para mi en estos momentos.

De repente a un compañero que trabaja en la aplicación de Java de mi empresa le compraron el IntelliJ y comenzó a comentar las bondades del producto y cómo había pasado de desesperarse y tirarse de los pelos con la cosa esa del Eclipse a tener un IDE en condiciones.

Eso me llevó a recordar que cuando asisto a alguna charla virtual suelen regalar un ReSharper a los asistentes… y una cosa me llevó a la otra, y es que la envidia es tiñosa, y muy mala malosa, y yo soy el peor de todos. Por lo tanto entré en la web de JetBrains y me bajé el producto en su versión demo de treinta días y…

¡¡MADRE DEL AMOR HERMOSO!!

¡Como alguien me quite el producto me lo como con ropa y todo! ¿Cómo he podido vivir yo sin eso?

A ver, que no estoy exagerando ni mucho menos. El producto cuesta sus pelas, pero os aseguro que las vale. Ahora que estoy desarrollando en C# porque no tengo más cojones, se me ha hecho prácticamente indispensable y eso que lo llevo usando tan sólo unas dos semanas.

Os cuento lo que hace. Y ya me conocéis, que yo no me caso con nadie y no tengo pelos en la lengua.

***

ReSharper es una extensión a Visual Studio (creo que soportan todas las versiones del producto desde la 2003 menos las Express). En mi caso lo instalé en mi Visual Studio Ultimate de la MSDN.

Lo que hace el producto es ayudarte a teclear código, pero a todos los niveles. Hay que verlo para creerlo. Cuando está instalado lo que más llama la atención es que te coloca una tira vertical al lado derecho de la ventana de edición, similar a la de la derecha en donde pones los breakpoints, bookmarks y el IDE te marca el código modificado.

En esa columna te coloca una serie de rayitas horizontales de colorines. Rojo para los errores. Naranja para las mejoras (ahora os cuento), verde para las sugerencias. Creo que hay más colores, pero en este momento no me acuerdo (son las cosas de estar tirado en el sofá tecleando en mi MacBook). Arriba del todo hay una marca global que te dice el

Cuando posas el ratón sobre la rayita, te dice de qué va la cosa, y si haces clic te lleva al código fuente en cuestión.

Y aquí es donde viene lo interesante. Te ofrece la mejora o la solución, y si le dices que sí, te lo corrige.

Pero os aseguro que es algo terrorífico. Hay cosas más o menos chorras, como cambiar un tipo por una variable automática, pero otras dan miedo.

Es capaz de cambiar tus bucles for o foreach por sentencias LINQ. Con eso ya os lo he dicho todo. A mi al menos eso me da mucho miedo. Del bueno, ojo. Que coja tres bucles anidados y te los convierta en una sentencia LINQ de una línea me deja embobado.

Peor hay más. Simplifica los operadores lambda, te transforma bloques de código en otros menos agresivos con la aplicación, te formatea el código, te ofrece lo que vas a escribir a continuación…

No sé, cada vez que hago algo nuevo me sorprendo por las posibilidades que te ofrece. Otra de las cosas que me trae loco es que es capaz de eliminar código redundante, como la creación de delegados o la eliminación de código redundante.

Os pongo un ejemplo que me dejó todo loco.

Yo solía poner sentencias del tipo:

Debug.WriteLine(String.Format(“bla bla {0} bla bla {1}”,a.Hola,a.Adios));

Pues bien, él me sugiere

Debug.WriteLine(“bla bla {0} bla bla {1}”,a.Hola,a.Adios);

Vale. Tú lo sabes. Yo no lo sabía hasta que no me lo ofreció ReSharper. Y así con muchas cosas más, pero lo que de verdad me admira son las transformaciones a LINQ y viceversa. No me canso de repetirlo. Bucles a LINQ. Bucles a LINQ.

También tiene soporte en XAML. Es decir, editar XAML pasa de ser una pesadilla a ser bastante mejor. Si tu usas Blend, mejor para ti. Yo la última vez que intenté hacer algo con el producto terminé hasta la coronilla. Entre excepciones y la *** manía de ponerle márgenes hasta a su madre… Pues bien, con ReSharper editar a mano XAML también mejora la cosa.

Refactoring. Todo lo que te puedas imaginar y más. Si añadimos las reglas para estilo de código, te detecta las variables y los métodos que no lo siguen, ofreciéndote cambiarlos si así lo deseas. Y es una cosa a la que vas a decir que sí, porque esas rayitas naranjas no molan nada, y que no te las vea el jefe… :-P

Lo dicho, en cuanto te sales de las guías de estilo el producto no solo te lo dice sino que te ofrece la posibilidad de cambiarlo. Por supuesto puedes definir las tuyas, no las que el programa quiera.

Como abras la pantalla de opciones te vas a caer de culo, porque puedes configurar cualquier cosa. Por tener hasta tienes “juegos de configuración”, pudendo cargar la que quieras cuando quieras, por si tienes un proyecto con unas reglas y otro con otras.

También tiene algunas chorradillas (es un decir) interesantes, como que te pinta una raya de color debajo de un número que represente un código ARGB, por poner un ejemplo. Son cosas que no se echan en falta hasta que no las tienen y luego te las quitan.

Ya para terminar comentaros los Find Usages. Algo así como Find all references pero con muchos esteroides. Pones el cursor sobre un símbolo, le das a la opción con el botón derecho del ratón y goza. Así he encontrado un par de problemas serios de sincronización que me tenían todo loco, y encima en un rato de nada.

Opciones que no he probado han sido la de limpiar el código de toda la solución de una tacada y otras que seguro se me escapan.

Bueno, pues lo dicho, si quieres aumentar tu productividad de forma bastante seria, prueba el producto. Seguro que luego pasas por caja. Y si entráis en la Web de JetBrains podréis ver capturas de pantallas y algún vídeo enseñando lo que es capaz de hacer.

Viendo el código fuente de .NET con Visual Studio 2012

Rafael Ontivero — Sat, 15 Sep 2012 11:19:14 GMT

Quien tenga una versión anterior de Visual Studio seguro que sabe que se puede navegar por las tripas de .NET y ver cómo Microsoft ha implementado todo el tema. Pues bien, más o menos a mediados de agosto del corriente (2012) se anunció la disponibilidad del código fuente de .NET 4.5, lo que nos permite meternos en las tripas del Framework y, lo que es mucho más interesante, mirar cómo funciona todo lo nuevo relacionado con Windows 8.

El artículo citado da un somero repaso a las novedades no específicas de la biblioteca, entre las que se pueden destacar el añadido de métodos asíncronos en conjunción con las clases de tareas, y que ahora el jitter es capaz de optimizar el código para los procesadores multinúcleo. También se mejora el rendimiento de casi todo (como siempre dicen, lo que a veces no es cierto), y se potencia el acceso de .NET a nueva parte nativa de Windows 8 (o RT o Metro o como quieras llamarlo), que es código nativo escrito en C++ y C++/CX, permitiendo a este lenguaje acceder, también, a código escrito en otros lenguajes .NET gracias a su parte CX (que como ya he dicho varias veces, es nativa).

Como en otras versiones, el código fuente está disponible para descarga directa, o para ser visto desde nuestro propio código, y también como símbolos de depuración.

La captura de abajo nos muestra una aplicación Metro por defecto, detenida en un punto de interrupción, tal y como se ve en mi Visual Studio 2012 sin cambiar la configuración por defecto:

Fijaos en que la ventana de Call Stack estgá prácticamente vacía, y si hacemos Step Into simplemente saltamos a la siguiente línea de nuestro código fuente.

Vamos a habilitar la posibilidad de meternos dentro del código de Microsoft.

Nos vamos a TOOLS -> PROPERTIES, abrimos la pestaña lateral de Debugging, y cambiamos las siguientes opciones:

· Marcar Enable Just My Code

· Marcar Enable .NET Framework source stepping

· Desmarcar Step over porperties and operators (Managed only)

· Marcar Enable source server support

· Desmarcar Require source files to exactly match the original version.

Dejadlo todo más o menos como en la imagen:

Ahora, en la pestaña de Symbols, hay que añadir una nueva dirección de descarga de los mismos: http://referencesource.microsoft.com/symbols. Como en la capura.

Finalmente, cuando le deis a OK el IDE se quedará bajando ficheros. Hay que esperar a que termine, y dependiendo de lo rápida que sea tu conexión, tendrás que esperar bastante tiempo.

Con esta configuración, cada vez que se necesite algo, el IDE irá a los servidores de Microsoft, por lo que la carga y depuración de vuestro programa podría ser muy lenta a veces… por lo que se pueden bajar todos los símbolos de una tacada e instalarlos de forma local, apuntando la URL anterior a done los hayamos instalado. Podéis bajarlos de aquí.

La siguiente captura muestra algo de las tripas de Metro:

Vale. Ahora el tío de la rebaja. ¿Habéis intentado profundizar en el código fuente, en métodos como el Activate() de la primera captura? No entra, ¿verdad? No muestra código fuente, sino que simplemente salta sobre la llamada.

Un gallinfante a quien adivine por qué es.

Vale: es código nativo. Es decir, la parte Metro del .NET Framework no es código manejado, sino nativo. Es decir, está escrita en C++/CX, en donde la parte CX actúa como Sugar Syntax de todo el perifostio COM y COM+ que finalmente es .NET

Y todavía me atrevería a añadir algo más. Metro esconde en la manga algunos trucos de desarrollo que a MS no le interesa que se sepan, y ya visteis lo fácil que es hacer ingeniería inversa de una aplicación .NET. Si toda esa parte hubiera estado hecha con .NET, sería facilísimo meterle mano.

¡Y qué cojones, donde esté C++ que se quite cualquier lenguajucho de mala muerte! ;-)

No puedo editar las propiedades en XAML ("Property editing not available")

Rafael Ontivero — Tue, 11 Sep 2012 09:55:00 GMT

Ayer me pasó algo muy curioso con Visual Studio 2010SP1, y es que, de repente, el editor XAML se quedó tonto del todo y la ventana para editar las propiedades dijo que “Property editing not available”… y ahí se quedó el jodío, enseñando ese texto y nada más.

Y no, no estaba experimentando ni haciendo ninguna guarrería con el editor. De hecho estaba tecleando código en un BackgroundWorker que nada tiene que ver con la interfaz, y menos con la ventana (perdón, Page, que ahora ando con esto del Windows Phone) que falló.

La cosa era muy curiosa, porque el editor XAML funcionaba bien, y si dejabas caer algún componente sobre la ventana este se añadía sin problemas. Lo que no funcionaba era la ventana de propiedades.

En Connect hay recogido un bug que se supone fue solucionado en la RTM, pero yo acabo de comprobar que no ha sido así. Quizás hayan rebajado un poco la incidencia, pero sigue ahí.

De nuevo quiero reiterar que no toqué nada. Estaba en una ventana editando código e hice clic sobre la que mostraba el Page, dividida entre XAML y parte visual. Al redibujarse, el Page dio un salto él solo, pasando de 80% a 100% y todo dejó de funcionar.

En el citado enlace se dan varias soluciones, que a mi no me funcionaron. Incluso cerré y abrí el IDE, recompilé, volví a abrir todas las ventanas… Nada.

Lo único que solventó el tema fue limpiar la solución, cerrando el IDE inmediatamente después. Al abrirlo de nuevo, aparecieron un par de warnings y errores sin mucho sentido en relación a dicho Page. Una vez reconstruida la solución, todo volvió a la normalidad.

Lo dicho, aviso para navegantes y cómo lo solucioné yo.

Multiplataforma de la buena (mismo código fuente)

Rafael Ontivero — Tue, 03 Jul 2012 18:32:00 GMT

Antes de empezar, y de que me deis caña de la buena, quiero decir que todo esto son elucubraciones personales mías y que lo más seguro nadie esté de acuerdo conmigo. Dicho esto, vamos al meollo del asunto.

Ya sabéis que me he ido distanciando un poco de la plataforma Windows a la vez que me he acercado a la de Apple sin realizar el cambio total. De Linux no quiero hablar, porque cada vez que tengo que hacer algo con él, sudo tinta china y al final, tras muchos cabezazos, suelo terminar desistiendo.

Lo último fue compilar el SDK de lector del libros electrónicos Boox i62HD. Tras instalar una Debian 6 x86 virtual en vmWare Fusion (el Workstation del MAC) por segunda vez, ya que la primera falló estrepitosamente porque el instalador sí que reconoció el discos duro SCSI pero luego el kernel instalado no, fui incapaz de compilarlo.

Primero me encontré con una serie de paquetes que no estaban presentes y que el comprobador del SDK no avisó que faltaban, lo que te obliga a recorrer la cadena de errores para descubrir que te falta esto o aquello.

Lo último, y que todavía está sin solucionar, es que falta una dependencia en un fichero de proyecto, en concreto incluir “-l z” en el lugar correcto, que es enlazar con la biblioteca zlib. En mi caso el problema no es saber qué falta, sino dónde añadirlo. Tras varios intentos infructuosos y muchas páginas de internet leídas, no conseguí solucionarlo.

Había un bug similar si instalabas el SDK en un linux x64, pero el mío era x86, y el parche existente intentaba modificar ficheros que no existen (al menos en mi instalación).

Pues bien, ni me han hecho ni *** caso ni tampoco lo han solucionado, lo que me lleva a preguntarme cómo cojones están programando. Y menos mal que usé una Debian, que es la misma distribución que usan los que han creado el SDK, que si llego a instalarme otra cosa…

Esto es un ejemplo de la desidia reinante en Linux. Lo dije en un foro hace tiempo. Los programadores de linux me parecen muy poco profesionales, tendentes a montar cualquier cosa que les parezca c00l y luego, cuando viene la hora de la verdad y demostrar que se es un programador con dos cojones, pasan del tema porque eso de solucionar bugs ya no es tan fascinante como lo otro, y encima solventar cualquier cosa son un montón de horas en las que no estamos subiendo nuestra supuesta caché c00l en la comunidad.

Aparte de deleznable, me parece una práctica muy poco seria y que sigue dejando a Linux como lo que es: o bien un juguete para niños falsamente interesantes, o bien algo destinado a servidores de bajo coste, y si no contadme cómo es el único sistema operativo que ha reventado con el segundo extra añadido hace unos días.

Por lo tanto, para mi el desarrollo en Linux queda completamente descartado a corto y largo plazo, por lo menos hasta que se pongan un cohete en el culo, cosa que dudo mucho que ocurra jamás (y espero equivocarme).

***

Luego vino el tema del swtiching. Lo cierto es que tras el entusiasmo inicial, la cosa deja mucho que desear en cuanto a usabilidad y, sí, rendimiento. Ya lo he ido comentando por este blog con anterioridad. OS X Lion y Mountain Lion, si los comparamos con XP, son la rehostia, pero comparados con Windows 7 dejan mucho, pero mucho que desear. La usabilidad es pésima, aparte de ciertos problemas de ergonomía a los que al final uno termina acostumbrándose.

También es cierto que cuando le coges el tranquillo ya no hay vuelta atrás, más que nada por la integración de todos los elementos, más todavía si tienes un iPad o un iPhone. Puedes conseguir casi lo mismo en Windows, pero no de forma tan integrada ni coherente.

Respecto al rendimiento, diré que por fin tengo un MAC que funciona como yo quiero, tras gastarme más de 300 euros en añadirle un segundo disco SSD al iMac de 27”. Es decir, en este momento mi máquina principal es un iMac de mediados del 2011 con un i7 a 3.4 GHz, un disco SSD de 256GB como disco de sistema para el OS X y uno de 1TB como secundario para datos. En este momento el disco FireWire de 2TB que usaba como secundario lo tengo como copia de Time Machine y, aparte de que arranca en 8 segundos (antes tardaba más de dos minutos y el disco seguía rascando hasta casi los diez), sólo veo la roseta multicolor de la muerte cuando se para el disco mecánico y tiene que arrancar. Además, la carga de aplicaciones, incluso las pesadas como Pages o Word, es prácticamente instantánea.

Y justo ahora, mientras escribo esto en Scrivener, tengo abierta una máquina virtual en Unity con Windows 7 x86 en la que se está instalando el SP1 de Visual Studio 2010 porque he instalado el AtmelStudio, que es un IDE basado en el Microsoft para generar ejecutables para los microprocesadores de Atmel.

***

Acabo de hacer una pausa para lanzar el JTAG MK-II, conectarlo a Windows y verificar que el AtmelStudio lo reconoce y funciona, todo ello virtualizado. Que es una de las cosas a las que quería llegar. Con un buen producto de virtualización, uno puede tener lo mejor de ambos mundos. Un equipo silencioso a más no poder que ejecuta de forma transparente tanto aplicaciones Windows como OS X sin mayor complicación que molestarse un poco en configurar las cosas, y encima con un rendimiento equivalente a si se ejecutara en real.

Evidentemente tenemos BootCamp, pero os aseguro que Windows no funciona igual que en un PC real, y perdemos todas las cosas buenas que puedes hacer con un MAC.

***

Pero no es a eso a lo que me refiero. Más bien todo esto es una especie de parche o pegote. De lo que realmente quiero hablar es de desarrollar para al menos Windows y MAC sin tener que crear dos programas diferentes.

Descartamos de entrada que un mismo ejecutable pueda funcionar en ambas plataformas. Por parte de los dos contendientes queda descartado. Microsoft podría haber hecho .NET para OS X o Apple Cocoa para Windows, pero no creo que eso vaya a ocurrir nunca jamás.

La única posible solución es Mono, pero ignoro sin un EXE de Windows se lanzará en un MAC o no, y lo voy a descartar por razonamientos que expondré más adelante.

***

Por lo tanto, la otra posible solución es compatibilidad en el código fuente. Que yo conozca, sólo tenemos dos grandes contendientes: QT y lo que ahora es Embarcadero pero que todos conocemos como Delphi y/o C++Builder.

De QT he hablado ya por aquí, pero no como plataforma cruzada. He estado usándolo un poco, en un proyecto en donde trabajaba, pero sólo para generar aplicaciones Windows.

En principio QT es multiplataforma si no te sales del propio Framework, y de hecho he podido compilar un mismo código fuente en ambas plataformas sin más que compilar o bien desde Windows o bien desde OS X. Hay que tener mucho cuidado y usar el propio Creator de QT, y todos los ficheros servirán sin problema. Eso sí, necesitas dos ordenadores, uno para cada plataforma. Tres si quieres también Linux.

Esto nos trae a lo que hemos tratado antes. Como no es posible ejecutar OS X desde una máquina Windows (no sin violar licencias y sin hacks y sin limitaciones y fallos aleatorios), la única solución es tener un MAC más o menos potente y usar un Windows virtualizado, compartiendo la carpeta de desarrollo.

En mi caso, pese a no estar haciendo nada más que estudiar ahora que estoy en paro y tengo tiempo para jugar con todo esto, tengo una carpeta en donde está todo mi código fuente, carpeta que está compartida con SkyDrive y de ese modo puedo verla también en mi ordenador Windows (no el virtualizado), aparte de hacer copia de seguridad de forma automática.

Ojo con sincronizar mediante SkyDrive entre real y virtual, porque el tema no es instantáneo y puedes armar un buen jaleo. La solución es compartir una carpeta de tu MAC en tu Windows virtual. Con Fusion la cosa funciona muy bien, y hasta Embarcadero ha solucionado los problemas que tenía para compilar sobre carpetas de red (Microsoft siempre lo ha tenido resuelto, incluso dando la posibilidad de cachear localmente los ficheros intermedios).

Si nos damos cuenta, con QT tenemos que compilar y ejecutar en cada máquina, lo que en principio no es un gran problema, pero sí cuando quieres algo que no está en el Framework. Ahí si que tienes que, mediante compilación condicional, sacarte tu mismo las castañas del fuego. Dada mi escasa experiencia con QT multiplataforma, no puedo asegurar si es algo muy habitual o no.

***

El otro participante es Embarcadero, con su FireMonkey bajo Delphi/C++ Builder. La historia de todo esto es un poco rocambolesca, ya que la empresa ha llevado muchos años implementando compilación condicional en su VCL. Sólo hay que mirar el código fuente de cualquier versión (creo que desde la 2009) y ver cómo muchos ficheros tienen secciones para Windows, MAC y Linux.

Uno, por tanto, se esperaba que cualquier día anunciaran que la VCL se había convertido en multiplataforma y que se podría compilar para estos tres sistemas operativos.

Pero no, Embarcadero compró un producto a medio hacer y en seis meses lo transformó en su FireMonkey, que anunció a bombo y platillo con su nueva versión de RAD Studio XE2. Que por cierto se encuentra completamente lleno de bugs y no hay entrada de blog explicando esta o aquella característica que no hable de que hay un problema y que han tenido de resolverlo de alguna manera. Y es que seis meses es muy poco tiempo.

FireMonkey es una gran idea implementada muy pobremente. La idea es usar el IDE de Delphi o de C++ Builder para, a partir de un mismo código fuente, generar un ejecutable Windows o MAC, pero siempre desde Windows, por lo que estamos ante el mismo problema que antes.

La ventaja aquí es que puedes hacerlo todo desde Windows, hasta depurar. Es decir, es necesario instalar un servidor en el lado MAC, servidor que te va a permitir enviar el bundle OS X al MAC y depurarlo.

Y como todo primer producto, está completamente lleno de bugs y da muchos problemas, tanto el IDE como la depuración remota y el framework en sí. Embarcadero lleva sacados cinco parches, uno de ellos tan grande que exige reinstalarlo todo, que mejoran algo pero no mucho.

Y para más INRI, son aplicaciones de 32 bits, cosa que en los MAC se está acabando a pasos agigantados.

Esperemos que el XE3, que saldrá este verano, mejor algo la cosa.

***

Nos falta comentar Mono, el C# multiplataforma y de código abierto. Ya he hablado algo de él aquí con anterioridad, pero ahora voy a matizar un poco más. Mono engloba una serie de tecnologías más o menos integradas que comparten un mismo lenguaje de programación: C#.

Basado en ports, todo el meollo se centra en un IDE (disponible para ambas plataformas, como el de QT) que permite crear aplicaciones basadas en los ya citados ports, de los que disonemos de varios según qué plataforma.

Por un lado tenemos el de Windows.Forms, que nos permitirá generar código compatible con la tecnología de Microsoft y ejecutar en Windows, MAC y Linux. GTK# es otro de ellos. También está MonoMAC, en exclusiva para MAC. Hay más pero nos detenemos aquí.

La idea es que cada port conserva la idiosincrasia de cada origen. Es decir, el API de GTK# es el GTK pero traducido a C#, y así con todos. Es una buena idea y en general, se puede generar código para Windows y MAC sin problemas mayores que los que tendríamos con QT.

***

Pero ahora viene el tío de la rebaja. Hemos visto algunas pegas que tienen todos estos sistemas de desarrollo, pero no son las peores de todas. De todos modos, si desarrollas para MAC necesitarás un MAC, y lo mismo para Windows, así que llevar a cabo esas tareas en ambas máquinas no es todo lo malo que se puede esperar, y de hecho en todos los casos existen soluciones bastante óptimas, aunque lo más deseable sería el acercamiento de Embarcadero, con compila en un sitio, ejecuta en dos.

La mayor pega de todas consiste en que prácticamente ninguno de estos sistemas pinta los controles como nativos. QT podría salvarse por los pelos, pero ni FireMonkey ni Mono, salvo MonoMac, aparecen como aplicaciones nativas. En la documentación de algunos productos la llaman hasta “alien”. Ya os podéis imaginar. Y si bien en Windows un usuario normal puede aceptar ciertos interfaces exóticos, un fanboy (perdón, maquero) de pro seguro que te manda a la mierda con todas sus palabras, y encima con razón.

El caso de MonoMac no se aplica, ya que no podremos compartir código fuente con Windows puesto que se trata de un envoltorio sencillo sobre el propio Cocoa con la idiosincrasia de OS X.

Por lo tanto, el único Framework que sé de forma fehaciente que ha entrado en la App Store de los MAC ha sido QT tras aplicar unos parches para evitar que el propio QT modificara ficheros dentro del bundle. De todos modos no sé qué pasará con el Sandboxing y si QT (y los demás) lo soportan.

Finalmente, está completamente claro que, a fecha de hoy, desarrollar en multiplataforma de manera coherente continua prohibido, principalmente por limitaciones de los Frameworks existentes que de problemas técnicos, dado que el rendimiento y las herramientas base (como compiladores de plataforma cruzada o lenguajes comunes en diferentes plataformas), están más que maduros.

Tan sólo habría que crear un Framework que utilizara los controles nativos de cada plataforma, cosa que a fecha de hoy no existe (más sobre esto luego).

***

¿Qué nos queda, pues? Tan sencillo y tan complejo como dividir nuestra aplicación en dos partes. La primera, la parte visual, tendremos que hacerla diferente para cada plataforma. Objective-C en MAC, Win32 (MFC, o cualquier otro que pinte nativo), y la parte no visual o el núcleo de nuestro programa en algún lenguaje común, como puede ser C++ y STL y mantener al loro todo el tema para que compile y funcione en todos los sistemas de destino…

Es más trabajo, pero creo que es la única forma de mantener un interfaz visual nativo y coherente. El problema viene cuando nuestra aplicación es demasiado simple de modo que mantener esta estructura es más costoso que crear dos programas de forma independiente.

Aparte, claro está, la bajada de rendimiento al tener que desacoplar ambas partes, aunque esto es muy bueno y debería ser una constante en cualquier desarrollo no trivial, aunque estemos haciéndolo solo para Windows o sólo para MAC. No obstante, a veces la caída de rendimiento es tal, o el programa es tan meramente visual que este acercamiento no es aplicable.

***

Si os dais cuenta no he entrado en el tema de código abierto versus código cerrado, y es que para el programador medio, se la trae floja si tiene el fuente o no de lo que esté usando: no lo va a mirar porque o bien no tiene tiempo o bien no está capacitado.

Tampoco he cubierto el tema Metro de Windows 8, que está de lado del tema móvil, en el que no he entrado pese a haber también Frameworks genéricos. Aquí estamos igual, pero ahora las plataformas son Windows Phone, Windows Metro (o RT), Android e iOS, y si las de Windows y MAC son disparejas, no os digo estas. Y, a fecha de hoy, que yo sepa, no hay ningún Framework multiplataforma y compatible. FireMonkey promete llegar a Android, Metro y a C++ en próximas versiones, pero si ya con dos plataformas la cosa está como está, no quiero saber cuando haya tantas…

***

Me falta hablar de un jugador que no he nombrado y que tiene muy buena pinta, quizás la mejor de todas pero, como apenas lo he probado, lo dejo para una futura entrada. Se llama wxWidgets y hace tiempo que hablé de él aquí, pero para Windows. Estamos ante un Framework con mucha solera en el mundo del desarrollo y que usan empresas como Google en su producto Google Drive a través de wxPython.

Y la mayor ventaja está en que, aparte de estar disponible para alguna que otra plataforma embebida, los controles son los nativos de cada sistema operativo.

***

QT en Windows y OS X (Fijaos cómo los controles son casi nativos en cada sistema).

FireMonkey en Windows y OS X (Esto no pasa la MAC App Store ni a golpe de talonario. Por no aparecer ni el menú aparece donde debe).

WxWidgets en OS X (Todos los controles son nativos).

Visual C++ 2012 soportará Windows XP

Rafael Ontivero — Fri, 15 Jun 2012 20:49:28 GMT

Dicho así, a bote pronto, puede parecer una tontería, pero no lo es. Los que hayan estado probando las diferentes versiones alfas, betas y omicrones de Visual C++ 11 se habrán dado cuenta de que no generan código para Windows XP.

El motivo no era otro más que se han hecho una serie de mejoras al runtime de C++ (ya sabéis, la biblioteca de C y de C++) que se basan en una serie de funciones de Win32 que no están presentes en Windows Xp y sí en Vista y siguientes.

La respuesta fácil sería decir que han hecho eso para empezar a ir descartando a XP como sistema operativo soportado y forzar que los nuevos programas no funcionen con él, pero a la vista de las noticias no ha sido así. De hecho, hace poco tiempo alguien publicó la forma de soportar XP con las versiones beta ya publicadas mediante un truco. No me preguntéis cómo porque no lo he mirado.

Independientemente de eso, cuando un programa debe ejecutarse en un sistema que no tiene todas las importaciones de, por ejemplo, Kernel32.DLL, lo que hace es realizar una carga parcial o suministrar funciones dummy para que el sistema funcione. Es decir, si por ejemplo el runtime de C++ llama a una supuesta función de Kernel32.DLL llamada UnaFuncion() que no está en, digamos, XP pero sí en Windows 7, lo que se hace es, o bien esas se marcan como delayed (retardadas) y sólo se cargan manualmente una vez que el runtime ha comprobado que el sistema operativo la posee, o bien se suministra una vacía o con emulación.

No me preguntéis más porque realmente no sé cómo se hace ya que nunca me ha hecho falta, y tampoco sé si está documentado de forma oficial o no, pero es un mecansimo más o menos conocido que usa al menos la propia Microsoft para soportar sistemas operativos obsoletos y no tener varios juegos de ficheros.

***

Y ya que estamos en el tema, os comento otra cosa. Hace unos días se anunció que las versiones Express (todas) de Visual Studio 2012 sólo soportarían crear aplicaciones Metro en Windows 8 y que, si queríamos escritorio, deberíamos seguir usando las 2010 para ello.

Hablamos, claro está, de las gratuitas. La versión Professional y superiores sí que iban a poder crear ambos tipos de aplicaciones, y todo bajo un mismo IDE tal y como estamos acostumbrados.

[Para los despistados, diré que con las versiones Express, si uno necesita crear un proyecto mixto, digamos una DLL hecha en C, C++ ó C++/CLI para que luego una aplicación en C# la use, tienes que instalar los productos por separado y manejar cada tipo de proyecto también por separado, y nada de depurar y saltar de código manejado a nativo y viceversa. Con las versiones de pago todo está en un mismo IDE y se pueden manejar de forma conjunta].

En principio la imposibilidad de crear aplicaciones de escritorio con la Express 2012 puede parecer trivial ya que tenemos las 2010, pero lo cierto es que perdemos muchas mejoras en todos los lenguajes. Podría citar como ejemplo los métodos asíncronos en C# y toda la nueva parafernalia del C++11 para C++, que no es poco.

Pero ha sido tal el clamor popular (y no tan popular, porque algunos MVP le han dado caña de la buena a MS -no, esta vez yo no he movido un dedo), que Microsoft ha reaccionado y va a sacar una versión 2012 Desktop para crear aplicaciones de escritorio.

Es decir, que vamos a tener al menos dos C# Express, dos C++ Express y demás, una para aplicaciones Metro y otra para escritorio. Y lo que es mejor, las versiones escritorio creo, y digo creo porque no lo tengo claro, va a ser un solo IDE que va a soportar todos los lenguajes como las versiones de pago…

***

Enlaces originales:

MonoTouch: muy bonito pero una guarrería

Rafael Ontivero — Wed, 30 May 2012 09:17:01 GMT

Ayer estuve jugando un poco con MonoTouch, más que nada por curiosidad. Para los que no lo sepáis, es un IDE más una biblioteca que envuelve de forma conveniente todo el desarrollo para iOS, tanto iPhone como iPad y que permite a un programador de C# desarrollar para estas plataformas sin tener que aprender nada de Objective-C y demás zarandajas.

Es un decir, porque realmente no es más que un envoltorio fino a todo eso. Por lo tanto, si estás desarrollando para Windows o Silverlight, no esperes sentarte y ponerte a ello porque aparte de usar la sintaxis de C#, todo lo demás es iOS. Incluso se usa el IDE de xCode para crear los elementos gráficos y su interactuación, como son los outlets (propiedades) y las actions (los eventos).

La ventaja es que al ser una capa fina apenas introduce sobrecarga y todo es nativo. El inconvenientes es que tienes que aprenderte todas las idiosincrasias del iOS.

Y otra cosa que no me creo mucho es el tema de la compartición de código. No esperes tener el mismo código fuente de tu aplicación y compilar para Android, iOS, OS X y Windows. Podrás compartir bloques de código, pero nada más.

***

Otra cosa es que estas herramientas son de pago. Desde 400$ la más barata hasta viarios miles de dólares. Depende de qué quieras y cómo. Las versiones gratuitas para Android e iOS no caducan pero sólo permiten ejecutar código en el simulador.

Las versiones para escritorio son completamente gratuitas.

Se me olvidaba decir

***

Ahora bien, como decidas desinstalar algo… arreglado vas. Aparte de que no hay desinstalador, los procesos para hacerlo son completamente insuficientes y te dejan el sistema hecho unos zorros con miles de archivos desperdigados por todo el disco.

Versiones anteriores traían un desinstalador embebido dentro del PKG que realizaba la instalación, pero al menos la que yo he instalado no lo trae.

Primero ejecuta los comandos descritos aquí. Eso te va a limpiar digamos que las partes públicas del entorno. Y si tienes la última versión de xCode instalada, te puedes cargar la carpeta /Developer de un plumazo sin problemas porque sólo tendrás el Mono de los cojones en ella. Pero antes de hacerlo, míralo por si acaso.

Una vez pasado ese script, si te pica la curiosidad, haz una búsqueda global con la palabra “mono”.

En mi caso he usado CleanMyMac para limpiar el ordenador de basura, pero tu puedes hacerlo a mano o con otra herramienta. Ojo con los ficheros que no son del mono.

Finalmente tenemos que desinstalar MonoDevelop. En mi caso, de nuevo con CleanMyMac.

Y creo, sólo creo, que tengo limpio de nuevo el sistema.

Hay que joderse.

Ocultación de datos y paso de variables

Rafael Ontivero — Tue, 24 Apr 2012 09:45:00 GMT

Leo en Twitter un par de preguntas más que curiosas sobre dos cosas que se dan por supuestas en el desarrollo orientado a objetos. Aunque una de ellas está formulada al revés, yo aquí le voy a dar el sentido correcto, e intentaré responder, en la medida de mis conocimientos, a ambas.

***

La primera de ellas es “¿por qué las variables de una clase no deben ser públicas?”

Es una de las primeras cosas que nos enseñan en la POO. Extendiendo la pregunta al ámbito completo, el concepto se conoce como “ocultación de datos”, y se extiende no sólo a las variables de clase, sino también a los objetos en sí y en general al programa completo.

Por poner un caso extremo, en la mayoría de Frameworks serios, el punto de entrada de un programa cualquiera debería ser:

MiApp theApp;

theApp.Run();

Vale, es un poco extremo, pero a ese nivel es lo que necesitamos: una aplicación, y que la vamos a ejecutar. No nos hace falta nada más ni tenemos que conocer nada más a ese nivel.

Es decir, uno de los motivos de la ocultación de datos es dar a conocer únicamente lo estrictamente necesario, y de hecho no nos importa si theApp tiene una variable llamada Juanito o Pepito porque no tiene utilidad conocerlo a ese nivel.

Y de hecho no nos interesa que nadie sepa la estructura interna de MiApp porque sencillamente ahí no podemos y no debemos hacer nada más que ejecutar el objeto que es la representación en memoria de nuestra aplicación. Quizás, o bien en el constructor o bien en el método Run(), pasar los argumentos con los que ha sido llamada la aplicación, pero sólo si es pertinente y nos interesa.

La regla nos dice que si no lo necesitamos a ese nivel, no lo hagamos público. Pero claro, todavía no he explicado por qué. Simplemente he definido la regla: oculta todo lo que puedas.

Jorge Serrano, respondiendo en Twitter, lo ha dicho bastante claro: No te interesa que nadie te pueda cambiar los zapatos sin tu consentimiento. Yo diría que cada perro debe lamerse su pijo, expresión más castiza. Imagina que vas andando por el monte, y alguien te cambia tus botas de trekking por unas chanclas de playa sin tu consentimiento… O que estás en una reunión de alto copete y una chavala empieza a esto…, lamerte el tema…

Reformulado en código, y retrocediendo un poco, la idea es bastante interesante.

En la programación procedural clásica (es decir, C y similares), y tal y como lo dijo Stroustrup en no recuerdo qué lugar, un programa es un conjunto de funciones que menean un conjunto de datos.

En teoría, cualquier función podría tocar cualquier dato. Digo en teoría porque en C y similares también hay métodos, más primitivos, para ocultar datos. Quien haya desarrollado aplicaciones más o menos grandes con esta filosofía, se habrá encontrado con serios problemas:

Métodos que cambian datos que no deberían cambiar.
Datos que deberían ser diferentes pero que por un despiste tienen el mismo nombre y que son combinados por el enlazador como uno solo.

Poniéndolo en otras palabras: se pueden dar situaciones en las que la modificación de un dato genere efectos laterales que terminen en un comportamiento no deseado, o incluso generar una onda de interferencia que termine tumbando la aplicación.

Lo mismo podría pasar con dos variables que accidentalmente han sido nombradas igual. Un compilador moderno debería avisar de este último caso a nivel de enlazador, y en general, al menos con Visual C++, así ocurre. Otra cosa es que el programador novel le haga caso o se dé cuenta del aviso. Y no todos los compiladores notifican de este hecho, sobre todo los de plataforma cruzada para sistemas embebidos, que suelen ser bastante antiguos.

Volviendo al tema central, la OO intenta solucionar este problema con las clases y la ocultación de datos. Es decir, una clase es una serie de métodos que definen cómo tocar a una serie de datos de forma auto contenida. Y hasta la fecha es la mejor solución que se ha podido encontrar, y si alguien conoce alguna mejor (que no sea una paja mental), le vaticino los laureles del éxito más absoluto y arrollador.

En otras palabras: una clase es una entidad con un comportamiento definido por su código y es algo opaco a cualquier cosa que intente ver su interior excepto un interfaz público que sirva para tratar con ella.

Y hay varias razones, todas ellas muy poderosas, para que esto deba ser así, lo que lleva implícito una serie de obligaciones: ocultación de datos, interfaz pública y autocontención. Otras características como polimorfismo extienden pero no obligan, por lo que las vamos a obviar.

Volviendo al ejemplo de los zapatos, pensemos en un objeto zapato genérico. Cuando construyamos una persona, a la clase persona le añadimos dos objetos zapatos (que podrían ir en un array, pero no es imprescindible).

Y ahora viene el truco del almendruco. Atarse los cordones. Podemos hacerlo de varias formas.

La más chapucera es acceder al método miembro cordón de cada zapato y atarlo, ejecutando una serie de acciones (código) sobre dichos cordones. Para ello necesitamos que cordón sea público.

¿Pero qué pasa si tenemos varios tipos de zapatos? Por ejemplo, unos que lleven hebillas. Ups. El código para atar zapatos que está en la clase persona ya no nos sirve…

Si embargo, si definimos un zapato padre que tenga un método llamado AtarCordones() y que internamente use el dato miembro cordón para realizar la misma operación que antes hacíamos desde la clase persona, cuando heredemos de dicho zapato una nueva clase llamada sandalia, tan sólo tendremos que redefinir el método AtarCordones() que, en lugar de usar cordón, usará hebilla y una serie de acciones con ellas.

Y lo que es más importante, la clase contenedora, persona, se desentiende de qué zapato tenemos, de si tiene hebillas o cordones. Simplemente llama a zapato.AtarCordones() y la acción estará hecha.

[Hablando más seriamente, deberíamos tener una clase base virtual llamada, por ejemplo, ZapatoGenérico que defina un método virtual llamado AtatCordones(). Y luego deberíamos heredar de ahí el Zapato normal y la Sandalia. Y quizás otras variantes de calzado.]

Por lo tanto, al ocultar los datos internos y dejar una interfaz pública, ganamos muchas cosas:

Los objetos que manipulen nuestro objeto lo harán a través de una interfaz definida y que debe ser siempre la misma (con la salvedad de los pasos de refactorización que sean necesarios y que cambien los nombres o la propia interfaz).
El punto de arriba mejora la claridad del código,
Nos evita tener que depurar los objetos llamadores porque no ha cambiado nada en ellos,
Nos permite cambiar el comportamiento interno del objeto manipulado sin tener que preocuparnos de la clase manejadora,
Permite el efecto biblioteca (comentado por Herb Sutter en su Rationale a C++/CLI, que su vez lo toma de Stroustrup): podemos meter la clase Zapato en una biblioteca, y podremos cambiar su comportamiento interno sin tener que recompilar el código que la use,
Oculta la visibilidad, permitiendo un código mucho más limpio y con menos interferencias y símbolos globales, que al menos en C++ pueden lentificar la compilación en grado sumo.
Acelera la carga en tiempo de ejecución, porque el cargador del sistema, al tener menos símbolos públicos, tiene que inicializar y relacionar menos cosas.

Vale, creo que no se me escapa nada, y si lo hiciera, con los puntos de arriba hay suficiente.

Todo esto nos lleva a una serie de reglas de diseño con las clases que, al menos yo, llevo a rajatabla:

Oculta todo lo que puedas.
Usa el nivel más cerrado posible: private en C++ para todo lo que puedas. Luego, cuando refactorices y necesites que algo sea conocido por clases hijas, pásalo a protected, pero con sumo cuidado ya que si hay (o se quiere) efecto lateral, mejor pon un método protegido en el padre que pueda ser llamado por el hijo para acceder a ese miembro privado.
Define interfaces públicos, pero los menos posibles. Si un zapato no va desatar los cordones, no lo definas. Si lo necesitas, ya lo definirás. (Aquí hay que mantener cierto equilibrio, porque si sabes que lo puedes necesitar, mejor lo declaras pero no lo defines –cuerpo vacío-, ya que podría ser peor luego tener que cambiar la interfaz ya definida y usada).
Documenta por qué, no cómo (el cómo ya te lo dice el propio código, a no ser que sea algún algoritmo complejo, y en ese caso en el 99% de las veces seguro que se puede hacer de otra forma más sencilla).

Finalmente esto nos lleva a un problema que plantea mucha gente, y es que toda esa ocultación y esos métodos de acceso pueden volver un programa extremadamente lento.

Os lo puedo asegurar: eso fue en tiempos pasados, cuando los compiladores eran animales mitológicos y se sabía poco sobre ellos. Ahora, cualquier compilador medio decente se va a comer tus miles de líneas de código en un santiamén y va a generar mejor código que el que tu pudieras hacer a mano saltándote todos esos pasos. Al menos en C++ y quiero creer que también en C#.

***

Bueno, ahora viene la segunda pregunta, que reformulo pues está planteada con los conceptos cambiados: “¿Alguno sabe la razón de por qué las variables se pasan por valor y los objetos por referencia?” Hablamos de C#, ya que en C++ y C++/CLI podemos pasarlos como nos salga de la pepitilla…

Para responder a esta pregunta debemos meternos un poco en cómo funcionan los compiladores.

Una variable nativa, digamos un entero, ocupa 4 bytes (por decir algo, todo depende de dónde ejecutemos). Un objeto ocupa tanto como la suma de sus datos miembro y una o varias vtable en caso de que tenga métodos virtuales y del nivel de anidación de la herencia (así como de lo bueno que sea el compilador).

[Una vtable es un array de punteros a función que, en tiempo de ejecución, determinan qué método se va a ejecutar dentro de un objeto con métodos virtuales. Un buen compilador resumirá esto en cambiar un call directo a un call indirecto en base a un índice almacenado en algún lugar.]

Cuando nosotros definimos una clase, y a partir de ella instanciamos un objeto, el compilador (y en tiempo de compilación) hace un pase de manos y agrupa todos los métodos miembro en un bloque que junta con los demás métodos miembro de las demás clases, añadiendo unas firmas especiales a los nombres de función.

Digamos que una vez compilado, un programa OO se convierte en un programa no OO que tiene una serie de funciones globales que acceden y modifican una serie de datos… ¿Os suena, verdad? Es que es la única forma de hacerlo, os lo puedo asegurar. La ventaja está en que, salvo oscurísimos errores del compilador que cada vez ocurren con menos frecuencia, a todos los efectos, el comportamiento final simula ser completamente orientado a objetos.

Bueno, cuando pasamos parámetros en una llamada a método, el sistema usa una pila, que es un área de la memoria especialmente destinada a las tareas descritas.

No vamos a entrar en detalles técnicos, pero la cosa funciona así: el compilador pone en la pila los datos a pasar, copiándolos quizá de otro punto de la pila. Entonces hace un call en ensamblador a la función que hemos llamado, y cuando entremos en ella, sabrá que en la cima de la pila tiene sus parámetros.

Cuando pasamos un parámetro por valor, estamos copiando dicho valor en la pila. Si es un entero, ocupará 4 bytes. Si es un objeto, ocupará tantos bytes como datos miembro tenga (ojo, sólo los datos, no el código), más las tablas virtuales más algún que otro elemento más que hace la función de metadatos del objeto pasado.

Si el objeto ocupa 10 bytes, se copiarán, y si ocupa 100, 1K o 100K, se tendrán que copiar absolutamente todos los bytes. Dependiendo de qué objeto, la copia podría ser onerosa en tiempo de ejecución y gasto de memoria.

Cuando pasamos un objeto por referencia, estamos pasando un puntero al dato. No importa en qué lenguaje estemos, siempre es un puntero. Todo lo demás lo hace el sugar syntax del lenguaje, que nos endulza la sintaxis y el operar con ellos.

En este caso, de media, una referencia a un objeto en C#, y si no lo han cambiado, ocupa unos 10 bytes independientemente de qué tamaño real tenga el objeto en sí.

Por lo tanto, ahora vemos por qué en C# un objeto se pasa por referencia y un tipo nativo por valor: optimización.

Esto genera una serie de idiosincrasias en C# que al menos a mi no me gustan mucho, ya que estamos obligando al programador a que lo haga al estilo del lenguaje y no como uno quiera (ya sabéis, eso de “programar en” y “programar con”).

La optimización es la adecuada para la mayoría de casos, pero a veces querríamos hacerlo de otra forma, y es cuando uno ve las limitaciones del lenguaje. En el caso que nos ocupa, un objeto no se puede pasar por valor, lo que fuerza a copiarlo a mano si vamos a modificarlo y no queremos que el original sufra cambios. Y a veces eso es difícil, ya que en algunos casos la copia es de nuevo por valor y no se produce la mutación a nuevo objeto cuando modificamos la referencia creada, y no podemos hacer nada porque el C# (y el .NET) son así.

Sin embargo sí que podemos pasar un tipo nativo por referencia, añadiendo ref al parámetro (con lo cual modificaremos su valor desde dentro de la función llamada). No obstante, la implementación es una chapuza como un castillo, ya que la cosa funciona así dadas las severas limitaciones de la máquina virtual .NET: El valor a pasar por referencia se copia al montículo (heap en inglés, que es donde se guardan los objetos y demás elementos instanciados por referencia) y entonces se pasa, en la pila, una referencia a ese valor puesto en el montículo. Cuando salimos de la función llamada, el sistema coge del montículo el valor modificado y lo vuelve a poner en la pila.

Es lo que se llama box/unbox, y viene determinado por la limitación del .NET de acceder a la pila cuando el elemento a tocar no está encima de ella. La única ventaja que obtenemos de esto es que es mucho más difícil generar una inyección de código mediante el envenenamiento de los parámetros de retorno de la pila.

***

Para aquellos que quieran tener una visión más amplia de la orientación a objetos, así como muchas explicaciones, les recomiendo el libro de Bertrand Meyer, Construcción de software orientado a objetos Segunda Edición, que es un tocho de más de mil páginas denso como él solo… Pese al proselitismo hacia Eiffel, es un gran libro. Hay edición en castellano de Prentice Hall (que es la que yo tengo), pero no sé si se podrá encontrar o no.

Otro no menor pero más práctico, es Code Complete 2 de Steven C. McConnell. Este es mucho más práctico y orientado hacia el código real que escribimos las personas normales.

Windows Phone y las petisoperías

Rafael Ontivero — Thu, 12 Apr 2012 07:45:58 GMT

Hay que joderse, que dijo aquél. Este podría ser el resumen de esta entrada. Ahora mismo veréis por qué.

***

Estoy empezando a jugar de forma más o menos seria con Windows Phone. Ya cuando salió, el no poder ejecutar código nativo básicamente me hizo pensar que Microsoft había perdido el tiempo y que WP iba a ser un gran y nuevo fracaso de la compañía que había perdido el norte, el sur, el este y el oeste…

Pasa el tiempo y pese a todos los intentos de MS, WP no levanta cabeza. Ni cuota de mercado ni aplicaciones, comparándolo con Android e iOS, que crecieron mucho más rápido.

Ahora sé algunas razones, imposibilidad de usar C++ incluída.

***

Windows Phone 7.0 no tiene sockets. Toma ya. Increíble. Para los legos: no hay posibilidad de crear ningún tipo de aplicación de chat, ni de comunicación remota a servidores ni nada parecido. Todo hay que hacerlo mediante HTTP, que no conserva el estado y necesita sobredimensionar el lado servidor frente al cliente…

Whidows Phone 7.5 tiene sockets… de aquella manera. Cuando la aplicación pasa a background el socket se cierra, con lo que pierdes la persistencia en la comunicación. Aquí lo puedes solucionar mediante técnicas Push (que todavía no he visto e ignoro las limitaciones y ventajas que puedan tener). Pero de momento, aplicaciones verticales que requieran una conexión permanente tampoco están permitidas.

***

Ahora llega la última versión, con dispostivos de 256 MB de memoria… Y la vuelven a cagar. Dadas las limitaciones de los mismos, dejan de funcionar las tareas periódicas y las intensivas… Y te dicen que cuando lances la aplicación mires en qué dispositivos estás ejecutando y uses secuencias if/else para cambiar el comportamiento.

En primer lugar eso es una soberana imbecilidad como una casa. ¿Tienes que codificar las cosas dos veces? Pues no, tendrás que hacerlo todo con la limitación predicha, porque si lo puedes hacer sin esos elementos, es una soberana gilipollez repetir el código. El problema vendrá cuando sin eso no puedas hacerlo.

En segundo lugar, mientras los demás fabricantes implementan mejoras y optimizan el código de sus sistemas operativos, Microsoft hace lo contrario. Apple pasa de dispositvos de 256 MB de RAM a 512 y luego a 1024. Microsof pasa de 512 a 256, llevándose cosas de en medio.

***

Recuerdo la presentación de Windows Phone: que si sólo .NET, que si sólo procesadores multicore, que si sólo dispositivos de gama alta… Al final tienen que pasar por el aro, pero en lugar de abrir el Windows CE interno al lenguaje C y/o C++ y quitar la mierda del .NET, que seguro consume 40 de los 60 MB de la huella de memoria de cada proceso, van y quitan prestaciones… porque lo de las tareas asíncronas es sólo una de tantas limitaciones impuestas, que podéis leer en la entrada que os enlazo más arriba.

***

Resumendo, que van de mal en peor. RFOG dixit.

C++/CX (II). C++/CX vs WRL

Rafael Ontivero — Fri, 04 Nov 2011 19:13:32 GMT

Bueno, una vez que hemos visto lo que hay dentro del nuevo Windows 8, y comprobado que WinRT no es un subsistema sino algo por encima de Win32 como es .NET, vamos a contaros las dos formas que hay de programar con C++ para la interfaz Metro.

Ya lo he comentado antes, pero voy a repetirlo aquí por mor de claridad. En Windows 8 hay dos escritorios diferentes. Por un lado tenemos el clásico de toda la vida que es prácticamente idéntico al de Windows 7, y por otro el de la interfaz Metro. Si no cambian las cosas, los equipos que lleven un procesador x86 tendrán acceso indistinto a los dos, mientras que aquellos que lleven procesador ARM sólo verán la interfaz Metro.

Eso quiere decir que habrá dos tipos de aplicaciones: las clásicas y las Metro. Las primeras sólo podrán compilarse para x86 (de 32 o de 64 bits) y sólo funcionarán en las máquinas Intel. Si estamos en la interfaz Metro y lanzamos una aplicación de este tipo, el sistema cambiará al escritorio clásico.

Las segundas podrán compilarse para x86 o para ARM y en ambos casos funcionarán en sus propios sistemas, pero siempre bajo la interfaz Metro. Es decir, si queremos que nuestra aplicación Metro escrita con código nativo pueda correr en los dos tipos de arquitectura, tendremos que proveer dos compilaciones.

Con .NET (C# y VB.NET) viene a pasar lo mismo, aunque en este caso creo que con especificar AnyCPU será suficiente para que la aplicación corra en ambas arquitecturas. Y de nuevo tendremos los dos tipos de aplicaciones: de escritorio y Metro, con las mismas reglas.

Por lo tanto, cualquier programa escrito en cualquier lenguaje que funcione ahora mismo en Windows 7, no debe tener ningún problema en ejecutarse en la siguiente versión, pero siempre en el escritorio clásico. Y podremos seguir escribiéndolos como hasta ahora.

***

Eso quiere decir que tenemos dos API diferentes e incompatibles entre sí. Por un lado tenemos el API de Win32 clásico y tradicional, sobre el que se construyen bibliotecas de terceros y el .NET. Aquí podemos meter VB6, Delphi, C#, C++/CLI, QT… Vamos, lo que hasta ahora.

Y para Metro hay una nueva API que se llama WinRT. Creo que hay cosas compartidas con Win32, pero no me hagáis mucho caso porque todavía no he visto nada. De todos modos si las hubiera, podemos tomarlas como si fueran nuevas, porque son excluyentes, al menos de momento.

Es decir, o bien desarrollas para Win32 o bien para WinRT, pero no puedes tener un ejecutable que use partes del otro más allá de las que MS ha querido compartir, y entre ellas no se encuentra C++/CX.

Por lo tanto también hay dos versiones de .NET. La de la interfaz Metro se construye sobre WinRT, y la clásica sobre Win32. Nos podemos hacer a la idea de que, aunque tengamos un API con nombres similares, por dentro funciona todo diferente (lo que no es cierto, pero a efectos prácticos sí que lo es, ya que las aplicaciones Metro deberán ir firmadas y el proceso de firmado garantiza que no vas a salirte de las API estándar -¿De qué me sonará eso?).

***

No obstante, WinRT no está escrito con C++/CX si no que está hecho con C++ clásico. Y en cierto modo es lógico, ya que no es más que una extensión a Win32, que es C y C++. Además, independientemente de mis diatribas personales, es algo bueno que le añada funcionalidad a un API que lleva tanto tiempo funcionando con regularidad y sin grandes problemas. Imaginaos los bugs que podría tener algo escrito desde cero.

Por lo tanto, podemos desarrollar aplicaciones para Metro sin usar .NET ni C++/CX. Podemos utilizar C++ y una biblioteca de plantillas llamada WRL (Windows Runtime Library), que viene a ser algo así como el ATL de Metro.

Microsoft no recomienda usarla, más que nada porque es compleja y porque de momento no hay documentación alguna sobre ella, pero está ahí, y es la base de Metro.

Si queremos echarle un vistazo, podemos acercarnos a “Program Files (x86)\Windows Kits\8.0\Include\winrt\wrl” y ver qué hay dentro. Tomaos un par de aspirinas antes.

Básicamente se trata de toda la infraestructura y parafernalia para acceder a los objetos COM y componentes de Metro.

***

C++/CX ocupa el nicho de lenguaje nativo para Metro, con lo que es más rápido que C# y que VB.NET, y es con el único con el que se puede acceder a DirectX (y por tanto a la creación de juegos). También es nativo. Es decir, que no es .NET y compila al código máquina que todos conocemos y de hecho es idéntico al C++ de toda la vida.

Lo que ocurre es que contiene una serie de extensiones que nos van a facilitar la vida a la hora de operar con Metro y sus componentes. Soporta clases parciales, se entiende bien con XAML e instanciar o crear un componente COM es un juego de niños comparado a como se hace con Win32.

Digamos que con esas extensiones nos ahorramos una buena faena a la hora de programar, y será el compilador el que sustituya esa azúcar sintáctica por el código necesario.

En siguientes entradas os contaré más sobre C++/CX.

El compilador como servicio

Rafael Ontivero — Fri, 21 Oct 2011 17:16:52 GMT

Me he quedado poco menos que estupefacto con esta entrada del blog de SomaSegar. Y no, no penséis mal, que no es malo.

Básicamente viene a decirnos que está disponible la CTP de “Roslyn”, que según entiendo es una extensión -de momento- a Visual Studio 2010 SP1. De hecho nos la podemos bajar y jugar con ella.

Comienza diciendo que los compiladores se han venido haciendo en C++ nativo, pero que ya es hora de cambiar y que han rehecho los compiladores de C# y de Visual Basic desde cero en… Visual Basic.

Hay que joderse. La primera en la boca. ¿Pero no decían que el compilador y el propio .NET estaban hechos en C# (lo siento, no encuentro la referencia)? Ahora no, ahora resulta que C# está escrito en C++.

Y la segunda, también: C# está hecho en Visual Basic.

O están tontos, o yo no me entero, o mienten más que hablan. Para nada me extraña de que hubieran mentido en lo de hacer C# en C++, de hecho es lo lógico y coherente, ¡pero construirlo todo en VB?

De todos modos dejemos esto aquí, corramos un estúpido velo, y centrémonos en el meollo del artículo: compilador como servicio.

Es decir, en Visual Studio 11 los compiladores de C# y VB no serán ejecutables, sino servicios expuestos al público (espero que haya uno para invocarlo desde la línea de comandos), de modo que cualquiera podrá compilar.

No solo eso, sino que dejarán de ser una caja negra que, a partir de un código fuente, genera una salida compilada, sino que podremos acceder a los diferentes estados del proceso de compilación, e incluso podremos realizar solo unos pasos, como análisis semántico o la obtención del código IL (ensamblador del .NET).

Eso posibilita la creación de scripts en una consola interactiva. ¿Recuerdan la consola aquella que tenía el Visual FoxPro que permitía ir encadenando comandos como si programáramos? Pues lo mismo, pero en VB y en C#. Vamos, que reinventan la rueda.

En la entrada original hay un par de imágenes enseñando lo que puede hacer.

WinTablet.info: Windows 8 y los Tablet

Rafael Ontivero — Sun, 25 Sep 2011 09:43:55 GMT

Ya sabéis que me gusta meter baza en los nuevos productos de Microsoft más que a un pollo la mierda. No creo que os pille de sorpresa, pero en este caso estamos hablando de caviar Beluga ya que encima tenemos dominio y web propia.

Sí, lo que leéis, el RFOG ha sido invitado a participar en un blog de temática exclusiva sobre Windows 8 y su orientación hacia los Tablet. Sin restricción de temática, sin censura y con libertad total de publicar lo que quiera (no, que no se os abran los ojos como platos, de momento no voy a poner porno).

Bueno, después de la presentación chula, vienen los detalles. Nos hemos juntado cuatro interfectos de entre los indeseables de la internet y que encima somos granos en el culo de las grandes corporaciones y nos hemos decidido a poner los puntos sobre las íes en el tópico descrito más arriba. La idea fue originalmente de Juan Luis Chulilla, quien la propuso a Ctitanic y a mi. No hace falta decir que tardamos 100 milisegundos en decir que sí, que es el tiempo medio de reacción entre el ojo y el cerebro (para aquellos que tengan neuronas, claro). Luego se nos unió Mahjong, y así formamos el cuarteto concertante (la referencia es de Verne).

Dicho y hecho, sólo faltaba arremangarse y empezar a escribir, así que el sitio ya contiene entradas chulas, aunque todavía anda algo en obras y debéis poneos casco no sea que se os caiga algún ladrillo en la cocorota.

Para aquellos que todavía estéis en Babia, os comento. Windows 8 es la siguiente versión de Windows 7, y viene en modo dual. Es decir, que trae dosShell de usuario. La primera es la que todos ya conocemos, con su menú inicio, su explorador y su Internet Explorer, con las mejoras pertinentes. Lo pongo en cursiva porque hay mucha gente a la que la Ribbon en el Explorador no les mola nada… a mí sí.

La segunda interfaz se llama Metro y está destinada a los Tablet, sean del tipo que sean. Si habéis visto Windows Phone ya tenéis una idea de qué es. Como siempre con las tecnologías de Microsoft, debajo hay más de lo que parece, y también ahora ocurre así.

A simple vista Metro parece nada más que una interfaz de apretar botones, pero dentro existe un motor basado en DirectX muy potente e interesante, envuelto en una capa que se programa con C# y una variante de C++/CLI. Y no es .NET, es nativa. De esto os contaré más aquí, pero en otro momento.

Finalmente también hay una preview de la siguiente versión de Visual Studio que es capaz de generar ejecutables para esta nueva plataforma, y de esto también hablaré por aquí.

Bueno, lo dicho, daos una vuelta por WinTablet.info.

Un caso de fracaso... o dos

Rafael Ontivero — Thu, 04 Nov 2010 21:28:00 GMT

Bueno, esta es otra de esas entradas nada técnicas y personalísimas, en la que voy a contar varias cosas, respoder a las inquietudes que asertus ha comentado en la entrada anterior.

Generalmente los casos de éxito se suelen airear a lo grande, a bombo y platillo, con grandes titulares, pero los fracasos se suelen ocultar debajo de la alfombra, y cuanto menos se sepa de ellos, mejor.

Pues bien, yo voy a contar aquí un proyecto que ha fracasado, o al menos lo ha hecho según el planteamiento original, y luego comentaré algo sobre Evernote 4 y su bajada de WPF…

Aparte del firmware, y a veces junto con él, suelo entregar una aplicación para PC que se encarga de lidiar con la electrónica que vendemos, o simplemente demuestra su funcionamiento, aunque las más de las veces sirve como herramienta de configuración y verificación.

Es un proyecto bastante complejo que ha arrancado y parado varias veces, ha mutado y vuelto a mutar, pero al final estuvo claro qué se quería, y cómo. Fue tiempo de ponerse a picar código como un loco. De eso hace unos meses, y más o menos el esfuerzo duró como dos meses hasta que nuevas y más urgentes tareas volvieron a pausarlo, pero esta vez no porque se llegara a un callejón sin salida (y no me refiero a técnico, sino comercial o de concepto), sino porque se vio que había tareas de mayor prioridad.

Se detuvo en un punto interesante: la parte del PC estaba casi terminada, por lo menos la primera fase, y ya iba a pasar al hardware, aunque estimé que necesitaría otra semana más para estar listo y empezar con la interoperabilidad entre el PC y la electrónica. Una siguiente iteración, cuando programa y placa se hablaran entre ellos, volvería al PC para finiquitarlo y dedicar el resto del tiempo al desarrollo embebido, cienes y cienes de variantes del firmware que el programa del PC debería ensamblar e insertar en la placa…

Esos dos meses fueron un poco como de pesadilla. Entusiasmado y emocionado, con mucha ilusión, comencé a hacerlo con el Feature Pack de Visual Studio 2008. Sí, ya sabéis, la Ribbon, las ventanas estilo Visual Studio y todo eso, la última versión de MFC. De esa pelea, porque pelea sin cuartel fue, tenéis las últimas entradas de mi sección MFC en el Guille. En concreto iba a aprovechar todo un esqueleto de Visual Studio incluyendo el control de propiedades igual que se trabaja con .NET. Es decir, el programa tendría un Editor de Propiedades y una “Paleta de Componentes” como las tiene el .NET. Pero relacionadas con mi firmware, y el usuario podría coger pedazos de firmware, echarlos sobre un contenedor y luego ir cambiando las propiedades. Finalmente, una opción enviaría dicho firmware a la placa.

Bonito, ¿no?

Bueno, pues fue un fracaso. No solo tuve que pelearme con todas y cada una de las cosas que iba añadiendo, sino que luego no funcionaban ni como estaban documentadas (en el caso de que lo estuvieran) ni como dicta la razón. Entre las cosas que me costó mucho hacer funcionar está el personalizar las barras de herramientas, hacer funcionar el editor de propiedades, y que el modelo Documento/Vista funcionara como yo quería…

No voy a contar ninguna pelea, ni voy a poner el grito en el cielo, ya no, ya me he cansado de predicar en el desierto. Básicamente me tuve que leer medio internet, y navegar hasta las profundidades del código fuente de MFC para, en primer lugar saber cómo funcionaba y por qué hacía lo que hacía, y en segundo para saber cómo heredar y cambiar el comportamiento y mirar por qué no funcionaba como se esperaba…

El summum de la desesperación vino cuando pasé el proyecto a Visual Studio 2010 y empezaron a aparecerme fugas de memoria que en la versión 2008 no había (o si las había no eran detectadas)… así que volví a la versión 2008SP1.

Pero ahí no terminan las cosas, las cosas terminan cuando, de repente, los diálogos dejaron de funcionar. Me explico. Tengo varias clases base heredadas de CDialogEx que usan una plantilla de diálogo y que implementan el contenido común. Luego heredo de ellas una jerarquía pero sin plantilla y con pocas líneas modifico el comportamiento. No son muchas, son cuatro clases base de las que heredan cuatro hijas de cada una de ellas, pero que creadas de esta forma ahorran muchos dolores de cabeza y concentran la funcionalidad siempre en un mismo sitio.

Pues bien, eso dejó de funcionar, de repente, sin tocar nada. No he investigado mucho, pero parece ser que la cadena de constructores se interrumpe cuando uno de ellos es incapaz de encontrar el recurso de diálogo en el ejecutable, diálogo que seguro existe, no tiene ningún problema y que puedo ver en el editor de Visual Studio. El constructor retorna a medio construir, y cuando se llama a ShowDialog() se dispara un ASSERT que pone un insulso mensaje en la ventana de Debug y ni se abre el diálogo, ni se genera una excepción, ni pasa nada de nada. Como el silencio administrativo pero en programa.

Ahí fue cuando decidí parar la vez anterior, o más bien llegó la fecha límite y tuve que cambiar a otra cosa. A últimos de la semana pasada retomé el proyecto, ví lo de los construtores y… lo mandé a tomar por culo.

Con esas misma palabras.

El martes empecé una versión limitada en funcionalidad, en Windows Forms y C#. Básicamente se abre un diálogo que deja elegir entre unos módulos, y luego, Form a Form, permite modificar el comportamiento. Y finalmente dándole a un botón envías el resultado. La aplicación se guarda a sí misma, la información está en ficheros INI de texto, y tiene casi toda la funcionalidad que la anterior, pero hecho de forma bastante más chapucera.

También me he encontrado con algún tropiezo, pero en su mayoría debido a mi propia torpeza. De todos modos estamos a jueves (han pasado tres días) y… ¡Ya estoy en la misma fase en la que acabé la otra vez! Es decir, he tardado 3 días a hacer en .NET lo que en MFC me llevó casi dos meses. Evidentemente no es la misma aplicación ni de lejos, ni tan bonita ni tan funcional como era la otra, y creo que no me atrevería a hacer algo de complejidad similar en C#. Ya no me fío después de cómo las he pasado con .NET…

No me malinterpretéis, con esto que os he contado no quiero decir que .NET sea la rehostia, que no lo es, de hecho ahora tengo un problema con un thread que me parece que es una limitación (que no un bug) de .NET…

Por otro lado, y es un consenso entre varios MVP de C++ y entre los programadores en general, que el Feature Pack es algo bloated, a-funcional y lleno de enormes torpezas. Complejo a conciencia, escasamente documentado, y la versión 2010 tiene fugas de memoria internas (Haced la prueba: construid una aplicación de cuadro de diálogo sin más, ejecutadla y cerradla. La ventana de depuración os dará fugas de memoria sin que el usuario haya añadido una sola línea de código).

Añadamos que nos genera ejecutables de más de 2 megas de tamaño… Ciertamente un fracaso, y no propio. Yo al menos me he sacado las castañas del fuego en tres días, a ver lo que tarda Microsoft.

***

Otra de las noticias que está corriendo como la pólvora es que Evernote 4 ha abandonado WPF en pro de C++ y del código nativo. Más o menos cuentan lo que yo ya dije hace mucho tiempo: .NET no vale para aplicaciones de sistema ni para nada medianamente complejo que no sea para lo que se ha pensado, que son aplicaciones verticales de bases de datos sin muchos Forms (ni muy complejos) y como competencia directa de Java (que todavía vale menos, IMHO).

Una prueba de ellos es que, a fecha de hoy, ninguna aplicación de Microsoft está enteramente hecha en .NET. No Office, ni partes interesantes de Windows, ni otras herramientas enterprise. Lo más cercano es el editor de Visual Studio 2010, que no está mal pero que funciona sensiblemente más lento que el del 2008, y cuando digo más lento es más lento. En mi caso, a veces ni siquiera me pilla un doble clic rápido. Además, como muestra un botón, ya que la gente que estaba haciendo el editor tuvo que ponerse seria con la que hacía WPF para que solucionaran serios problemas tanto de rendimiento como de funcionalidad, o al menos eso es lo que se deja entrever en algunas noticias y se comenta en los mentideros de la red.

Hay un tercer problema, y es que la supuesta unificación del API de .NET para deshacerse del de Win32 se está convirtiendo, con el tiempo, igual de disparejo, con las mismas inconsistencias entre diferentes partes…

Es muy posible que en fechas no muy lejanas veamos morir a más lenguajes .NET, seguro que C++/CLI entre ellos. De momento en Visual C++ 2010 no tiene IntelliSense porque al parecer no les dio tiempo a implementarlo, pero es que tampoco se ha actualizado para añadir algunas de las cosas de .NET 4.0…

Así que, una vez desaparecido éste, gente del Visual Basic, poneros a remojo. Y los Accesseros también. Son mis 2 céntimos sin usar información privilegiada de ningún tipo, pero son cosas que se ven venir. Y ya de paso metamos a Windows Phone, que tampoco creo que dure mucho y eso que acaba de nacer…

Volviendo a Evernote, y habiendo hecho un análisis somero, parece ser que han utilizado WTL, ATL y STL, con librerías de terceros, pero no MFC (No me extraña). De hecho, aplicaciones masivamente utilizadas como Chrome o Picasa no usan ni MFC ni WPF (ni .NET). Por algo será.

Tampoco han usado QT, cosa que en principio me extraña un poco porque es EL FRAMEWORK de moda y de éxito… Yo llevo bastante tiempo detrás de aprender QT, pero no me decido. Cojo un libro, leo un par de capítulos y lo dejo, para repetir al cabo de unos meses. Ahora con el iMAC en marcha veo QT de otra forma, y de hecho los dos libros de Cocoa (el de la Vespa y el Unleashed) creo que van a dormir el sueño de los justos…

Ah, por cierto, esta entrada ha sido escrita con Word 2008 para MAC, guardada como un fichero HTML, cargado en el IE 7 con una máquina virtual windows, visto su código fuente y copiado directamente como HTML en el editor WEB del blog (cosas de la interoperabilidad). Las aplicaciones Windows han estado corriendo en modo Unity y, Asertus, de momento tengo tanta faena en el curro que cuando llego a casa (antes no llegaba a casa, estaba en casa) sólo tengo tiempo y ganas de bajarme el correo personal, navegar un rato e irme a dormir. Tengo instalado QT tanto en la virtual Windows como en el iMAC, pero apenas lo he usado por encima, y eso que me está rondando una idea para un juego que…

Sobre delegados, closures, punteros y la falacia del puntero loco

Rafael Ontivero — Fri, 30 Jul 2010 10:45:20 GMT

Leía esta mañana –mientras se carga una serie de gráficos en mi actual proyecto- el blog de Marino Posadas que, aunque publica poco, publica bien, y me he quedado más que estupefacto con lo que nos ha contado. He de matizar que en ningún momento dudo de la palabra de Marino, y es por eso por lo que me ha llamado tanto la atención de lo que nos ha contado.

Antes de seguir aquí lo mejor es que leáis su entrada, y volváis a esta.

***

El primer malentendido sobre el texto nos lo ha solucionado el propio Marino en los comentarios: no, Anders no se tiró seis meses para inventar los delegados, sino que estuvo tal tiempo creando el .NET, y durante el cual salió la idea del delegado. Haremos la vista gorda e ignoraremos el hecho de que en Delphi (y C++ Builder) el propio Anders ya tenía algo así.

Además, siempre he dicho que el delegado es el paso siguiente al puntero a función y/o función de retrollamada (o callback, como le se suele citar habitualmente). Eso también queda fuera de toda discusión.

Cuenta Marino que Anders primero analizó que una mayoría de las BSOD en Windows venían a cuenta de drivers defectuosos, y que otra mayoría venía causada por una variación sobre un mismo tema: el moldeo o casting incorrecto de punteros a función, algo que es bastante común en el desarrollo de sistemas.

Por lo tanto, para acabar con el segundo problema, decidió implementar los delegados en .NET. Aquí tenemos la primera falacia de todas, y encima autocontenida. Es decir, los delegados están en .NET, pero no en la creación de drivers, ni en la de software de sistemas, que se sigue haciendo en C++, así que solución, nada de nada.

Claro, a no ser que pensara que el mundo™ iba a abandonar sus millones de líneas de código™ y se iba a pasar derechito al .NET™, acabando en un par de meses con el infierno de los punteros.

Espero que ya se haya dado cuenta de que no, que el .NET está y sirve para lo que está y sirve, y para nada más. Por lo tanto, está claro que no ha acabado con el problema de los punteros locos.

Lo que ha hecho ha sido crear una plataforma de desarrollo en la que se minimiza el problema, pero el código nativo (nuevo y viejo) sigue adoleciendo del mismo. Además, en .NET un delegado vacío, hasta donde llego, lanza una excepción, de igual forma que la ejecución de un puntero a función nulo lanza, también, una excepción, que si eres buen programador, habrás capturado.

***

Vamos ahora a por la segunda falacia. ¿Sabéis qué es en realidad un delegado? Pues un delegado es una clase normal y corriente, pero que está cableada en cierta medida dentro del compilador de C#. De hecho, en C++/CLI podemos usarla como una clase más. Podéis leer algo sobre esto aquí.

¿Y qué hace esa clase? Pues tiene un constructor que viene a recibir un puntero a método o función global. Tiene un método que es el que ejecutará ese puntero recibido. Y tiene una serie de eventos y sobrecarga de operadores que nos permiten la semántica de utilizar “+=” y “-=” para añadir/quitar punteros a función.

Y cuando mandamos ejecutar el delegado, lo que hace es comprobar si el puntero es válido, y si lo es, lo ejecuta. Y si se trata de un delegado multicast, entonces contiene una bolsa de punteros a función que va comprobando que sean válidos y ejecutando uno detrás de otro.

Ni más ni menos.

***

Ahora vamos a lo que vamos, que es la tercera falacia y la más importante de todas. ¿Sabíais que con C++ hacer eso mismo es casi trivial? ¿Sabíais que ya está hecho en Boost (no lo he mirado, pero me apuesto un gallifante a que los hay, y seguro que de varios tipos)? ¿Realmente quería Anders acabar con el tema de los problemas con las funciones de retrollamada? No lo creo, ya que si eso realmente hubiera estado en su agenda, lo que se habría hecho es modificar Win32 para que aceptara un objeto de tipo delegado creado con alguna clase de C++, con un operador puntero para C.

Porque niños, hacer eso mismo en C++ no sólo es trivial, sino mucho más directo, ya que podemos sobrecargar el operador de llamada a función y el de puntero, como nos lo demuestran los predicados de la STL… Pero claro, Anders tiene que barrer para casa y expresar las genialidades de .NET y C#...

En fin…

Uniones en C#

Rafael Ontivero — Wed, 28 Apr 2010 18:09:00 GMT

Hay veces que uno no encuentra lo que busca, y cuando no lo está buscando, lo encuentra. O algo así. El hecho está en que empecé a hacer una pequeña utilidad interna en C# que necesitaba bastantes estructuras y encima con campos repetidos.

Eso en C++ es fácil de solventar. Un se crea una jerarquía de estructuras igual que podría hacerlo de clases, y listo. Es decir, si yo necesito tres estructuras diferentes que tengan, por ejemplo, varios campos del mismo nombre y tipo, lo más fácil es crear una estructura base y heredar de ella. Algo así:

struct Base
{
    string Nombre;
    string NombreAlternativo;
};

struct Casa:public Base
{
    string Dirección;
};

struct Coche:public Base
{
    string Propietario;
};

De este modo ahorro escritura, ya que tanto la estructura Casa como Coche tendrán los campos Nombre y NombreAlternativo sin haberlos tenido que teclear. Suena un poco trivial pero cuando tienes diez o doce estructuras lo agradeces, incluso de esta forma te evitas los errores de tecleo y pones en una de ellas un campo con “Nonbre” en lugar de Nombre.

Eso en C++, en C# llega uno tan contento, se pone a picar código y… ¡ñas, no deja! El compilador protesta como un loco…

Me voy a la ayuda y, efectivamente, una limitación más del .NET: pese a que ellas mismas heredan de ValueType e indirectamente de Object (por cierto realizando una metástasis muy extraña y pasando de ser un tipo-referencia, como es Object, a un tipo-valor…)

Pero sigo leyendo para abajo y me encuentro con una sorpresa, y es cómo hacer uniones aprovechando los atributos.

El tema está aquí, y básicamente viene a decir, en la sección “Attributes on Structs”, que utilizando los atributos “LayoutKind.Explicit” y “FieldOffset”, podemos definir el punto de inicio de cada elemento de la estructura de forma manual.

Veamos un ejemplo muy socorrido en C/C++ en relación a las direcciones IP, que todos hemos manejado alguna vez. Una dirección IP se puede ver como un entero sin signo de 32 bits (que es como las ve el software) o como cuatro números situados entre 0 y 255. Esto en C/C++ se puede expresar así:

union IP
{
    __int32 As32bits;
    unsigned char asBytes[4];
};

Para referirnos a ellas, podemos usar ambas partes y ambas serán el mismo valor:

IP miIP;
miIp.AsBytes[0]=192;
miIp.AsBytes[0]=168;
miIp.AsBytes[0]=1;
miIp.AsBytes[0]=1;

Y como miIP.As32bits tendremos en valor equivalente.

Pues bien, en C# esto se puede conseguir más o menos así:

using System.Runtime.InteropServices;
[StructLayour(LayoutKind.Explicit)]
struct IP
{
    [FieldOffset(0)]
    Public Int32 As32bits;
    [FieldOffset(0)]
    Public byte a;
    [FieldOffset(1)]
    Public byte b;
    [FieldOffset(2)]
    Public byte c;
    [FieldOffset(3)]
    Public byte d;
}

Y podríamos acceder a ella tanto asignando los valores a, b, c, d como As32bits. También podríamos añadirlo como un array, pero eso queda de ejercicio de clase.

(NOTA: La entrada está escrita sin comprobar el código, por lo que podría haber algún gazapo. De todos modos, la esencia del código es correcta.)

Algunos bugs del Compact Framework

Rafael Ontivero — Wed, 21 Apr 2010 09:51:00 GMT

No llevo ni mil líneas de código de un nuevo proyecto embebido en C# y ya me he encontrado con al menos cinco bugs. En su momento abandoné C# para escritorio porque era un juguetito que apenas daba de sí para realizar aplicaciones de sistemas medianamente complejas. El mayor problema estribaba en que como te salieras de lo que los sabios habían determinado, aquello no funcionaba ni para atrás. Cosas que fallaban, muchas. Las más flagrantes eran serios problemas con los constructores estáticos, agravados en el caso de que se produjera una excepción dentro de ellos, excepciones que no se lanzaban cuando debían, y un largo etcétera en relación a elementos de Windows Forms.

Tengo constancia de que muchos de esos problemas han sido solucionados con los distintos Service Packs que le han ido saliendo a la versión 2.0 del .NET Framework, y pensaba que ya que el Compact también lleva unos cuantos, no tendría problemas con él.

Pero no es así en relación al Compact. Fijaros que no estoy hablando del 3, ni del 3.5, sino del 2.0, que lleva una buena porrada de años en la calle y que ya debería funcionar medianamente bien. No quiero yo ver la porquería que serán el 3 y 3.5 (recuerdo haber encontrado y reportado 5 bugs en una única sesión de media hora de jugar con ellos, de los cuales la mayoría serían resueltos en next version, que es la forma políticamente correcta que tiene Microsoft de quitarse a los pesados de encima y decirte con buenas palabras que no lo van a solucionar).

Los más triviales del Compact 2.0 se encadenan en torno al componente Tab Control, y básicamente tienen que ver con el tamaño del mismo y la posición de las páginas. Hablamos del .NET Compact Framework 2.0 con todos sus parches en compilación AnyCPU, no de la versión de escritorio.

Cuando el componente es más grande que la ficha y sale por debajo porque está anclado por arriba a la misma, .NET dibuja una barra de desplazamiento vertical que permite contener el componente completo. Sin embargo, si la anclamos por debajo, la barra de desplazamiento no aparece, y entonces los controles que haya en la parte superior ocultos a la vista no serán visibles.

El siguiente también tiene relación con este, y se presenta de forma aleatoria (o al menos yo no he sido capaz de poder reproducirlo siempre). El control no se redimensiona. Ya puedes ponerle el Width o el Heigth al valor que quieras, que él seguirá con el que tenga en tiempo de diseño. Parece estar relacionado también con el tipo de anclaje y de dock, pero no estoy seguro.

El gordo. Este problema clama al cielo, es para llorar, ya veréis. Crea un proyecto embebido en C# para Windows CE con el asistente y para el Compact 2.0. Añade un PictureBox al Form. Clica en la propiedad Image y carga un fichero JPG. Una vez hecho esto deberemos estar viendo la imagen en tiempo de diseño. Ejecutemos sobre un emulador o sobre un dispositivo real.

¡Tachán! Excepción al canto, la imagen no aparece por ningún lado. Os adjunto una imagen, para que veáis que no hay trampa ni cartón:

A la izquierda está el editor abierto por la excepción y mostrando esta, del tipo “Exception”. A la derecha está el Form mostrando la imagen, y más a la derecha el emulador.

Para más inri y jocosidad (aunque es para llorar), el tipo de excepción es “Exception”, así, a pelo. No del tipo recurso no encontrado, ni fichero no encontrado, ni nada de eso. Simplemente una “excepción”.

Pero todavía hay más, porque al menos en Windows CE te salta la excepción, en Windows Mobile, por ejemplo, simplemente falla, sin disparar ningún tipo de excepción ni nada.

No os vayáis, porque ¡sí, hay más!: incluso poniéndola a mano como un recurso normal, luego en el ejecutable ¡no hay imagen! Es decir, que lo que quiera que haga de linker en el C# pasa olímpicamente de este tipo de recurso.

¿Es para llorar o no? Pues eso, que se le quitan a uno las ganas.

V2.0

Bueno, lo de arriba fue escrito y programado para que se publicara el 21 de abril, ya que tengo entradas preparadas hasta esa fecha, pero resulta que mientras llega el citado día, seguí con el tema a ratos, porque no es un proyecto del curro, sino personal. Si lo contado hasta ahora clama al cielo, no os digo ya lo que viene a continuación.

Unos días después de desistir con el tema, vi el dispostivo con Windows CE por encima de la mesa y me dije que iba a reintentarlo, y así lo hice. Conecté el aparato (un JE200 vuelto a convertir en un cacharro CE puro para los curiosos) y para escarnio y befa personal, ¡funcionó a la primera! Bueno, no realmente, porque para evitarme la descarga de todo el Compact sobre el dispositivo, y sabiendo que él traía ya una versión 2.0, desconecté la opción de cargar siempre la última versión en el aparato/emulador.

Y entonces funcionó. O en otras palabras, la imagen se embebió en el ejecutable y este funcionó perfectamente. No obstante, había ahora un nuevo problema: el color de fondo de los botones no se cambiaba por el que yo había decidido (suma bug y sigue).

Me da por probar en un emulador de Windows Mobile 2003 y funciona todo perfecto, incluso lo de los botones. De vuelta al emulador del CE, me dice que el .NET instalado es muy viejo. ¿Cómo que muy viejo? Si lo que pasa es que no hay .NET (Si lo sabré yo que . Otro más al cesto.

Para resolver lo anterior, reactivo lo de bajar la última versión del Compact, lo hizo, cargó y funcionó, aunque el tema de los botones siguió sin funcionar… Lo cierto es que funcionó sólo la primera carga. En la demás ya dejó de hacerlo. Suma y sigue.

Bueno, al final, resumiendo: tras al menos dos Service Packs y varias “actualizaciones de seguridad”, el Compact no sólo es la misma mierd@ que antes, si no incluso peor, con regresiones que ni siquiera estaban presentes en la RTM.

Personalmente se me cae la cara de vergüenza ajena con esto, lo que reafirma y confirma algo que he dicho por aquí no hace poco: los test no valen para nada. Y me da para otra entrada sobre este tema que ya estoy empezando a barruntar. Permaneced atentos.

Hemos leído: Adam Nathan: Windows Presentatio Foundation Unleashed

Rafael Ontivero — Sat, 31 Oct 2009 12:25:16 GMT

La idea de adelantar casi un año la lectura de este libro respecto a mi plan ha sido la de hacer un programa utilizando WPF, pero al final ha sido peor el remedio que la enfermedad. O dicho de otro modo: pese a ser enormemente potente, pese a soportar temas, pese a contener ideas relativamente nuevas y bien implementadas... no lo voy a hacer con WPF. Simplemente es que no me gusta cómo ha sido expresada dicha potencia. Me han dicho que quizás si leyera el libro equivalente de Petzold lo vería de otro modo, pero de Petzold ya tuve bastante con el de Programación en Windows con C#, que contenía más errores que aciertos.

Sí, ya sé que los libros de Petzold sobre Win32 y C son una referencia de base, de hecho tengo tres ediciones de las cinco que hay, pero por eso mismo: la referencia son estos, no los nuevos. No creo que nadie pueda negarme que el de C# no tenga errores.

Sin embargo, el de Nathan es otra cosa, y pese a tener ya más de tres años, sigue siendo actual y no desmerece para nada. Me dicen que pasa lo mismo con el de Petzold, que quizás compre y lea.

Dividido en cinco partes, ninguna tiene desperdicio. En la primera se nos presenta XAML y lo que significa para WPF, así como los conceptos que hay detrás de todo esto. Lo más destacable es que, a partir de un fichero de marcas como es XAML (que no es más que una variación de XML), el sistema es capaz de construir el tipo de interfaces que es capaz de hacer. Aunque suene un poco como a magia, no lo es, ya que la construcción del fichero y los tags son complejos.

Otras cosas interesantes son las propiedades propagadas, en las que si tu modificas una de ellas, todos los hijos las modificarán de acuerdo al cambio, con lo que variar aspectos de la UI puede llegar a ser trivial en muchos casos. En los eventos ocurre parecido: si uno hace clic en un componente que no tiene dicho evento asignado, éste irá subiendo por el árbol hasta llegar a alguien que lo maneje. Si bien esto último puede sonar espectacular en .NET, en MFC y otros frameworks es el comportamiento habitual.

La segunda parte nos presenta los controles de que disponemos en WPF. Pese a toda su enorme potencia a veces resultan escasos, porque básicamente son una serie de contenedores. A los programadores de GTK o de QT les deben sonar los componentes de layouts y fluentes en el sentido de que reordenan los hijos de forma automática. Aparte de los botones, los cuadros de lista, los combos y los labels, pocos más hay. También nos cuenta cómo juntar todo esto en un programa, y crea una especie de clon de las ventanas de Visual Studio, y digo "especie de" porque realmente el soporte de docking está como ausente, pero aceptaremos pulpo pese a no haber hablado de arrastrar y soltar (que me temo WPF no soporta directamente).

En la tercera nos explica cómo trabajar con recursos, enlace a datos y el soporte para estilos, plantillas (de estilos), pieles (skins) y temas. Aquí me he llevado otro pequeño desengaño, ya que pese a la potencia de todo esto, resulta sensiblemente difícil añadir o cambiar el aspecto de una aplicación. Para hacerlo es necesario al menos saber XAML, y presenta un potencial y enorme agujero de seguridad ya que dicho XAML puede contener código arbitrario...

La penúltima parte cubre la multimedia: cómo hacer gráficos 2D y 3D, animaciones, vídeo y audio. Pese al soporte ampliado, la verdad es que no hay mucha mejora respecto a otras tecnologías.

La quinta y última parte sí que es interesante, por lo menos para mi: Interoperabilidad con Win32, C++/CLI, COM, ActiveX y Windows Forms. De todos modos, nada nuevo bajo el sol, y para ver interoperabilidad entre C++/CLI y WPF y/o Windows Forms de verdad, el libro de Sivakumar. También vemos cómo crear controles personalizados y de usuario.

No os llevéis a engaño por mis comentarios. El libro es muy bueno, lo explica todo perfectamente, pero la tecnología me ha desilusionado un poco. No sé, esperaba más. No más complejidad (que ya tiene bastante), sino más facilidad y menos picar código (aunque sea XAML)... Sí, ya sé que tenemos el Expression Blend, pero creo que aprender a manejar esa bestia parda tampoco es tarea de un rato...