Iniciando con OWIN, el inicio de algo grande.

Hola que tal?, en esta serie de Post me voy a enfocar de una manera práctica a este nuevo “bicho” que está apareciendo, y que se va a quedar por un buen rato, que es OWIN. Si no sabes lo que es, te recomiendo que leas los siguientes Links antes de seguir:

Bueno, asumo que ya los leíste, si no, voy a hacer un pequeño resumen de por que es necesario una implementación de este tipo, y la justificación no es inventada por mí, si no voy a escribir lo que dice el Team de ASP.NET.

ASP.NET ha estado presente aproximadamente 10 años, y sin duda a permitido la creación de muchas y muy buenas web apps, (Sitios y Servicios). Pero ya las estrategias de desarrollo han evolucionado, y si bien ASP.NET Web API y MVC responden  a esta evolución de excelente manera, hay que dar un paso más en esta evolución, es aquí donde aparece el proyecto Katana, el cual proporciona un conjunto de componente para las aplicaciones ASP.NET que le permite ser flexible, ligero, portátil y proporcionar un mejor rendimiento, todo esto pensado para la nube.

Luego de haber leído los artículos anteriores, se nos viene a la cabeza de inmediato node.js, que llamó la atención de inmediato con la sencillez de este framework para crear y ejecutar un servidor web. Bueno, los objetivos de katana se enmarcan a la luz de Node.js, no hay misterio ni problemas al reconocerlo,resumir que Katana trae mucho de los beneficios de Node.js sin forzarnos a los desarrolladores, tirar todo lo que ya sabemos de las aplicaciones con ASP.NET. Entonces la idea es que empezar con el proyecto Katana debe ser igual de fácil que introducirse en Node.js.

Vamos a comenzar con el código, y verás, al igual que tú , estoy aprendiendo, así que espero que nada resulte a la primera, ya que encuentro de mucha utilidad, aprender de los errores.

 

image

 

Luego debemos instalar el paquete de Microsoft.Owin.Host.SystemWeb, el cual nos proporciona un servidor OWIN que ejecuta las canalizaciones de solicitudes de ASP.NET (si no tienes claro esto, insisto, lee los artículos Sonrisa)

image

Se van a instalar dependencias como la Microsoft.Owin, que provee helpers y métodos para desarrollar aplicaciones OWIN. Podemos utilizar estos helpers para crear rápidamente un servidor que responda “Hola Mundo”. Vamos a crear una clase y se llamará Startup, puedes notar que se instaló un template:

image

Con lo cual nos crea la estructura básica y le vamos agregar un poco más de código:

 

using System;

using System.Threading.Tasks;

using Microsoft.Owin;

using Owin;

 

[assembly: OwinStartup(typeof(Demo1.Startup))]

 

namespace Demo1

{

    public class Startup

    {

        public void Configuration(IAppBuilder app)

        {

            app.Run(context =>

            {

               context.Response.ContentType = “text/html”;

               return context.Response.WriteAsync(“<h1> Hola Mundo!!</h1>”);

            });

        }

    }

}

Al ejecutarlo tendremos el siguiente resultado:

image

Y si, igual de sencillo que Node.js, pero sigamos avanzando. Una de las máximas de OWIN es que exista una des acoplamiento de componentes como el IIS, es decir, al contrario del ejemplo anterior, que ocupamos la canalización de request de ASP.NET, el cual se soporta en System.Web. Esto de todas maneras no es para nada malo, de hecho añade un gran valor, ya que nos permite tener la flexibilidad y composición de pipeline de OWIN combinado con las capacidades de gestión y madurez de IIS.  Pero hay otros escenarios, en donde no es necesario IIS, por ejemplo , es posible que necesitemos que un servicio del SO tenga una puerta escuchando peticiones Web para configuración , y no queremos tener montado un IIS o un apache solo para eso, si no que el mismo servicio sea el host.

Pasar de portar el host desde IIS a una app de linea de comandos, vamos a requerir agregar un nuevo paquete nuget con el servidor y sus dependencias para iniciar el host bajo esta modalidad. Para esto vamos a tener nuestro servidor en un host Katana llamado OwinHost.exe, y utilizaremos un HTTPListener basado en Katana. Paso siguientes entonces en crear una app de consola y agregar los paquetes correspondientes:

image

Agregamos una clase de partida quedando así:

using Microsoft.Owin.Hosting;

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

 

namespace KatanaDemo2

{

    class Program

    {

        static void Main(string[] args)

        {

            using (WebApp.Start<Startup>(“http://localhost:8888”))

            {

             Console.WriteLine(“Presiona una tecla para detener al server”);

             Console.ReadKey();

            }

        }

    }

}

Con esto le estamos diciendo, que escuche los requerimientos por el puerto 8888 de servidor, en este caso mi equipo. Como puedes apreciar , no hay ninguna referencia hacia System.Web. La clase startup es exactamente igual que el escenario anterior, lo probamos y listo!

image

Y esto es solo el inicio, vamos a crear ejemplos mucho más sofisticados, como ves es un cambio grande pero necesario en términos de arquitectura. Así que nos iremos paso a paso.

Espero que te sirva!

Nos vemos @chalalo.

[Sin olvidar] Web Forms, como detectar y redireccionar usuarios móviles.

Hola que tal?, en este post quería abordar el tema de Mobile y Web Forms, ya hemos visto las facilidades que existe con ASP.NET MVC , o con MVVM, en donde tenemos vistas que, debido a que controlamos todo el código generado, podemos fácilmente incluir algún framework como jqueyrmobile. Pero no hay que olvidar que existe una gran cantidad de sitios que utiliza y seguirá utilizando WebForms, de manera que es siempre necesario revisar el tema de como agregar la posibilidad de detectar los dispositivos móviles con esta tecnología y re direccionar a una vista consistente con un navegador móvil.

Una de las opciones que tenemos en tener un crear una Master Page específica, en donde podemos ocupar los mismos formularios, pero separamos en dos MasterPages, una con la vista normal y la otra con la versión móvil, esto nos permite tener estilos CSS y HTML  de nivel superior,(entiéndase doctype y metas específicos para móviles) , todo esto nos evita duplicar la lógica ya desarrollada

protected void Page_PreInit(object sender, EventArgs e)
{
      if (Request.Browser.IsMobileDevice)
             MasterPageFile = "~/Mobile.Master";
}

Ahora bien, el enfoque anterior, si bien es apropiado para ciertos escenarios, puede no ser adecuado cuando dicha lógica o flujo de trabajo de los formularios no se ajusta a una vista móvil, por ejemplo un carro de compras. En este caso vamos a requerir la creación de un WebForm independiente y exclusivo ara la vista móvil. Lo más usual es que creemos  una carpeta con el nombre “Mobilel” para dejar ahí todas las páginas para móviles ahí. Podemos crear un “segundo” sitio completo, con master pages, css, paginas, etc. Además como se supone una lógica simplificada, no es necesario replicar todo el sitio de escritorio y luego modificarlo, solo lo necesario y pueden compartir la misma lógica de negocio que las paginas de escritorio . Como consejo en esta etapa, te recomiendo tener una capa de negocios consistente ente ambas vistas, además de la utilización de WebServices que puedes acceder mediante jquery en vistas totalmente HTML, mucho más liviano que ocupar webcontrols dentro de un formulario móvil.

Generalmente es conveniente hacer la redirección a la vista móvil solo en la primera solicitud de su sesión de navegación, por las siguientes razones:

  • Facilidad para permitir a los usuarios acceder a la vista normal o de escritorio si así lo desean. Típicamente colocamos un link indicando “Versión de Escritorio”. En este caso, no habría redirección y consulta sobre si es un dispositivo móvil por cada postback.
  • Evita el riesgo de interferir con las solicitudes dinámicas de recursos compartidos entre las dos vistas(móvil y escritorio)

Para lo anterior, lo que debemos hacer, en el archivo Global.asax, es implementar en el método Session_start la siguiente lógica:

void Session_Start(object sender, EventArgs e)
       {
          HttpRequest httpRequest = HttpContext.Current.Request;
           if (httpRequest.Browser.IsMobileDevice)
           {
               string path = httpRequest.Url.PathAndQuery;
               bool isOnMobilePage = path.StartsWith("/Mobile/",
                                                     StringComparison.OrdinalIgnoreCase);
               if (!isOnMobilePage)
               {
                   string redirectTo = "~/Mobile/";
                   HttpContext.Current.Response.Redirect(redirectTo);
               }
           }
       }

Como puedes observar, lo primero que se hace es comprobar la información del httpRequest, de manera de verificar si el usuario  está navegando desde un móvil, luego mediante el path, comprobamos si estamos navegando dentro de nuestra sitio móvil, en el caso de que se cumpla de que estamos desde un móvil, pero no lo estamos en la vista móvil, lo re direccionamos a la vista adecuada.

Otro punto importante es el tema de cache de salida, ya que es posible que un usuario que se hubiese encontrado navegando en una pagina “X Escritorio” cause que se almacene cache para esa página, luego un usuario móvil visita la misma página, va a recibir el cache de salida de la página “X Escritorio” en su vista “X Movil”. Para evitar este problema, le podemos indicar a ASP.NET que varíe el cache de salida según si el usuario es móvil o de escritorio. Para esto agregamos en la declaraciones del webform:

<%@ OutputCache VaryByParam="*" Duration="60" VaryByCustom="isMobileDevice" %>

Con esto estamos indicando que vamos a indicar de manera customizada la variación del refresco del cache de salida en memoria, ahora lo que debemos hacer es agregar el siguiente método en el global.asax:

public override string GetVaryByCustomString(HttpContext context, string custom)
{

  if (string.Equals(custom, "isMobileDevice", 
                                            StringComparison.OrdinalIgnoreCase)) 
       return context.Request.Browser.IsMobileDevice.ToString();

return base.GetVaryByCustomString(context, custom);

}

Eso va a asegurar a los visitantes de nuestro sitio que no van a recibir una salida de cache generada por un usuario de escritorio.

Eso!, ven, no hay que olvidarse de WebForms, aun son muchos los desarrolladores que están con esta tecnología, recordemos también que ahora existe un solo ASP.NET, y tu elijes que condimentos tener en tu sitios.