.NET o no .NET, esa es la cuestión

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

Yoda Code y el Optimizador de .NET

Rafael Ontivero — Sat, 08 Dec 2012 13:09:54 GMT

Dicen que a veces la vida te da sorpresas, sorpresas te da la vida. Y en este caso es completamente cierto. A raíz de la entrada anterior, un par de amigos comentaron en Twitter sobre la misma, haciendo uno de ellos hincapié en el Yoda Code que había puesto.

No soy yo muy partidario de Yoda, más que nada porque todos los lenguajes con los que programo suelen avisarte del uso de un solo igual en las comparaciones, aparte de que, como perteneciente a la vieja escuela, veo raro poner eso al revés. No es que sea gratuito, sino que viene de la forma en que aprendimos los lenguajes.

Digamos que para nosotros, en null==handler, null es un lvalue y debe ir a la derecha sí o sí. A ver, que es un poco tontería porque es una comparación, no una asignación, pero así lo veo al menos yo.

Evidentemente no hay nada en contra de utilizar al amigo Yoda (esperemos que Spielberg no se nos enfade y empiece a pedirnos derecho de marca). Simplemente yo lo veo extraño.

***

Pues nada, el RFOG pone las manos en la masa y decide investigar si hay alguna diferencia en el código generado por el compilador entre ponerlo de una forma u otra. Y ahí es donde se lleva una sorpresa que seguro vosotros tampoco os esperáis (no, no es la que pensáis. Paciencia, joven padawan).

Para ello se crea un proyecto de consola con el siguiente código fuente en C#:

        static void Main(string[] args)
        {
            var a = 33;
            if (40 == a)
                Console.WriteLine("Es diferente");
            else
                Console.WriteLine("Es igual");
        
            if (a == 40)
                Console.WriteLine("Es diferente");
            else
                Console.WriteLine("Es igual");
        }

Y en C++ (más bien C, pero a efectos de nuestro interés da igual):

            auto a = 33;
            if (40 == a)
                printf("Es diferente");
            else
                printf("Es igual");
        
            if (a == 40)
                printf("Es diferente");
            else
                printf("Es igual");
			return 0;

Y finalmente en C++/CLI, más que nada por mor de completitud:

int main(array<System::String ^> ^args)
{
	auto a = 33;
	if (40 == a)
		Console::WriteLine("Es diferente");
	else
		Console::WriteLine("Es igual");
	if (a == 40)
		Console::WriteLine("Es diferente");
	else
		Console::WriteLine("Es igual");
	return 0;
}

Si os fijáis, el código es idéntico excepto sus diferencias de sintaxis. Para ver el código resultante, se pone un punto de interrupción en la asignación de la variable a, se lanza el programa y luego nos vamos a Debug -> Windows -> Disassembly (o pulsamos Alt-8). Y miramos el código resultante en los tres casos. Primero en Debug y para C#:

Nítido como el agua: tanto monta, monta tanto, a==40 que 40==a. Perfecto. Vamos con C++/CLI:

Más o menos como en C#, de hecho el código es prácticamente el mismo. Finalmente C++ nativo:

Otra vez como lo esperado. Ninguna diferencia en la generación de código en la parte de la comparación. Bueno, no, algo peor porque el código generado en C++ es a todas luces peor que el de C#, cosa que me extraña. Esta es la primera sorpresa, pero todavía hay más.

De todos modos, si te preocupaba la generación de código tanto usando a Yoda como sin usarlo, ves que no hay diferencia.

Aun así, te recomiendo que sigas leyendo. Lo interesante viene ahora.

***

Pasemos a las versiones Release, que se suponen generan mejor código. La versión en C# genera exactamente el mismo código, por lo que realmente el compilador no está haciendo nada de nada. No hace falta que ponga ninguna captura: el código es idéntico.

En C++/CLI ya vemos algo diferente, y es que el breakpoint se ha movido él solo hacia abajo. Eso quiere decir que ha entrado el optimizador de código:

La versión en ensamblador es terroríficamente simple:

Como el compilador ya sabe el resultado, simplemente ejecuta el código adecuado y punto. El que el primer bloque de ensamblador sea tan largo se debe al prefijo de carga de main, y ese je 00000015 no es más que la comparación de a con 40, que el optimizador todavía realiza.

¿Por qué lo hace? Buena pregunta: otro hilo podría haber cambiado el valor de a, por lo tanto es necesaria la comparación. Ya sé que en este contexto no es válido, pero en otro sí que podría serlo.

Lo mismo nos pasa con C++ nativo, y ahora sí que vemos cómo el código está más que optimizado y apenas son unas cuantas línea de código ensamblador. La siguiente captura está dedicada a todos aquellos que piensan que no vale la pena desarrollar en C++:

***

Hasta ahora está todo meridianamente claro: No hay diferencia entre ir con Yoda o sin él y que el compilador de C++ es una caña generando código.

¿Estamos todos de acuerdo? Yo al menos lo estaba hasta hace bien poco. Ahora os dedico dos nuevas capturas de pantalla:

Y este es el bombazo: el código en .NET es casi idéntico al nativo. Cosa que hace unos años no pasaba. ¿Cómo he obtenido esas capturas? Os vais a Tools -> Options -> Debugging -> General -> Supress JIT optimization on module load y desmarcáis la casilla.

Bueno, el código es casi tan bueno como el nativo, pero fijaos que es mucho menor que las versiones anteriores. Esto me lleva a confirmar una sospecha: la gente de Microsoft está haciendo bien sus deberes, llevando al compilador de C# a cotas cada vez más altas.

Y es que con los años parece ser que han mejorado mucho:

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.

Yuliop y Windows Phone 7 SDK: Una introducción

Rafael Ontivero — Thu, 01 Nov 2012 18:52:42 GMT

Como ya comenté hace algo de tiempo, he realizado un cambio laboral bastante radical, dejando de lado el desarrollo de sistemas embebidos verticales escritos en C y C++ para subir un paso en el escalón del desarrollo en cuanto a tipos de proyecto. En otras palabras, ahora mi tarea principal es desarrollar con Windows Phone para una startup llamada Yuilop.

He pasado de ser un desarrollador más o menos versátil a estar no sólo centrado en una plataforma fija, sino en una única aplicación: su cliente de mensajería. Os contaré cómo funciona la cosa.

La aplicación está disponible para la mayoría de teléfonos Android y para iOS, y próximamente habrá una versión para Windows Phone 7.5, la que estoy haciendo yo. Olvidaros de Windows Phone 7.0 porque no tiene sockets y es prácticamente imposible hacer algo ahí. Se podría implementar con BOSH, pero no vale la pena.

Con la aplicación instalada en un teléfono se pueden enviar mensajes de texto, con emoticonos y emojis, de manera similar a como se realiza con otras aplicaciones similares. También puedes enviar fotos y localizaciones. Hasta aquí nada nuevo bajo el sol.

Lo novedoso está en que también puedes hacerlo a gente que no tenga la aplicación. Es decir, puedes chatear con prácticamente cualquier persona que tenga un móvil a través de SMS. Es decir, tu envías un mensaje de chat y la otra persona recibe un SMS, y justo al revés.

También puedes hablar por teléfono mediante VOIP. Siempre que la otra parte tenga Yuilop instalado podrás hablar con ella de forma gratuita a través de la WiFi o del 3G, sin gastar una llamada de voz tradicional…

No, espera, no. Eso también lo puedes hacer con cualquiera. Incluso con teléfonos fijos. O en otras palabras: no es necesario que la otra persona tenga la aplicación instalada para poder hablar con ella a través de Yuilop.

Todo ello con coste cero. O más bien, pagas la transferencia de datos, el Wifi o el 3G. No pagas ni SMS ni establecimiento de llamada ni a razón del tiempo que estés hablando o chateando o SMSseando.

¿Cómo puede funcionar algo así? Pues bastante fácil: la aplicación tiene publicidad, y el pulsar en ella, o instalarte aplicaciones recomendadas, o seguir ciertas indicaciones te dan energía, que es lo que gastas a la hora de hablar o chatear con gente no Yuilop.

Es decir, que cada vez que hagas algo con gente de fuera de la aplicación, gastas energía. Cada vez que instalas las aplicaciones recomendadas, o haces clic en la publicidad, o chateas con gente Yuilop, obtienes energía. También por invitar a amigos y que estos acepten la invitación.

***

Como veis resulta algo bastante interesante y más potente que las aplicaciones de la competencia (que no nos dejan nombrar).

Pues bien, el que esto suscribe tiene en un estado bastante avanzado la aplicación para Windows Phone. Dadas las características de este sistema operativo, hay algunas opciones que no van a estar disponibles, no porque no queramos, sino porque no podemos.

Y eso me lleva al tema técnico. Llevo dos meses desarrollando con Visual Studio 2010 y el SDK 7.1. Ha habido momento en los que he estado a punto de renunciar dadas no ya las enormes carencias de la plataforma, sino también la falta de documentación y las inconsistencias y bugs de todo ello.

Y de eso es de lo que voy a hablar próximamente aquí. Primero haré una lista de todos los problemas con los que me he encontrado y la forma que te tenido de solucionarlos cuando he podido hacerlo, que no siempre ha sido así.

Para adelantaros un poco el tema, el modelo MVVM es una mierda limitadísima que sólo permite realizar aplicaciones típicas y sencillas, el acceso a bases de datos es, más que pésimo, limitado e incoherente, y existen ciertas limitaciones incoherentes para realizar algunas tareas. Además, la gestión de eventos es mínima, la creación de controles personalizados deja mucho que desear, así como el API expuesto en relación a los componentes con los que podemos trabajar (y ahí incluyo también el Windows Phone Toolkit y sus amigos de Coding4Fun).

Y no, el modelo asíncrono de desarrollo es toda una gozada si no existieran las limitaciones arriba descritas. Los métodos asíncronos, los operadores lambda, los métodos de extensión (pese a ser aberraciones, ya os contaré) y demás zarandajas son una gozada.

Mejor no hablar de XAML, menuda porquería de implementación aunque la idea esté genial.

Y a todo ello añadimos el hecho de que apenas existe documentación. Mientras que para la explicación de una clase en .NET 3, 3.5 ó 4.0 tienes una explicaciones más que detalladas contándote todo, en Silverlight las páginas están más que peladas. Por no incluir ni siquiera ponen lo imprescindible. Parece que se hayan creado a partir del propio código fuente sin más. Y no, no vale aplicar las explicaciones de una a la otra: simplemente funcionan diferente o el comportamiento no existe.

Bueno, lo dicho, estad atentos que le voy a dar caña a Windows Phone 7.5 (Parece ser que la versión 8 ya es adulta y han añadido cosas muy interesantes. También os contaré dentro de unos meses, cuando empiece con ella).

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.

¡El rey ha muerto! ¡Viva el rey!

Rafael Ontivero — Sun, 26 Aug 2012 14:21:00 GMT

Bueno, como resulta más que evidente, este blog anda así como un poco parado, y cuando escribo algo para él, suelo hablar de cualquier cosa excepto de tecnologías Microsoft y Windows.

Como bien sabéis, en principio pasé una etapa de bastante inestabilidad informática, con mi conversión a Apple que al final se ha quedado al 50% ya que hay muchas cosas que no me terminan de convencer. Es decir, suelo usar OS X y mi iPad para las tareas normales, pero aun así conservo varias máquinas virtuales Windows e incluso arranque dual con Windows gracias a Boot Camp. De hecho estoy escribiendo esto en un MacBook Pro Retina Display, ahí es nada. Pese a todas las pifias de Apple, hay muchas cosas en las que son inigualables. Y punto.

De programar, mejor no hablamos. Alguna cosilla he hecho en QT para MAC y para Windows, pero nada serio y siempre para consumo propio.

Después de aquello, o más bien durante, dejé de trabajar, más o menos a finales de marzo. Ya estaba cansado del sector, mucho ruido y pocas nueces, un área que cada vez va perdiendo más y más ventas y productos por la sempiterna falta de actualizarse cuando ves al lobo venir. A efectos prácticos la empresa cerró en España a la vez que las de otros países pasaban de un grupo inversor a otro.

Lo curioso con la española es que el cierre se produjo una semana después de la reforma laboral que permitía hacer eso sin pasar por el control del Estado, estos politicastros nuestros de mierda sabrán qué están haciendo con el país.

A mi me dan ganas de largarme a otro lugar, pero como dice el refrán, no hay mal que por bien no venga. Justo antes de todo esto, comencé conversaciones con una Start Up que han llegado a buen puerto.

Entre medias, unos meses de descanso y desintoxicación programática, con días dedicados a estar tumbado a la bartola o simplemente a leer sin más.

También han ocurrido otras cosas muy interesantes para mi. Con pareja parece ser que afianzada, todo empezó más o menos en el mismo punto en el que todo terminó. Me refiero a cerrar una etapa y a abrir otra nueva.

Chica nueva (aunque antes no había ninguna). Casa nueva (aquí sí, sí que tenía casa). Trabajo nuevo. Y entre medias, unos mesecitos para afianzarlo todo.

Cerramos etapa dedicada a la programación de hardware, muchas veces a pelo, sin sistema operativo y justo encima del hardware, con pequeñas aplicaciones bajo Windows para apoyarlo, todo ello mayormente escrito en C, C++ y a veces C#.

Y abrimos una nueva, plenamente orientada hacia tecnologías Microsoft, en concreto Windows Phone, y en un futuro Windows RT y sus tabletas.

Eso quiere decir que, si las fuerzas nos acompañan, volveremos aquí, hablando sobre Windows Phone (que por cierto, para aquellos que me comentaron tiempo ha, no es tan obtuso de programar ni mucho menos), C# y tecnologías anexas.

Así que afilad los ratones.

QT: QFileSystemModel: actualizando rutas (BUG)

Rafael Ontivero — Wed, 11 Jul 2012 08:03:09 GMT

Ya me extrañaba a mi que no me encontrara, tarde o temprano, con algún tipo de bug en esto del QT. Además, se trata de un bug bastante serio y que, según he leído por ahí, lleva sin solucionar desde que se creó la citada clase, allá por la versión 4.4 o así. Y estamos en la 4.8, varios años después.

Os comento. QFileSystemViewer es la parte documento del modelo documento/vista para trabajar sobre el sistema de ficheros. Como ya vimos ayer, si queremos conectarlo a una parte visual, llamamos al setModel() de la parte visual pasándole un puntero al documento.

Lo cierto es que en QT esta arquitectura es mucho más sencilla de entender y manejar que la de, por ejemplo, MFC.

Pero ¿qué ocurre cuando se crea o modifica un fichero? En principio, debería existir alguna forma de comunicar a QFileSystemViewer ese hecho.

No la hay. La primera en la frente.

***

En cierta medida, esto viene solucionado de aquélla manera. La vista tiene un método para indicarle al documento (???) que monitorice una ruta. Supongo que se le dirá a la vista porque también sirve para indicar que esa es la ruta padre a partir de la cual no se puede descender.

Ciertamente es bastante barroco. ¿Por qué no hacerlo con el documento, ya que es el que realmente mantiene el tema de los archivos? El único handicap es que un sólo objeto del tipo QFileSystemViewer podría servirnos para muchas vistas diferentes, pero con crearnos varios objetos… Además, si queremos diferentes vistas de un mismo documento, este documento ha de ser idéntico para todas ellas, por lo que la idea de un solo documento para todo no nos vale. Simplemente no lo entiendo y punto.

***

El bug. A ver, cuando uno llama a setRootIndex() pasándole un contexto a una ruta, la vista no descenderá de ese punto, y el documento instala un QFileSystemWatcher que monitorizará esa carpeta y actualizará la vista en consecuencia.

Así es cómo funcionan mantener y leer las actualizaciones de ficheros.

El problema es que no funciona. Da igual que crees una nueva carpeta o un fichero, el sistema no se entera de la actualización. Y como no hay forma de indicarle que el sistema de ficheros ha cambiado…

***

La solución. Es un poco barroca (y lenta), pero es que no me ha funcionado ninguna de las otras soluciones encontradas en internet.

Tenemos que cambiar la ruta de monitoreo a una que no nos interese y de nuevo a la que nos interese. Algo así:

//The only way I've found to refresh after some update

QFileSystemModel *pModel=static_cast<QFileSystemModel *>(ui.listView->model());

pModel->setRootPath(m_ruta+”..”);

pModel->setRootPath(m_ruta);

pModel->sort(0);

El programa se queda como autista cosa de un segundo y la vista o vistas quedan actualizadas.

***

Esto me ocurre en una unidad de red montada mediante la compartición de carpetas de vmWare Fusion, por lo que el problema también podría estar en la capa del OS X, la del vmWare y la de red del propio Windows, pero el tema es que no funciona.

***

Otra cosa que he vi ayer, fue que, tras unas cinco horas de trabajar con el escenario mixto de máquina virtual Windows sobre OS X, ésta se fue volviendo cada vez más lenta hasta ir arrastrándose… Ignoro a qué se debe, así que hoy estaré más atento. De momento ya he visto que, tras lanzar un programa escrito con QT, la memoria no recupera unos 200 megas. Espero que sean cachés y no otras cosas más indefinibles.

QT: QFileSystemViewer a partir de una ruta

Rafael Ontivero — Tue, 10 Jul 2012 15:59:41 GMT

Esto es un “truco” que he encontrado de refilón y lo voy a anotar aquí para que no se me olvide y para goce y disfrute de quien me lea.

La idea es utilizar el modelo documento/vista de QT para navegar a través del sistema de ficheros, pero solo a partir de una ruta en concreto.

Si lo utilizamos conforme a la documentación, el árbol de ficheros se verá completo, con todas nuestras carpetas y ficheros. Nosotros queremos que la raíz del árbol sea una ruta cualquiera.

QFileSystemModel *model=new QFileSystemModel;

QModelIndex index=model->setRootPath(“ruta_a_limitar”);

ui->treeView->setModel(model);

ui->treeView->setRootIndex(index);

En donde treeView es un QTreeView.

Compilar wxWidgets en mac

Rafael Ontivero — Wed, 04 Jul 2012 11:24:00 GMT

Decía ayer que wxWidgets podría ser una buena herramienta para desarrollar aplicaciones multiplataforma a partir de un único código fuente, quizás incluso mejor que QT ya que utiliza los controles nativos allí donde los haya.

WxWidgets es muy similar a MFC en cuanto a jerarquía de clases y a “concepto”, y de hecho el paso de una tecnología a la otra es mucho menos traumático que el paso, por ejemplo a QT. De wxWidgets se han dicho muchas cosas negativas. Que si no soporta excepciones, que si ocupa mucho tamaño, que si es muy complicada, y en general que tiene una arquitectura obsoleta.

Personalmente creo que ninguna de esas cosas es cierta, no al menos en el sentido en que se dice. Ciertamente su jerarquía de clases no tiene excepciones, pero nadie impide que las uses en tu código. Otra ventaja es que su API es genérica para todas las plataformas, y que tiene un montón de clases de soporte que nos evitan la compilación condicional.

Por ejemplo, tenemos soporte directo para impresión, depuración, bases de datos, modelo documento/vista, arrastrar y soltar, ficheros de configuración, sincronización y threads, protocolos de red, OpenGL y hasta para la creación de diagramas…

Aparte existen varias herramientas de soporte, algunas de ellas realmente buenas aunque sean de pago. El problema es que sólo están disponibles para Windows, y tendremos que tener la clásica solución de una máquina virtual bajo OS X.

La única pega para desarrollar bajo MAC es que, hasta hace bien poco, el Framework estaba basado en Carbon (ya sabéis, el API de C de OS X que ya está obsoleto), pero la última versión, la 2.9.3 soporta compilar sobre Cocoa y 64 bits sin problema alguno.

Otra pega es que tenemos que compilarla nosotros, ya que sólo se distribuye en código fuente. Para Windows ya lo expliqué hace tiempo. De todos modos no es muy difícil una vez que has atinado con las opciones adecuadas.

***

Lo primero es bajarnos el tema, de aquí. Os recomiendo que elijáis la opcion de “With Unix line endings (for Unix and OS X). Yo lo he descomprimido en mi HOME, a partir de una carpeta que he llamado “wxWidgets”. Debemos entrar en ella, y una vez ahí, como en todo proyecto tipo Unix, configuramos la compilación:

./configure --with-cocoa --prefix=$HOME/wx --enable-stl --disable-shared --with-macosx-version-min=10.7 --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/

Una vez hayamos terminado, un simple make seguido de otro make install nos dejará el sistema listo y en producción.

***

Fijaos en las opciones que he elegido. “—With-cocoa” hace que se compile con el API de OS X actual, y con la de “—prefix” le estamos diciendo que use nuestro HOME para no enmarranar las carpetas del sistema operativo. Esto es muy útil porque si luego queremos desinstalarlo tendremos problemas.

Con “—disable-shared” le estamos diciendo que queremos las bibliotecas estáticas y no las dinámicas. Si vamos a poner alguna aplicación en la Tienda, es la mejor opción, ya que nuestro programa será un único ejecutable.

Y finalmente las dos últimas opciones. Yo he puesto Lion (10.7), pero vosotros podéis poner Snow Leopard (10.6). Si os fijáis, la ruta de los SDK ha cambiado en las últimas versiones de Xcode. Recordadlo para otras ocasiones.

Se me olvidaba comentar que necesitamos instalar las “Command Line Tools” para poder compilar cualquier cosa desde la consola de comandos. Abrimos Xcode, nos vamos a las Opciones (Command + ;) y las seleccionamos de allí.

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

Alfred: Cómo lanza aplicaciones dentro de vmWare

Rafael Ontivero — Tue, 26 Jun 2012 08:22:49 GMT

Escenario.

Quieres (o ya tienes) aplicaciones virtualizadas en el Dock. Es decir, tu tienes un programa dentro de una máquina virtual vmWare y quieres lanzarla desde el Dock sin más.

Para ello, una vez que la máquina virtual está en modo Unity, lanzas la aplicación desde el menú de vmWare y te aparecerá el icono de la misma en el Dock. Ahora sólo tienes que, con el botón derecho del mismo, elegir “Opciones -> Mantener en el Dock”.

La próxima vez que quieras lanzarla, con hacer clic sobre dicho icono es suficiente para que se abra la máquina virtual y tu programa de forma completamente transparente. Si la máquina está en modo Unity la aplicación se abrirá como una más del MAC. Si no, lo hará dentro de la ventana.

Vale.

Problema

Ahora queremos poder lanzar esa aplicación desde un atajo de teclado. Hace tiempo expliqué cómo hacer algo similar con Automator y una serie de pasos. No sé si funcionará en el caso que nos ocupa, ni me importa mucho ya que ahora tengo instalado Alfred y su Power Pack, que es lo que realmente debería traer OS X de serie…

Solución

Alfred con el Power Pack tiene la opción de lanzar cualquier aplicación con una combinación de teclas que, creo, se superpone a las del sistema operativo. Hacerlo para cualquier aplicación es completamente trivial, pero para las aplicaciones internas de una máquina virtual es harina de otro costal.

Mirando aquí y allí, he descubierto que el Dock guarda la configuración de los programas que tiene en su barra aquí: ~/Library/Preferences/com.apple.dock.plist

Si abres dicho fichero con xCode te encuentras una serie de items numerados. Hay que buscar el que nos ocupa, y en la rama “file-data -> _CFURLString” tenemos lo que nos interesa: la ruta al arhivo que el sistema usa para lanzar el programa que nos interesa.

Una breve inspección nos dice que, para cada máquina virtual, y dentro de su bumdle, existe una carpeta llamada “Applications” que contiene un fichero por cada aplicación “exportada” por la máquina virtual.

Ahora ya sólo nos queda añadir el fichero deseado al lanzador de aplicaciones de Alfred.

Supongo que los que usáis Parallels tendréis algo equivalente.

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:

Ingeniería inversa de una aplicación Metro: más fácil que nunca

Rafael Ontivero — Tue, 05 Jun 2012 14:18:15 GMT

Andaba yo esta mañana mirando mis fuentes de noticias cuando me encuentro con esta entrada: Your Metro-style app needs protection and here is why.

En principio no me lo creí, o pensé que el contenido venía de versiones anteriores a la última Release Preview de Windows 8. Pero no, es completamente cierto.

Todos debéis saber que realizar ingeniería inversa a un programa escrito en .NET es cosa de minutos y es una tarea enormemente sencilla incluso si la aplicación está ofuscada. Si no lo está, podemos obtener el código fuente completo tal y como lo escribió el autor, y encima en el lenguaje que queramos.

Esto nos da un truco muy sencillo para usar código de terceros escrito en un lenguaje .NET que no conocemos. Tomamos el código a copiar, creamos una aplicación, le aplicamos un Reflector (que es como se llaman a estos programas) y obtenemos el código fuente en el lenguaje deseado, ya sea VB.NET, C# o incluso C++/CLI.

Si el programa está ofuscado la ingeniería inversa es algo más difícil, pero con un poco de práctica es posible convertir el resultado en algo legible. No obstante, si queremos copiar un bloque de código o ver cómo está hecha una cosa, no necesitamos más. Copiamos, pegamos y listo. A ver, no es tan fácil, pero un ofuscador de código lo único que hace es cambiarle el nombre a todo y allí donde es posible, separar o juntar cosas. Nada que un experto medianamente espabilado no pueda deshacer.

Pues bien, las aplicaciones Metro en Windows 8 todavía son más fáciles de desensamblar. Estoy intentando instalarme un programa de demo, pero todavía no sé cómo se hace localmente pese a tener el paquete listo para su instalación.

Mientras averiguo eso, podéis jugar un ratín como he jugado yo. Lo primero de todo es hacer que la carpeta “C:\Program Files\WindowsApps” esté visible. Para ello abrimos la ventana de Windows Explorer en el escritorio y en la opción “View” del menú, seleccionamos “Options”. Allí, en la pestaña “View”, marcamos “Show hidden files, folders and drives” y ya de paso, también “Hide extensions for known file types”, que no es imprescindible pero ayuda.

Ahora ya podemos ver la carpeta WindowsApps. Desde el explorador de Windows nos dice que no podemos entrar. Podríamos tomar control de la carpeta, pero al menos yo no lo he hecho, ya que abriendo una consola de comandos con permisos elevados podemos entrar y ver el contenido:

Vaya. Tenemos acceso a todas las aplicaciones Metro instaladas… Aunque podemos navegar por ellas desde la ventana de comandos, también podemos copiarlas a otro destino con el comando “xcopy <origen> <destino> /r/s”. Y eso es lo que he hecho. Me he movido el “Reader” de Microsoft.

Y ahora puedo entrar sin tocar nada de nada:

Interesante, ¿no? Tenemos archivos XAML, ejecutables, imágenes, metadatos, todos ellos al alcance de la mano. Dos pantallazos más:

Creo que es suficiente, ¿no?

Pues no, ahora vamos a abrir y desensamblar algún ejecutable. La aplicación Reader que hemos estado viendo parece ser que es binaria (luego volveremos sobre ello), pero por ejemplo la “BingFinance” es .NET pura y encima está sin ofuscar:

En la imagen de arriba vemos dos ficheros de dicha aplicación abiertos de… esto… piernas.

***

Pero todavía hay más. Vamos a echar un vistazo a un par de aplicaciones escritas por uno mismo. La primera es un SplitView en C++ tal y como sale del asistente de Visual Studio 2012RC. Entre otras cosas genera dos ficheros “ejecutables”. Un EXE tradicional, que es binario o al menos así lo parece, y otro con la extensión Winnmd y el mismo nombre. Este sí que es manejado, pero parece ser que sólo contiene las exportaciones a WinRT. Tampoco tengo claro qué es, aunque parece ser que WinRT necesita las exportaciones del programa y MS lo ha solucionado de esta manera. En fin, aquí esta:

Ahora veamos la misma aplicación tomada del asistente de C#. En este caso sólo hay un ejecutable, el propio programa que es desensamblable por completo:

***

¿Os mola? A mi nada de nada. Esperemos que Microsoft se ponga las pilas con esto, porque si no mal vamos.

Un poco hasta los cojones del OS X sí que estoy, la verdad

Rafael Ontivero — Fri, 01 Jun 2012 14:02:55 GMT

No sé quién diría eso de en MAC eso no pasa, pero el hecho es que, a fecha de hoy, OS X Lion no llega ni a la suela de los zapatos de Windows 7. Esperemos que el Montañés mejore algo, porque lo que es la versión actual, es un mucho mierdosa.

Aparte de las infinitas carencias en usabilidad, con un Finder al que hay que meterle diez extensiones o instalarse sustitutos para se que acerquen un poco al Explorador de Windows, los programas más o menos mierdosos que necesitan sustituto (léase Mail, iCal, …), las porquerías del Spotlight que unas veces va lentísimo, otras antepone los propios programas de Apple a otros de terceros aunque los de origen no se hayan usado nunca (y por eso uso Alfred), la necesidad de gastarte una pasta en sustitutos que en la mayor parte suelen ser gratuitos en Windows, las pifias de programas serios como iPhoto que unas veces sí y otras también es incapaz de recordar que tengo activo el photo streaming, los petes del Pages porque él lo vale y que me hace rememorar las primeras versiones de Open Office, que cascaban o iban mal sí o sí, los enganches y autismos varios del iTunes, la ruedecilla multicolor de la muette, que aparece de vez en cuando, sobre todo en Safari, la lentitud en arrancar el sistema completo…

… Todo eso, a lo que hay que sumar la pésima gestión de memoria y, ahora mismo, dos problemas con el kelmer o que creo que vienen directamente del mismo.

***

Tengo un monitor secundario enganchado a un puerto Thunderbolt pero usado como DVI con su adaptador correspondiente. Pues bien, cada dos por tres pierde lo que quiera que pierda y ambas pantallas se ponen a parpadear. La anexa porque se ha perdido, y la principal poniendo y quitando el escritorio como si eso fuera a solucionar en algo la otra pantalla.

***

El otro problema viene con el puerto de la SD, que sólo me permite insertar una tarjeta por reinicio. Sí, una vez que he insertado una tarjeta, y tras su expulsión, ya no vuelve a leer nada de ella.

***

En ambos casos no es el hardware, porque en Windows con Boot Camp en ningún momento me ha pasado nada parecido. Es el *** OS X que, tras cada actualización, va peor que la anterior.

***

Y ya para finalizar, ¿quién es lumbrera al que se le ha ocurrido poner el puerto de la SD justo debajo de la ranura del DVD? Porque manda cojones, mucho diseño, mucha tontería pero lo dicho: ergonomía poca o ninguna. Justo hace un momento casi tengo que desmontar mi iMAC (que todavía está en garantía) porque he metido por error la SD en el hueco del DVD…

En fin, que mucho ruido pero pocas nueces.

***

Perdonadme la entrada, pero creo que tengo razón al quejarme de todas estas cosas y de más que no os cuento porque tengo la duda de si es el layer 8 o el sistema.

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.

C++/CX (IV). Clases parciales

Rafael Ontivero — Fri, 18 May 2012 15:10:00 GMT

Éramos pocos y parió la abuela. ¿Sabéis por qué C++/CLI (el C++ de .NET) se quedó en la cuneta en eso de ser a first class .NET language (o en cristiano: un lenguaje .NET de primera clase)? Efectivamente, la ausencia de clases parciales.

Cuando Microsoft introdujo el .NET 3.0 también cambió la forma de entender la interacción con la parte visual. Si bien antes las ventanas se construían con código, aunque de forma más o menos automatizada gracias al diseñador visual (hablamos de Windows Forms), a partir de ese momento se implementó una nueva forma que, pese a ser una idea cojonuda, peca un poco de mal implementada, como casi todo lo que hace la casa.

Los viejos lobos de mar nos hemos defendido con las plantillas de cuadro de diálogo, que definían los tales mediante una serie de palabras claves. Luego Windows se encargaba de leer la versión binaria de ese texto y nos construía nuestro cuadro de diálogo.

Pues bien, XAML es la enésima reencarnación de lo mismo, pero con esteroides. Y digo enésima porque por ejemplo Delphi, C++ Builder e incluso el ya vetusto VB6 lo hacían más o menos así.

XAML es un lenguaje (lo que me cuesta llamarlo así) XML que define la estructura de una ventana y todos sus componentes. La idea es tener algo que nos defina por completo, y de forma independiente del código, la parte visual de un programa y que encima se pueda crear tanto de forma manual como con programas… Eso sí, léete tu un fichero XAML escrito con Blend, que lo vas a flipar en colores.

Bueno, a lo que vamos, XAML tiene que poder interactuar de alguna forma con el código. Para evitarnos cosas como MFC, Microsoft permitió que se pudiera definir una misma clase en más de un fichero. Y nacieron las clase parciales.

La idea es bien sencilla. XAML conoce una parte de la clase que define la ventana, y el programador conoce otra. Luego el compilador las une y hemos conseguido nuestro objetivo.

Pues bien, C++/CX implementa clases parciales de forma casi idéntica a C#. Es la única forma de que C++ pueda entenderse con XAML sin hacer virguerías todavía peores.

En resumen:

No está definido en el estándar de C++11.

Sólo funciona para ref class. O en otras palabras: no vale para código C++ clásico ni para la parte clásica de una aplicación Metro escrita en C++/CX.

Se añade una nueva palabra reservada, partial, que debe ir en todas las declaraciones menos en una.

Tomándolo del artículo en inglés en el que me baso, os pego un ejemplo:

// foo.private.h

#pragma once

partial ref class foo // <- here the partial keyword is used

{

private:

int _id;

Platform::String^ _name;

};

// foo.public.h

#pragma once

#include "foo.private.h"

ref class foo // <- partial keyword is not used here

{

public:

int GetId();

Platform::String^ GetName();

};

// foo.cpp

#include "pch.h"

#include "foo.public.h"

int foo::GetId() {return _id;}

Platform::String^ foo::GetName {return _name;}

Es decir, cuando declaremos una clase en varios ficheros, todos ellos deben llevar la palabra reservada partial excepto uno de ellos, que hará de concentrador. Supongo que esto facilita la tarea del compilador, que irá anotando las partes parciales y las irá añadiendo poco a poco a la otra de forma dinámica y conforme se vaya encontrando el código. Y finalmente, en uno o más CPP definimos los métodos y demás. Aquí ya no hace falta para nada la palabra partial porque eso ya lo podíamos hacer antes sin problema alguno.

Esto nos lleva al dibujo siguiente, tomado también del artículo citado:

Eso es lo que hace Visual C++ a la hora de crear una ventana, generando estos cinco ficheros. El XAML contiene la definición de la ventana y todo lo que pongamos dentro, y es idéntico a uno generado en C#. También genera otros dos con los nombres terminados en .g.h y en .g.cpp, que contienen código necesario para que el sistema pueda enlazar el archivo XAML con el código fuente que hayamos podido editar, que a su vez reside en otros dos sendos ficheros con las extensiones de .xaml.h y .xaml.cpp.

Nuestro código debe ir en los ficheros terminados en xaml (para la definición de la parte visual), xaml.h (para la declaración de la clase que representa la ventana) y xaml.cpp para todo lo demás.

Debemos ser muy cuidadosos en no tocar los otros dos ficheros, que suelen ser generados de forma automática al vuelo por Visual Studio (y supongo que por Blend, pero eso no lo he probado todavía) y que, si hacemos algo mal, podemos tirar abajo el diseñador y luego la aplicación no se cargará bien. Digamos que dichos ficheros son los equivalentes al InitializeComponents() de WindowsForms y que, si los tocamos sin conocimiento de causa, podemos dejar inservible nuestra ventana.

Os dejo que juguéis con lo descubierto. Creaos una aplicación vacía, ponedle un botón o lo que querás y añadidle un evento.