ASP.NET 5 Config Transformations

Este viernes tuve la oportunidad de participar en el Microsoft Web & Cloud Tour, donde estuvimos viendo la gran cantidad de novedades que nos trae el anteriormente conocido vNext y ahora rebautizado ASP.NET 5.

La verdad es que hay tanta cantidad de novedades que se merece un post en exclusiva, pero una de las preguntas que me hicieron en la charla no supe contestarla y las opciones que se barajaron no me acabaron de convencer del todo.

Primero de todo explicare el cambio que origino la consulta.

Las configuraciones en ASP.NET 5

Pues uno de los grandes cambios que nos encontraremos con ASP.NET 5, es que desaparecen todos los ficheros de configuración del App_Start, el web.config y el Global.asax.

Eso es así porque ahora las aplicaciones web serán 100% modulares gracias a OWIN y el fichero de configuración pasa a ser un JSon.

El punto de entrada y configuración de la app ahora es el fichero Startup.cs donde se configuraran y se inicializarán todos los Middelware que necesitemos utilizar en la web.

config.json

{
    "Data": {
        "DefaultConnection": {
            "ConnectionString": "Server=(localdb)\mssqllocaldb;Database=aspnet5-WebApplication3-c058d79d-8b19-4465-ab76-9441127294f6;Trusted_Connection=True;MultipleActiveResultSets=true"
        }
    },
    "EntityFramework": {
        "ApplicationDbContext": {
            "ConnectionString": "Data:DefaultConnection:ConnectionString"
        }
    }
}

Con este fichero se nos simplifica mucho la configuración. Pero precisamente esta simplicidad es lo que planteo la duda.

Como utilizo las transformaciones de configuración en un fichero JSon ?

Con el fichero de configuración anterior era muy fácil tener transformaciones para tener por ejemplo una cadena de conexión para Debug y otra para Release, pero a simple vista con el fichero JSon esto no se podrá hacer.

Lo primero que tenemos que fijarnos es como se utiliza ahora el fichero de configuración, pues como he comentado antes ahora la inicialización de la app se encarga el fichero Startup.cs y al mirar su constructor despejamos la duda.

   public Startup(IHostingEnvironment env)
   {
      // Setup configuration sources.
      Configuration = new Configuration()
         .AddJsonFile("config.json")
         .AddEnvironmentVariables();
   }

Como podemos observar en el constructor se define cual será el fichero de configuración y las variables de entorno que se utilizaran en nuestra aplicación.

De esta manera podríamos tener una condición del entorno para poder cargar un fichero u otro, pero hay otra manera que me parece más elegante.

  //Get envoirement state
  var envConfig = Environment.GetEnvironmentVariable("KRE_CONFIGURATION");

 // Setup configuration sources.
 Configuration = new Configuration()
     .AddJsonFile("config.json")
     .AddJsonFile(string.Format("config.{0}.json", envConfig))
     .AddEnvironmentVariables();

Esta solución me parece mucho más potente, porque nos permite tener diferentes ficheros de configuración para cada entorno.

configfiles

Pero eso no es todo, porque no solo se nos permite tener ficheros de configuración json, ademas podemos añadir ficheros de tipo *.ini con “AddIniFile(“config.ini”)” o cargar nuestro propio fichero implementando la interfaz IConfigurationSource.

Como acceder a las variables de la configuración

Al tener la configuración como json nos permite tener variables de configuración mucho mas complejas.

{
    "MySettings":{
        "UserProfile":{
            "UserName": "Marc Rubiño"
        }
    }
}

Para acceder a estas variables solo tenemos que llegar al nivel que necesitemos.

    var userName = Configuration.Get("MySettings:UserProfile:UserName");

Bueno con esta explicación espero que se hayan despejado las dudas que salieron en la presentación y espero poder seguir despejando poco a poco las novedades que nos encontraremos en ASP.NET 5.

Cross-posting  http://mrubino.net 

 

Xamarin Forms & PCL HttpClient

Esta estrada viene por la consulta realizada por @barbpabl sobre como utilizar httpClient desde una librería PCL. Porque tenia problemas al ejecutar desde Android.

Antes de empezar solo recordar que una librería PCL es aquella que al compilar es compatible con diferentes plataformas y nos ayuda a generar librerías multi-plataforma.

Por ejemplo con la librería PCL generada con un proyecto Xamarin.Forms v.1.0.6186 la librería es compatible con:

PCL

A partir de aquí como reutilizar mis llamadas Http en una sola librería para poder compartir el código en todas las plataformas compatibles con esta librería.

1. Crear el proyecto Xamarin Forms

Lo primero de todo es crear el proyecto móvil con Xamarin Forms,

proyect

 

2. Añadir las librerías necesarias con Nuget

2.1  Añadir Microsoft Http Client Libraries

Con esta librería tendremos disponible la versión PCL de la librería .NET de HTTPClient. Es importante que se instale desde la solución a todas las plataformas, porque cada una tiene unas dependencias que hay que tener instaladas.

Microsoft Http Client Libraries  –>

PM> Install-Package Microsoft.Net.Http

HttpClient2

2.2 Añadir la librería para trabajar con Json al proyecto PCL

NewtonSoft  –> PM> Install-Package Newtonsoft.Json

3. Crear un Servicio para las llamadas Http

Creamos una clase service para utilizar desde nuestra pcl y que este disponible para compartir en todas las plataformas.

public async Task<Weather> GetAsync(string url)
        {
            var data = "";
            using (var client = new System.Net.Http.HttpClient())
            {
                var response = await client.GetAsync(url);
                if (response.StatusCode == System.Net.HttpStatusCode.OK)
                {
                    data = await response.Content.ReadAsStringAsync();
                }
            }
            return JsonConvert.DeserializeObject<Weather>(data);
        }

Este servicio recupera el resultado de una llamada http asíncrona y serializa el resultado en un objeto Weather de nuestro modelo. A esta función se le pasa la url a consultar como  parámetro.

4. Utilizamos el servicio desde la App PCL

Ahora solo tenemos que utilizar este servicio desde nuestro viewModel para recuperar el tiempo que hace en Barcelona.

public async void LoadHttpTemp()
     {
         var serviceHttp = new Services.HttpService();
         var data = await serviceHttp.GetAsync("http://api.openweathermap.org/data/2.5/weather?q=BArcelona&units=metric");
         if (data != null) Temp = data.Main.Temp.ToString("00.##°C");
     }

Gracias a que la propiedad Temp está bindeada con la interfaz, automáticamente se mostrará el resultado en el formulario una vez recibida la información.

Aplicación de ejemplo

Este es el resultado de la App “Android & Windows Phone” utilizando el servicio.

Android WP

Podéis descargar la App de ejemplo desde GitHub…

Cross-posting: http://mrubino.net 

 

 

Banners ads con Xamarin.Forms & CustomRenders

Mis compañeros de Pasiona Joan Isaac y Joan Caparrós están trabajando duro en el proyecto con Xamarin.Forms y han querido aportar su granito de arena explicando como agregar publicidad en nuestras app. Esta opción no está ni siquiera en ingles y por eso los he animado ha escribir el artículo. Espero que no sea el último.

Antes de encontrar la solución se realizó una búsqueda para encontrar la mejor solución y que fuese lo más adaptable posible. Decidimos tratar de integrar los anuncios a través de Customs Renderers.

Este método permite poner el anuncio en la mejor posición y hacerlo visible/invisible según la necesidad, por ejemplo, si la aplicación tiene unos usuarios Premium que paga para evitar los anuncios, se podrían hacer invisibles los anuncios, pero si el usuario es un usuario libre, se podría mostrar el anuncio en la aplicación en la mejor posición para evitar problemas con la experiencia del usuario.

Ciertamente el diseño básico Xamarin.forms está limitado (recordemos que Xamarin.Forms intenta compactar en un único control el máximo de propiedades disponibles comunes a las tres plataformas) y si se quiere hacer modificaciones para añadir funcionalidades propias de cada plataforma, es posible hacerlo a través de Customs Renderers. Los customs renderers permiten modificar los controles usados en el PCL añadiéndoles funcionalidades nativas propias de cada dispositivo.

CustomRender

Como se puede ver en la imagen anterior, definiendo un control propio y conectándolo con cada uno de los nativos, se consigue poder modificar el control común en cada una de las plataformas para poder modificarlo con las propiedades y/o funcionalidades propias de cada una de las plataformas que se requieran.

Esta función es necesaria porque la API para mostrar los anuncios depende de cada plataforma, y estos anuncios se construyen con objetos personalizados en función cada plataforma. Combinando Customs Renderers  y la API de Banners logramos nuestro objetivo, añadir anuncios en nuestro proyecto Xamarin.Forms de forma rápida, que se adapten al diseño y usable para el usuario.

Customview

En nuestro caso, y como se puede ver en la imagen, para poder añadir los Banners nativos en cada uno de los controles personalizados, hemos optado por usar el control View y por tanto los controles nativos ViewRenderer personalizados para poder añadir en estos cada uno de los banners usados.

 Banner

Ejemplo.

Requisitos:

PCL

  • Lo primero que has de hacer es crear la clase en el PCL, en este caso, una clase que herede de vista. (En este punto, se recomienda compilar para hacer esta clase visible)
  • Esta clase, esta vacía, ya que la definición de la funcionalidad estará en las clases dependientes.
1
2
3
public class MyBanner: View
{
}

Código específico para cada Plataforma

  • Windows Phone
    • Antes de empezar, es necesario añadir la librería GoogleAds.dll, que se puede encontrar en este enlace: https://developers.google.com/mobile-ads-sdk/download#downloadios
    • Una vez bajada, se ha de añadir la librería al proyecto específico de Windows Phone 8.1
      1. Clic derecho en la solución de Windows Phone
      2. Add->Reference->Browse.
      3. Busca el archivo GoogleAds.dll de Windows Phone, y añadelo.
    • Es necesario crear una clase, en este caso, “CustomBannerRendered.cs”
      • Esta clase tendrá la lógica de Windows Phone 8.
      • en el atributo “adUnitID” hay que poner el key que tengamos de Google Ads.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[assembly: ExportRenderer(typeof(MyBanner), typeof(CustomBannerRenderer))]
namespace WinPhone.CustomRenders
{
    public class CustomBannerRenderer : ViewRenderer
    {
        protected override void OnElementChanged(ElementChangedEventArgs<View> e)
        {
            base.OnElementChanged(e);
            if (e.OldElement == null)
            {
                AdView bannerAd = new AdView
                {
                    Format = AdFormats.Banner,
                    AdUnitID = "Your key",
                };
                AdRequest adRequest = new AdRequest();
                bannerAd.LoadAd(adRequest);
                Children.Add(bannerAd);
            }
        }
    }
}
  • Android
    • Antes de empezar debes añadir el componente para la versión de Android que vayas a usar, en este caso, se ha usado de Google Play service, la versión para ICS.
    • Para añadir el componente se debe:
      1. Hacer clic derecho en la carpeta Components, del proyecto de Android.
      2. Haz clic en “Get more components”
      3. Buscar “Google play service”.
      4. Hacer clic en “Add to App”
    • El siguiente paso es configurar el Android Manifest para otorgarle los permisos necesarios:
      • Haz clic con el botón derecho encima de la solución y selecciona propiedades.
      • Selecciona la pestaña de Android manifest y en Required permisions, selecciona:
        •  ACCESS_NETWORK_STAT
        • INTERNET
    • El siguiente paso es añadir meta-data en el archivo “AndroidManifest.xml”
    • Finalmente ya se puede crear la clase, en este caso “CustomBannerRenderer.cs
    • En AdUnitID, poner la Key de Google Ads.
1
2
3
4
<application>
<meta-data android:name="com.google.android.gms.version" android:value="@integer/google_play_services_version" />
<activity android:name="com.google.android.gms.ads.AdActivity" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize" />
</application>

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[assembly: ExportRenderer(typeof(MyBanner), typeof(CustomBannerRenderer))]
namespace Android.CustomRenders
{
    public class CustomBannerRenderer : ViewRenderer
    {
        protected override void OnElementChanged(ElementChangedEventArgs<View> e)
        {
            base.OnElementChanged(e);
 
            if (e.OldElement == null)
            {
                AdView ad = new AdView(this.Context);
                ad.AdSize = AdSize.Banner;
                ad.AdUnitId = "Your key";
                var requestbuilder = new AdRequest.Builder();
                ad.LoadAd(requestbuilder.Build());
                this.SetNativeControl(ad);
            }
        }
    }
}
  • iOS
    • En este caso en particular ya no se necesario poner la key de Google Ads, ya que se usa el servicio iAds, de Apple.
    • En este caso, solo es necesario añadir la nueva clase, “CustomBannerRenderer.cs”

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[assembly: ExportRenderer(typeof(MyBanner), typeof(CustomBannerRenderer))]
namespace iOS.CustomRenders
{
    public class CustomBannerRenderer : ViewRenderer
    {
        protected override void OnElementChanged(ElementChangedEventArgs<Xamarin.Forms.View> e)
        {
            base.OnElementChanged(e);
 
            var adBannerView = new ADBannerView(new System.Drawing.Rectangle(0, 386, 320, 50));
            base.SetNativeControl(adBannerView);
 
        }
    }
}

 Resultado real :

res

Ya lo tenemos todo !! Pero como más vale un ejemplo que mil palabras, podéis descargar el ejemplo desde github…

Cross-Posting: http://mrubino.net

 

 

 

Xamarin Forms uno para todos !!!

Hace unos meses que estoy trabajando en un proyecto con Xamarin Forms y creo que es buen momento para empezar a hacer una serie de entradas sobre el tema y explicar mi experiencia utilizando esta plataforma.

Que es Xamarin

Xamarin es una plataforma que nos permite crear Apps nativas para iOS, Mac, Android, Windows Phone, Windows 8 y más. Además nos permite utilizar solo un lenguaje de programación “C#” y  reducir tanto los perfiles como la cantidad de equipos involucrados en el desarrollo.

Ventajas

  • Aplicaciones 100% nativas
    • Interfaces Nativas
    • Acceso a la API nativa del dispositivo
    • Rendimiento 100% nativo
  • Un solo lenguaje de programación C#
  • IDEs sencillos
    • Xamarin Studio: IDE propio
    • Visual Studio
  • Código compartido
    • el 100% de la lógica de negocio puede compartirse entre las plataformas
    • Técnicas para compartir el código:
      • Proyectos compartidos: podemos utilizar directivas de compilación #if para utilizar dependiendo de las necesidades específicas de la plataforma.
      • PCL “Portable Class Library”: librerías .NET compatibles con diferentes plataformas.
      • Xamarin.Forms: nos permite crear interfaces nativas con más de 40 controles compatibles.

Arquitectura Xamarin Clásica

La forma de plantear el diseño de la App tenía que ser parecido a este:

xamarin_old

  1. Core Library:  Xamarin nos proporciona la posibilidad de crear código compartido en C# para reutilizar en todas las plataformas, Este código podríamos tener  toda la lógica de negocio, la capa de acceso a datos y la capa de servicios. De esta manera solo tendremos una librería donde poner nuestra lógica y reducir el código repetido y facilitar el mantenimiento.
  2. Specific Platform layer: Aunque utilicemos código compartido siempre necesitaremos acceder a utilidades nativas de la plataforma y crear un interfaz de usuario específico para cada plataforma.

Xamarin Forms

Pero con la aparición de Xamarin.Forms ha cambiado mucho la forma de afrontar el diseño de la App y podemos tener una capa de interfaz común para diseñar nuestras interfaces multiplataforma. El resultado final son los controles nativos de la plataforma.

xamarin_Forms

  1. Core Library: Lógica compartida
  2. Shares UI Code: Interfaz de usuario compartido.
  3. Specific Platform layer: acceso a recursos específicos de la plataforma.

 

Controles en Xamarin.Forms

Pages

Las páginas son controles contenedores que representan un Activity en Android, un View Controller en iOS y una Página en Windows Phone.

pages

Layouts

Los layouts son contenedores de otros layouts o vistas. Lo utilizaremos para posicionar los controles dentro de las páginas.

Layouts

Views

Los controles o widgets más comunes que utilizamos normalmente en las aplicaciones.

  • BoxView: Control para pintar un rectángulo relleno de color.
  • Button: Control tipo botón.
  • DatePicker: Control para seleccionar fechas.
  • Entry: Control para editar texto en una sola línea.
  • Editor: Control para editar texto múltiples líneas.
  • Image: Control para mostrar imágenes.
  • Label: Control para mostrar texto de solo lectura.
  • ListView: Control para mostrar una lista.
  • OpenGLView: Control para mostrar contenido OpenGL.
  • Picker: Control para seleccionar un elemento de una lista.
  • ProgressBar: Control de barra de progreso.
  • ActivityIndicator : Control visual para avisar que algo está en curso sin informar el progreso.
  • SearchBar: Control de búsqueda.
  • Slider: Control visual para la captura de un valor lineal.
  • Stepper: Control para incrementar o reducir un valor numérico.
  • Switch: Control visual para la selección on-off.
  • TableView: Estructura contenedora de columnas y celdas.
  • TimePicker: Control visual para la entrada de horas y minutos.
  • WebView: Control contenedor de HTM

 Cells

Celdas predefinidas para facilitar el uso en listas y TableViews.

  • EntryCell: Celda especializada con un label para el título y un entry para la introcucción de datos.
  • SwitchCell: Celda especializada con un label para el título y un switch para seleccionar.
  • TextCell: Celda especializada con dos labels, no con el título y el otro par la descripción.
  • ImageCell: Celda especializada con una imagen y dos labels, uno para el título y otro para la descripción.

 

Otras utilidades

Otras utilidades que nos serán de gran ayuda en el desarrollo  y que veremos en otras entradas son:

  • CustomRenderers: nos permite personalizar la visualización y el comportamiento de los controles para cada una de las plataformas.
  • DependencyServices: nos permite acceder desde Xamarin.Forms a características nativas de cada plataforma, como podría ser el GPS, cámara, etc.
  • MessagingCenter: Nos permite publicar y suscribirse a mensajes para comunicar nuestros ViewModels o diferentes componentes.

 

Espero que esta introducción os parezca interesante y pueda publicar más entradas sobre el tema que me parece súper interesante.

Cross-Posting http://mrubino.net 

 

 

SPA con Asp.Net Mvc & Angular

Hace tiempo que quería escribir esta entrada pero la vida me ha dado otras prioridades desde que he vuelto a ser padre. Pero después de varias peticiones me gustaría explicar como combino una aplicación Asp.net Mvc con angular intentando aprovechar las ventajas de tener las vistas en el servidor.

El proyecto

Lo primero que he hecho es crear una solución con dos proyectos uno para la interfaz donde estará angular y otra para los servicios de datos, de esta manera queda más clara la separación de estas responsabilidades de la aplicación.

Proyecto

  • Datos: Proyecto Web API
    • Models: en esta carpeta estaría emulando la parte de negocio y las entidades que usaré en los servicios REST.
    • Controllers: He creado dos controladores para los servicios Uno con para consultar datos maestros y otro para consultar los datos de los concesionarios de coches en los que se basa este ejemplo.

Views

  • Angular: Proyecto ASP.NET MVC
    • Controllers: los controladores típicos de ASP.NET MVC.
      • Home: Controlador de la home donde redirige a la vista principal. Esta vista principal es la encargada de contener las otras vista de angular tipo SHELL.
      • Concesionarios: El controlador que gestiona las vistas con la lista de concesionarios y detalle-edición de los vehículos.
  • Views: Las vistas de MVC donde se encuentra el HTML que necesitamos.
    • Concesionarios: partials views de las diferentes pantallas de la aplicación.
    • Home/Index: vista principal contenedor de las otras vistas.

Index

1
2
3
4
5
</pre>
<div id="main-content">
<div class="bodyPartialView" data-ng-view=""></div>
 <!-- The SPA Views go here --></div>
<pre>
  • Scripts: En la carpeta scripts tendremos todo los ficheros scripts que necesitamos en nuestra aplicación Angular.

Scripts

  •  
    • Libs: librerías de terceros que utilizamos como por ejemplo JQuery.
    • App: donde tendremos los script de la aplicación
      • controllers: los controladores en angular son el código js referente a una vista y su contexto.
      • directives: podemos crear atributos nuevos Html que angular podrá injectar en nuestras vistas, de esta manera podríamos crear nuestros propios controles con HTML y scripts.
      • filters: código que nos permite filtrar o tratar los datos
      • services: servicios disponibles en nuestra aplicación angular, yo por ejemplo tengo un servicio que es el encargado de cargar los datos desde los servicios REST llamado dataContextService.
      • App.js: es el punto de entrada de la aplicación donde está definido el routing de angular.

App.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
demoApp = angular.module('demoApp', [])
    .config(['$routeProvider', function($routeProvider) {
        $routeProvider
            .when('/', {
                templateUrl: '/Concesionarios/List',
                controller: 'ListaCtrl'
            })
            .when('/detalle/:id', {
                templateUrl: '/Concesionarios/Detail',
                controller: 'DetalleCtrl'
            })
            .when('/edit/:id', {
                templateUrl: '/Concesionarios/Edit',
                controller: 'EditCtrl'
            })
            .otherwise({ redirectTo: '/' });
 
    }]);

El enrutamiento de angular es el encargado de configurar las url que se tienen que mapear para servir una vista y que controlador hay que cargar con la misma. Lo bueno de este enrutamiento que acepta tanto código inyectado HTML, como páginas. De esta manera podemos enrutar las vistas de la aplicación angular con las vistas de servidor de MVC.

Ventajas de utilizar las vistas de Servidor

Como he comentado anteriormente la ventaja de utilizar las vistas de servidor es que tenemos la posibilidad de utilizar sus recursos y el sistema de autorización de partes de la página evitando mostrar en cliente las partes privadas de nuestra aplicación, pero no os olvidéis siempre de hacer lo mismo con los servicios. Nadie tendría que acceder a nuestros servicios de datos sin los permisos adecuados.

1. Localización de las vistas en el servidor

Al tener enrutada las vistas desde cliente a las vistas de servidor podemos utilizar los recursos como cualquier otra aplicación ASP.NET MVC. Evitando tener que descargar todos los posibles recurso de todos los idiomas al cliente la primera vez.

</pre>
<h1>@Resources.Language.Title_List</h1>
<pre>

res

2.Autorización de la interfaz de usuario

Otra de las ventajas de utilizar las vistas de MVC es que podemos utilizar el sistema de seguridad que nos ofrece ASP.NET sin problemas. De esta manera solo se descargará la parte de HTML que el usuario tenga permisos y no hará falta administrar la seguridad de la interfaz desde el propio cliente.

Permitir editar solo a los usuarios autentificados:

</pre>
<div data-ng-repeat="coche in item.Coches"><a href="#/detalle/{{coche.IdCoche}}">{{ coche.Marca}}- {{coche.Modelo}}</a>
 @if (Request.IsAuthenticated)
 {
 <button class="btn btn-mini" data-ng-click="edit(coche.IdCoche)"><i class="icon-edit"></i></button>
 }</div>
<pre>

Lista si el usuario no está autentificado

list

Lista si el usuario está autentificado (Aparece el botón de editar)

list2

Conclusión

Bajo mi punto de vista los extremos siempre son malos, no deberíamos tener todo en el servidor ni todo en el cliente, hay que buscar el equilibrio que haga que nuestras aplicaciones puedan aprovechar lo mejor de cada entorno.

Podéis encontrar el ejemplo en : https://github.com/Marckys/AngulaR-ASP.NET-MVC

Cross-Posting: http://mrubino.net/ 

 

 

Por qué Knockout no es una librería SPA

Últimamente tengo muchas conversaciones donde se hablan de aplicaciones SPA (Single Page Application) y en el momento de hablar de que librería me gusta más, siempre suele salir a la palestra Knockout y no puedo evitar poner cara de circunstancia, porque esta librería en concreto no me encaja en absoluto como SPA.

Parece ser que no queda muy claro cual su intención o que necesidad cubre. Por eso haré una pequeña comparación sobre diferentes librerías para poder despejar las dudas que se puedan tener sobre ellas.

Que es una aplicación SPA

Una aplicación ”Single Page Application” como bien indica su nombre, es aquella que tiene una pagina principal que se utiliza como contenedor de el resto de páginas. No necesita cargar completamente el documento,  es capaz de separar las vistas de los datos e inyectar el contenido de las paginas o vistas en el contenedor principal. De esa manera puede controlar la carga, la navegación, el histórico, etc. Eso nos permite ofrecer una experiencia de usuario más rica y tener el control total de la interfaz de usuario desde el cliente.

Por eso una buena librería para hacer SPA tendría que darnos una solución completa a estas necesidades:

  1. Routing:  Navegación e histórico.
  2. Datos: Tratamiento de datos con las llamadas AJAX
  3. DOM: interactuar con los objetos del documento.
  4. Mv* : Estructura del código y separando responsabilidades utilizando un patrón Modelo Vista …
    1. Data Binding: es importante que si separamos las vistas del modelo de datos, tengamos un mecanismo para que se comuniquen las dos partes de forma automática y tener un “Two-Way Data Bind” es una buena opción.
    2. Async: Para trabajar con procesos o llamadas a otros módulos lo mejor es utilizar asincrónica y utilizar Promises para facilitar esta tarea.
    3. DI: si utilizamos módulos AMD como componentes se tendría que poder hacer inyección de dependencias.
  5. Testing: esto ya es para nota

La Comparativa

Comparación de las principales librerías que se utilizan actualmente en el desarrollo Web:

Librerías

Datos

DOM

Routing

MV*

DataBind

DI

Testing

KnockoutJs

X

X

X

MVVM

X

X

AngularJs

JQlite

MVW

Durandal

JQuery*

MVW

KnockoutJs*

Require*

X

Backbone

X

X

MVC

X

X

X

* Tiene dependencia con esta librería para su funcionamiento.

  • Knockout:  Como se puede observar esta librería solo nos aporta una manera muy potente de enlazar nuestros datos con las vistas utilizando MVVM y utilizando Two-Way Data Bind. No tiene dependencias  con otras librerías es 100% JavaScript y no abarca todo lo que necesita una aplicación SPA por si sola.
  • Angular: Framework que abarca todo el desarrollo con JavaScript y nos evita depender de otras librerías. Además podemos hacer test unitarios de nuestro código.
  • Durandal: Es una librería que se apoya en otras para poder cubrir todas las necesidades de una aplicación SPA.
    • Knockout para el Data Binding,
    • Require para la inyección de dependencias
    • JQuery para el las llamadas AJAX e interactuar con el DOM.
  • Backbone: Una librería muy liviana, más dirigida en estructurar nuestro código utilizando un patrón MVC que dar cobertura a una aplicación de tipo SPA.

Conclusión

Como se ha podido comprobar en esta comparación Knockout no se puede comparar con las librerías o frameworks SPA, porque solo tiene un objetivo. Que es enlazar nuestro datos con las vistas utilizando un patrón MVVM.

Para conseguir una experiencia SPA completa, tendríamos que combinar Knockout con otras librerías como hace DurandalJS.

Espero que esta reflexión en voz alta deje fuera de las conversaciones sobre SPA a la pobre Knockout 😉

cross-posting: http://mrubino.net 

 

¿ Qué es un Microsoft MVP ?

Me acabo de enterar que por tercer año consecutivo Microsoft me han reconocido como MVP en la especialidad de ASP.NET-IIS, este reconocimiento para mi es un gran honor que me motiva cada día a seguir aportando mi granito de arena a la gran comunidad .NET y que de vez en cuando nos reunimos para compartir nuestros conocimientos.

Una cosa que me sorprende cada día más, es que muchos de mis compañeros y eso es extrapolable a toda la red, no conocen que es un Microsoft MVP y eso me sorprende porque la comunidad está plagada de recursos que han aportado estos perfiles y la colaboración en muchos foros tecnológicos.

Eso me da que pensar que existen una gran cantidad de profesionales que realmente no se preocupan por investigar más allá de lo que necesitan en su día a día, o que no tienen ese gusanito que te obliga a aprender nuevas tecnologías aunque realmente no las necesites actualmente para tu trabajo. Y es que en estos años he llegado a escuchar de todo sobre los MVP, que si son los que tienen todos los certificados de Microsoft, que es un certificado especial que se puede comprar, etc.

Por ese motivo me gustaría aclarar algunos puntos sobre este tema:

¿ Qué es un Microsoft MVP ?

Para empezar el reconocimiento MVP “Most Value Profesional” es un premio que otorga Microsoft a Profesionales independientes que consideran lideres excepcionales de la comunidad y que comparten con los demás su pasión, habilidad técnica y conocimiento práctico sobre los productos de Microsoft.

Microsoft da este premio para valorar la aportación de una persona durante todo un año a la comunidad bajo sus criterios de selección y que pasan por un líder MVP territorial y que después es definitivamente aprobado por el equipo de producto en Microsoft Corporation “Redmond” de la especialidad en la que se le ha propuesto.

5618_mvp_wallpaper_1024x768

En la actualidad son ya más de 4.000 los MVP que hay en todo el mundo. Representan a más de 90 países, hablan más de 40 idiomas, responden a más de 10 millones de preguntas al año y se les ha distinguido en casi 90 tecnologías de Microsoft. mas…

Qué no es un MVP

Los MVP son profesionales independientes y por consecuencia un MVP no es ni un trabajador de Microsoft , ni un certificado especial, ni nada que tenga que ver con conseguir el reconocimiento con un examen o por la compra de ningún producto Microsoft.

Como ser MVP

Ser un MVP no puede ser nunca un objetivo, tiene que ser la consecuencia de la dedicación a la comunidad. Este premio es un reconocimiento a una trayectoria dentro de la comunidad y es contraproducente tanto para la persona como para la comunidad solo participar para conseguir este reconocimiento ya que se pierde toda visión imparcial y se pierde la efectividad cuando se trata de ayudar a los demás.

Conseguir esta distinción no es sencillo: entre los más de 100 millones de miembros de la comunidad técnica y social de todo el mundo, solo se reconocen en torno a 3.800 MVP cada año.

Mi consejo es participar en la comunidad activamente y no pensar en el premio. cualquiera puede llegar a convertirse en MVP y cualquiera puede proponer a alguien que crea que se lo merece para que Microsoft lo tenga en cuenta para las siguientes nominaciones.

Puedes proponerte a ti mismo u a otras personas en http://mvp.microsoft.com/es-es/nominate-an-mvp.aspx

Conclusión

Yo solo puedo estar orgulloso de ser reconocido con este premio por Microsoft, pero sobre todo estoy orgulloso de participar activamente en la comunidad y crecer profesionalmente con ella y rodeado de tantos amigos virtuales y presenciales. Gracias a todos.

Cross-Posting: http://mrubino.net

Retrospectiva 2012

Este ha sido un año de grandes cambios y experiencias, soy consciente que he tenido olvidado un poco el blog pero eso me ha dejado un poco más de tiempo para participar más intensamente con las comunidades.

Por eso este año he podido conocer más gente en persona o desvirtualizar a otras tantas que tanto hemos coincidido por la red.

Una de mis buenas intenciones para este año, como la de aprender ingles será volver a retomar el blog técnico como anteriormente y poder ofrecer mi granito de arena a la comunidad explicando mis experiencias en el desarrollo de aplicaciones.

Además agradecer a la gente de CampusMVP por ofrecer algunas de mis entradas al mundo anglosajón y de esa manera ampliar un poco mis horizontes virtuales :-)

Otro gran cambio que he sufrido en este año ha sido el reto de formar parte del equipo de Pasiona Consulting y formar parte de Techdencias dándome la oportunidad de participar más activamente en eventos tecnológicos rodeado de un gran equipo de profesionales como son Toni RecioQuique MartínezEduard Tomàs , Isabel Cabezas, Fernando Escolar, Pablo Bouzada, Roger Bardomà, Alex Casquete, Edin Kapic, Jaume Vinyes. Un equipo increíble !!!

Espero que este año como mínimo me vaya igual que este que dejamos hoy.

Hackathon & Meghaton Windows 8

558289_412611465466750_1522753019_n _MG_6639

WP_000007 WP_000009

We Love JS

WP_001539 WP_001541

TechDay Madrid

A8YLvYRCQAEejtU A8TESqOCcAA7YE-

WP_000055 WP_000061

AndorraDotNet

WP_000034 WP_000035

BcnDevConf

WP_000068 WP_000067

Windows Server 2012 Road Show “Sevilla”

WP_000088 WP_000089

Feliz 2013 !!!

[Win8 JavaScript] Patrón Promise

Una de las novedades que nos encontraremos a la hora de afrontar una aplicación Windows Store app , es que la mayoría de veces que interactuemos con sus APIS tendremos que hacerlo de forma asíncrona. De esta manera nuestra aplicación no afectará de forma directa al sistema y la respuesta ante el usuario será más ágil y rápida.

Un ejemplo muy gráfico sería acceder a un fichero del sistema:

Windows.Storage.FileIO.readTextAsync(fichero).then(function (contenido) {

//Mostrar contenido

  });

En este ejemplo hemos utilizado la API WinRT para poder acceder al contenido de un fichero de forma asíncrona.  En cuanto se accede al contenido del fichero se lanza la función anónima que está dentro del “then”  mientras la ejecución de nuestra aplicación ha continuado. De esta manera solo mostraremos el contenido del fichero si hemos podido acceder al mismo sin bloquear la aplicación.

Por convención los nombres de las funciones asincrónicas terminan en “Async“. De esta manera puedes saber que la ejecución se producirá después que se devuelva la llamada.

Habitualmente se utilizan llamadas asíncronas para los procesos como:

  • Mostrar un cuadro de diálogo de mensaje
  • Trabajar con el sistema de archivos
  • Enviar datos a Internet y recibirlos

¿Cómo funcionan las llamadas asíncronas en las Windows Store app?

Para trabajar de forma asíncrona tanto WinRT com WinJS utilizan el patrón Promise. Este patrón se puede utilizar para gestionar las llamadas asíncronas de una manera facil de seguir y encadenar.

Un objeto Promise devolverá un resultado en algún momento en el tiempo, por ejemplo la función then nos permitirá actuar cuando la promesa se cumpla y para eso disponemos de tres parámetros.

promise.then( onComplete, onError, onProgress);
  • onComplete : función que se lanza cuando se cumple la promesa.
  • onError :  función que se lanza cuando hay un error.
  • onProgress : función que se lanza cuando se notifica un cambio en el progreso de la promesa.

Siguiendo con el ejemplo anterior veremos como capturar los errores y las notificaciones de progreso.

Windows.Storage.FileIO.readTextAsync(fichero).then(
      function complete(res) {
            document.getElementById("result").textContent = res;
      },
      function error(res) {
            document.getElementById("error").textContent = "Error";
        },
      function progress(res) {
            document.getElementById("progress").textContent = "Progress";
 });

Otra función que podemos utilizar es done.

promise.done(onComplete, onError, onProgress);

La diferencia es que en el caso de un error en el procesamiento, la función then devuelve un objeto promise en el estado de error pero no inicia una excepción. Mientras que el método done inicia una excepción si no se proporciona una función de error.

Además then devuelve una promesa lo que nos permite el encadenamiento de promesas, mientras que done devuelve undefined. Por eso se recomienda usar then para una etapa intermedia de la operación (por ejemplo .then().then()) y done para la etapa final de la operación (por ejemplo, .then().then().done()).

Encadenamiento de Promise

Como then devuelve una promesa, puedes encadenar mas de una función asíncrona para su ejecución.

  var divResultado = document.getElementById("result");

  WinJS.xhr({ url: "http://localhost:32999/api/values" })
           .then(function (result) {
               divResultado.innerText = result.responseText;
            return result;
           })
           .then(function (result) {
               divResultado.style.backgroundColor = "green";
           },
             function (error) {
                 divResultado.style.backgroundColor = "red";
                 divResultado.innerText = "Error";
  });

En este ejemplo se puede comprobar como realizar una llamada asíncrona a un servicio de datos externo, en el primer then trataremos los datos, el segundo then destacaremos en la interfaz que los datos se han cargado correctamente y luego tendremos una función  para tratar las excepciones.

Es recomendable encadenar las promesas y no anidarlas para una mejor lectura del código y un mejor seguimiento de los errores.

Si lo preferimos podemos tener una función global para el tratamiento de los errores.

WinJS.xhr({ url: "http://localhost:32999/api/values" })
           .done(function (result) {
               divResultado.innerText = result.responseText;
 });

 WinJS.Promise.onerror = function errorhandler(event) {
         var ex = event.detail.exception;
         var promise = event.detail.promise;
   };

Pero si utilizamos el evento onerror para capturar el error en tiempo de ejecución, estaremos limitando un poco el control de los errores de las llamadas asíncronas.

 

Por último hay que tener en cuenta que para procesos muy largos la mejor opción es utilizar tareas en segundo plano.

Para más información visitar la página oficial de msdn donde hay gran cantidad de información y ejemplos sobre el desarrollo de aplicaciones Windows Store App

cross-posting: http://mrubino.net

 

Update: 22/10/2012
Por si no queda muy claro, Promise no hace que nuestro código sea asíncrono. Promise es una implementación del Patrón Observable y nos ayuda a gestionar nuestras llamadas asíncronas de una manera más sencilla. Las funciones asíncronas son las própias de WinRT acabadas en “Async“.