Iniciando con SPA y Hot Towel

Ciertamente no soy un gurú en ASP.NET y en general con .Net (como si lo soy en Delphi 😉 …) así que cuando estuve investigando para un nuevo proyecto de Single Page Application (SPA) y ASP.NET, encontré Hot Towel lo que me pareció exactamente lo que necesitaba.

Para empezar que es Single Page Application?, bueno como su nombre lo indica es básicamente una aplicación web de 1 sola página, tal y como suena. La pregunta es si es 1 sola página entonces no tiene más que 1 contenido estático y no sirve para nada. Y bueno acá esta la diferencia. Es técnicamente 1 sola pagina web (imagina 1 sólo archivo .html) pero cuyo contenido o parte de éste cambia gracias a un mecanismo que nos permite agregar o reemplazar fragmentos de html en tu única página web. El mecanismo para hacerlo es usando AJAX (o algo que nos permita la misma capacidad de hacer llamadas al servidor como websockets). Es probable que ya hayamos usado esta técnica antes, solo que bueno ahora tiene nombre y esta de moda. Personalmente he hecho aplicaciones así con 100% Python y también con ASP.NET.

Las ventajas de una SPA son varias, por ejemplo una experiencia de usuario más fluída ya que no se carga toda la página por completo, y una respuesta más rápida por la misma razón. Cierto es que al estar todo en una misma página, hay que tener más cuidado con el código javascript, ya que puede crecer demasiado y podemos perder el control.

Otro punto es que, dependiendo de la estrategia que uses, la programación se hace más sencilla. Puedes tener simplemente páginas html + css + javascript y en el backend solo un servicio web que provee la data vía JSON o XML con métodos como REST, simplificando enormemente la arquitectura, y haciendo más evidente la separación de la capa de presentación de la de datos.

Ahora Hot Towel es un template para Visual Studio que nos permite tener una aplicación SAP como por arte de magia, incorporando y configurando un grupo de librerías como:

  • jquery
  • knockout
  • boostrap
  • breeze

Lo simpático de Hot Towel es que sin escribir nada ya está todo configurado y listo para usarse evitando tener que hacer configuraciones manuales, y como la instalación es con NuGet más fácil imposible.

 

Anuncios

Instalando app Android en el dispositivo

Después de hacer la pequeña aplicación de Demo del post anterior solo quedaba probarlo en el dispositivo. Ciertamente hay varias formas de hacerlo, pero como yo estoy en el proceso de desarollo y debug todavía quería hacerlo directamente desde Eclipse. Para esto es necesario tener instalado el “adb” Android Debug Bridge. Este se instala junto con el SDK de Android y lo encontramos en la ruta “C:\Android-sdk\platform-tools\adb.exe”

Luego será necesario tener el driver necesario para el aparato que usamos, en mi caso como ya dije el Samsung Galaxy S WiFi 5″. En la página http://developer.android.com/guide/developing/device.html  está la información oficial de la página de Android.

En está página están los link a los drivers de varios fabricantes: http://developer.android.com/sdk/oem-usb.html  sin embargo me fué imposible encontrar lo que necesitaba ahi, si alguien me da el link oficial se los agradeceré! Sin embargo navegando navegando encontré está página http://forum.xda-developers.com/showthread.php?t=961956donde encontré lo que necesitaba. La primera vez que lo instalé no pasó nada. Volví a instalar y ahora si!! Para verificar la instalción conectas el dispositivo a la PC con un cable USB y luego vas hasta la ruta del adb y ejecutamos:

adb devices

y si todo fúe bien debería aparecer un código de identificación del dispositivo.

Ahora en Eclipse ejecutas como lo harías para el emulador y la aplicación se transferirá al aparato y se ejecutará:

Iniciándome con Android

Esta semana gracias a mi madre, tengo ahora una tableta Samsung Galaxy S de 5″ y 8Gb con conectividad Wifi de la promoción de tiendas Wong. Asi que qué mejor para probar la programación en este sistema operativo, y por fin portar nuestra aplicación Dataware a este SO móvil y ampliar nuestra oferta más allá de J2Me y Windows Mobile (6.5 para abajo por supuesto)

Este juguetito viene con las siguientes características:

  • Versión firmware 2.2.2
    Versión kernel 2.6.32.9 se.infra@SEI-28 #1
    Número de compilación FROYO.VXKE1
  • Resolución 800×480

El aparato es realmente una belleza, hubiera preferido quizás uno de color negro, pero el blanco no está nada mal. La pantalla es impresionante y la sensibilidad también. Aún no lo he usado mucho pero so far so good.

Sobre el tamaño bueno yo lo siento muy bien, es como un celular enorme pero delgado. Para mi esto está ok ya que el dispositivo objetivo de nuestras aplicaciones son los celulares y el comportamiento de este se semeja más a estos que a una tablet.

Ya tenía instalado el Eclipse:

  • Version: Helios Service Release 2
    Build id: 20110301-1815

A continuación los pasos que he seguido para iniciar el desarrollo.

Continúa leyendo Iniciándome con Android

Delphi XE2 y Firemonkey (ii) Direct2D y Windows

En post previo sobre Delphi XE2 y Firemonkey expresé mis dudas sobre el uso de Direct2D en Windows previo a Vista.

Como indicara en el mencionado post, la información disponible sobre Firemonkey daba cuenta que en su implmentación para Mac OSX (y iOS? ) usará OpenGL y en Windows usará DirectX para 3D y Direct2D para 2D en plataforma Windows.

Como ya sabemos Direct2D sólo está disponible preinstalado a partir de Windows 7 y disponible en Vista via una actualización. Pero, y en XP (probablemente la base instalada más grande de Windows)???. La pregunta se caía de madura, habrá soporte en esta versión? Asi que le hice la pregunta al propio Andreano Lanusse y la respuesta fue:

Cases where Direct2D is not supported, like Win XP FireMonkey will use GDI+.

Michel Swindell también respondió en el mismo sentido:

on Windows if D2D is not available, FM will use GDI+ for HD vector forms/controls.

Bueno al menos estará disponible, habrá que ver como se comporta ya que GDI+ no es acelerado por hardware, ya que definitivamente las capacidades requeridas para Firemonkey lo hacen inviable con GDI puro.

En un post posterior Andreano Lanusse, contesta las interrogantes surgidas sobre el uso de Firemonkey a través de MS RDP (Remote Desktop), en esta da cuenta de que si el servidor es un un Windows Vista/7  “físico” no tendrá ningún problema ya que estas versiones de Windows soportan 3D en RDP. Si es Wiindows Vista/7 virtualizado en algún entorno sin GPU como XenApp y VmWare ESX, soportará la parte 2D de Firemonkey usando GDI+, la parte 3D se pierde por que no hay una versión de software para estas capacidades. En el caso de un servidor RDP con Windows XP, en esta versión RDP no soporta 3D y la parte 2D como ya dijimos será con GDI+.

Ahora, por que no se usó OpenGL en Windows? pudo ser, pero este no viene preinstalado asi que es una limitante. Además está documentado que los drivers nativos para OpenGL en Windows no son muy pulidos y dan problemas.

DirectX está disponible desde Windows 95, por que no se usó directamente DirectX en lugar de Direct2D para la parte 2D? Bueno me imagino que fue por que hacer 2D con Direct2D es muchisimo más fácil que hacer 2D con DirectX, que si se puede pero la API ya es bastante densa para 3D, usarla para 2D debe ser horrible. Hay que recordar que Direct2D no es si no una capa encima de DirectX. Esto me hace pensar que Embarcadero pudo crear su propia capa 2D, pero realmente seria mucho esfuerzo y encima sujeto a los múltiples mutaciones que Microsoft le ha hecho al DirectX.

Solo nos queda esperar para poder poner a prueba todo el poder de Firemonkey, en todas las plataformas

Delphi XE2 y Multiplataforma

Realmente la nueva versión de Delphi, la XE2, me tiene más que entusiasmado.

Una de las características más saltantes, es en definitiva el soporte multiplataforma.

Delphi no es nuevo en este sentido, ya hace varios años atrás tuvo un ingreso promisorio pero fallido en el terreno de Linux con Kylix, que no era sino Delphi para Linux, toda la IDE completa funcionando sobre esta plataforma. En aquella época la solución a la compatibilidad de entornos gráficos se hizo reemplazando la VCL, que está atada a la API de Windows, con CLX una versión multiplataforma basada en Qt. Sin embargo en ese momento Borland/CodeGear no pudo lograr mantener el producto en el tiempo y finalmente fue dado de baja. Se que hasta hoy hay desarrolladores que siguen trabajando con Kylix, haciendo mantenimiento a software legacy.

Luego de la debacle de Kylix, y como tenía cierta base instalada, surgió un producto llamado CrossKylix, que ofrece desde Delphi para Windows, compilar para Linux usando el compilador por línea de comandos del Kylix. Este tuvo cierta aceptación, pero su creador no fue bien visto a ojos de Borland/CodeGear.

Ya desde el 2008 se vienen escuchando pasos con respecto al soporte multiplataforma. Por supuesto la primera y más obvia petición de los desarrolladores era algo tan sencillo como compilación para Win64, algo que los usuarios de VisualStudio y Java ya gozaban.

En ese momento Delphi toma una decisión interesante: debian cambiar el concepto de su propio compilador, necesitaban un Cross Compiler, es decir que desde el propio Delphi para Windows (x32) se pudiera compilar para diversas plataformas. Es por esto que el soporte para Win64 a demorado tanto tiempo, para que éste encajara en la nueva arquitectura del compilador.

Delphi XE2 viene con esta tecnología de Cross Compiler, ahora uno va a poder programar en el Delphi para Windows de siempre y compilar para:

  • Win32
  • Win64
  • Mac OS X
  • iOS (!!!!)

y producir aplicaciones nativas. Como se ve no hay Delphi para Mac, es el Delphi para Windows compilando para Mac. Nótese que para el caso de Mac y iOS por restricciones (me parece) de Apple es necesario producir el ejecutable final con la herramienta propia de Apple, el XCode, pero sin necesidad de escribir una sola línea en el oscuro Objective-C.

Bajo esta nueva arquitectura la parte visual multiplataforma esta soportada por el nuevo Firemonkey, para poder ver en acción al nuevo Delphi pueden darle una mirada a este video en el blog de Andreano Lanusse:

En el reporte que hiciera Joylon Smith sobre el lanzamiento de Delphi XE2 en Auckland, indica también lo siguiente:

  • Native Android apps – using PhoneGap in RadPHP
  • Native Android apps – to come in the future for Delphi (as well as Linux)

Ajá!!! Con la nueva versión de RadPHP también se podrá compilar para Android, empleando como intermediario PhoneGap, este producto muy interesante permite crear aplicaciones en HTML5 que puedan usar las API nativas de varias plataformas (como Android por ejemplo).

Sin embargo gracias a la tecnología del Cross Compiler, va a ser posible en corto tiempo tener un compilador nativo para Android. Recordemos que si bien la plataforma de desarrollo  de Android es Java, el corazon del robot verde no es si no Linux, y que además Android provee una API para hacer código nativo empleando NDK (Native Development Kit), que es en C o C++.

Mmmm muy interesante, si el Cross Compiler puede generar código nativo para Android y siendo Mac un sobrino de Unix (sus origenes se remontan a FreeBSD y NetBsd), no debería ser ningún problema crear ejecutables nativos para Linux.

Por qué el soporte para Mac llegó antes que el soporte para Linux? bueno acá entramos al terreno de las suposisciones. La mía es primero que Mac tiene desarrolladores más dispuestos a pagar que los de Linux, segundo que Firemonkey (en su encarnación por parte de KSDev) ya estaba maduro en Mac cuando Embarcadero lo adquirió y tercero me parece que hay algunos  desarrolladores en Embarcadero que usan Mac como plataforma principal (aunque trabajan sobre Windows en forma virtualizada).

Se vienen tiempos interesantes para Delphi, el soporte para Mac OS X y especialmente para iOS definitivamente atraerá miradas…

Delphi XE2 y Firemonkey

Bueno, poco a poco van apareciendo más detalles de la nueva versión de Delphi, la XE2.

Ahora tenemos más detalles de Firemonkey y hasta un logo!! FireMonkey-Medium

Andreano Lanusse ha publicado un blog con más detalles interesantes y hasta un par de screenshoots. Por lo que yo entiendo con Firemonkey no tenemos componentes nativos como en la VCL (que seguirá existiendo), si no que todos son dibujados por este framework. Lo bueno de esto es que se consigue libertad absoluta sobre el diseño del control. Otro punto interesante es el soporte en Firemonkey de Styles, que al igual que CSS permitirá crear temas y lo que es mejor aún lograr un look and feel (casi) nativo en cada plataforma, lo cual es muy importante para las aplicaciones para Mac y no herir susceptibilidades. Continúa leyendo Delphi XE2 y Firemonkey

Delphi y UI acelerados por hardware

Tradicionalmente Delphi ha usado las APIs que le provee Windows para dibujar sus controles, es más, los controles propios de Windows son dibujados por el sistema operativo y no por Delphi.

Windows, hasta el Vista usaba GDI para realizar estos dibujos. GDI es una API en C, para gráficos en 2D, es decir líneas, curvas, rectángulos. Internamente esta es la API que usa Windows para dibujar sus controles.  Esta API es rápida pero limitada, ya que no soporta antialiasing, ni transparencias. Sin embargo es muy rápido ya que era (hasta el Windows Vista)  parcialmente “acelerado por hardware”, esto quiere decir que algunas operaciones eran realizadas por el procesador gráfico GPU.

Al salir Windows XP, se creó un nuevo subsistema gráfico llamado GDI+ (GDI plus). Esta API en C++ ofrecía mejoras en la calidad de los gráficos ya que soportaba anitaliasing y transparecias, pero sigue siendo una API para gráficos en 2D. Estas nuevas características son realmente notorias para gráficos de alta calidad, con bordes suavizados tanto en en las lineas y curvas como en el dibujo de las letras (fonts). Sin embargo esta API trabaja integramente por software, es decir no es acelerada por hardware lo que hace que sea mucho más lento que GDI, claro que para gráficos sencillos sin mucha animación como son las interfaces de usuario tradicionales puede no ser muy dramático.

A partir de Windows Vista, Microsoft desarrolló una tecnología diferente para soportar “Aero” que es su nuevo manejador de ventanas “Desktop Window Manager (DWM) composition engine”. Este manejador está basado en DirectX. DirectX es una API de para gráficos 3D y es acelerada por hardware (asumiendo que la tarjeta gráfica soporte DirectX v9, que es el caso de todas las tarjetas modernas). Estas capacidades permiten gráficos de alta calidad usando menos CPU y de forma más rápida.

Continúa leyendo Delphi y UI acelerados por hardware