Tras actualizar XCode a una versión posterior y desde entonces al intentar conectar desde Windows utilizando Xamarin Mac Agent…
Oops!
El mensaje de error nos lo deja todo muy claro, debemos abrir XCode y aceptar la neuva licencia. Sin embargo, tras abrir XCode, nunca salta la ventana para poder aceptar la licencia.
¿Qué ocurre?, ¿qué podemos hacer?.
La solución
Encontramos una sencilla solución al poder aceptar la licencia de XCode utilizando la línea de comandos.
Abre XCode y dirígete a Preferences > Locations. Asegúrate de tener establecida a la última versión de XCode la opción Command Line Tools:
Command Line Tools
Todo preparado. Abre una línea de comandos y ejecuta:
sudo xcodebuild -license
Acepta la licencia (agree), vuelve a Visual Studio en Windows e intenta de nuevo establecer una conexión. Todo debería funcionar sin problemas.
Con la llegada de la última Preview de Visual Studio 2017, la versión 15.7, llegan grandes mejoras en la experiencia al editar XAML de Xamarin.Forms. Ahora el engine que gestiona IntelliSense de XAML de Xamarin.Forms pasa a ser el mismo que WPF o UWP. Hablamos de mejoras en autocompletado, sugerencias, extensiones de marcado o navegación entre diferente código.
En este artículo, vamos a realizar un rápido repaso por las mejoras principales.
NOTA: Recuerda, hablamos de una versión Preview de Visual Studio. Es posible contar con la versión Preview instalada junto a la versión estable aunque estas mejoras aún no estan disponibles en la versión estable.
Un repaso a las mejoras principales
Autocompletado
Comenzamos con la funcionalidad básica, el autocompletado. Esta versión mejora la búsqueda de coincidencias con lo escrito obteniendo resultados aun con valores no correctos, incompletos, o con minúsculas o mayúsculas.
Autocompletado
Se obtiene ayuda para completar tanto elementos visuales como paneles o controles, así como sus propiedades o eventos.
Extensiones de marcado
Las extensiones de marcado son una forma de obtener un valor que no sea específico de tipo primitivo o un objeto XAML. Mediante la apertura y cierre de llaves, se define en su interior lo que se conoce como extensión de marcado.
Otra necesidad muy habitual al trabajar con XAML dada la alta probabilidad de requerir hacer un enlace a datos o acceder a un recurso:
Extensiones de marcado
Tenemos autocompletado con extensiones de marcado como Binding, StaticResource o x:Static, pero también con aquellas personalizadas.
Namespaces
Ahora también tenemos sugerencias al trabajar con XML namespaces:
Namespaces
Sugerencias
También tendremos sugerencias, como al editar C# aparecerá la linterna, principalmente indicando que algo no es correcto para permitir corregir el problema. Renombrar, crear espacio de nombres, etc…
Sugerencias
Resolución de recursos
Los recursos definidos en la misma página son detectados por IntelliSense facilitando sugerencias:
Resolución de recursos
NOTA: De momento, no se detectan recursos a nivel de aplicación, solo a nivel de página.
Errores
Cualquier error de marcado se indicará subrayando en azul la línea problemática.
Errores
Sin duda un paso sólido y necesario adelante de una de las opciones más reclamadas. Aun hay posibilidad de mejora (recursos a nivel de aplicación, más opciones de autocompletado como con estilos, etc.) pero tras probar desde pequeños proyectos a algunos de mayor tamaño, la mejora es notoria. Y a ti, ¿que te parece?.
Visual Studio para macOS esta basado en MonoDevelop. Antes de lanzarnos de lleno a crear un Add-in es importante conocer lo que se conoce como el modelo de extensión. La arquitectura de Visual Studio para macOS es extensible. La forma de extender se basa en rutas de extensión que permiten que terceros extiendan el comportamiento. Por ejemplo: para extender la zona de edición de código, se expone /MonoDevelop/SourceEditor2/ContextMenu/Editor permitiendo añadir nuevos comandos en el menu contextual al hacer clic derecho.
AddIn Maker
AddIn Maker es un proyecto Open Source creado por Mikayla Hutchinson que permite el desarrollo y la depuración de add-ins para Visual Studio macOS desde Visual Studio macOS.
Para añadirlo, nos dirimos al menu principal de Visual Studio y pulsamos sobre Addins…
Desde aquí podemos gestionar Addins en Visual Studio.
Crear proyecto de Add-in
Tras instalar AddIn Maker, tenemos accefso a un nuevo tipo de proyecto, Addin.
Seleccionamos la nueva plantilla, asignamos un nombre y continuamos.
Xamarin.Forms GTK
Llegamos a este punto, habitualmente, crearíamos nuestra interfaz de usuario utilizando GTK# o XWT. Cuando hablamos de XWT nos referimos a un tookit cross platform de UI para crear aplicaciones de escritorio con Mono y .NET.
Recientemente, hemos recibido los paquetes NuGet de la versión Preview de Xamarin.Forms 3.o. Entre las diferentes novedades encontramos soporte a Linux. El soporte de Linux se logra con un nuevo backend basado en GTK#.
Por lo que si usamos GTK#, ¿podríamos usar XAML y Xamarin.Forms para definir la UI de add-ins para Visual Studio?.
Es una posibilidad que personalmente he pensado en multitud de ocasiones e incluso lo he llegado a hablar con miembros de la comunidad Xamarin como con Matthew Robbins creador de MFRactor (tuvimos una genial conversación en el pasado MVP Summit).
Manos a la obra!
Comenzamos creando un proyecto de tipo IDE Extension:
IDE Extension
Este proyecto ya cuenta con la referencia a MonoDevelop.Addins, versión 0.4.4 al escribir este artículo. Continuamos añadiendo el paquete NuGet de Xamarin.Forms
Xamarin.Forms.Platform.GTK
Para trabajar con Xamarin.Forms, debemos realizar la inicialización. La mejor opción para realizar esta tarea es realizarla nada más se abra el IDE. Para ello, vamos a crear un comando:
public class InitXamarinFormsCommand : CommandHandler
{
protected override void Run()
{
Forms.Init();
}
}
Y modificaremos el archivo Manifiest.addin.xml para añadir nuestro comando como punto de extensión en el arranque del IDE.
Llega la hora de extender. En nuestro caso, vamos a crear un sencillo Previewer de XAML para Xamarin.Forms.
NOTA: El objetivo de este ejemplo es demostrar como utilizar Xamarin.Forms para definir la UI de extensiones par Visual Studio. No estamos ante un nuevo Previewer de XAML. Aunque el funcionamiento es bastante rápido y correcto, no es el objetivo buscado.
Fíjate que en esta ocasión, añadiremos un nuevo comando en el menu principal, opción editar.
Veamos la definición del comando:
public class PreviewXAMLCommand : CommandHandler
{
protected override void Run()
{
Pad pad = null;
var pads = IdeApp.Workbench.Pads;
foreach (var p in IdeApp.Workbench.Pads)
{
if (string.Equals(p.Id, "LiveXAMLAddin.Pads.XAMLPreviewerPad", StringComparison.OrdinalIgnoreCase))
{
pad = p;
}
}
if (pad == null)
{
var content = new Pads.XAMLPreviewerPad();
pad = IdeApp.Workbench.ShowPad(content, "LiveXAMLAddin.Pads.XAMLPreviewerPad", "XAML Previewer", "Right", null);
if (pad == null)
return;
}
pad.Sticky = true;
pad.AutoHide = false;
pad.BringToFront();
}
protected override void Update(CommandInfo info)
{
info.Visible = true;
if (IdeApp.Workbench.ActiveDocument != null && IdeApp.Workbench.ActiveDocument.FileName.ToString().Contains(".xaml"))
{
info.Enabled = true;
}
else
{
info.Enabled = false;
}
}
}
Reconoces a un Pad como un panel lateral anclable tanto a izquierda como derecha. En esta ocasión, creamos un nuevo Pad donde mostrar la previsualización de XAML, de título «XAML Previewer» y anclado a la derecha.
Para habilitar la opción de menu, vamos a determinar si el usuario esta editando un archivo XAML. Para ello, utilizamos IdeApp.Workbench.ActiveDocument. Tenemos posibilidad de acceder a toda la información del documento, como su formato o contenido.
Utilizando XAML para definir UI
¿Qué vamos a mostrar en el Pad?
Vamos a utilizar XAML!. Creamos una nueva ContentPage:
Tenemos acceso a todas las opciones disponibles con XAML, entre ellas, sistema de enlace a datos, etc. Para utilizar la página XAML como contenido del Pad vamos a embeber el contenido:
var page = new PreviewerView();
var pageContainer = page.CreateContainer();
Tenemos disponible el método de extensión CreateContainer de Xamarin.Forms en el backend GTK para obtener la ContentPage como contenido nativo.
Cafa vez que se cambie el texto de la página XAML en el editor de Visual Studio, vamos a actualizar la previsualización XAML:
Podemos utilizar MVVM (de hecho en este ejemplo se usa) en combinación con toda la potencia y las opciones de extensión que tenemos.
El resultado:
El resultado
Tienes el código fuente del ejemplo disponible GitHub:
¿Qué te parece?. Quizás en un futuro sea una opción a la hora de extender Visual Studio. Ahora que tenemos el IDE en más de un sistema operativo, es hora de pensar en contar con una opción para crear extensiones que compartan la mayor cantidad de código posible.
Recientemente hemos recibido la versión Xamarin.Forms 3.0 Pre-Release. Esta nueva versión llega con soporte a .NET Standard, multi-targeting (también a PCL), mejoras en rendimiento, corrección de errores así como nuevas características. Entre las características nuevas encontramos:
Nuevas plataformas soportadas como Linux (GTK) o versiones anteriores de Windows (WPF).
Visual State Manager.
FlexLayout.
Uso de CSS para manejar estilos.
Localización Right to Left.
El evento
Ante tal cantidad de novedades, ¿algo mejor que verlas todas en un evento?. En este evento vamos a realizar un repaso de cada novedad a base de demos.
El evento se celebrará en la ETS de Ingeniería Informática. Dirección detallada:
E.T.S. Ingeniería Informática – Universidad de Sevilla, Aula A2.14 Av. Reina Mercedes s/n Sevilla Se 41012
La fecha
Será el próximo Martes, 10 de Abril de 19:00h a 20:30h(GMT+1).
Una de las funcionalidades que estarán disponibles en próximas versiones de Xamarin.Forms y ya disponible en las Nightly es VisualStateManager.
NOTA: Puedes acceder a los paquetes Nightly de Xamarin.Forms en este enlace.
En este artículo, vamos a darle un primer vistazo a esta nueva característica.
VisualStateManager
VisualStateManager se utiliza para definir y gestionar diferentes estados entre elementos visuales de una página. En concreto, un VisualState es la colección de propiedades de un elemento visual que en conjunto definen el estado de un elemento visual.
Para entender como utilizar VisualStateManager de forma sencilla, vamos a crear un ejemplo habitual. A continuación, vamos a crear un sencillo formulario para asegurar que el usuario registra una contraseña de forma correcta, es decir, vamos a pedir introducir la misma hasta en dos ocasiones:
Creamos dos VisualState o estados visuales. El primero de ellos lo utilizamos cuando la contraseña es correcta. En el segundo estado, que utilizaremos cuando la contraseña sea incorrecta (no coincide) vamos a modificar el color de fondo a rojo.
Según vamos escribiendo salta el evento TextChanged del Behavior y en el mismo, validamos si la contraseña es igual a la anterior. En este momento, utilizamos el método GoToState de VisualStateManager para cambiar de un estado a otro según el caso.
Tienes el código fuente del Toolkit disponible GitHub:
Estamos ante una funcionalidad muy solicitada que añade bastante potencial para la gestión de estados ante la interacción de la aplicación. ¿Qué te parece a ti?. Recuerda, cualquier duda o comentario puedes añadirla a los comentarios de la entrada.
Una de las grandes nuevas características que tendremos en Xamarin.Forms, ya disponible en paquetes Nightly, es FlexLayout.
En este artículo, vamos a realizar una introducción a este nuevo Layout, sus opciones y características principales.
Layouts de Xamarin.Forms
En Xamarin.Forms contamos con diferentes Layouts que nos permiten organizar y posicionar los diferentes elementos visuales que componen la interfaz de usuario.
Las clases Layout y Layout<T> en Xamarin.Forms son tipos especiales de Views que actúan como contenedores de otras Views o Layouts.
Layouts en Xamarin.Forms
¿Qué es FlexLayout?
Al trabajar con CSS en desarrollo web, para adoptar una sintaxis limpia para crear diseños adaptativos llegó Flexbox.
Flexbox proporciona una forma eficiente de distribuir, alinear y gestionar el espacio entre elementos incluso cuando el tamaño de la ventana o de cada elemento es dinámico o desconocido.
Basados en esta opción, contamos con un nuevo Layout llamado FlexLayout con gran cantidad de opciones para la gestión de la distribución y tamaño de elementos.
¿Por dónde empezamos?
Probablente sea tu primera pregunta. Comenzamos creando un nuevo proyecto Xamarin.Forms.
Tras crear el proyecto, actualizamos el paquete a la versión Nightly de Xamarin.Forms:
Xamarin.Forms Nightly
NOTA: Puedes ver como acceder a versiones Nightly de Xamarin.Forms en este enlace.
Basta con añadir en la página:
<FlexLayout>
</FlexLayout>
Para comenzar a trabajar con FlexLayout.
FlexLayout, propiedades
El comportamiento del Layout es diferente en base a sus propiedades. A continuación, vamos a revisar las propiedades fundamentales.
Direction
La propiedad Direction controla la dirección de los elementos. Los valores posible son:
Row
Column
RowReverse
ColumnReverse
Simplificando, esta propiedad permite definir como se distribuyen los elementos que contiene. Puede ser de forma horizontal, vertical o de forma invertida en ambas direcciones. La dirección predeterminada es horizontal, de izquierda a derecha.
NOTA: En el «mundo flexible» no se usa «horizontal» o «vertical» si no eje principal (main-axis) y eje transversal (cross-axis).
Aunque no se establezca de forma explícita, FlexLayout tiene como valor predeterminado Row.
Wrap
Contamos con los siguientes valores:
Wrap
NoWrap
Reverse
Pero…¿para qué lo usamos?.
Para entender correctamente esta propiedad vamos a crear un sencillo ejemplo. Dentro de un FlexLayout añadimos elementos:
Comenzando el ejemplo
Son textos de 24px de ancho. Por defecto, como hemos visto anteriormente se organizarán en formato de Row de izquierda a derecha.
Bien, vamos a duplicar los elementos. ¿Qué va a ocurrir?, ¿se salen elementos de pantalla?, ¿se ajusta el tamaño de todo?, ¿se dividen elementos a una nueva línea?.
Duplicamos elementos
Nada como probar, para tener la respuesta. El contenedor se adapta para poder contenedor todos los elementos hijos. Este es el comportamiento por defecto. Es decir, la propiedad Wrap tiene como valor predeterminado NoWrap.
Podemos modificar el comportamiento de forma sencilla:
Wrap
JustifyContent
Si hasta ahora piensas que todo tiene buena pinta, esta propiedad te va a gustar. Cuenta con las siguientes opciones:
Start
Center
End
SpaceBetween
SpaceAround
SpaceEvenly
Esta propiedad te puede recordar a la alineación de texto. Define como se organizan los elementos en el eje principal. El valor por defecto es Start. Con este valor los elementos se agrupan al inicio del eje principal.
Start
Por el contrario, la opción End agrupa los elementos al final del eje principal:
End
Centrados:
Center
La opción SpaceBetween mantiene el mismo espacio entre cada elemento:
SpaceBetween
SpaceAround, es similar a la opción anterior, los elementos se distribuyen uniformemente manteniendo además el mismo espacio alrededor (en ambos lados). Nota que el primer elemento tendrá una unidad de espacio con respecto al borde del contenedor, pero dos unidades con respecto al siguiente elemento (el siguiente elemento cuenta con su propio espacio).
SpaceAround
Por último, contamos con SpaceEvenly donde los elementos se distribuyen manteniendo el mismo espacio entre elementos y los bordes.
SpaceEvenly
AlignItems
Esta propiedad es similar a la anterior por lo que es rápida de asimilar. Los posibles valores son:
Start
Center
End
Stretch
Define el comportamiento predeterminado de cómo se colocan los elementos a lo largo del eje transversal (cross-axis).
El valor predeterminado es Stretch que se encargará de «estirar» los elementos para que rellenen toda la altura del contenedor. El resto de opciones hacen justo lo que imaginas, agrupan los elementos al inicio, centro o final del contenedor.
AlignContent
¿Recuerdas lo que pasaba al añadir más elementos al probar la propiedad relacionada con Wrap?. Utilizando Wrap tenemos un contenedor flexible multilínea.
Esta propiedad permite controlar la alineación de los elementos haciendo Wrapping. Nos permite controlar el espacio adicional en el eje transversal.
NOTA: Esta propuedad no tiene efcto cuando solo hay una línea de elementos.
Los valores posibles son:
Start
Center
End
Stretch
SpaceBetween
SpaceAround
SpaceEvenly
Como en AlignItems el valor por defecto es Stretch. Con este valor, los elementos se «estiran» para adaptarse al espacio disponible a lo largo del eje transversal.
Hemos visto anteriormente el resto de propiedades, sin embargo, hay en esta ocasión ligeras diferencias.
El valor Start alinea los elementos del contenedot al inicio del eje transversal. Recuerda que el eje transversal tiene como orden predeterminado de arriba hacia abajo. Por lo tanto, el valor End los coloca en la parte inferior (abajo) y Center en el centro.
Propiedades de cada elemento
Además de poder cambiar el comportamiento del Layout gracias a sus propiedades principales, podemos adaptar diferentes opciones utilizando propiedades de cada elemento.
FlexLayout.Grow
La gran aportación de FlexLayout es permitir que sus elementos sean «flexibles». Esta propiedad nos permite tener aún más control en este sentido. El valor de la propiedad puede ser desde cero a cualquier valor numérico positivo. Vamos a ver en que consiste.
Por defecto, el valor de la propiedad es 0. Este valor hace que el elemento no crezca para ajustarse al espacio disponible. Podríamos decir que es como un «interruptor apagado». Si tenemos en un contenedor un elemento, y establecemos el valor a 1, el elemento pasa a ocupar todo el espacio.
Básicamente, esta propiedad define la capacidad de un elemento para crecer si es necesario. Acepta un valor sin unidades que sirve como una proporción. Indica qué cantidad de espacio disponible dentro del contenedor flexible debe ocupar el elemento.
Si todos los elementotienen un crecimiento flexible establecido en 1, el espacio restante en el contenedor se distribuirá por igual a todos los hijos. Si uno de los hijostiene un valor de 2, el espacio restante ocuparía el doble de espacio que los demás (o lo intentará, al menos).
FlexLayout.Basis
Esta propiedad define el tamaño predeterminado de un elemento antes que se distribuya el espacio restante disponible. Puede ser una proporción, por ejemplo un porcentaje (5%, 25%, etc.). También se pueden utilizar algunas palabras reversadas como Auto.
En combinación con FlexLayout.Grow permite un control bastante completo sobre el tamaño de cada elemento hijo del contenedor.
Conclusiones
No es extraño encontrar la necesidad de gestionar Wrapping de elementos, elementos con diferentes espacios de forma dinámica, etc. La llegada de un nuevo Layout basado en algo conocido como Flexbox y que aporte la posibilidad de gestionar Layouts flexibles de forma sencilla es importante.
FlexLayout
Tienes un ejemplo de FlexLayout disponible en GitHub:
¿Qué te parece esta nueva opción?. Recuerda, cualquier duda o pregunta es bienvenida en los comentarios de la entrada.
Con la llegada de .NET Core (y el formato project.json) llegamos a tener la opción de hacer multi-targeting. El multi-targeting no es más que compilar casi el mismo código varias veces para plataformas diferentes. Por ejemplo, con ASP.NET Core era habitual utilizar net45 o netcoreapp1.0. Más habitual era crear librerías con diferente funcionalidad basada en diferentes versiones de .NET Core. Por ejemplo, una librería con netstandard1.0 y netstandard1.4 como target.
Aunque con algunas otras plataformas (como UWP) era posible hacer algo similar no ha sido hasta el cambio a MSBuild y últimas versiones de Visual Studio 2017 donde hemos llegado a poder hacer multi-targeting con UWP, PCLs, Xamarin.Android y Xamarin.iOS.
En este artículo, vamos a conocer todos los conceptos básicos de Multi-Target así como sus beneficios a la hora de trabajar con Xamarin.
Multi-Targeting con Xamarin
Si cuentas con una librería que no requiere de código específico por plataforma no es necesario hacer multi-targeting. Como desarrolladores Xamarin, si utilizas una librería portable sin requerir código específico por plataforma, te puede interesar actualizar a una libreria .NET Standard pero sin necesidad de multi-targeting. Uno de los motivos principales para necesitar multi-target es utilizar código específico desde una librería. En estos casos, podemos tener una librería con el código común junto con N proyectos por cada plataforma que deseamos soportar. Con el uso de inyección de dependencias accedemos a la implementación específica de una plataforma. Es una forma de trabajar habitual y correcta. Sin embargo, con multi-targeting podemos tener un único proyecto con el que acceder al código de plataforma directamente.
Vamos a crear el ejemplo más básico. Partimos desde una librería .NET Standard.
Librería .NET Standard
Tras crear el proyecto, hacemos clic derecho sobre el mismo y elegimos la opción Editar:
Editar proyecto
Podemos editar el proyecto sin necesidad de descargar o cerrar el mismo viendo los cambios de forma inmediata.
Acontinuación, tienes el código fuente de un ejemplo disponible GitHub haciendo uso de Multi-Targeting en Xamarin:
El ejemplo es una librería con soporte a Multi-Targeting para netstandard1.0, netstandard2.0, MonoAndroid80, XamariniOS11 y uap10.0.15063.
NOTA: Se puede añadir soporte a .NET Framework, TvOS, macOS o Tizen en la misma librería con Multi-Targeting.
En el ejemplo, tenemos una interfaz IMultiTargeting con un único método:
stringSample ();
En la implementación de cada plataforma, sencillamente se devuelve una cadena con el nombre de la plataforma. Sin embargo, en cada implementación tenemos acceso a APIs nativas de la plataforma.
Ejemplo
Plugin Visual Studio para crear plantillas Multi-Targeting
James Montemagno que ya ha actualizado sus plugins para utilizar Multi-Targeting ha agrupado su experiencia en actualizar Plugin For Xamarin Templates para Visual Studio 2017 con soporte a Multi-Targeting.
Tras instalar el plugin, encontraremos dentro del conjunto de plantillas de proyecto de C# una llamada Plugin for Xamarin:
A crear nuevo plugin!
Este tipo de proyecto se encarga de preparar todo lo necesario para crear un nuevo Plugin para Xamarin para múltiples plataformas con un único proyecto utilizando Multi-Targeting:
Estructura del proyecto
Recuerda, cualquier duda o comentario es bienvenido en los comentarios!
Un proceso que repetimos de forma continua en el desarrollo de aplicaciones móviles con Xamarin.iOS es desplegar la aplicación en un dispositivo. Para realizar el despliegue necesitamos conectarlo al equipo de desarrollo por USB.
Hasta ahora…
La última versión de Visual Studio permite utilizar la opción de XCode de depurar iOS/tvOS para desarrolladores Xamarin. Esta nueva opción llamada WiFi debugging permite depurar aplicación Xamarin.iOS sin necesidad de conectar el teléfono vía USB.
Requisitos
Para poder utilizar WiFi debugging es necesario tener:
XCode 9.0
macOS 10.12.4
Visual Studio 2017 1.6 en el caso de Windows o 7.4 en macOS
NOTA: El Mac y el dispositivo deben estar conectados a la misma red.
Preparando el dispositivo
Para conectar con un dispositivo vía WiFi en depuración, necesitamos utilizar XCode. Conectamos el dispositivo por USB.
En XCode nos dirigimos a Device Manager disponible en Window > Devices and Simulators.
Aquí encontraremos al dispositivo. Tras seleccionarlo se debe marcar la opción Connect via network.
Connect via network
Todo listo!.
NOTA: Dado que el Apple TV 4K no cuenta con puerto USB esta opción se convierte en algo especialmente importante para depuración aplicaciones tvOS.
Probando la conexión
Una vez que el dispositivo (iOS 11) está configurado, no hay que configurar nada en Visual Studio. El dispositivo aparecerá en Visual Studio y podremos utilizarlo para depurar.
NOTA: Entre errores de conexión habituales se encuentran problemas de red. Se utiliza el puerto 62078 para la conexión con XCode.
Otra interesante característica añadida relacionada con la depuración vía WiFi es la capacidad de detectar si el dispositivo se encuentra bloqueado. Anteriormente si el dispositivo se encontraba bloqueado obteníamos un error en el despliegue. Ahora, Visual Studio mostrará una alerta indicando que el dispositivo se encuentra bloqueado. Si desbloqueamos, el despliegue continua. También tenemos la opciñon de cancelar deteniendo la implementación y la sesión de depuración.
En Enero de este año se abría un interesante debate acerca de aquellos puntos que se suelen necesitar crear o extender en Xamarin.Forms. Hablamos de aspectos como Custom Renderers o efectos habituales. No es algo como nuevos controles o cambios drásticos, más bien, cosas como añadir bordes redondeados a ciertos elementos o poder subrayar una parte de texto. Para determinar con exactitud la opinión de la comunidad, y así podemos ayudar al equipo de Xamarin.Forms a afinar las necesidades principales y poder cubrirlas, Adam Pedley creó una encuesta con interesantes resultados.
Comunidad Xamarin
Xamarin.Forms Community Sprint
Aunque la idea inicial era ayudar al equipo de Xamarin.Forms a conocer pequeñas mejoras deseadas por la comunidad, lo cierto es que diferentes miembros de la comunidad se interesaron por ayudar directamente. Esto ha dado lugar a lo que se conoce como Community Sprint. Con la ayuda y revisión del equipo de Xamarin.Forms hay creadas un listado de Issues que se pueden tomar permitiendo que cualquier desarrollador de la comunidad pueda contribuir en todo momento con gran ayuda. Existe un canal Slack donde tener comunicación con todos los miembros de comunidad participando así como con miembros del equipo de Xamarin.Forms.
NOTA: Puedes ver un listado de las mejoras ya realizadas en este enlace.
Si te apetece contribuir, tan solo debes elegir una de las Issues abiertas etiquetadas como Community Sprint. Estaré encantado de ayudarte junto a otros miembros de la comunidad en tus pasos, anímate!.
Cuando desarrollamos aplicaciones móviles, siempre tenemos en cuenta el dispositivo final donde se va a ejecutar, es decir, las optimizaciones a diferentes niveles se encuentran a la orden del día. Hablamos de opciones como cachear imágenes, reutilizar celdas en listados o compilar el XAML entre una infinidad de opciones.
Por otro lado, la mayoría de aplicaciones necesitan guardar datos como caché para optimizar arranques o bien, para evitar volver a realizar peticiones HTTP innecesarias. En este artículo, vamos a conocer y a utilizar Monkey Cache de James Montemagno.
Cachear datos
Mientras que tenemos diferentes opciones para cachear imágenes, cachear información es algo donde hay diversidad de opciones. A continuación, vamos a conocer Monkey Cache, una forma sencilla y potente de cachear información durante un periodo de duración concreto.
Monkey Cache
Monkey Cache tiene como objetivo permitir cachear información de forma sencilla, sin requerir gran cantidad de dependencias controlando el tiempo de caducidad de los datos. Es importante resaltar que la librería no tiene como objetivo gestionar peticiones HTTP, esstados, etc. tan solo cachear la información.
Estamos ante una librería NET Standard 2.0 con el siguiente soporte a plataformas:
Platforma
Versión
Xamarin.iOS
iOS 7+
Xamarin.Mac
All
Xamarin.Android
API 14+
Windows 10 UWP
10.0.16299+
.NET Core
2.0+
ASP.NET Core
2.0+
.NET
4.6.1+
Utilizando Monkey Cache
Vamos a utilizar la aplicación WeatherApp para controlar las diferentes peticiones a la API de OpenWeatherMap.org.
Comenzamos añadiendo los paquetes NuGet necesarios. Monkey Cache cuenta con diferentes implementaciones como SQLite, LiteDB o FilesStore.
En nuestro ejemplo, vamos a utilizar la opción más sencilla (y con menos dependencias), FileStore.
MonkeyCache NuGet
Tras contar con los paquetes necesarios, continuamos creando un identificador de aplicación utilizando la propiedad ApplicationId, que se encargará de crear una carpeta específica para la aplicación en disco:
La aplicación verificará si los datos han expirado o no. En caso de expirar o no existir, realiza la petición HTTP. Al realizar la petición HTTP, añadimos en cache los datos durante 1 hora (expireIn). Si los datos no han expirado, utilizamos los datos cacheados evitando realizar la petición HTTP.
Sencillo, ¿verdad?.
NOTA: Es posible hacer estas llamadas genéricas para reutilizar en diferentes servicios.
La librería conservará datos a menos que indiquemos que deseamos borrarlos. Podemos borrar todos los datos:
Barrel.Current.EmptyAll();
O podemos eliminar todos los datos expirados:
Barrel.Current.EmptyExpired();
WeatherAppMonkeyCache
Tienes el código fuente del ejemplo disponible GitHub:
Me he quedado con dudas…
El uso de la librería es sencillo, pero…¿diferencias con Akavache?. Akavache ofrece persistencia en forma de clave-valor con un rendimiento muy alto utilizando SQLite y Reactive Extensions. Monkey Cache busca simplificar uso, gestión de la expiración y dependencias.
Introducción
Crear add-ins para Visual Studio macOS
Xamarin.Forms 3.0
Introducción
Introducción
Sin cables, depuración por WiFi
El origen
La importancia de la optimización
