lunes, 12 de agosto de 2013

Wallet / NFC: Como podríamos aplicarlos


Wallet o billetera, es una aplicación que ya viene por default en Windows Phone 8 como parte del sistema operativo, en muchos artículos podemos encontrar que está, puede ser utilizada como un medio de identificación o instrumento de pago. Algunas de las cosas que nos permite Wallet es:

·  Administrar cupones, Tarjetas de Crédito / Débito  tarjetas de membresía, lealtad, entre otras dentro de la misma aplicación.
·         Vincular elementos de Wallet a aplicaciones
·         Realizar transacciones con NFC.

Entre algunas de sus características esta:

·         La información del Wallet se almacena por aplicación. Es decir que cada aplicación tiene su propio almacenamiento Wallet.
·         Cada aplicación almacena información relacionada con los servicios que ofrece. Por ejemplo, ofertas, transacciones e información detallada de una membresía.
Cabe recalcar que el acceso a los elementos del Wallet es controlado de tal forma que los elementos de nuestra aplicación solo pueden trabajar con los elementos que fueron creados por ella misma o que hayan sido vinculadas a la aplicación por el usuario, de cualquier forma para ciertos tipos de elementos el teléfono solicita al usuario su aceptación para agregar los elementos al Wallet, y cada tipo de elemento puede agregar campos personalizados.

Cabe señalar que Wallet incluye soporte para almacenar el historial de uso de una tarjeta, además de que también incluye soporte de agentes de segundo plano que puede ser utilizado para actualizar datos asociados con una tarjeta o notificar al usuario de algún evento en particular con la aplicación.

Los usuarios pueden almacenar tantos elementos como se requiera y Wallet las almacena de manera segura, también cada elemento se asocia con una aplicación la cual puede administrar transacciones en la tarjeta, si se ha creado un agente, este puede actualizar el balance de la tarjeta además de notificar al usuario de ofertas y/o promociones o cualquier otra información que se requiera enviar al usuario.

El acceso al detalle de las tarjetas puede ser protegido por un pin creado por el usuario, además también pueden utilizarse los elementos de pago del Wallet para comprar elementos en la tienda de Windows Phone.

Después de tener un panorama un poco general sobre esta aplicación, como es que la podríamos utilizar en el mundo real, veamos algunos escenarios en los cuales podríamos aprovechar estas tecnologías.

Escenario 1:

En algunas tiendas departamentales ofrecen en temporadas puntos que tienen un valor monetario, los famosos monederos electrónicos, me ha tocado que no solo las tiendas departamentales hacen uso de este tipo de “Ofertas / Promociones” si no también los supermercados.

Ahora imaginemos que por cada supermercado y tienda departamental nos dan una tarjetita de estas, cuanto espacio ocuparía en nuestros bolsillos cada una de estas. Bueno pues he aquí un buen ejemplo en el cual podemos utilizar estas tecnologías.

Ahora imaginemos que podemos vender una solución a este tipo de establecimientos donde podemos ahorrarles la compra de estas tarjetitas que contienen los puntos. Esto pues además de tener un ahorro se podría decir que contribuimos a no generar más basura, que al final del día es donde terminan estas tarjetas.

Supongamos que en lugar de que nos den la tarjeta nos proporcionen con una terminal y/o aplicación un instrumento de pago electrónico dentro de Wallet, esto como consecuencia pues ya no tendríamos que cargar con tanta tarjeta y solo requeriría una terminal con una aplicación asociada para cada establecimiento que nos haga la transacción de lo que estamos comprando en ese momento.

En el caso de las tiendas departamentales, hay tiendas que solo utilizan su tarjeta como medio de identificación para que el socio pueda realizar sus compras en ese establecimiento, en lo particular me ha tocado que en la entrada hay una persona revisando que tengas la membresía, pero porque no poner una terminal en la entrada donde esta lea un dispositivo móvil (en este caso un Smartphone) utilizando la tecnología NFC, para leer un elemento del Wallet y esta a su vez nos permita la entrada.

Otro punto es que al llegar a la caja el establecimiento tenga una solución que permita agilizar el cobro de la mercancía, ya que hoy en día hay que darle la tarjeta de membresía, el medio de pago y a veces una identificación al cajero, pero porque no una solución que con solo acercar un móvil con Wallet esta sirva de las 3 cosas pero de una forma más ágil. Esto creo yo ahorraría tiempo.

Como podemos ver en este primer escenario tenemos una buena aplicación de estas dos tecnologías.



Escenario 2:

Representemos una experiencia con un cliente, mi cliente se dedica a la venta de artículos al mayoreo y menudeo, mucha de su fuerza de venta es a través de la venta de reparto, es decir que tienen gente contratada que va de puerta en puerta ofreciendo los productos, esta levanta el pedido del cliente y lo almacena en unas handheld, pero supongamos que no nada más venden sus productos, si no también realizan la cobranza a los clientes.

Actualmente lo que hacen estas personas es que o transmiten sus su información por archivo plano, utilizando tecnología 3G, que está bien se puede sustituir con una solución más actualizada como con Windows Azure (pero esto será para otro post). Sin embargo los agentes de pues de algún tiempo llegan a una sucursal y tienen que conectar su handheld en un puerto a la computadora y poder hacer su transmisión de información.

En este escenario como podríamos proponer una mejor solución con las dos tecnologías que estamos platicando, bueno pues se me ocurre poder dar de alta un elemento en el Wallet como una membresía pero que sirva meramente como identificación del agente de venta, que cuando llegue a una terminal en alguna sucursal este de manera más ágil pueda emparejar su dispositivo móvil con NFC para establecer comunicación y que una aplicación comience a tomar la información almacenada en el dispositivo móvil  sin que el usuario tenga que firmarse en alguna pantalla ya que contaríamos con la información suficiente del elemento del Wallet como para poder relacionar toda la información que se está obteniendo.

Ahora dentro del mismo esquema, imaginemos que la aplicación tiene implementado un agente en segundo plano, como lo platicamos en un punto anterior este nos permite notificar al elemento del Wallet información que queremos que le llegue a los agentes, con esto podemos proponer una solución que implemente un agente y este a su vez obtenga información por WCF, para que les informemos a los agentes de promociones que no hayan sido cargadas en los móviles, o simplemente una notificación de que ya tiene n días de no pasar a alguna sucursal para descargar la información, o también que su zona de venta cambio por algún motivo extraordinario.


Considero que el uso de estas tecnologías le vendría bien a este cliente para realizar sus tareas de una manera más ágil y eficaz, ademas de que en lugar de proporcionar a sus vendedores un dispositivo para comunicarse y otro para hacer su labor de venta con un solo dispositivo podría sustituir a estos dos que a su vez se vería reflejado en la reducción de costos ya que no tendrían que adquirir una handheld. 

Escenario 3:

A mí en lo particular me ha tocado que me dan tarjetas de descuento para diversos establecimientos como: restaurantes, farmacias, tiendas naturistas, y porque también las del transporte público, entonces imaginen la cantidad de tarjetas que podríamos tener en el bolsillo, pero porque no podríamos proponer soluciones a todas estas tarjetas, bien se pueden implementar cada una de estas como un elemento del Wallet, donde si voy a un restaurant ya no tengo que sacar mi tarjeta de descuento y mi identificación oficial para que me hagan el descuento en la cuenta si no que se puede proporcionar una solución donde solo se acerque el móvil y este aplique el descuento correspondiente sobre el total de la cuenta.

Esto estaría demasiado bien, ¿porque?, pues porque ya no tendríamos la necesidad de cargar con tanta tarjeta física. Y con el uso de estas tecnologías estaríamos proporcionando soluciones más inteligentes.
En el caso del transporte público, en lugar de estar deslizando una tarjeta para cada tipo de transporte (metro, suburbano, metro bus), porque no tener soluciones más inteligentes que solo requieran acercar nuestro móvil y listo.

Ventajas

Como podemos observar en los diferentes escenarios estamos ahorrando dinero y recursos a los prospectos de clientes puesto que ya no tiene que estar gastando en tarjetas, además de que estaríamos contribuyendo al medio ambiente y proponiendo soluciones más inteligentes y agiles.

Desventajas


Desafortunadamente no todo el mundo tiene un Smartphone que cuente con Wallet y NFC como aplicación y tecnología, sin embargo esto va creciendo y debemos estar preparados para proponer soluciones como estas.


PD: La parte practica se las debo para el próximo Post.





jueves, 3 de enero de 2013

Programación Asíncrona


Hola a todos en este post les voy a platicar un poco de la programación asíncrona, esta se puede entender cuando una operación de larga duración se ejecuta en otro hilo sin que esta operación haga un bloqueo en la aplicación. Algunas operaciones que pudieran requerir de un tiempo de ejecución largo y que sería conveniente programarlas de manera asíncrona serían los operaciones como las de acceso al disco, peticiones en red, lectura y escritura de archivos, etc. 


Probablemente ya hemos utilizado programación asíncrona en alguna ocasión, tal vez utilizamos por ejemplo un ThreadPool para alguna operación, donde el hilo principal era liberado y podía seguir ejecutando las siguientes tareas.

Sin embargo la parte más difícil es que seguramente queremos saber cuándo una operación asíncrona haya finalizado. Para esto requeríamos hacer más cosas, esto se puede resolver en el código de bloqueo porque los métodos se ponen en el orden de ejecución, la contra es el bloqueo de la interfaz. En el mundo asíncrono esto no trabaja así, ya que seguramente la siguiente línea va a correr antes de que el método asíncrono termine.

Para resolver esto se han tenido que utilizar patrones para ejecutar código después de que una operación de segundo plano se complete, Insertando el código en la operación de segundo plano después del principal de la operación, suscripción de un evento que se activa al finalizar, Delegado o lambda para ejecutar después de la finalización (call back).

Si la siguiente operación se necesita ejecutar en un hilo en particular, también se necesita lidiar con la operación de gestión de colas en ese hilo. Todo esto ya se torna más desordenado y complejo.
Actualmente nos encontramos con los modificador Async y Await que son fundamentales para la programación asincrónica. El modificador async indica al compilador que un método o expresión lambda es asincrónico y se pueden usar operadores await para designar puntos de suspensión dentro del método. Este tipo de método es conocido como método asincrónico.

Dentro de un método async, se pueden aplicar operadores await a tareas particulares para suspender la ejecución del método asincrónico hasta que la tarea esperada termine. Mientras tanto, se devuelve el control al invocador del método asincrónico. La suspensión no representa una salida del método asincrónico y los bloques finally no funcionan.

Estas características hacen que la programación asíncrona sea más fácil eliminando la necesidad de implementar algún patrón de mayor complejidad. Ya que el compilador hace el trabajo difícil que el desarrollador hacía antes, incluyendo la firma de las continuaciones para la finalización del método suspendido. Como resultado, el código asincrónico es mucho más fácil de escribir y el programa mantiene una estructura lógica que es similar al código sincrónico. Por ejemplo, algunos procesos de rutina, tales como ciclos y manejo de excepciones, pueden ser difíciles de escribir en código asincrónico tradicional. En un método async, se pueden escribir estos elementos como se haría en una solución sincrónica y se resuelve este problema.
 
Veamos un ejemplo entre código de bloqueo y asíncrono con un ejemplo sencillo.
 
1) Abrimos Visual Studio y creamos un proyecto en winform.
2) Agregamos un botón y un listbox a la interfaz, queda algo así.
 
 
3) Agregamos el siguiente código.
 
 
        private void button1_Click(object sender, EventArgs e)
        {
            this.Ejecutar();
        }

        private void Ejecutar()
        {
            ProcesoSync(@"Z:\New folder.rar");
            list1.Items.Add("Se termino de procesar el archivo de forma sincrona....");
            ProcesoAsync(@"Z:\New folder.rar");
            list1.Items.Add("1 UI no bloqueada, continua ejecucion de codigo...");
            list1.Items.Add("2 UI no bloqueada, continua ejecucion de codigo...");
            list1.Items.Add("3 UI no bloqueada, continua ejecucion de codigo...");
            list1.Items.Add("4 UI no bloqueada, continua ejecucion de codigo...");
        }
 
        void ProcesoSync(string archivo)
        {
            byte[] buffer = null;
            try
            {
                using(var FsRead = new FileStream(@archivo, FileMode.Open, FileAccess.Read))
                {
                    list1.Items.Add("En lectura sync");
                    var binReader = new BinaryReader(FsRead);
                    long fileLen = new FileInfo(archivo).Length;
                    buffer = binReader.ReadBytes((Int32)fileLen);
                    binReader.Close();
                }

                using (var FsWrite = new FileStream(@"ArchivoSync.rar", FileMode.CreateNew, FileAccess.Write))
                {
                    list1.Items.Add("En escritura sync");
                    FsWrite.Write(buffer, 0, buffer.Length);
                }
           
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }

        async void ProcesoAsync(string archivo)
        {
            try
            {
                list1.Items.Add("Comienza proceso Async");
                byte[] buffer = null;
                using (Stream streamRead = new FileStream(@archivo, FileMode.Open, FileAccess.Read))
                {
                    list1.Items.Add("En lectura Async");
                    buffer = new byte[streamRead.Length];
                    Task ReadData = streamRead.ReadAsync(buffer, 0, (int)streamRead.Length);
                    await ReadData;
                }
               
                using (Stream streamWrite = new FileStream(@"ArchivoAsync.rar", FileMode.CreateNew, FileAccess.Write))
                {
                    list1.Items.Add("En Escritura Async");   
                    Task WriteData = streamWrite.WriteAsync(buffer, 0, buffer.Length);
                    await WriteData;
                    if (WriteData.IsCompleted)
                        list1.Items.Add("Se termino de procesar el archivo de forma Async....");
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
        }

4) Esto lo único que hace es que copia un archivo, pueden probar con un archivo grande para que se aprecie el ejemplo.
 
5) Ejecutan la aplicación.
 
se puede apreciar que cuando se esta ejecutando la parte síncrona la ventana esta pasmada esperando a que termine, una vez terminada manda al listbox una serie de mensajes, esto no pasa con la ejecución de la parte asíncrona ya que lo que esta leyendo el archivo y escribiendo esto lo hace en segundo plano y permite a la interfaz ejecutar las demás tareas que pudiera tener programada.
 
En resumen la programación asíncrona es importante y útil, sin embargo la importancia de su uso va en función del tipo de aplicación que se está desarrollando, por ejemplo, para el desarrollo de aplicaciones en Windows 8, la aplicación debe de cumplir con la parte de fluida y rápida por lo que el usuario poco o casi nada debería de notar estos procesos de larga duración.
 
sin mas espero les haya interesado el tema, un saludo y feliz año!!!

jueves, 29 de noviembre de 2012

Adios a las carpetas BKP_App_Fecha_V_0.0

Hola a todos, el día de hoy voy a cambiar un poco de tema aunque voy a continuar platicándoles o desarrollando ejemplos de apps para Windows 8, hoy me encontré con algo muy interesante y que espero sea del interés de ustedes, ya que cuantas veces les a pasado como a mi en lo particular que somos desarrolladores, muy organizados y mas a la hora de que no sabemos como va a explotar el código que acabamos de meter o estamos en el paso de la muerte que lo único que hacemos es empezar a generar carpetas con las siglas BKP_, backup_, respaldo_00 etc. etc., que al final en una de esas decimos mejor me regreso a la versión a revisar algo, pero con todas esas carpetas ya no sabemos ni cual es y tenemos que empezar a ejecutar todas esas soluciones. Ahora pues les comento que se libero la Team Fundation Express 2012. esto quiere decir que ya podemos tener nuestros progresos de nuestras aplicaciones de manera decente, y poder tener un versionador como dios manda, y lo mejor de todo GRATIS!!!.

Aquí lo pueden descargar la imagen ISO

NOTA: si tienen VS en español bajen la versión del idioma correspondiente porque si no van a tener broncas.

Una vez que se ejecute el instalador nos aparece la siguiente pantalla para iniciar el wizard.

 
Como se puede observar, lo primero que se hace es una revisión para que la instalación funcione correctamente. aquí lo que podría comentar es que igual por tratarse de una versión express el TFS requiere de un servidor SQL, para lo cual se instalara o actualizara la versión express de SQLcon la que cuente el equipo.
 
 
La instalación es realmente muy fácil, después procederemos a crear un grupo de trabajo, donde no hay nada que configurar salvo elegir la plantilla para trabajo en equipo donde por default nos trae 3 opciones y tendrán que elegir la que mas les convenga.
 

 
Una vez terminada la instalación nos mostrara una pantalla como la que se muestra a continuación.
 
 
Donde a partir de este momento tendremos nuestro versionador instalado en el equipo local que nos va a permitir tener un proyecto con versiones y mejor organizado.
 
el objetivo de esto en si era platicarles de esta herramienta que en lo particular se me hace muy buena para llevar un mejor control, a partir de aquí vamos a empezar a desarrollar nuestra aplicación en Windows 8 que les platique en el blog anterior donde el objetivo va a ser verla publicada en el Store de Windows.
 
 
Para los que estén un poco interesados en el tema, o se quieran enfocar al desarrollo en esta plataforma. hay que contar con una suscripción de desarrollador, la cual cuesta al rededor de 50 DLS. por año, esto bueno rápidamente les platico que se dan de alta, Microsoft los provee de un dashboard donde podrán tener visibilidad de cuando $ han obtenido por las descargas de sus aplicaciones, apartar nombres de aplicaciones, y subirlas al store, para este ultimo paso sus apps van a tener que pasar por una revisión donde si cumplen con los standares no van a tener ninguna bronca y su App estará disponible en el menor tiempo posible.
 
bueno espero que esta herramienta les ayude mucho, lo importante es que no consume muchos recursos como lo ha de hacer la versión completa y de costo :s.
 
y bueno, ya estoy trabajando en la App que les e estado comentando y los post posteriores serán ya parte del desarrollo de la misma.
 
saludos.


domingo, 21 de octubre de 2012

Desarrollo de Aplicaciones en Windows 8

Hola a todos, este es mi primer post, es básicamente para conocer un poco del entorno de desarrollo de aplicaciones en Windows 8, en el enlace se encuentra un PDF con una introducción, y el desarrollo de una primer aplicación con estilo metro, el objetivo es conocer un poco del entorno de desarrollo y conforme se vaya avanzando construir una o varias aplicaciones funcionales. Aquí les dejo mi primer aporte esperando les guste. Todos los comentarios son bienvenidos.

Descargar contenido