[Xamarin.Forms] Novedades de la versión 1.3: Triggers

Novedades de Xamarin.Forms 1.3

Recientemente Xamarin lanzo la version 1.3 definitiva de Xamarin.Forms con una cantidad de novedades muy sustansiosa. Entre otras novedades contamos con:

  • Soporte para Estilos.
  • Soporte para Behaviors.
  • Soporte para Triggers (DatTriggers y MultiTriggers).
  • Nuevo miembro en las páginas, OnBackButtonPressed para gestionar la pulsación del botón físico atrás.
  • Mejoras en el DependencyService para añadir más flexibilidad a la hora de registrar dependencias.
  • Corrección de bugs.

En este artículo vamos a analizar todas las novedades relacionadas con el uso de triggers en Xamarin.Forms 1.3.

¿Te apuntas?

¿Qué son los Triggers?

En concepto de los Triggers es muy simple. Podríamos resumirlo en
“cuando suceda esto lanza esta acción”. Nos permite realizar acciones
bajo ciertas condiciones.

Con la llegada de Xamarin.Forms 1.3 nos llegan los Triggers con las siguientes posibilidades:

  • Property Triggers: Cuando una propiedad recibe un valor concreto, lanza la acción.
  • Event Triggers: Cuando se dispara cierto evento, se lanza la acción.
  • Data Triggers: Cuandio una expresión Binding recibe un valor concreto, lanza la acción.

Todo elemento VisualElement contiene una propiedad Triggers de tipo IList<TriggerBase>.

Para analizar todas las novedades en Triggers incluidas en Xamarin.Forms 1.3 vamos a crear un nuevo proyecto desde cero:

Tras crear el proyecto procedemos a actualizar a Xamarin.Forms 1.3. Para
ello, vamos a gestionar los paquetes NuGet a nivel de solución.

NOTA: Si tenéis problemas al instalar Xamarin.
1.3 aseguráos de contar con la última versión de NuGet. Versiones
antiguas de NuGet pueden ocasionar problemas en la instalación. Para
asegurar tener la última versión debemos dirigirnos a Herramientas >
Extensiones y Actualizaciones -> Instalados. Aqui podremos
seleccionar NuGet e instalar la última versión.

Property Triggers o Triggers

Comenzaremos tratando los Property Triggers o sencillamente Triggers. Cuando una propiedad específica obtiene un valor (Value) en concreto, se aplican un conjunto de propiedades definidadas en la colección de  Setters.

Vamos a definir un simple botón:

<Button Text="Property Triggers" />

La apariencia visual del mismo:

Podemos definir en los recursos de la página un estilo para el botón:

<Style
     x:Key="PropertyTriggerStyle"
     TargetType="Button">
     <Style.Triggers>
       <Trigger
           Property="Button.IsFocused"
           Value="True"
           TargetType="Button">
         <Setter
             Property="Button.TextColor"
             Value="Red" />
       </Trigger>
     </Style.Triggers>
</Style>

En el estilo del botón hemos definido un Property Trigger que desencadenará el cambio del color de texto a rojo cuando la propiedad IsFocused sea verdadera, es decir, cuando el botón obtenga el foco.

La definición del botón quedaría:

<Button Style="{StaticResource PropertyTriggerStyle}" Text="Property Triggers" />

De modo que cuando hacemos clic sobre el botón y el mismo obtiene el foco, el color de texto pasa a rojo:

NOTA: En la propiedad Triggers podemos definir
una colección de Triggers. Cada Trigger vendra definido por la propiedad
y valor que desencadena la acción.

Event Triggers

Un Event Trigger se desencadena cuando un evento en concreto se dispara. Una vez desencadenado se ejecuta una clase que deriva de TriggerAction<T>.

Definimos un Slider muy sencillo, con valor 50 y un rango entre 0 y 100:

<Slider
     x:Name="SliderTriggers"
     Minimum="0"
     Maximum="100"
     Value="50">
</Slider>

El aspecto del mismo sería el siguiente:

Independientemente del valor, no tenemos color de fondo definido por
lo que el aspecto sera el mismo. Podemos otorgar al usuario mayor
feedback mostrando distintos colores segun el valor.

Creamos una clase que derive que TriggerAction<Slider>:

public class SliderColorTrigger : TriggerAction<Slider>
{
     protected override void Invoke(Slider sender)
     {
         var value = sender.Value;
 
         if (value < 40)
             sender.BackgroundColor = Color.Red;
         else if (value > 60)
             sender.BackgroundColor = Color.Green;
         else
             sender.BackgroundColor = Color.Black;
     }
}

En la clase sobreescribimos el método Invoke. Este método tenemos acceso al control por lo que podemos con suma facilidad verificar el valor del Slider y modificar su color de fondo e consecuencia.

Ahora llega el momento de usar el Event Trigger. Para ello, en XAML debemos añadir el namespace donde definimos el Event Trigger:

xmlns:triggers="clr-namespace:Xamarin_Triggers.Triggers;assembly=Xamarin_Triggers"

Añadimos nuestro SliderColorTrigger en la colección de Triggers del Slider:

<Slider
     x:Name="SliderTriggers"
     Minimum="0"
     Maximum="100"
     Value="50">
     <Slider.Triggers>
       <EventTrigger
           Event="ValueChanged">
         <triggers:SliderColorTrigger />
       </EventTrigger>
     </Slider.Triggers>
</Slider>

Si el valor es inferior a 40 el color de fondo pasa a ser rojo:

Mientras que si el valor es superior a 60, es color de fondo es verde:

Data Triggers

Muy similar a los Property Triggers pero en lugar de verificar que una propiedad en concreto tiene un valor o estado, la verificación es con Bindings. De esta forma, cuando un valor bindeado recibe algun valor en concreto, se desencadena una acción.

Veamos un sencillo ejemplo. Vamos a simular el clásico formulario
básico de recuperación de contraseña en la que se le pide el nombre de
usuario o coreo electrónico al usuario.

Definimos el control Entry que recibirá la información:

<Entry x:Name="EmailEntry"            
     Placeholder="Enter Email" />

Continuamos definiendo el botón que enviaría la información:

<Button      
     x:Name="ValidationButton" Text="Send"       
     FontSize="Large"            
     HorizontalOptions="Center">  
     <Button.Triggers>      
         <DataTrigger               
              TargetType="Button"            
              Binding="{Binding Source={x:Reference EmailEntry},
              Path=Text.Length}" Value="0">             
               <Setter Property="IsEnabled" Value="False" />  
          </DataTrigger>          
     </Button.Triggers>
</Button>

Analicemos el trozo de XAML anterior. Hemos definido un DataTrigger
en el botón de modo que se analiza el valor la longitud del texto de la
caja definida anteriormente. Si el valor es cero, se deshabilita el
botón.

Sin tener contenido en la caja de texto, el estado del botón es deshabilitado:

Una vez escrita la información el botón se habilita:

NOTA: También tenemos disponibles MultiTriggers
que nos permiten definir múltiples condiciones que se deben de dar para
poder realizar los cambios definidos en el conjunto de Setters.

Podéis descargar el ejemplo realizado a continuación:

También podéis acceder al código fuente directamente en GitHub:

Ver GitHub

Recordar que cualquier tipo de duda o sugerencia la podéis dejar en los comentarios de la entrada.

Más información

[Eventos] Desarrollo de Apps multiplataforma nativas con Xamarin

Introducción

Estamos en un mundo conectado donde los smartphones forman parte de
esa red conectada y del día a día de muchos de nosotros. Contamos con
múltiples plataformas de peso en el mercado:

  • iOS
  • Android
  • Windows Phone

Esto a nivel de desarrollo nos supone barreras. Contamos con
plataformas de desarrollo diferentes, lenguajes diferentes, etc.
suponiendo un nivel de aprendizaje y esfuerzo cada vez mayor de cara a
desarrolladores. Entre las posibles opciones contamos con Xamarin.
Se trata de un Framework de desarrollo que permite crear aplicaciones
para Android, iOS y Windows usando C# y la plataforma .NET.

Los eventos

Si eventos en plural. Bravent ha organizado un pequeño Tour
por varias ciudades donde tendremos una serie de sesiones técnicas
relacionadas con el desarrollo de aplicaciones multiplataforma nativas
con Xamarin donde veremos desde los conceptos básicos a usos más
avanzados conectando aplicaciones con Azure además todo planteado con
buenas prácticas y en un marco práctico.

El Tour pasara por tres ciudades:

  1. Madrid: El 4 de Febrero en las oficinas de Microsoft Ibérica. Registro.
  2. Sevilla: El 9 de Febrero en el Cloudng Point. Registro.
  3. Barcelona: El 16 de Febrero en las oficinas de Microsoft. Registro.

La agenda en todas las ciudades sera la siguiente:

  • 9:00h – 9:55h Introducción al desarrollo de Apps con Xamarin. El
    mercado móvil es hoy día un pilar importante tanto para usuarios como
    para desarrolladores. Sin embargo, tenemos un mercado amplio y diverso
    con una gran variedad de dispositivos y sistemas. Si entramos en el
    terrero de desarrolladores el problema se acentúa con diferentes
    entornos de desarrollo, lenguajes y otros elementos. En esta sesión
    repasaremos el estado actual, introduciremos Xamarin como herramienta
    para crear aplicaciones nativas multiplataforma desde Visual Studio
    analizando todas sus bondades.
  • 10:00h – 10:55h Arquitectura de proyectos multiplataforma con Xamarin. Nuestro
    objetivo como desarrolladores es crear aplicaciones útil y atractivas
    pero sobretodo perfectamente funcionales. Para poder lograr ese objetivo
    es sin duda muy importante la arquitectura aplicada a la App. En esta
    sesión repasaremos el patrón MVVM aplicándolo a una aplicación Xamarin
    en cada una de las plataformas paso a paso utilizando MVVMCross.
  • 10:55h – 11:10h Descanso
  • 11:10h – 12:05h  Introducción a Xamarin.Forms. Xamarin
    presento una nueva herramienta en su suite llamada Xamarin.Forms que
    tiene como objetivo permitir a los desarrolladores crear la interfaz de
    usuario para iOS, Android y Windows Phone con un mismo código común en
    C# o XAML. En esta sesión vamos a profundizar en todos los aspectos
    relacionados con Xamarin.Forms creando una aplicación desde cero donde
    aprenderemos todos los conceptos básicos.
  • 12:10h – 13:05h  Aplicaciones multiplataforma y Microsoft Azure. Prácticamente
    todo Frontend cuenta con un Backend. En esta sesión veremos las
    bondades de Azure Mobile Services y lo sencillo que es integrar con
    aplicaciones Xamarin. Además veremos otro punto importante en
    aplicaciones móviles como las notificaciones push utilizando Azure para
    ello.
  • 13:10h – 14:15h  Conociendo los servicios Xamarin, analíticas, análisis de rendimiento, testing y mucho más. El
    ecosistema Xamarin no cesa en las herramientas de desarrollo. Tenemos a
    dispositivos una gran variedad de servicios destinados a complementar
    el mismo, analíticas, testing, análisis de rendimiento, etc. En esta
    sesión vamos a hacer un repaso por todos los servicios disponibles
    realizando demos de cada uno de ellos.

En cuanto a ponentes, contaremos con Josué Yeray y un servidor.

Esperamos poder veros en alguna de las ciudades!

Más información

[Xamarin.Forms] Novedades de la versión 1.3: Estilos

Novedades de Xamarin.Forms 1.3

Recientemente Xamarin lanzo la version 1.3 definitiva de Xamarin.Forms con una cantidad de novedades muy sustansiosa. Entre otras novedades contamos con:

  • Soporte para Estilos.
  • Soporte para Behaviors.
  • Soporte para Triggers (DatTriggers y MultiTriggers).
  • Nuevo miembro en las páginas, OnBackButtonPressed para gestionar la pulsación del botón físico atrás.
  • Mejoras en el DependencyService para añadir más flexibilidad a la hora de registrar dependencias.
  • Corrección de bugs.

Del listado podemos sacar varias opciones muy interesantes entre las
que destaca el uso de estilos. En este artículo vamos a analizar todas
las novedades relacionadas con el uso de estilos en Xamarin.Forms 1.3.

¿Te apuntas?

Estilos

En toda aplicación móvil la apariencia visual es vital. Cada vez es
mayor el esfuerzo depositado a la hora de crear aplicaciones atractivas a
la par que intuitivas y en muchos casos conseguir una imagen única que
diferencia a la Aplicación del resto es prioritario. Por este motivo,
debemos de contar con opciones sencillas de poder personalizar los
distintos elementos que componen la interfaz.

Los estilos permitir definir múltiples propiedades visuales de elementos de la interfaz de forma reutilizable.

Para analizar todas las novedades en estilos incluidas en Xamarin.Forms 1.3 vamos a crear un nuevo proyecto desde cero:

Tras crear el proyecto procedemos a actualizar a Xamarin.Forms 1.3. Para
ello, vamos a gestionar los paquetes NuGet a nivel de solución.

NOTA: Si tenéis problemas al instalar Xamarin.
1.3 aseguráos de contar con la última versión de NuGet. Versiones
antiguas de NuGet pueden ocasionar problemas en la instalación. Para
asegurar tener la última versión debemos dirigirnos a Herramientas >
Extensiones y Actualizaciones -> Instalados. Aqui podremos
seleccionar NuGet e instalar la última versión.

Utilizaremos elementos simples para aprender a utilizar controles, en
este ejemplo, botones. Podemos modificar la apariencia del control
estableciendo directamente propiedades en el control:

<Button
     TextColor="Yellow"
     Text="Sin Estilo" />

El resultado:

Realmente es algo bastante sencillo, pero… ¿qué ocurriría si
tuviesemos múltiples botones en la Aplicación que deben tener la misma
apariencia visual?.

No suena muy óptimo repetir la misma asignación de propiedades una y otra vez, ¿cierto?. En estos casos lo ideal es utilizar estilos. Podemos definir un estilo directamente en un elemento visual:

<Button
     Text="Estilo como recurso del botón">
     <Button.Style>
        <Style TargetType="Button">
          <Setter Property="TextColor" Value="Blue" />
        </Style>
     </Button.Style>
</Button>

El estilo se define con propiedades Setter. Cada propiedad establecidad de tipo Setter puede modificar el valor de una propiedad del elemento indicado en TargetType. Eastablecemos la propiedad en Property y el valor en Value. En nuestro pequeño ejemplo, contamos con un Setter que modifica la propiedad TextColor del elemento de tipo Button.

Continuamos. Si tuviesemos múltiples botones y quisieramos aplicar el
mismo estilo, de la forma anterior no logramos reutilizar código.
Podemos reutilizar estilos de manera muy simple. Todas las páginas
tienen una propiedad Resources. Esta propiedad es de tipo ResourceDictionary, permitiendo contener un diccionario de claves de tipo string y de valor de tipo object.

<ContentPage.Resources>
</ContentPage.Resources>

El estilo definido en los recursos de la página:

<Style x:Key="ButtonStyle" TargetType="Button">
     <Setter Property="HorizontalOptions" Value="Center" />
     <Setter Property="VerticalOptions" Value="Center" />
     <Setter Property="TextColor" Value="Green" />
</Style>

Definimos el estilo como hemos visto previamente con un conjunto n de Setters. Es importante recalcar que establecemos la propiedad Key
que nos permite establecer una clave al estilo para poder referenciar
al mismo en cualquier elemento de manera fácil y sencilla. Este tipo de
estilos reciben el nombre de estilos explícitos.

Definimos un botón y utilizamos su propiedad Style para acceder al estilo definido.

<Button
     Text="Estilo Explícito"
     Style="{StaticResource ButtonStyle}"/>
<Button

De esta forma podemos definir un conjunto de propiedades en un estilo y
en los elementos deseados acceder al mismo. Sin  embargo, si queremos
aplicar el mismo estilo a todos los botones no es necesario definir la
propiedad Key en el estilo.

<Style TargetType="Button">
     <Setter Property="HorizontalOptions" Value="Center" />
     <Setter Property="VerticalOptions" Value="Center" />
     <Setter Property="TextColor" Value="Red" />
</Style>

Definimos el estilo exactamente igual pero sin propiedad Key. Este estilo recibe el nombre de estilo implícito. Si añadimos botones en la vista:

<Button
     Text="Estilo Implícito" />

Automáticamente sin realizar ninguna acción extra, el estilo implícito se aplica al botón.

NOTA: Importante recordar que si aplicamos una
propiedad directamente en un elemento visual, si valor tiene prioridad
sobre cualquier otro estilo explícito o implícito.

Estilos heredados

Otra de las características fundamentales que tenemos disponible en Xamarin.Forms 1.3 con los estilos es la herencia
de estilos. De esta forma, podemos extender un estilo base añadiendo
más opciones o incluso sobreescribiendo algunas de las propiedades
establecidas.

Recordamos el estilo utilizado hasta ahora:

<Style TargetType="Button">
     <Setter Property="HorizontalOptions" Value="Center" />
     <Setter Property="VerticalOptions" Value="Center" />
     <Setter Property="TextColor" Value="Red" />
</Style>

Podemos crear un estilo basado en otro utilizando la propiedad BasedOn:

<Style x:Key="InheritedButtonStyle" TargetType="Button" BasedOn="{StaticResource ButtonStyle}">
     <Setter Property="BorderColor" Value="Green" />
     <Setter Property="FontSize" Value="Large" />
</Style>

El estilo anterior define los valores para las propiedades BorderColor y FontSize además de incluir las definiciones de ButtonStyle.

<Button
     Text="Herencia de Estilos"
     Style="{StaticResource InheritedButtonStyle}" />

El resultado:

One more thing…

Nos queda por ver otra posibilidad muy habitual e interesante, definir estilos a nivel de aplicación. En Xamarin.Forms contamos con una nueva clase base Application.

Podemos definir una página con XAML y su code behind asociado definiendo la Aplicación:

xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"                    
x:Class="Xamarin_Styles.App">
  
</Application>

La clase deriva de Application:

public partial class App : Application
{
     public App()
     {
         InitializeComponent();
         MainPage = new NavigationPage(new MainView());
     }
}

Podemos definir recursos a nivel de Aplicación donde crear desde
recursos a estilos más complejos a compartir a lo largo de toda la
aplicación:

<Application.Resources>  
     <ResourceDictionary>
          <Style
               x:Key="AppButtonStyle"
               TargetType="Button">
               <Setter Property="Rotation" Value="25" />
          </Style>
     </ResourceDictionary>
</Application.Resources>

En nuestra vista principal podemos acceder al estilo definido en App.xaml:

<Style x:Key="InheritedAppButtonStyle" TargetType="Button" BasedOn="{StaticResource AppButtonStyle}">
     <Setter Property="BorderColor" Value="Green" />
     <Setter Property="FontSize" Value="Large" />
</Style>

El botón:

<Button
     Text="Herencia de Estilos desde App"
     Style="{StaticResource InheritedAppButtonStyle}"/>

El resultado final:

Podéis descargar el ejemplo completo realizado a continuación:

También tenéis el código fuente disponible e GitHub:

Ver GitHub

Recordar que podéis dejar en los comentarios cualquier tipo de sugerencia o pregunta.

Más información

[Quedada CartujaDotNet] Arrancando el año

Quedada

En CartujaDotNet vamos a realizar una quedada
informal para charlar abiertamente sobre tecnologías Microsoft,
herramientas utilizadas, intercambiar impresiones, etc. Además, se
analizarán las próximas charlas ya planteadas y los eventos confirmados
entre otros temas de interés.

No hace falta confirmar asistencia, y por supuesto será gratuito.

¿Te apuntas?

A continuación tienes disponible la fecha, hora y lugar:

Más información

[Xamarin.Forms] Novedades de Xamarin.Forms 1.3: Behaviors

Novedades de Xamarin.Forms 1.3

Recientemente Xamarin lanzo la version 1.3 definitiva de Xamarin.Forms con una cantidad de novedades muy sustansiosa. Entre otras novedades contamos con:

  • Soporte para Estilos.
  • Soporte para Behaviors.
  • Soporte para Triggers (DatTriggers y MultiTriggers).
  • Nuevo miembro en las páginas, OnBackButtonPressed para gestionar la pulsación del botón físico atrás.
  • Mejoras en el DependencyService para añadir más flexibilidad a la hora de registrar dependencias.
  • Corrección de bugs.

En este artículo vamos a analizar todas las novedades relacionadas con el uso de behaviors en Xamarin.Forms 1.3.

¿Te apuntas?

Behaviors

El concepto es algo muy sencillo. Un Behavior espera por “algo” para hacer “algo”. Concretamos más. Un Behavior espera por “algo”.
Puede ser un evento que se lanza, el cambio de una propiedad o
cualquier otra acción personalizada que deseamos monitorear. Una vez que
ese “algo” se desencadena, el Behavior puede hacer
acciones muy variadas, desde cambiar el valor de una propiedad, lanzar
un evento, hacer verificaciones o validaciones, etc.

Los Behaviors nos permiten encapsular lógica que se puede
adjuntar a un componente específico. Generalmente ayudan a personalizar o
completar ciertos componentes e incluso en muchas ocasiones son un a
ayuda fundamental para mantener una estructura idónea al implementar
patrones como MVVM.

Comenzamos creando un nuevo proyecto desde cero:

Tras crear el proyecto procedemos a actualizar a Xamarin.Forms 1.3. Para
ello, vamos a gestionar los paquetes NuGet a nivel de solución.

NOTA: Si tenéis problemas al instalar Xamarin.
1.3 aseguráos de contar con la última versión de NuGet. Versiones
antiguas de NuGet pueden ocasionar problemas en la instalación. Para
asegurar tener la última versión debemos dirigirnos a Herramientas >
Extensiones y Actualizaciones -> Instalados. Aqui podremos
seleccionar NuGet e instalar la última versión.

El objetivo que buscaremos en este ejemplo sera crear un Behavior analizando todas las partes implicadas que permitira solo introducir valores numéricos en una caja de texto.

Comenzamos creando el behavior. Crearemos una clase que heredará de Behavior<T>:

public class NumericEntryBehavior : Behavior<Entry>
{
 
}

Pasamos a ver la implementación:

public class NumericEntryBehavior : Behavior<Entry>
{
     private string _lastValidText;
 
     protected override void OnAttachedTo(Entry bindable)
     {
         bindable.TextChanged += EntryTextChanged;
         base.OnAttachedTo(bindable);
     }
 
     protected override void OnDetachingFrom(Entry bindable)
     {
         bindable.TextChanged -= EntryTextChanged;
         base.OnDetachingFrom(bindable);
     }
 
     private void EntryTextChanged(object sender, EventArgs e)
     {
         var entry = sender as Entry;
         if (entry != null)
         {
             double value;
             if (string.IsNullOrEmpty(entry.Text) ||
                 Double.TryParse(entry.Text, out value))
             {
                 _lastValidText = entry.Text;
                 return;
             }
 
             entry.Text = _lastValidText;
         }    
     }
}

Cada vez que el usuario escriba algo en la caja de texto haremos una
verificación para determinar si se trata de un valor numérico. Para
ello, sobreescribimos el método OnAttachedTo donde recibiremos el objeto Entry y nos suscribiremos a su evento TextChanged. De igual forma, sobreescribimos el método OnDetachingFrom donde eliminaremos la suscripción al evento y el Behavior del objeto Entry. En el evento TextChanged intentamos parsear el contenido recibido a Double para verificar si es un dígito o no. De esa forma, vamos comprobando que lo que escribe el usuario son dígitos o no.

NOTA: Para aquellos que tengáis experiencia
definiendo Behaviors en la plataforma Windows habréis observado algunas
diferencias. No tenemos acceso al objeto AssociatedObject. En cambio, el
objeto asociado se inyecta en los casos necesarios.

Una vez definido el Behavior es hora de implementarlo en nuestra
interfaz de usuario. Para acceder al mismo debemos definir el namespace
donde se encuentra:

xmlns:behaviors="clr-namespace:Entry_Behavior.Behaviors;assembly=Entry_Behavior"

Simple. Utilizamos la sintaxis clr-namespace para definir el namespace donde se encuentra definido.

<Entry>
     <Entry.Behaviors>
        <behaviors:NumericEntryBehavior />
     </Entry.Behaviors>
</Entry>

Vamos a analizar el trozo de XAML anterior. Cada elemento que hereda de VisualElement cuenta con una propiedad de tipo IList<Behavior>. Para utilizar nuestro behavior NumericEntryBehavior, dentro de la colección de Behaviors del control Entry, definimos el mismo utilizando el espacio de nombres behaviors, definido previamente.

NOTA: De nuevo, para aquellos con experiencia
previa con Behaviors en la plataforma Windows. En Xamarin.Forms cada
elemento heredado de VisualElement cuenta con una propiedad Behaviors.
No es necesario importar librerías para poder trabajar con Behaviors.

Y todo listo!. Si ejecutamos nuestro ejemplo podemos probar el “comportamiento” añadido al control Entry.
Al escribir información veremos que solo se permiten valores numéricos o
carácteres como la coma en caso de desear escribir decimales.

El resultado es el siguiente:

Podéis descargar el ejemplo completo realizado a continuación:

Recordar que podéis dejar en los comentarios cualquier tipo de sugerencia o pregunta.

Más información

[Eventos] dotNet Spain Conference, no te lo puedes perder!

dotNet Spain Conference

Como desarrolladores de la plataforma .NET tenemos ciertas citas más o
menos reservadas cada cierto tiempo a nivel nacional y local. Siempre
es un tremendo placer conocer nuevas herramientas, tecnologías,
experiencias y poder pasar un rato con compañeros brillantes tanto a
nivel profesional como a nivel personal. Pues bien, apuntad en vuestras
agendas una de esas citas imperdibles. A final de Febrero, concretamente
los días 27 y 28 de Febrero tendrá lugar el mayor evento de .NET celebrasdo hasta la fecha, la dotNet Spain Conference.

El evento esta centrado en exclusividad a .NET pero cubriendo todo el
espectro, desde .NET MicroFramework a desarrollo de Apps, Cloud, IoT,
soluciones ERP, etc.

El evento tendrá lugar en dos días, Viernes y Sábado organizado con Tracks de la siguiente forma:

  • Viernes: ALM/Tools, Web, Cloud, Data, Enterprise, Hands-on-lab patrocinadores.
  • Sábado: Apps, Games, IoT, Coding-4-fun, Talleres de programación para niños, Hands-on-labs patrocinadores.

Tendremos sesiones técnicas de elevado nivel de 1 hora y 15 minutos de duración organizadas en 8 tracks además de talleres, stands, etc.

Tendrá lugar en la Escuela Politécnica Superior (Universidad de Alcalá):

 Campus Universitario. Ctra. Madrid-Barcelona, Km. 33,600

28805 Alcalá de Henares

Por si fuera poco, durante el sábado se organizarán talleres destinados a los más peques de la casa para que aprendan a programar: pensamiento computacional, robótica, videojuegos y mucho más.

NOTA: La entrada tendrá un coste muy reducido de tanto 10 €  e incluso inferior si la compras con tiempo.

No te lo puedes perder!

Más información

[Tips and Tricks] RequestTheme, cambiar el tema al vuelo!

Introducción

En Windows Phone, podemos definir un tema totalmente personalizado para nuestras aplicaciones. Por defecto, ya contamos con dos temas, claro y oscuro (“Light” y “Dark”
respectivamente). Si no usamos nuestro propio tema totalmente
personalizado debemos gestionar los elementos de nuestra interfaz para
una correcta visualización tanto en el tema claro como en el oscuro. El
usuario puede cambiar el tema a utilizar (por defecto oscuro).

Podemos forzar el utilizar un tema en concreto e incluso en tiempo de ejecución podemos modificar el tema a utilizar para cualquier elemento.

NOTA: Modificar la propiedad Application.RequestedTheme en tiempo de ejecución provoca una excepción.

RequestTheme

La propiedad RequestedTheme nos permite obtener o establecer el tema a utilizar. Al cambiar el valor de RequestedTheme
de la Aplicación a nivel general o de un elemento en concreto provoca
que se obtengan las plantillas y estilos del ResourceDictionary
denominados “Light” o “Dark” de la colección ThemeDictionaries.

NOTA: La propiedad RequestedTheme es ignorada si el usuario tiene activo el modo de alto contraste.

Crearemos un ejemplo muy simple para realizar el cambio en tiempo de ejecución del tema. Creamos dos sencillos botones:

<Button Content="Light" />
<Button Content="Dark" />

El primero cambiara al tema claro y el segundo al tema oscuro:

En nuestra viewmodel, contaremos con un comando para cada botón:

private ICommand _lightCommand;
private ICommand _darkCommand;
 
public ICommand LightCommand
{
     get { return _lightCommand = _lightCommand ?? new DelegateCommand(LightCommandExecute); }
}
 
public ICommand DarkCommand
{
     get { return _darkCommand = _darkCommand ?? new DelegateCommand(DarkCommandExecute); }
}
 
private void LightCommandExecute()
{
 
}
 
private void DarkCommandExecute()
{
 
}

La definición de los botones quedara:

<Button Content="Light" Command="{Binding LightCommand}" />
<Button Content="Dark" Command="{Binding DarkCommand}" />

En Windows Phone 8.1, la App cuenta con una Window que contiene un único Frame que ocupa el 100% del área de la pantalla.

El Frame, se crea en el arranque de la aplicación y es el encargado de contener y gestionar cada una de las páginas (Page). La propiedad RequestedTheme establecida en un elemento FrameworkElement
es heredado en sus elementos hijos. Podemos anular la herencia
estableciendo la propiedad RequestedTheme en un elemento hijo concreto.
Estableceremos la propiedad en el Frame de la Aplicación provocando que
la misma sea heredada por sus elementos hijos, es decir, las páginas de
la Aplicación:

AppFrame.RequestedTheme = ElementTheme.Light;

En el segundo comando establecemos el RequestedTheme del Frame de la Aplicación al tema oscuro:

AppFrame.RequestedTheme = ElementTheme.Dark;

Al cambiar al tema claro nuestra interfaz se vera de la siguiente forma:

El resultado en video:

Podéis descargar el pequeño ejemplo realizado a continuación:

Más información