Manejo de la clase Task

Task Parallel Library (TPL)

Desde Framework 4 en adelante , nos encontramos con el concepto de Task para el manejo o ejecución de tareas asincronas. Realmente es una librería muy útil e intuitiva .

Pongámonos en la situación que queremos realizar una tarea asincrona, ya que sabemos que nos va a requerir demasiado tiempo, y si la ejecutásemos sincronamente esto provocaría el bloqueo de la aplicación hasta su finalización.

Para lanzar una rutina asincronamente utilizando el objeto Task únicamente necesitaremos  las siguientes lineas de código:

 Task mainTask = Task.Factory.StartNew(() =>
 {
                for (int i = 0; i < 100000; i++)
                {                
                    Console.WriteLine(String.Format("Msg {0}",i));
}
});

Bien, con este simple código, conseguimos realizar el printado por pantalla de 100.000 mensajes sin que provocar que el sistema se quede bloqueado.

Ahora, imaginémonos que hay la posibilidad de cancelar una Task, a demanda del usuario . Como podríamos realizar esta operación , si al crear la rutina dentro de una Task, perdemos la referencia a dicho rutina (esto puedes comprobarlo, debugando el código, y observaras que el flujo de la aplicación continua , sin pararse en la rutina de dentro de la Task) ?

Pues de la siguiente forma:

CancellationTokenSource tokenSource = new CancellationTokenSource();
CancellationToken cancellationToken = tokenSource.Token;

Task firstTask = Task.Factory.StartNew(() =>
{
                for (int i = 0; i < 100000; i++)
                {
                    if (cancellationToken.IsCancellationRequested)
                    {
                        break;
                    }

                    Console.WriteLine(i);
                }
}, cancellationToken);

tokenSource.Cancel();

Como podemos observar, únicamente tenemos que crear un objeto llamado “CancellationToken” que deberemos asociarlo a la task, de esta forma , podremos realizar comprobaciones del estado de dicho token, y saber si se ha realizado una petición de cancelación de la Task.

Bueno, como podéis observar es un ejemplo muy sencillo, pero partiendo de este punto , podéis aplicar esta técnica a cualquier problema con mayor o menor dificultad .

Saludos cordiales.

Windows 8 & FrameWork 4.0

Buenos días , antes de nada Felicitar el nuevo año a todo el mundo.

Vamos a comenzar el año , explicando una situación que me ha sucedido y que me ha traído muchos quebraderos de cabeza y que después de solucionarla , era una tontería.

Bien, comencemos:

Escenario:

Por motivos que no vienen al caso , imaginaros que os veis obligados a reinstalar el framework 4, si en algún momento se os ocurre des instalarlo e intentar instalarlo nuevamente, es posible que os encontréis que este segundo paso “volver a instalarlo” os es imposible , ya que os dirá que sigue instalado .

Si te pones a buscar o “Googlear” un poco, verás y encontraras multitud de post que te indican que te descargues el paquete del MSDN y que instales y listo, quizás tienes la suerte que esto te funciona ( a mi no me funcionó para nada ), si no es así, esto es lo que puedes hacer:

Solución:

Reparar Visual Studio 2012 y el solito se encarga de instalar otra vez las versiones de Framework necesaria para su funcionamiento .

Vaya tontería verdad, pues esto me ha ocasionado bastantes horas perdidas :(.

La brillante solución me la dio mi compañero Marc Rubiño (No me cansare de darle las gracias jajaja)

Observaciones:

No lo he comentado , pero el escenario del que os hablo , es una instalación de Windows 8 y VS2012 .

Saludos!

Patrón PRG (Post-Redirect-Get) para ámbito Web

Buenas a todos,

Saludos nuevamente a todos, hacia tiempo que no teneia tiempo para dadicar un rato a escribir en el blog, pero este fin de semana mira por donde no he tenido que trabajar 🙂 y aprovechando las horas libres, que he hecho?? pues navegar un poquito y mira por donde que me encontré con un post en Variable not found muy interesante sobre un patrón que no se le presta mucha atención, pero que nos puede ayudar mucho en ámbito web.

En mi caso , lo utilizo en MVC ya que es lo que mas desarrollo pero tendría la misma validez en ASP.net normal o incluso bajo otras tecnologías web.

Bueno, pasemos a lo importante :

Escenario – problema:

Un escenario muy habitual es que en un proyecto estemos desarrollando formularios o vistas que reciban mediante http-post diferentes campos que una vez tratados y validados desencadenen una modificación en nuestro repositorio de persistencia.

Hasta aquí todo normal, el problema grave es cuando al usuario decide “no sabemos el motivo” utilizar el maldito botón F5 o simplemente actualizar la página, esto provocaría dos inconvenientes:

  1. Nos saltaría una alerta realizada por el navegador informando que estamos intentando reenviar todos los datos del formulario, cosa que un usuario básico lo más probable no entienda y le asuste.
  2. Esta sería el problema importante, ya que al actualizar realmente lo que estamos haciendo es volver a ejecutar toda la lógica asociada al envío de datos.

¿Que hacemos para solucionar este inconveniente?

Esta claro que podríamos realizar toda las comprobaciones necesarias para no duplicar datos ni nada por el estilo, pero ¿podríamos encontrar alguna solución más sencilla y eficaz?

Solución , Post-Redirect-Get

Este patrón proporciona una solución muy sencilla que se basa en que cada método action que se consume mediante una petición post tiene que retornar una dirección a otro método action que será el encargado de retornar la vista con el resultado y no retornar una vista directamente.

Veamos un poco de código:

@using (Html.BeginForm())
{
    @Html.TextBox("ProductName")
    <input type="submit" value="send post" />
}

El método action que implementaríamos normalmente sería algo como esto:

[HttpPost]
        public ActionResult Index(string ProductName)
        {
            // Procesar resultados.
            if (Repository.UpdateName(ProductName)) return View();
            else return View("Error");

        }

Como podemos ver, el método action es ficticio y en sí, no tiene sentido, pero me sirve como ejemplo para situarnos en la diferencia entre una implementación normal y una bajo el patrón PRG.

Ahora el método action bajo PRG

 [HttpPost]
        public ActionResult Index(string ProductName)
        {
            // Procesar resultados.
            var id = "Identificador resultante";

            return RedirectToAction("View", new { id = id });
        }

Como vemos en la segunda implementación esta action no retorna directamente la vista en concreto, sino que procesa la petición principal , guarda en BD el producto o lo que tenga que hacer y como último redirecciona a otra vista que será la encargada de devolver el feedback al usuario final.

Como observamos , en concreto se redirecciona con un parámetro  de esta manera la vista final de feedback sabrá que mensaje mostrar o que operativa realizar.

Bajo este escenario, cuando el usuario llegue a la vista final donde recibirá el mensaje o la pantalla mostrando como queda el producto después de la modificación, ya dará igual que actualice la página o utilice F5, porque lo único que refrescara sera esa página que no tiene ninguna lógica asociada más que la de realizar un feedback.

 

Bueno y hasta aquí este pequeño post.

 

Como siempre espero que os resulte interesante, Saludos!!

Patrón Promise y la gestión de Callback

Hoy vamos a tratar un tema muy interesante, el patrón Promise, esta metodología de programación nos facilita la administración de los callback de las ya famosas funciones asíncronas.

“Es importante que quede claro que el patrón Promise no hace que nuestro código sea asíncrono.”

En cierto modo es una nueva re interpretación del patrón observable . A los que estáis desarrollando para Windows App Store esto no os sera desconocido, ya que es uno de los pilares si desarrollas con Java Script pero hoy obviaremos este punto y nos centraremos únicamente en como lo utilizaríamos directamente en entorno web puto y duro.

Antes de nada, veamos como realizaríamos un diseño de callback en Java Script:

Imaginemos que tenemos una función que nos retorna un resultado,

var Res= DoSomething();
alert(“El resultado es:” + Res);

Patrón Callback

Bien, este mismo código se puede diseñar con Callback y quedaría algo así:

DoSomething(success);

function success(result) {
alert(“El resultado es:” + result);
}

O como a mi me gusta más:

DoSomething(function(result){

      alert(“El resultado es:” + result)

});

De esta forma, estamos dejando la gestión del resultado a la función que pasamos como parámetro  Realizando este tipo de diseño podríamos pasar tantas funciones como quisiéramos dependiendo de los tipos de resultado que pudiéramos recibir, de esta forma:

DoSomething(function (result){
      alert(“El resultado es:” + result);
},function (error){
     alert(“Error:” + result);
});
Ahora observemos como diseñaríamos la función principal:
function DoSomething(successCallback, errorCallback) {
    try {
        //do stuff
        //…
        if (typeof successCallback === “function”)
            successCallback(“Respuesta correcta”);
    } catch (ex) {
        if (typeof errorCallback === “function”)
            errorCallback(“Respuesta erronea.”);
    }
}
Pues este tipo de arquitectura se consideraría el Patrón Callback  el cual nos es muy útil para estructurar de una manera mas coherente nuestro código, pero si tenemos en cuenta que, dependiendo el grade de complejidad que tengan nuestras funciones y que posiblemente alguno de los callback tienen llamadas a otras funciones internas, nos podría resultar difícil seguir el flujo de la aplicación.
Patrón Promise

Lo que nos aporta este patrón es una estructuración y una gestión diferente de nuestras llamadas callback. Esta escrito que un Promise tiene tres tipos de estados, “Satisfecho , Insatisfecho , Fallido“. Una de las diferencias esenciales es que en el Patrón Callback es necesario pesarle por parámetro a la función principal los diferentes callback (succcess, error), en cambio con Promise tenemos una llamada mucho más natural ya que no tenemos que indicarle ninguna función en los parámetros. Veamos como:

function DoSomething() {
    var deferred = $.Deferred();
    try {
        //do stuff
       //——
        deferred.resolve(“Resultado correctp”);
    }
    catch (ex) {
        deferred.reject(ex.message);
    }
    return deferred.promise();
}
Podemos observar que creamos un objeto $.Deferred(); que es un objeto que se desprende de la librería JQuery desde la versión 1.5 (leer mas). Desde ese momento utilizaremos este objeto para cambiarle el estado y como ultimo retornarlo, daros cuenta que cambiarle el estado al objeto seria como realizar las llamadas que recibíamos por parámetros con el Callback.
Como podemos ver, con este patrón, la función principal no tienen que realizar ninguna gestión de que callback utilizar ni ninguna comprobación adicional, únicamente se preocupa de realizar su trabajo y de cambiar el estado al objeto $.Deferred() y sera JQuery quien realizara la gestión de los callback.
Ahora veamos como se consumiría esta función:
       var promise = DoSomething();
        promise.then(function(result) {
            alert(“El resultado es: ” + result);
        },
        function(error) {
            alert(“Error: ” + result);
        });
Bueno, puede parecer un poco complicado pero si realizáis algunos ejemplos veréis que todo lo contrario y sobretodo veréis que este patrón es muy importante en la actualidad.
Como siempre espero que os haya parecido interesante .
Ciao!