[Tips and Tricks] Detectar modo de interacción en Windows 10

Introducción

Windows 10 ha llegado como la culminación en el viaje hacia la convergencia en el desarrollo entre plataformas Windows. Ahora hablamos de Apps Universales
escritas una única vez con un código común tanto para la lógica de
negocio como para la interfaz de usuario. Además, generamos un único
paquete que mantendrá una interfaz consistente y familiar para el
usuario pero adaptada a cada plataforma. Podemos crear apps que
funcionen en todo tipo de dispositivos como teléfonos, tabletas,
portátiles, dispositivos IoT, Surface Hub e incluso HoloLens.

Generamos un único paquete para todas las familias de dispositivos por lo tanto:

  • Debemos utilizar SDKs de extensión para acceder a APIs concretas de una familia de dispositivo.
  • Utilizaremos varias técnicas para adaptar la interfaz de usuario y
    poder otorgar la mejor experiencia de usuario posible en cada familia de
    dispositivo.

Sin embargo, a pesar de adaptar código e interfaz no siempre en cada dispositivo utilizaremos el mismo modo de interacción. Por ejemplo, en una Surface podremos interactuar con la App tanto utilizando teclado y ratón como con los dedos.

¿Podemos detectar el modo de interacción del usuario con nuestra App y actuar en consecuencia?

En este artículo vamos a aprender como detectar el modo de interacción.

Modo de interacción

Podemos acceder a la configuración actual de la ventana de la App utilizando UIViewSettings.GetForCurrentView() donde tenemos acceso a una propiedad llamada UserInteractionMode:

var userInteractiveMode = UIViewSettings.GetForCurrentView().UserInteractionMode;

La propiedad es de tipo enumeración con las siguientes opciones:

  • Mouse: El usuario esta utilizando ratón.
  • Touch: EL usuario utiliza pantalla táctil.
switch (userInteractiveMode)
{
     case UserInteractionMode.Mouse:
          InteractionMode = "Ratón";
          break;
     case UserInteractionMode.Touch:
          InteractionMode = "Táctil";
          break;
}

En función de los valores anteriores podemos realizar adaptaciones de
la interfaz de usuario para facilitar la interacción dependiendo del
modo del usuario. 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

[Xamarin] Integración continua con Team City

Introducción

La calidad en el software es algo innegociable. Un buen proceso en el
desarrollo y gestión del proceso es fundamental para conseguir ese
objetivo. Debemos entregar Apps móviles perfectamente adaptadas a cada
plataforma, ofreciendo la mejor experiencia de usuario posible pero
sobretodo, funcional. Una App funcional debe cubrir y cumplir unos
mínimos exigentes de calidad.

Como desarrolladores, somo humanos y el código no estara libre de
errores. Sin embargo, el proceso que apliquemos para la detección y
corrección a los mismos, es vital.

A veces, ocurre...

A veces, ocurre…

Realizar un proceso automático en cada nuevo checkin o de manera programada donde:

  • Compilar proyectos.
  • Pasar pruebas unitarias.
  • Pasar pruebas de interfaz de usuario.
  • Incluso publicar automáticamente paquetes y resultados.

Nos permitirá detectar problemas en el código de la forma más
prematura posible, pudiendo ofrecer mayor calidad. En este artículos
vamos a repasar todo lo necesario para realizar

Tests en Xamarin

Para centrarnos en su totalidad en la parte de integración continua
vamos a centrarnos en uno de los ejemplos realizados con Xamarin más
conocidos por los desarrolladores Xamarin, TipCalc:

TipCalc

TipCalc

Aplicación multiplataforma que nos permite calcular la cantidad de
propina a entregar en función del precio. Tenéis el código e incluso
tutoriales de como crearla paso a paso en este enlace.

Nos centramos a continuación en pruebas de nuestra App. Pensar que
nuestro código estara siempre absolutamente libre de errores es una
quimera. Sin embargo, si cada vez que compilamos el proyecto tenemos una
forma de pasar pruebas a nuestra aplicación tanto de lógica como de
interfaz de usuario sin duda reduciremos la cantidad de errores y
aumentaremos la calidad de la App.

Podemos crear dos tipos de pruebas diferenciadas:

  • Pruebas unitarias: Pruebas de pequeñas unidades funcionales de nuestra App. Utilizaremos NUnit para realizar estas pruebas unitarias generalmente de ViewModels, Helpers y Servicios.
  • Pruebas de interfaz de usuario: Pruebas sobre la interfaz de usuario, escritura en cajas de texto, pulsaciones de botones, etc. Utilizaremos Xamarin UITest para estas pruebas.

NOTA: Xamarin UITest es un framework de Testing
de UI basado en Calabash que nos permite escribir y ejecutar tests con
C# y NUnit para validar Apps Android e iOS.

Veamos una prueba unitaria de nuestro ejemplo:

[TestFixture]
public class TipCalcViewModelTests
{
     [Test]
     public void TipPercent_Updated_TipAmountAndTotalAreUpdated()
     {
         var model = new TipCalcViewModel
         {
             SubTotal = 10,
             PostTaxTotal = 12,
             TipPercent = 20
         };
 
         Assert.AreEqual(14, model.Total);
         Assert.AreEqual(2, model.TipAmount);
     }
}

Es una calculadora, verificamos que los cálculos de la misma sean
correctos. Asignamos una serie de valores y verificamos que los
resultados dados por la App son los esperados.

Pasamos a pruebas de interfaz de usuario:

[TestFixture]
public class TipCalculationTests
{
     private IApp _app;
 
     [SetUp]
     public void SetUp()
     {
         switch (TestEnvironment.Platform)
         {
             case TestPlatform.Local:
                 var appFile =
                     new DirectoryInfo(Path.Combine("..", "..", "testapps"))
                         .GetFileSystemInfos()
                         .OrderByDescending(file => file.LastWriteTimeUtc)
                         .First(file => file.Name.EndsWith(".app") || file.Name.EndsWith(".apk"));
 
                 _app = appFile.Name.EndsWith(".app")
                     ? ConfigureApp.iOS.AppBundle(appFile.FullName).StartApp() as IApp
                     : ConfigureApp.Android.ApkFile(appFile.FullName).StartApp();
                 break;
             case TestPlatform.TestCloudiOS:
                 _app = ConfigureApp.iOS.StartApp();
                 break;
             case TestPlatform.TestCloudAndroid:
                 _app = ConfigureApp.Android.StartApp();
                 break;
          }
      }
 
      [Test]
      public void CalculateTip()
      {
         const decimal subTotal = 10M;
         const decimal postTaxTotal = 12M;
 
         _app.EnterText(e => e.Marked("SubTotal"), subTotal.ToString(CultureInfo.InvariantCulture));
         _app.Screenshot("When I enter a subtotal");
 
         _app.EnterText(e => e.Marked("PostTaxTotal"), postTaxTotal.ToString(CultureInfo.InvariantCulture));
         _app.Screenshot("And I enter the post-tax total");
 
         var tipPercent = decimal.Parse(_app.Query(e => e.Marked("TipPercent")).Single().Text) / 100;
         var tipAmount = decimal.Parse(_app.Query(e => e.Marked("TipAmount")).Single().Text.Substring(1));
         var total = decimal.Parse(_app.Query(e => e.Marked("Total")).Single().Text.Substring(1));
 
         var expectedTipAmount = subTotal * tipPercent;
         Assert.AreEqual(expectedTipAmount, tipAmount);
 
         var expectedTotal = postTaxTotal + expectedTipAmount;
         Assert.AreEqual(expectedTotal, total);
 
         _app.Screenshot("Then the tip and total are calculated correctly");
     }
}

Accedemos a la App y accedemos a los distintos elementos de la
interfaz para interactuar con ellos, recuperar valores y hacer
verificaciones. Durante cualquier prueba podremos realizar acciones
extras como por ejemplo tomar capturas.

NOTA: Resaltamos que el objetivo fundamental del
artículo es la explicación paso a paso de conceptos y necesidades para
preparar TeamCity como servidor de integración continua para Apps
Xamarin. Hemos pasado de manera muy superficial por conceptos básicos de
pruebas (Arrange (Preparar), Act (Actuar), Assert (Afirmar)), conceptos
básicos de NUnit o de Xamarin UITest. En otros artículos
profundizaremos en pruebas e incluso en uso e integración con Xamarin
Test Cloud.

Integración Continua

La integración continua consiste en hacer integraciones automáticas de un Proyecto lo más a menudo possible para así detector fallos cuantos antes.

Entendemos por integración la compilación y ejecución de pruebas.

WorkFlow

WorkFlow

El flujo del proceso sería:

  1. El desarrollador trabaja en su equipo de desarrollo subiendo cambios
    al repositorio de código donde estaría el código además de las pruebas
    unitarias.
  2. De una forma automática, el repositorio de código envia el mismo al servidor de BUILD.
  3. El servidor de BUILD realizará la compilación de la solución o
    proyectos, ejecutará pruebas y recopilará la información de los
    resultados.
  4. Los resultados los obtiene el desarrollador para poder analizarlos y actuar en consecuencia.

“La integración continua no evitará que se
produzcan bugs, pero si nos permite encontrarlos y solucionarlos de una
forma dramáticamente más fácil”

Martin Flowler

Los beneficios de utilizar integración continua son:

  • Detectar errores con mayor rapidez y antelación. Esto provocará que sea más sencillo de corregir y por lo tanto más barato.
  • Consistencia. O lo que es lo mismo, tener Builds reproducibles. La
    App funcionará en cualquier entorno con las mismas condiciones. Evitamos
    la “contaminación de la Build” o lo que es lo mismo, tener la Build con
    parámetros “a fuego” y condiciones específicas de la máquina de Build.
  • Poder automatizar también la entrega consiguiendo una entrega continua.

CI Xamarin 03

Team City

Dentro de las opciones de software de integración continua disponible, en este artículos vamos a centrarnos en Team City. Es:

  • Fácil de instalar y configurar.
  • Está disponible para Windows y OSX.
  • Cuenta con versión gratuita.

NOTA: Tenemos otras opciones que podemos
utilizar para realizar integración continua con Apps Xamarin. Como por
ejemplo, TFS (mucho más que un servidor de integracion continua) o
Jenkins.

Instalación

Tras descargar la última versión de TeamCity procedemos a su
instalación en el servidor de integración continua. En este ejemplo, la
instalación y pruebas las realizare en mi propio equipo de desarrollo:

Inicio

Inicio

La instalación se realizará de forma muy sencilla de forma similar a cualquier otra instalación:

Similar al resto de instalaciones...

Similar al resto de instalaciones…

Al terminar comenzamos con las primeras configuraciones importantes.
Podemos dejar todos lo valores que nos facilitan por defecto y aceptar
pero tened en cuenta que:

  • serverUrl: Ruta de acceso al portal de administración web de Team City.
  • name: Nombre de la máquina correspondiente a nuestro servidor de integración continua.
  • systemDir, workDir y tempDir: Rutas del sistema, de trabajo y temporal correspondientes a nuestro Build Agent. Un Build Agent es una pieza configurable en Team City con capacidad para recibir diferentes comandos y lanzar Builds.
Configuración básica

Configuración básica

Llegados a este punto si accedemos a localhost con el puerto asignado a Team City veremos:

Todo listo!

Todo listo!

Configuración inicial

Los siguientes pasos en la configuración consisten en:

  • Creación de Base de Datos a utilizar.
  • Creación de usuario/s a utilizar.

La creación de la Base de datos es muy simple:

CI Xamarin 08

Elegimos BBDD a usar

Tras elegir el proveedor de Base de Datos y aceptar condiciones:

CI Xamarin 09

EULA

Pasamos a la creación de la cuenta de administrador:

Creamos usuario

Creamos usuario

Tras este paso podemos:

  • Crear nuevos usuarios.
  • Crear grupos.
  • Configurar diferentes notificaciones.
  • Integrar Team City con diferentes herramientas e IDEs.
  • Etc.
Configuración

Configuración

Llegados a este punto podemos crear un nuevo proyecto y dentro del
mismo diferentes Builds con múltiples pasos. Sin embargo, no lo haremos
así…

FAKE

A la hora de realizar integración continua tenemos varias opciones.
Por un lado, podemos hacer por ejemplo la Build del proyecto mediante
sencillas configuraciones en TeamCity y por otro lado podemos crear un script. Entre ambas opciones, siempre que sea posible es mejor contar con la segunda.

¿Por qué debemos crear un script?

Un script es:

  • Traceable.
  • Los desarrolladores pueden usarlo también!
  • Añaden más documentación extra al proyecto.
  • Mayor facilidad a la hora de mantenerlo.
  • Simplifica mucho la configuración del servidor de integración.

Para crear y gestionar nuestro script una opción muy recomendada es utilizar F# Make o FAKE.
Es un Sistema de automatización de Builds muy similar a Make o Rake. Es
un DSL sin necesidad de F# que podemos utilizar en Windows y OSX. Si
necesitamos más funcionalidad que la disponible por defecto escribiremos
código F# o referencias a librerías .NET.

Veamos un ejemplo básico de script con FAKE:

#r "tools/FAKE/tools/FakeLib.dll" // include Fake lib
open Fake
  
  
Target "Test" (fun _ ->
    trace "Testing stuff..."
)
  
Target "Deploy" (fun _ ->
    trace "Deploy stuff..."
)
  
"Test"            // define the dependencies
   ==> "Deploy"
  
Run "Deploy"

En el script de Build anterior definimos dos Targets, “Test” y
“Deploy” donde “Deploy” depende de “Test”. En la parte superior
incluimos y utilizamos la librería FakeLib (en otros scripts incluiremos
otras librerías y helpers).

Para ejecutar el script normalmente crearemos un archivo BAT donde descargaremos la útima versión de FAKE vía NuGet y lo ejecutaremos.

@echo off
.nugetNuGet.exe install FAKE -Version 3.5.4
packagesFAKE.3.5.4toolsFAKE.exe build.fsx %1

Sencillo, ¿cierto?

Integración Continua de Apps Xamarin con Team City

Pasamos a realizar (si lo sé, por fin) la integración continua con
nuestra App TipCalc. Comenzamos creando un script que nos permita
realizar un paso básica, la compilación de la solución:

// include Fake lib
#r @"packages/FAKE.3.5.4/tools/FakeLib.dll"
#load "build-helpers.fsx"
 
open Fake
open System
open System.IO
open System.Linq
open BuildHelpers
open Fake.XamarinHelper
open HockeyAppHelper
 
// *** Define Targets ***
Target "common-build" (fun () ->
 
    RestorePackages "TipCalc.sln"
 
    MSBuild "src/TipCalc/bin/Debug" "Build" [ ("Configuration", "Debug"); ("Platform", "Any CPU") ] [ "TipCalc.sln" ] |> ignore
)
  
// *** Start Build ***
RunTarget()

Utilizamos MSBuild para compilar la solución habiendo restaurado previamente paquetes.

NOTA: En nuestro ejemplo compilamos en modo Debug. Normalmente, interesará en modo Release e incluso realizar los dos modos.

Target "core-build" (fun () ->
 
    RestorePackages "TipCalc.Core.sln"
 
    MSBuild "src/TipCalc/bin/Debug" "Build" [ ("Configuration", "Debug"); ("Platform", "Any CPU") ] [ "TipCalc.Core.sln" ] |> ignore
)

Una vez creado el script, ¿cómo hacemos que se ejecute en TeamCity?, ¿cúando?. Vamos a ello!

Tras crear un nuevo proyecto en TeamCity, crearemos una nueva Build:

CI Xamarin 14

Conectamos con el repositorio

Conectamos con el repositorio de código utilizado. Se soportan todos
los repositorios habituales, VSO, TFS, Git, etc. Al crear la Build,
definiremos N triggers. Con ellos podemos ejecutar una acción, en nuestro caso el script en función de una determinada condición. Podemos:

  • Lanzar cuando se hagan cambios en el código.
  • Lanzar de manera programada a una hora o fecha concreta.
  • Lanzar ante cambio de rama.
  • Etc.

Normalmente se programarán Builds “pesadas”, es decir, con varias
compilaciones, gran cantidad de tests y se pasaran Builds más ligeras
cada vez que se suban cambios en el código:

 

CI Xamarin 15

Añadimos Triggers

CI Xamarin 16

Añadimos pasos

Llegamos al paso más importante. En Team City tenemos gran variedad de pasos de Build a nuestra disposición:

  • Compilar un proyecto
  • Restautar paquetes
  • Copiar ficheros
  • Ejecutar scripts
  • etc

En nuestro caso nos interesa ejecutar un script:

Ejecutamos script

Ejecutamos script

Elegimos la opción Command Line, seleccionamos el archivo del script e importante, en el campo Step name,
indicaremos el target que deseamos ejecutar del script. En nuestro
ejemplo, core-build que realizará la descarga de paquetes y la
compilación de la solución en modo Debug.

Sencillo, ¿verdad?. Pues el resto de acciones a realizar serán
similares pero con los consecuentes cambios en el script
correspondiente.

Pasamos a otra parte importante en la integración continua, pasar pruebas:

Target "core-tests" (fun () ->
    RunNUnitTests "src/TipCalc/bin/Debug/TipCalc.Tests.dll" "src/TipCalc/bin/Debug/testresults.xml" |> ignore
)

Contamos con helpers para pasar con facilidad tests con NUnit.
Indicamos la librería de pruebas además de una ruta con resultados. En
Team City, para pasar estas pruebas bastara con crear un nuevo paso de
Build de forma similar a la anterior.

NOTA: Podemos acceder con facilidad a los
resultados. Dependiendo de necesidades puede interesar añadir paso para
enviar estos resultados por correo, subirlo a otra web o herramienta.

Pasamos a ver la compilación del proyecto Windows Phone:

Target "windows-phone-build" (fun () ->
    RestorePackages "TipCalc.WindowsPhone.sln"
 
    MSBuild "src/TipCalc.WindowsPhone/TipCalc.WindowsPhone/bin/Debug" "Build" [ ("Configuration", "Debug") ] [ "TipCalc.WindowsPhone.sln" ] |> ignore
)

Android:

Target "android-build" (fun () ->
    RestorePackages "TipCalc.Android.sln"
 
    MSBuild "src/TipCalc.Android/bin/Debug" "Build" [ ("Configuration", "Debug") ] [ "TipCalc.Android.sln" ] |> ignore
)

Creación de paquete:

Target "android-package" (fun () ->
    AndroidPackage (fun defaults ->
        {defaults with
            ProjectPath = "src/TipCalc.Android/TipCalc.Android.csproj"
            Configuration = "Debug"
            OutputPath = "src/TipCalc.Android/bin/Debug"
        })
    |> fun file -> TeamCityHelper.PublishArtifact file.FullName
)

Recordad que podemos indicar las dependencias entre diferentes Targets.
De este modo un Target no se lanzará si el anterior no se ha completado
con éxito:

// *** Define Dependencies ***
"core-build"
  ==> "core-tests"
 
"android-build"
  ==> "android-package"

Llegados a este punto, vemos como podemos crear diferentes Targets en
nuestro script creando pasos de Build en nuestro proyecto para cubrir
todas nuestras necesidades. FAKE cuenta con una enorme cantidad de helpers para realizar tareas como:

  • Restauración de paquetes.
  • Utilizar FXCop.
  • Publicar un paquete Android.
  • Realizar entrega continua con HockeyApp (lo veremos con detalles en otro artículo).
  • Etc.

Tenéis el código fuente disponible e GitHub:

Ver GitHub

Para más información recomiendo el video «Using Continuous Integration with Xamarin Apps» del Evolve 2014 por Greg Shackles.

Espero que lo visto en la entrada os sea útil. Recordar que podéis
dejar en los comentarios cualquier tipo de sugerencia o pregunta.

Más información

[Microsoft Band] Web Tiles

Introducción

El año pasado Microsoft se aventuró en el terrero de wearables con el lanzamiento de Microsoft Band,
una pulsera cuantificadora compatible con Windows Phone, iOS y Android
con posibilidades de monitorización de pasos, ritmo cardiaco, sueño o
metros recorridos además de tener acceso a notificaciones del teléfono
como llamadas, mensajes, correos o notificaciones Twitter por ejemplo.

Microsoft Band

Microsoft Band

Además, Microsoft lanzó Microsoft Health, una plataforma en la nube donde controlar todos los datos recogidos relacionados con la salud y la actividad física.

WebTiles

Recientemente el equipo de Microsoft Band liberaron los Web Tiles.
Los Web Tiles son una forma fácil y sencilla de poder crear nuevos
Tiles que muestren información desde una URL que devuelva información en
JSON, RSS o ATOM feed sin necesidad de grandes conocimientos ni
programación.

Para ello, accederemos al siguiente enlace y completaremos el asistente paso a paso.

Paso a paso

Vamos a utilizar la herramienta para crear un Tile personalizado con información del tiempo en Sevilla.

1º Paso: Elegir Layout

En este apartado elegimos el Layout a utilizar en nuestro Tile entre un listado de 6 opciones diferentes. En nuestro ejemplo elegimos el primer Layout, cabecera con contenido con scroll.

Elegimos el Layout

Elegimos el Layout

NOTA: La opción de múltiples páginas es ideal cuando utilizamos un feed RSS o ATOM.

2º Paso: Establecer URL información

En el siguiente paso establecemos la URL de la fuente de información que deseamos utilizar. No podemos utilizar URLs que a pesar de devolver JSON requieran autenticación. Utilizaremos OpenWeatherMap para obtener un JSON con información del tiempo.

Fuente de información

Fuente de información

NOTA: Si en el paso anterior elegimos un Layout con múltiples páginas debemos introducir una URL de un feed RSS o ATOM.

3º Paso: Seleccionar la información a mostrar

En este punto la herramienta nos muestra toda la información del JSON
pudiendo configurar el contenido a mostrar de forma muy sencilla
arrastrando y soltando campos.

Configuramos la información a mostrar

Configuramos la información a mostrar

4º Paso: Personalización

En este paso personalizaremos la apariencia del Tile y del contenido:

  • Nombre del Tile.
  • Podemos elegir un color a utilizar o directamente usar el color por defecto usado en la Band.
  • Podemos subir un icono para el Tile. Utilizaremos una imagen PNG de 46 x 46px.

El resto de información es relacionada con la información de nuestro Tile (descripción, autor y organización).

Personalización

Personalización

5º Paso: Descarga

Todo listo!. En este punto podremos descargar nuestro WebTile y compartirlo:

  • Enviándolo directamente como adjunto en un correo.
  • Subiéndolo a OneDrive y compartiendo la URL.
  • Subiéndolo a nuestro propio Host y compartir la URL.
Todo preparado!

Todo preparado!

Resultado final

El resultado final será un nuevo Tile en la Band mostrando el icono y
texto configurado en los pasos anterior. Al pulsar sobre el Tile
veremos la siguiente información:

Resultado final!

Resultado final!

La instalación es sencilla. Abrimos el Web Tile recibido
(independientemente de la forma de distribución) y se nos abrirá la App Microsoft Health para confirmar si añadimos o no el Tile:

Añadiendo el Tile

Añadiendo el Tile

Más información

[Material] Taller y sesiones Windows en el TLP Innova

El Evento

La semana pasada tuvo lugar el TLP Innova, un
espacio dedicado a la innovación tecnológica donde profesionales y
estudiantes compartimos conocimientos y novedades en forma de charlas
técnicas y talleres.

El Material

Tuve el placer de participar en el evento con un taller y dos sesiones. El Jueves comenzamos con un taller de 3 horas sobre Windows 10. Windows
10 ha llegado como la culminación en el viaje hacia la convergencia en
el desarrollo entre plataformas Windows. Ahora hablamos de Apps Universales
escritas una única vez con un código común tanto para la lógica de
negocio como para la interfaz de usuario. Además, generamos un único
paquete que mantendrá una interfaz consistente y familiar para el
usuario pero adaptada a cada plataforma. Podemos crear apps que
funcionen en todo tipo de dispositivos como teléfonos, tabletas,
portátiles, dispositivos IoT, Surface Hub e incluso HoloLens.

En este taller nos centramos en crear una aplicación universal completa donde utilizamos todas las novedades principales, SDKs de
extensiones, diseño adaptativo, SplitView, vistas por familias de
dispositivos, novedades en XAML, en controles o utilización de nuevas
herramientas.

La App creada

La App creada

La presentación utilizada la tenéis disponible a continuación:

El Viernes por la mañana tuvimos una sesión introductoria al desarrollo de aplicaciones Universales con Windows 10. Repasamos conceptos básicos, novedades en controles, XAML y herramientas.

Por último, junto a Josué Yeray, alzamos la vista hacia novedades próximas como los nuevos Bridges
que permiten crear Apps Windows 10 desde código Android o iOS, viendo
como será el proceso, que se puede y que no hacer entre otras muchas
cuestiones.

En cuanto a las demos técnicas realizadas y todo el material del taller, lo tenéis en GitHub:

Ver GitHub

Llegados a este punto solo me queda agradecer la amabilidad y trato recibido por todos los “chicharreros”,
a todos los ponentes y sus grandes sesiones o talleres además de a la
organización del TLP Innova. El año próximo más y mejor si cabe!

Más información

[Tips and Tricks] Windows 10. Controlar si la App se ejecuta en pantalla completa

Introducción

Con la llegada de Windows 8 llegaron también las Apps Windows Store. Grandes ideas y conceptos nos llegaron con ellas:

  • Aplicaciones a pantalla completa dando peso al contenido sobre las “formas”.
  • Modelo de ejecución compartido.
  • Posibilidad de ejecutar más de una App de manera simultánea.
  • Comportamientos y acciones comunes realizadas de igual forma.
  • Tienda donde poder distibuirlas de forma sencilla y accesible para todos.
  • Etc.

Con Windows 10 se producen algunos cambios importantes en las Apps
Windows Store. De entre todas una de las que llama la atención de forma
inmediata es la ejecución de las Apps en modo ventana.
En nuestras Apps podemos programáticamente ejecutar en modo ventana o
pantalla completa. En este artículo vamos a ver como realizar esta
acción.

¿Ventana o pantalla completa?

Crearemos un nuevo proyecto UAP:

Nueva App UAP

Nueva App UAP

Añadimos las carpetas Views, ViewModels y Services además de las clases base necesarias para implementar el patrón MVVM de la misma forma que vimos en este artículo.

Definimos un botón en nuestra interfaz que nos permita programáticamente entrar y salir del modo pantalla completa:

<TextBlock
     TextWrapping="Wrap">
     Pulsa el botón inferior para entrar y salir del modo pantalla completa.
</TextBlock>
<Button
     Content="Modo Pantalla Completa"
     Command="{Binding FullScreenModeCommand}" />

En el comando definido en la ViewModel:

var view = ApplicationView.GetForCurrentView();
if (view.IsFullScreenMode)
{
     view.ExitFullScreenMode();
}
else
{
     var result = view.TryEnterFullScreenMode();
     Debug.WriteLine(result);
}

Contámos con nuevas propiedades y métodos en la clase ApplicationView
que nos permiten detectar facilmente si la App se ejecuta en modo
pantalla completa o no, además de poder cambiar de modo. Contámos con
una propiedad llamada IsFullScreenMode de tipo bool que
nos indica si la App se esta ejecutando o no en modo pantalla completa.
En función de esta propiedad utilizaremos el método ExitFullScreenMode para salir del modo pantalla completa o TryEnterFullScreenMode para entrar en el.

NOTA: Resaltar que el método para entrar en modo
pantalla completa realiza el intento para entrar en el modo. Cabe la
posibilidad de no poder entrar en modo pantalla completa. El método
devuelve una propiedad de tipo bool que indica si la operación se pudo
realizar con éxito o no. Es muy recomendable revisar el resultado
devuelto además de asegurar en caso necesario el cambio de modo
utilizando Window.Current.SizeChanged.

Elementos de UI del sistema

En modo pantalla completa también podemos mostrar los elementos de UI
del sistema como por ejemplo la TitleBar. Añadimos un nuevo botón en
nuestra interfaz:

 <TextBlock
     TextWrapping="Wrap">
     Cuando estamos modo pantalla completa podemos hacer una petición para mostrar los elementos de superposición del sistema.
</TextBlock>
<Button
     Content="Mostrar controles superpuestos del sistema"
     Command="{Binding ShowOverlayControlsCommand}"/>

En el comando:

var view = ApplicationView.GetForCurrentView();
view.ShowStandardSystemOverlays();

Utilizamos el método ShowStandardSystemOverlays incluido en ApplicationView.

Modo de ventana preferido

También podemos establecer el modo preferido con el que deseamos que la App se lance. Añadimos un CheckBox en nuestra interfaz para elegir si la App se ejecuta o no en pantalla completa:

<TextBlock>
     Una App puede ser lanzada en modo ventana o Pantalla completa.
     Marca o desmarca la caja inferior y cierra y abre la App para probar.
</TextBlock>
<CheckBox
     x:Name="FullScreenModeCheck"
     Content="Lanzar en modo Pantalla Completa"
     IsChecked="{Binding IsFullScreenMode}"
     Command="{Binding SetFullScreenModeCommand}"
     CommandParameter="{Binding ElementName=FullScreenModeCheck, Path=IsChecked}"/>

Bindeamos si esta seleccionado o no con una propiedad en la ViewModel:

private bool _isFullScreenMode;
 
public bool IsFullScreenMode
{
     get { return _isFullScreenMode; }
     set
     {
          _isFullScreenMode = value;
          RaisePropertyChanged();
     }
}

Utilizamos la propiedad PreferredLaunchWindowingMode para selecionar el modo preferido de la ventana:

ApplicationView.PreferredLaunchWindowingMode = isChecked ? ApplicationViewWindowingMode.FullScreen : ApplicationViewWindowingMode.PreferredLaunchViewSize;

Establecemos una propiedad de tipo enumeración llamada ApplicationViewWindowingMode con las siguientes opciones:

  • Auto.
  • PreferredLaunchViewSize: Modo ventana. Utilizará el tamaño establecido en la propiedad PreferredLaunchViewSize. En caso de no estar establecida se utilizará el último tamaño de ventana utilizado.
  • FullScreen: Pantalla completa.
FullScreenMode Sample

FullScreenMode Sample

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

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

Ver GitHub

Con Windows 10 tenemos nuevas APIs que nos permiten detectar con
facilidad el modo de la ventana, cambiarlo e incluso elegir el modo con
el que deseamos lanzar la App. Espero que lo visto en la entrada os sea
útil. Recordar que podéis dejar en los comentarios cualquier tipo de
sugerencia o pregunta.

Más información

[Evento] TLP Innova, no te lo puedes perder!

Introducción

La semana próxima tendrá lugar el TLP Innova, un
espacio dedicado a la innovación tecnológica donde profesionales y
estudiantes podremos compartir conocimientos y novedades en forma de
charlas técnicas y talleres y así mejorar nuestras capacidades y poder
aplicarlas a nuestro entorno laboral o de investigación.

Las sesiones

En la agenda tendremos la oportunidad de contar con
sesiones técnicas muy variadas y de las que podréis sacar mucho. Serán
impartidas por algunos de los profesionales más reconocidos en el
territorio nacional e incluso algunos de talla internacional como Bruno
Capuano, Alberto Díaz y Josué Yeray, todos MVP de Microsoft, Alejandro
Campos Magencio miembro de Microsoft DX y otros ponentes de renombre a
nivel nacional como Santiago Porras también MVP de Microsoft, Vanessa
Estorach fundadora de e-Growing y un servidor.

Una agenda muy completa donde tenemos desarrollo móvil
multiplataforma, desarrollo web, Internet of Things, Windows 10, Azure e
incluso Marketing.

Talleres

Pero por si toda la agenda anterior no es motivo ya de suficiente peso, también tendremos talleres!

Miércoles:

  • 11:00 – 14:00 | Taller: Microsoft Azure, la nube más potente al alcance de todos por Alberto Díaz

Jueves

  • 10:00 – 13:00 | Taller: Xamarin.Forms, un código para unirlos a todos! por Josué Yeray
  • 16:00 – 19:00 | Taller: Desarrolla para todos los dispositivos Microsoft con Windows 10 por Javier Suárez

¿Nos vemos allí?

Más información

[Material] Windows 10 Developer Readiness Powered by MVPs

El evento

Windows 10 ha llegado como la culminación en el viaje hacia la convergencia en el desarrollo entre plataformas Windows. Ahora hablamos de Apps Universales
escritas una única vez con un código comun tanto para la lógica de
negocio como para la interfaz de usuario. Además, generamos un único paquete que mantendrá una interfaz consistente y familiar para el usuario pero adaptada a cada plataforma.

Ante la inmensa cantidad de novedades disponibles en la nueva plataforma Universal de Windows, el pasado Jueves, 11 de Junio tuvimos hasta siete sesiones de desarrollo sobre Windows 10 con Josué Yeray, Rafa Serna, Bruno Capuano y un servidor.

El material

Tuve el placer de participar en varias sesiones técnicas sobre
desarrollo de Apps Windows 10. Comenzamos viendo las posibilidades del
control RelativePanel, nuevo control de layout que permite posicionar a
los elementos de forma relativa con respecto al panel y ellos mismos
facilitando además la adaptación de los elementos de la interfaz ante
cambios de orientación o tamaño de pantalla. Además, vimos los Adaptive
Triggers utilizados en XAML para detectar condiciones de entorno como
distintos tamaños de pantalla permitiéndonos aplicar distintos estados
visuales para adaptar la interfaz a cada dispositivo.

Tuvimos otra sesión en la que vimos las  principales novedades en
XAML, mejoras en rendimiento, nuevas herramientas, nuevas APIs de
perspectiva 3D, etc.

En cuanto a las demos técnicas realizadas, las tenéis todas disponibles en GitHub:

Ver GitHub

Más información

Próximamente todas las grabaciones de las sesiones estarán disponibles en el siguiente enlace en Channel 9.

Renovado como Windows Platform Development MVP!

Microsoft MVP 2015

Parece que fue ayer, pero fue hace un año cuando recibí un correo que comenzaba por…

Estimado/a Javier Suarez,

Enhorabuena. Nos complace presentarle el programa de nombramiento MVP de Microsoft…

Y un año despues tengo que confirmar que volver a recibirlo hace la misma e incluso más ilusión!. Un gran honor formar parte de un grupo de desarrolladores tan talentosos y apasionados además de grandes personas.

Agradecimientos

Llegados a este punto, siempre quieres agradecer a muchas partes que
han ayudado en el camino. Comienzo por vosotros, si, si hablo de ti
querido lector. Gracias por leer estos artículos técnicos y ayudarme a
aprender intercambiando opiniones día a día, gracias a mis compañeros MVPs,
en especial a los de desarrollo Windows con quienes comparto la inmensa
mayoría de eventos, proyectos personales y grandes momentos (soís grandes),  a los grupos de usuario WPSUG, SVQXDG y CartujaDotNet donde colaboro y me permiten aprender más y más cada día con fantásticos compañeros y a Cristina González,
MVP lead, por su increíble labor siempre pendiente de todos nosotros
además de a los chicos de Microsoft España. Podría continuar nombrando a
muchos amigos y compañeros, pero me temo que me extendería en exceso y
al final y al cabo sabéis quienes sois 😉.

Por último, no quisiera terminar sin agradecer a mi familia y
sobretodo a mi pareja que siempre me apoya y me cede tiempo para que
pruebe esa última versión de algun remoto SDK que acaba de salir o de participar en X evento, en definitiva,  probar, jugar con la tecnología y divertirme.

Y ahora que?

Ahora, a continuar aprendiendo y disfrutando compartiendo todo lo posible en blogs, comunidades técnicas y otras vías con más ganas y más ilusión si cabe.

¿Me acompañas?

Os adelanto una “sorpresa”, permaneced atentos a Septiembre…

Felicidades

También me gustaría felicitar a todos los MVPs veteranos que han sido
renovados asi como aquellos que entran a formar parte desde este
momento. Enhorabuena!