La llegada de iOS 26 trajo consigo el nuevo lenguaje de diseño Liquid Glass, un aspecto visual con transparencias dinámicas y efecto “vidrio líquido” que Apple implementó a nivel de interfaz en toda la plataforma.

Si recientemente actualizaste tu entorno a macOS Tahoe y Xcode 26 y al compilar tu app en iOS 26 encontraste que la IU se rompió o se ve inconsistente con tu sistema de diseño actual, este artículo te explica cómo optar temporalmente por el diseño clásico mientras adaptas tu UI al nuevo sistema — una solución práctica que puedes implementar hoy mismo.

¿Qué es Liquid Glass y por qué afecta tu app?

Liquid Glass es el nuevo lenguaje visual de Apple presentado oficialmente en junio de 2025. Reemplaza el diseño plano tradicional con una apariencia translúcida, reflejante y con profundidades tipo “vidrio”.

Aunque visualmente es atractivo, este cambio puede:

• Alterar colores de fondos y transparencias.
• Afectar elementos del sistema como barras de navegación, tab bars, menús y modales.
• Romper layouts que dependen de vistas sólidas o sin transparencia.

Si tu diseño se basa en colores sólidos o un sistema visual con alta precisión de contraste, la transición puede provocar inconsistencia visual o comportamientos inesperados durante la ejecución en dispositivos con iOS 26.

A mí me ha pasado con algunos controles usando MAUI, por ejemplo usando TitleView, algo parecido a esto:

Solución: desactivar Liquid Glass temporalmente en tu app

La buena noticia es que Apple provee un método oficial para “optar por compatibilidad” y desactivar provisoriamente el nuevo diseño  visual en tu app mientras migras tu UI.

1. Editar el archivo Info.plist

Abre el archivo Info.plist de tu proyecto y agrega la siguiente clave:

<key>UIDesignRequiresCompatibility</key>
<true/>

• Esta configuración indica que tu app requiere compatibilidad con el diseño clásico.
• Al compilar con este flag, iOS 26 renderizará tu app sin aplicar el estilo Liquid Glass, devolviendo un comportamiento visual similar al de versiones anteriores.

Importante: solo es una solución temporal

Apple ha dejado claro que esta compatibilidad estará disponible solo hasta iOS 27, lo que significa que:

• A partir de iOS 28 (y versiones futuras), el flag puede ser removido.
• Lo ideal es que actualices tu UI para adoptar o adaptarse al nuevo lenguaje visual antes de que desaparezca esta opción.

Recomendaciones para migrar tu diseño

Mientras usas esta solución temporal, aquí tienes algunas acciones recomendadas:

• Audita los elementos de UI afectados:
  Revisa vistas que dependen de colores sólidos o layouts absolutamente posicionados.
• Evalúa la legibilidad y contraste:
  El nuevo estilo puede afectar los niveles de legibilidad — asegúrate de probar diferentes modos de contraste y transparencia en iOS 26.
• Actualiza tus assets visuales:
  Iconos, fondos y componentes deben adaptarse para funcionar armoniosamente con transparencias y profundidad.

Conclusión

Si tu UI falla o se ve dañada al compilar y ejecutar tu app en iOS 26 con Liquid Glass, puedes:

• Añadir UIDesignRequiresCompatibility = YES en tu Info.plist para desactivar el nuevo estilo visual.
• Ganar tiempo mientras actualizas tu diseño y pruebas adecuadamente en entornos reales.

Esta técnica no es solo útil — es estratégica para mantener la experiencia de usuario intacta hasta que completes la migración a la nueva estética de Apple.

¿Tienes una app en Xamarin.Forms que ya guarda datos sensibles usando SecureStorage, y no quieres que tus usuarios reingresen todo al migrar a .NET MAUI? Aquí te cuento paso a paso cómo hacerlo de forma segura y fluida.

Por qué se daña la migración? diferencias clave entre plataformas

Tanto Xamarin.Essentials como .NET MAUI tienen la clase SecureStorage para guardar pares de clave/valor de forma segura. Pero ojo: no funcionan igual a nivel interno en Android ni iOS.

El resultado: si simplemente cambias el código, tu app .NET MAUI no encontrará lo que guardaste antes en Xamarin, porque está buscando en otro sitio.

Solución paso a paso: usar LegacySecureStorage

• Crea una clase LegacySecureStorage en tu proyecto .NET MAUI (puede ir en cualquier carpeta, por ejemplo dentro de MigrationHelpers).
• Usa este código que te permite leer lo que ya estaba guardado con Xamarin.Essentials:

#if ANDROID || IOS
using System;
using System.Threading.Tasks;
using Microsoft.Maui.ApplicationModel;
#if ANDROID
using Android.Content;
using Android.Security.Keystore;
using AndroidX.Security.Crypto;
using Java.Security;
using Javax.Crypto;
using Android.Preferences;
#endif
#if IOS
using Security;
using Foundation;
#endif

namespace TuApp.Helpers
{
    public static class LegacySecureStorage
    {
        internal static readonly string Alias = $"{AppInfo.PackageName}.xamarinessentials";

#if ANDROID
        static readonly object locker = new object();

        public static Task GetAsync(string key)
        {
            lock (locker)
            {
                var context = Android.App.Application.Context;
                var sharedPrefs = context.GetSharedPreferences(Alias, FileCreationMode.Private);
                var encryptedValue = sharedPrefs.GetString(key, null);
                return Task.FromResult(encryptedValue);
            }
        }

        public static bool Remove(string key)
        {
            lock (locker)
            {
                var context = Android.App.Application.Context;
                var sharedPrefs = context.GetSharedPreferences(Alias, FileCreationMode.Private);
                var editor = sharedPrefs.Edit();
                editor.Remove(key);
                return editor.Commit();
            }
        }

        public static void RemoveAll()
        {
            lock (locker)
            {
                var context = Android.App.Application.Context;
                var sharedPrefs = context.GetSharedPreferences(Alias, FileCreationMode.Private);
                var editor = sharedPrefs.Edit();
                editor.Clear();
                editor.Commit();
            }
        }
#endif

#if IOS
        public static Task GetAsync(string key)
        {
            var query = new SecRecord(SecKind.GenericPassword)
            {
                Service = Alias,
                Account = key
            };

            var match = SecKeyChain.QueryAsRecord(query, out var resultCode);
            if (resultCode == SecStatusCode.Success && match?.ValueData != null)
            {
                var value = NSString.FromData(match.ValueData, NSStringEncoding.UTF8);
                return Task.FromResult(value);
            }

            return Task.FromResult(null);
        }

        public static bool Remove(string key)
        {
            var query = new SecRecord(SecKind.GenericPassword)
            {
                Service = Alias,
                Account = key
            };

            var result = SecKeyChain.Remove(query);
            return result == SecStatusCode.Success;
        }

        public static void RemoveAll()
        {
            var query = new SecRecord(SecKind.GenericPassword)
            {
                Service = Alias
            };
            SecKeyChain.Remove(query);
        }
#endif
    }
}
#endif

Android

En Android, la clase LegacySecureStorage utiliza la clase AndroidKeyStore para almacenar la clave de cifrado que se usa al encriptar un valor antes de guardarlo en un objeto SharedPreferences con el nombre {tu-app-package-id}.xamarinessentials.

Agrega la clase llamada AndroidKeyStore dentro de la carpeta Platforms\Android de tu proyecto .NET MAUI.

using Android.Content;
using Android.OS;
using Android.Runtime;
using Android.Security;
using Android.Security.Keystore;
using Java.Security;
using Javax.Crypto;
using Javax.Crypto.Spec;
using System.Text;

namespace MigrationHelpers;

class AndroidKeyStore
{
    const string androidKeyStore = "AndroidKeyStore"; // this is an Android const value
    const string aesAlgorithm = "AES";
    const string cipherTransformationAsymmetric = "RSA/ECB/PKCS1Padding";
    const string cipherTransformationSymmetric = "AES/GCM/NoPadding";
    const string prefsMasterKey = "SecureStorageKey";
    const int initializationVectorLen = 12; // Android supports an IV of 12 for AES/GCM

    internal AndroidKeyStore(Context context, string keystoreAlias, bool alwaysUseAsymmetricKeyStorage)
    {
        alwaysUseAsymmetricKey = alwaysUseAsymmetricKeyStorage;
        appContext = context;
        alias = keystoreAlias;

        keyStore = KeyStore.GetInstance(androidKeyStore);
        keyStore.Load(null);
    }

    readonly Context appContext;
    readonly string alias;
    readonly bool alwaysUseAsymmetricKey;
    readonly string useSymmetricPreferenceKey = "essentials_use_symmetric";

    KeyStore keyStore;
    bool useSymmetric = false;

    ISecretKey GetKey()
    {
        // check to see if we need to get our key from past-versions or newer versions.
        // we want to use symmetric if we are >= 23 or we didn't set it previously.
        var hasApiLevel = Build.VERSION.SdkInt >= BuildVersionCodes.M;

        useSymmetric = Preferences.Get(useSymmetricPreferenceKey, hasApiLevel, alias);

        // If >= API 23 we can use the KeyStore's symmetric key
        if (useSymmetric && !alwaysUseAsymmetricKey)
            return GetSymmetricKey();

        // NOTE: KeyStore in < API 23 can only store asymmetric keys
        // specifically, only RSA/ECB/PKCS1Padding
        // So we will wrap our symmetric AES key we just generated
        // with this and save the encrypted/wrapped key out to
        // preferences for future use.
        // ECB should be fine in this case as the AES key should be
        // contained in one block.

        // Get the asymmetric key pair
        var keyPair = GetAsymmetricKeyPair();

        var existingKeyStr = Preferences.Get(prefsMasterKey, null, alias);

        if (!string.IsNullOrEmpty(existingKeyStr))
        {
            try
            {
                var wrappedKey = Convert.FromBase64String(existingKeyStr);

                var unwrappedKey = UnwrapKey(wrappedKey, keyPair.Private);
                var kp = unwrappedKey.JavaCast();

                return kp;
            }
            catch (InvalidKeyException ikEx)
            {
                System.Diagnostics.Debug.WriteLine($"Unable to unwrap key: Invalid Key. This may be caused by system backup or upgrades. All secure storage items will now be removed. {ikEx.Message}");
            }
            catch (IllegalBlockSizeException ibsEx)
            {
                System.Diagnostics.Debug.WriteLine($"Unable to unwrap key: Illegal Block Size. This may be caused by system backup or upgrades. All secure storage items will now be removed. {ibsEx.Message}");
            }
            catch (BadPaddingException paddingEx)
            {
                System.Diagnostics.Debug.WriteLine($"Unable to unwrap key: Bad Padding. This may be caused by system backup or upgrades. All secure storage items will now be removed. {paddingEx.Message}");
            }
            LegacySecureStorage.RemoveAll();
        }

        var keyGenerator = KeyGenerator.GetInstance(aesAlgorithm);
        var defSymmetricKey = keyGenerator.GenerateKey();

        var newWrappedKey = WrapKey(defSymmetricKey, keyPair.Public);

        Preferences.Set(prefsMasterKey, Convert.ToBase64String(newWrappedKey), alias);

        return defSymmetricKey;
    }

    // API 23+ Only
#pragma warning disable CA1416
    ISecretKey GetSymmetricKey()
    {
        Preferences.Set(useSymmetricPreferenceKey, true, alias);

        var existingKey = keyStore.GetKey(alias, null);

        if (existingKey != null)
        {
            var existingSecretKey = existingKey.JavaCast();
            return existingSecretKey;
        }

        var keyGenerator = KeyGenerator.GetInstance(KeyProperties.KeyAlgorithmAes, androidKeyStore);
        var builder = new KeyGenParameterSpec.Builder(alias, KeyStorePurpose.Encrypt | KeyStorePurpose.Decrypt)
            .SetBlockModes(KeyProperties.BlockModeGcm)
            .SetEncryptionPaddings(KeyProperties.EncryptionPaddingNone)
            .SetRandomizedEncryptionRequired(false);

        keyGenerator.Init(builder.Build());

        return keyGenerator.GenerateKey();
    }
#pragma warning restore CA1416

    KeyPair GetAsymmetricKeyPair()
    {
        // set that we generated keys on pre-m device.
        Preferences.Set(useSymmetricPreferenceKey, false, alias);

        var asymmetricAlias = $"{alias}.asymmetric";

        var privateKey = keyStore.GetKey(asymmetricAlias, null)?.JavaCast();
        var publicKey = keyStore.GetCertificate(asymmetricAlias)?.PublicKey;

        // Return the existing key if found
        if (privateKey != null && publicKey != null)
            return new KeyPair(publicKey, privateKey);

        var originalLocale = Java.Util.Locale.Default;
        try
        {
            // Force to english for known bug in date parsing:
            // https://issuetracker.google.com/issues/37095309
            SetLocale(Java.Util.Locale.English);

            // Otherwise we create a new key
#pragma warning disable CA1416
            var generator = KeyPairGenerator.GetInstance(KeyProperties.KeyAlgorithmRsa, androidKeyStore);
#pragma warning restore CA1416

            var end = DateTime.UtcNow.AddYears(20);
            var startDate = new Java.Util.Date();
#pragma warning disable CS0618 // Type or member is obsolete
            var endDate = new Java.Util.Date(end.Year, end.Month, end.Day);
#pragma warning restore CS0618 // Type or member is obsolete

#pragma warning disable CS0618
            var builder = new KeyPairGeneratorSpec.Builder(Platform.AppContext)
                .SetAlias(asymmetricAlias)
                .SetSerialNumber(Java.Math.BigInteger.One)
                .SetSubject(new Javax.Security.Auth.X500.X500Principal($"CN={asymmetricAlias} CA Certificate"))
                .SetStartDate(startDate)
                .SetEndDate(endDate);

            generator.Initialize(builder.Build());
#pragma warning restore CS0618

            return generator.GenerateKeyPair();
        }
        finally
        {
            SetLocale(originalLocale);
        }
    }

    byte[] WrapKey(IKey keyToWrap, IKey withKey)
    {
        var cipher = Cipher.GetInstance(cipherTransformationAsymmetric);
        cipher.Init(CipherMode.WrapMode, withKey);
        return cipher.Wrap(keyToWrap);
    }

#pragma warning disable CA1416
    IKey UnwrapKey(byte[] wrappedData, IKey withKey)
    {
        var cipher = Cipher.GetInstance(cipherTransformationAsymmetric);
        cipher.Init(CipherMode.UnwrapMode, withKey);
        var unwrapped = cipher.Unwrap(wrappedData, KeyProperties.KeyAlgorithmAes, KeyType.SecretKey);
        return unwrapped;
    }
#pragma warning restore CA1416

    internal string Decrypt(byte[] data)
    {
        if (data.Length < initializationVectorLen)
            return null;

        var key = GetKey();

        // IV will be the first 16 bytes of the encrypted data
        var iv = new byte[initializationVectorLen];
        Buffer.BlockCopy(data, 0, iv, 0, initializationVectorLen);

        Cipher cipher;

        // Attempt to use GCMParameterSpec by default
        try
        {
            cipher = Cipher.GetInstance(cipherTransformationSymmetric);
            cipher.Init(CipherMode.DecryptMode, key, new GCMParameterSpec(128, iv));
        }
        catch (InvalidAlgorithmParameterException)
        {
            // If we encounter this error, it's likely an old bouncycastle provider version
            // is being used which does not recognize GCMParameterSpec, but should work
            // with IvParameterSpec, however we only do this as a last effort since other
            // implementations will error if you use IvParameterSpec when GCMParameterSpec
            // is recognized and expected.
            cipher = Cipher.GetInstance(cipherTransformationSymmetric);
            cipher.Init(CipherMode.DecryptMode, key, new IvParameterSpec(iv));
        }

        // Decrypt starting after the first 16 bytes from the IV
        var decryptedData = cipher.DoFinal(data, initializationVectorLen, data.Length - initializationVectorLen);

        return Encoding.UTF8.GetString(decryptedData);
    }

    internal void SetLocale(Java.Util.Locale locale)
    {
        Java.Util.Locale.Default = locale;
        var resources = appContext.Resources;
        var config = resources.Configuration;

        if (Build.VERSION.SdkInt >= BuildVersionCodes.N)
            config.SetLocale(locale);
        else
#pragma warning disable CS0618 // Type or member is obsolete
            config.Locale = locale;
#pragma warning restore CS0618 // Type or member is obsolete

#pragma warning disable CS0618 // Type or member is obsolete
        resources.UpdateConfiguration(config, resources.DisplayMetrics);
#pragma warning restore CS0618 // Type or member is obsolete
    }
}

iOS

En iOS, la clase LegacySecureStorage utiliza la clase KeyChain para almacenar valores de forma segura. El SecRecord que se usa para guardar los valores tiene el campo Service configurado como {tu-app-package-id}.xamarinessentials.

Agrega la clase llamada KeyChain dentro de la carpeta Platforms\iOS de tu proyecto .NET MAUI.

using Foundation;
using Security;

namespace MigrationHelpers;

class KeyChain
{
    SecRecord ExistingRecordForKey(string key, string service)
    {
        return new SecRecord(SecKind.GenericPassword)
        {
            Account = key,
            Service = service
        };
    }

    internal string ValueForKey(string key, string service)
    {
        using (var record = ExistingRecordForKey(key, service))
        using (var match = SecKeyChain.QueryAsRecord(record, out var resultCode))
        {
            if (resultCode == SecStatusCode.Success)
                return NSString.FromData(match.ValueData, NSStringEncoding.UTF8);
            else
                return null;
        }
    }

    internal bool Remove(string key, string service)
    {
        using (var record = ExistingRecordForKey(key, service))
        using (var match = SecKeyChain.QueryAsRecord(record, out var resultCode))
        {
            if (resultCode == SecStatusCode.Success)
            {
                RemoveRecord(record);
                return true;
            }
        }
        return false;
    }

    internal void RemoveAll(string service)
    {
        using (var query = new SecRecord(SecKind.GenericPassword) { Service = service })
        {
            SecKeyChain.Remove(query);
        }
    }

    bool RemoveRecord(SecRecord record)
    {
        var result = SecKeyChain.Remove(record);
        if (result != SecStatusCode.Success && result != SecStatusCode.ItemNotFound)
            throw new Exception($"Error removing record: {result}");

        return true;
    }
}

Finalmente, en tu código, lee y migra datos de la siguiente manera:

// Ejemplo: migrar el "username"
string? username = await LegacySecureStorage.GetAsync("username");

if (!string.IsNullOrEmpty(username))
{
    // Guardar en MAUI SecureStorage
    await SecureStorage.Default.SetAsync("username", username);

    // Eliminar del almacenamiento antiguo
    LegacySecureStorage.Remove("username");
}

En resumen

MAUI y Xamarin.Essentials usan almacenamiento seguro con nombres/identificadores distintos a nivel interno.
Lo que guardaste con Xamarin no se encuentra automáticamente al pasar a MAUI.

Qué hacemos
1. Leemos lo antiguo con LegacySecureStorage (apunta a los mismos contenedores/alias de Xamarin).
2. Lo guardamos de nuevo con SecureStorage.Default (el formato/ubicación que entiende MAUI).
3. Limpiamos lo viejo para no dejar basura y evitar inconsistencias.
4. Ejecutamos la migración al iniciar la app para que el usuario ni lo note.

Recomendación extra

• Si prefieres algo ya empaquetado, usa el plugin Plugin.Maui.FormsMigration para orquestar la migración.
• Mantén el mismo Package Name (Android) y Bundle Identifier (iOS) para que los datos previos sean accesibles.
• Haz una lista de claves críticas (token, refresh_token, username, etc.) y verifícalas con logs en un build interno antes de publicar.

Con esto, la migración queda transparente para el usuario (sin re-login ni reconfiguraciones) y tu base de datos segura queda alineada al modelo de MAUI. Nos leemos pronto!

Estás desarrollando con .NET MAUI y todo va bien… hasta que necesitas acceder a algo específico de Android o iOS. Dónde va ese código? Cómo lo haces sin romper la portabilidad? Y, sobre todo, por qué no hay una guía clara que lo explique?

MAUI tiene una base de código única, pero hay momentos en los que sí o sí necesitas tocar el sistema operativo.

En este artículo vas a aprender cómo agregar código específico de cada plataforma de una forma ordenada, usando las herramientas que MAUI te da, por ejemplo: directivas de compilación, clases parciales o inyección de dependencias. Todo explicado de forma directa y con ejemplos.

¿Qué significa “código específico de cada plataforma” en MAUI?

Cuando hablamos de “código específico de cada plataforma” en .NET MAUI, nos referimos a cualquier funcionalidad que no está disponible de forma compartida entre plataformas. Es decir, cosas que solo existen o funcionan diferente en Android, iOS, Windows o macOS.

Ejemplos comunes:

• Obtener el identificador del dispositivo (Android/iOS).
• Acceder a sensores o al GPS.
• Usar APIs exclusivas como el llavero de iOS o el sistema de archivos de Windows.

MAUI, por diseño, te da una única base de código. Pero también sabe que vas a necesitar romper esa uniformidad en ciertos casos. Por eso, permite introducir código específico sin tener que duplicar tu aplicación por cada plataforma.

El objetivo no es evitar el código nativo, sino encapsularlo bien. Así puedes seguir escribiendo tu app como si todo fuera multiplataforma… y solo abrir esa “puerta” nativa cuando lo necesites.

Estructura del proyecto .NET MAUI y dónde va el código nativo

En un proyecto .NET MAUI, todo empieza en una carpeta única y compartida. Pero si miras un poco más de cerca, vas a ver subcarpetas para cada plataforma: Platforms/Android, Platforms/iOS, Platforms/Windows, y Platforms/MacCatalyst. Ahí es donde va el código específico.

Por ejemplo, si necesitas usar una API nativa de Android, ese código va dentro de Platforms/Android. Lo mismo con iOS o cualquier otra plataforma.

Lo importante es que este código no se ejecuta automáticamente. MAUI no mezcla todo; solo compila el código de la plataforma que estás ejecutando. Por eso es seguro tener código específico ahí: no afecta a las otras plataformas.

Esto mantiene el código compartido limpio, y solo compila lo que corresponde según la plataforma.

Uso de directivas de compilación (#if ANDROID, #if IOS, etc.)

Las directivas de compilación son la forma más directa de escribir código que solo se ejecute en una plataforma específica. Básicamente, le dices al compilador: “esto solo compílalo si estoy en Android” (o iOS, o Windows).

public class IdentifierInfoService
{
    public string GetIndentifier()
    {
#if ANDROID
        return Android.Provider.Settings.Secure.GetString(
            Android.App.Application.Context.ContentResolver,
            Android.Provider.Settings.Secure.AndroidId);
#elif IOS
        return UIKit.UIDevice.CurrentDevice.IdentifierForVendor.AsString();
#else
        return "No soportado en esta plataforma";
#endif
    }
}

Uso en tu app:

Puedes utilizar esta clase directamente en cualquier parte del código compartido. Por ejemplo, en tu MainPage.xaml.cs:

public partial class MainPage : ContentPage
{
    public MainPage()
    {
        InitializeComponent();

        var service = new IdentifierInfoService();
        string id = service.GetIndentifier();

        result.Text = $"ID del dispositivo: {id}";
    }
}

Esto funciona bien si el código específico es simple y no lo usas en muchos lugares. Pero si empieza a crecer, puede volverse difícil de mantener. En ese caso, es mejor encapsularlo usando interfaces y separar las implementaciones por plataforma (lo veremos más adelante).

✅ Cuándo usarlo:

• Cuando solo necesitas una pequeña diferencia entre plataformas.
• Para pruebas rápidas o funcionalidades mínimas.

❌ Cuándo evitarlo:

• Cuando el código nativo empieza a repetirse o a crecer.
• Si quieres mantener el proyecto limpio y escalable.

Uso de partial clases y métodos parciales

Otra forma elegante de manejar código específico de plataforma en .NET MAUI es con partial class y partial methods.

Esto te permite definir la estructura de tu clase o método en el código compartido, pero escribir su implementación específica en los archivos de cada plataforma.

Por ejemplo, en tu código compartido:

namespace Sample.Services;
public partial class DeviceInfoService
{
    public string GetIdentifier() => GetIdentifierInternal();

    protected static partial string GetIdentifierInternal();
}

Te presente el nombre de espacio que le pongas a esta clase, ya que en las siguientes clases que vas a crear tiene que ser el mismo.

Ahora, en la carpeta Platforms/Android crea la clase que accederá al código nativo de Android:

namespace Sample.Services;
public partial class IdentifierInfoService
{
    protected static partial string GetIdentifierInternal()
    {
        return Android.Provider.Settings.Secure.GetString(
               Android.App.Application.Context.ContentResolver,
               Android.Provider.Settings.Secure.AndroidId);
    }
}

Y finalmente lo mismo en la carpeta Platforms/iOSpara acceder al código nativo de iOS:

namespace Sample.Services;
public partial class IdentifierInfoService
{
    protected static partial string GetIdentifierInternal()
    {
        return UIKit.UIDevice.CurrentDevice.IdentifierForVendor.AsString();
    }
}

Uso en tu app:

Puedes utilizar esta clase directamente en cualquier parte del código compartido. Por ejemplo, en tu MainPage.xaml.cs:

public partial class MainPage : ContentPage
{
    public MainPage()
    {
        InitializeComponent();

        var service = new IdentifierInfoService();
        string id = service.GetIndentifier();

        result.Text = $"ID del dispositivo: {id}";
    }
}

Con esto, todo tu código compartido sigue limpio y no necesitas preocuparse por las plataformas. Solo hace una llamada, y MAUI se encarga del resto en tiempo de compilación.

Ventajas:

• Código más limpio y organizado.
• Fácil de mantener y escalar.
• Separación clara entre lógica compartida y lógica nativa.

Inyección de dependencias con interfaces específicas por plataforma

Cuando tu lógica específica de cada plataforma crece o necesitas una solución más escalable, usar interfaces con inyección de dependencias es la forma más limpia y flexible de manejarlo en MAUI.

1: Crear una interfaz en tu proyecto compartido

public interface IIdentifierInfoService
{
    public string GetIdentifier();
}

2: Implementación en Android

En la carpeta Platforms/Android crea una clase llamada IdentifierInfoService.csque implemente a la interface creada anteriormente:

public class IdentifierInfoService : IIdentifierInfoService
{
    public string GetIdentifier()
    {
        return Android.Provider.Settings.Secure.GetString(
               Android.App.Application.Context.ContentResolver,
               Android.Provider.Settings.Secure.AndroidId);
    }
}

2: Implementación en iOS

En la carpeta Platforms/iOS crea una clase llamada IdentifierInfoService.csque implemente a la interface creada anteriormente:

public class IdentifierInfoService : IIdentifierInfoService
{
    public string GetIdentifier()
    {
        return UIKit.UIDevice.CurrentDevice.IdentifierForVendor.AsString();
    }
}

3. Registro en MauiProgram.cs

En la clase MauiProgram.cs agrega el registro de cada implementación:

#if ANDROID
    builder.Services.AddSingleton<IDeviceInfoService, DeviceInfoService>();
#elif IOS
    builder.Services.AddSingleton<IDeviceInfoService, DeviceInfoService>();
#endif

4: Usarlo en cualquier parte de tu app

En una página o ViewModel, inyectas la dependencia:

public partial class MainPage : ContentPage
{
    private readonly IIdentifierInfoService _deviceInfoService;

    public MainPage(IIdentifierInfoService deviceInfoService)
    {
        InitializeComponent();
        _deviceInfoService = deviceInfoService;

        string id = _deviceInfoService.GetIdentifier();
        result.Text = $"ID del dispositivo: {id}";
    }
}

Y listo. Con esto estás obteniendo un identificador nativo, específico de cada plataforma, pero sin ensuciar tu código compartido.

Buenas prácticas para mantener tu proyecto limpio y escalable

Cuando trabajas con código específico de cada plataforma en MAUI, es fácil caer en un caos de archivos y lógica duplicada. Estas prácticas te van a ayudar a evitarlo:

1. Usa interfaces siempre que puedas

Separar la definición (interface) de la implementación te da flexibilidad, testabilidad y un código más limpio.

2. Evita abusar de las directivas de compilación

Si bien #if ANDROID, #if IOS son útiles, pueden volver el código difícil de leer si se usan en exceso. Si necesitas lógica más compleja, encapsula todo en clases separadas.

3. Organiza tus archivos por plataforma

No pongas código específico en archivos genéricos. Aprovecha la estructura de carpetas (Platforms/Android, etc.) para mantener todo ordenado.

4. Centraliza el registro de dependencias

Mantén el registro de servicios (en MauiProgram.cs) lo más claro posible. Agrupa los AddSingleton por plataforma y comenta lo necesario.

6. Piensa en el futuro

Si estás empezando con una implementación simple, no te preocupes. Pero si sabes que vas a expandir esa lógica (por ejemplo, más APIs nativas), es mejor arrancar con interfaces desde el principio.

Conclusión

Agregar código específico de cada plataforma en .NET MAUI no es una trampa al sistema ni un retroceso: es una necesidad real en muchas apps, y MAUI está diseñado para manejarlo bien… siempre que tú lo manejes bien también.

Ya viste:

• Dónde va el código específico en el proyecto.
• Cómo usar directivas de compilación para diferencias simples.
• Cómo usar partial class e interface para mantener todo limpio.
• Buenas prácticas y errores que podés evitar desde el primer día.

¿Qué sigue ahora?

• Revisa qué partes de tu app podrían beneficiarse de lógica específica por plataforma.
• Usa el patrón que más sentido tenga: directo, parcial o con interfaces.
• Prueba en cada plataforma donde tu app vaya a vivir.

Y recuerda: escribir código nativo no es romper el concepto de MAUI. Es entenderlo bien. Nos leemos pronto :)

Docker es una herramienta de contenedores que permite a los desarrolladores crear, ejecutar y distribuir aplicaciones en diferentes entornos. A su vez Windows Subsystem for Linux 2 (WSL 2) cuenta con un kernel de Linux real, compatible con contenedores Docker.

Docker funciona en WSL 2 y Docker Desktop es la forma más fácil de instalar Docker en Windows, sin embargo, para algunas personas (y me incluyo) suele ser un poco tedioso y pesado. Sobre todo, estar esperando que la ballenita se quede cargando por un largo rato en tu barra de tareas o simplemente no te gusta tener muchos programas abierto al momento de desarrollar. En esas ocasiones entonces quizás quieras ejecutar Docker desde WSL 2 sin necesidad de usar Docker Desktop.

Además, ten en cuenta que Docker Desktop es gratuito solo para personas o pequeñas empresas. Si lo estás utilizando en el trabajo y tu empresa supera una cierta cantidad de empleados o ingresos, entonces deberías pagar una suscripción. Para ver más detalles sobre el modelo de suscripción de Docker puedes ir aquí.

Habilita WSL 2 en Windows 11

Lo primero que debes hacer es habilitar la característica de WSL en Windows 11. Para hacerlo, presionar Windows y escribir "Agregar características de Windows"

Luego en la ventana que se abrirá, buscar la opción "Windows Subsystem for Linux", activa la casilla y reinicia.

Descarga e instala una distribución de Linux

Una vez que hayas habilitado WSL en Windows 11, necesitarás descargar e instalar una distro de Linux para ejecutar Docker. Puedes elegir cualquier distro de Linux que desees, pero en este ejemplo usaremos Ubuntu. Para descargar Ubuntu, ve a la tienda Microsoft Store y busca "Ubuntu":

Preparándose para la instalación de Docker

Primero vamos a hacer update y upgrade de los paquetes de nuestra distro:

sudo apt update && sudo apt upgrade

Luego instalamos algunas dependencias:

sudo apt install --no-install-recommends apt-transport-https ca-certificates curl gnupg2

A continuación, configuramos las direcciones en el repositorio de paquetes, para eso primero vamos configurar temporalmente algunas variables del sistema operativo:

. /etc/os-release

Luego nos aseguramos de que la ruta de descarga sea una ruta segura para apt:

curl -fsSL https://download.docker.com/linux/${ID}/gpg | sudo tee /etc/apt/trusted.gpg.d/docker.asc

Ahora agregamos y actualizamos el repositorio para que esté listo:

echo "deb [arch=amd64] https://download.docker.com/linux/${ID} ${VERSION_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/docker.list

Hacemos un último sudo apt update y con esto estamos listos para instalar Docker.

Si eres observador habrás notado que he usado ${ID} y ${VERSION_CODENAME}. Bueno, estas son variables del sistema, las puedes ubicar si usas el siguiente comando: nano /etc/os-release

Instalando Docker

Ahora podemos instalar el engine de docker y algunas herramientas adicionales, para eso ejecutamos el siguiente comando:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Administra Docker sin usar sudo

El daemon Docker se vincula a un socket de Unix, no a un puerto TCP. Por defecto, es el usuario root es el que el puede acceder al socket de Unix, otros usuarios solo pueden acceder a él mediante sudo.

Entonces tienes 2 caminos, acceder a este socket usando sudo todo el tiempo o creando un grupo y dándole permisos a usuarios específicos. En esta ocasión iremos por la segunda opción:

Creamos un grupo llamado docker

sudo groupadd docker

Ahora agregamos nuestro usuario al grupo docker

sudo usermod -aG docker $USER

Cierra la ventana de terminar y vuélvela. Deberías de ver el grupo docker cuando escribas el comando groups de la siguiente manera:

Lanzando dockerd

Casi todas las distros Linux usan systemd u otro sistema de inicio (init), pero WSL tiene su propio sistema de inicio. Para no complicarnos la vida vamos a usar el sistema de inicio de WSL, solo lanzamos dockerd y vemos la magia:

sudo dockerd

Abre otra terminal y prueba el docker cli:

docker run --rm hello-world

Deberías ver un mensaje de "Hello from Docker!" en la terminal:

Iniciando dockerd automáticamente

Lo que haremos a continuación es hacer que dockerdse ejecute automáticamente al iniciar la terminal, para esto tendremos que editar el archivo ~./profile.

Primero abrimos el archivo ~./profileusando nano:

sudo nano ~./profile

Y a continuación agregamos las siguientes sentencias al final del archivo:

DOCKER_DISTRO="Ubuntu-20.04"
DOCKER_LOG_DIR=$HOME/docker_logs
mkdir -pm o=,ug=rwx "$DOCKER_LOG_DIR"
/mnt/c/Windows/System32/wsl.exe -d $DOCKER_DISTRO sh -c "nohup sudo -b dockerd < /dev/null > $DOCKER_LOG_DIR/dockerd.log 2>&1"

Ten en cuenta que a la variable DOCKER_DISTRO se le debe asignar el nombre correcto de la distribución que estés usando. Si no estás seguro del nombre exacto de tu distro, ejecuta wsl -l -q desde tu terminal PowerShell y verás la lista de distros que tienes.

Después de hacer esta configuración notarás que al iniciar la terminal de tu distro te está solicitando la contraseña de `root` esto porque en las sentencias que escribimos líneas arriba se usa en comando `sudo`. Para hacer que no te pida contraseña al iniciar la terminal haremos lo siguiente:

Ejecutamos `sudo visudo` y dentro de este archivo agregamos la siguiente línea al final del archivo:

%docker ALL=(ALL)  NOPASSWD: /usr/bin/dockerd

Guardamos y al abrir nuevamente nuestra terminal ya no volverá a solicitarnos la clave.

Probando Docker

Una vez instalado y configurado Docker podemos probar y empezar a usarlo, para efectos de este tutorial vamos a ejecutar Nginx en Docker.

Primero descargamos la imagen de Nginx desde Docker Hub:

docker pull nginx

Y a continuación ejecutamos Nginx:

docker run --name docker-nginx -p 80:80 nginx

Ahora podemos acceder desde nuestra maquina en Windows a nginx con la siguiente dirección: http://localhost:80

Conclusión

Instalar Docker en Windows 11 sin usar Docker Desktop es posible gracias a la función de WSL2 que permite ejecutar una distribución de Linux dentro de Windows. Este ejercicio es especialmente útil para aquellos desarrolladores (como yo :P ) que prefieren trabajar con herramientas de línea de comando o que quieren tener más control sobre la instalación de Docker en su máquina. Nos leemos pronto :)

Usualmente muchos de nuestros usuarios requieren que las aplicaciones que ellos usan puedan ser administrables, es decir, puedan cambiar su contraseña, nombre de usuario, etc. Pero sobre todo existe la necesidad de que cada usuario pueda usar su propia foto de perfil y para eso necesitamos poder subir y almacenar esas fotos en un servidor de almacenamiento.

En este articulo vamos a ver la forma de como hacer todo ese procedimiento de almacenar las imágenes y que obtengamos una URL de la imagen para así poder hacer referencia de ella en diferentes ocasiones.

Bueno, hoy usaremos una herramienta de Azure que nos ayudará con este propósito, esta herramienta es una Cuenta de almacenamiento que nos permitirá almacenar nuestras imágenes rápida y fácil.

Para empezar con este tutorial será necesario tener una cuenta de Azure, si aún no tienes una puedes obtener una cuenta gratuita.

Configurando el servidor

Lo primero que haremos será crear un nuevo servicio en nuestro portal de Azure, para eso vamos a la opción Crear un recurso y luego a Cuenta de almacenamiento

En esta sección lo que vamos hacer es elegir nuestra suscripción, grupo de recurso que vamos a usar; si tú no tienes un grupo de recurso puedes crear uno; también es importante elegir la ubicación de nuestro servicio.

Una vez creada nuestra cuenta de almacenamiento vamos a la sección Contenedores y ahí vamos a agregar un nuevo contenedor, le damos un nombre apropiado en nuestro caso xamarin-blob (guarden este nombre que nos servirá más adelante)

Finalmente, regresamos al resumen de nuestra cuenta de almacenamiento y nos dirigimos a la opción Llaves de acceso aquí vamos a obtener nuestra cadena de conexión la cual usaremos más adelante en nuestro proyecto.

Escribamos código

Crearemos un nuevo proyecto móvil multiplataforma en Visual Studio

Lo primero que haremos será agregar un par de paquetes nuget a nuestro proyecto. El primero será WindowsAzure.Storage hacemos clic derecho en nuestra solución y luego en Administrar paquetes nuget para la solución. Buscamos el nombre de nuetro paquete ya mencionado y seleccionamos solo el proyecto principal.

Hacemos lo mismo para el siguiente paquete llamado Xam.Plugin.Media

Ahora cambiaremos la estructura de nuestro proyecto y crearemos algunas clases necesarias para que finalmente nuestro proyecto quede de la siguiente manera:

Iniciemos por la carpeta Services. Creamos una clase llamada BlobServices.cs y agregamos el método Upload

Ahora encapsularemos esta clase para que sea dependiente de una interface, para eso vamos a seleccionar el nombre de la clase y hacer clic derecho, luego Acciones rápidas y refactorización, a continuación, clic en Extraer en una interface y finalmente seleccionar el método que queremos encapsular.

A continuación, iremos a la carpeta ViewModels y en la clase MainViewModel.cs agregaremos los siguientes métodos:

PickPicture: Este método nos permitirá elegir una foto de nuestra galería para poder subirla.

TakePicture: Este método nos permitirá tomar una foto con la cámara del dispositivo para poder suburla.

Upload: Este método nos permitirá subir la foto que hemos tomado o elegido de la galería.

private async Task Upload()
{
    IsBusy = true;
    ResponseUrl = await blobServices.Upload(Path);
    IsBusy = false;
}

Ahora vamos a ir a la carpeta Views y escribiremos la vista que nos mostrará la aplicación. Básicamente son 3 botones, un panel para mostrar la foto y una etiqueta para mostrar al final la URL que retorna la cuenta de almacenamiento en Azure.

Ajustes finales

En ambas plataformas necesitamos que el usuario otorgue permisos a nuestra aplicación para poder acceder a la galería o para poder hacer uso de la cámara.

Android

En Android crearemos una sub carpeta en la carpeta Resources llamada xml, dentro de esta carpeta crearemos un archivo llamado  file_paths.xml y escribiremos lo siguiente:

<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <external-files-path name="my_images" path="Pictures" />
    <external-files-path name="my_movies" path="Movies" />
</paths>

Paso siguiente será agregar la siguiente línea de código en la clase MainActivity.cs dentro del método OnCreate

CrossCurrentActivity.Current.Init(this, savedInstanceState);

iOS

En iOS lo único que haremos será agregar el siguiente código a nuestro archivo Info.plist

<key>NSCameraUsageDescription</key>
<string>This app needs access to the camera to take photos.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>This app needs access to photos.</string>
<key>NSMicrophoneUsageDescription</key>
<string>This app needs access to microphone.</string>
<key>NSPhotoLibraryAddUsageDescription</key>
<string>This app needs access to the photo gallery.</string>

Finalmente, obtendremos lo siguiente:

Conclusión

En este tutorial vimos una manera fácil y sencilla de subir y almacenar imágenes desde una aplicación hecha con Xamarin Forms, se los servicios de Cuentas de Almacenamiento de Azure y se logró con el resultado esperado. Recuerden que el proyecto completo está en mi cuenta de GitHub, lo pueden descargar modificar, pero sobre todo aprender de él. Nos leemos pronto 😊

Muchas veces nuestros usuarios necesitan ver la información que están usando como input en nuestras aplicaciones. Ese es el caso del campo contraseña, que por ser un campo con un cierto grado de seguridad no muestra su valor actual.

En este articulo veremos una técnica para darle la facilidad al usuario de mostrar el valor del campo contraseña sin usar Custom Renderers.

El contexto

Como sabrán muchas de las aplicaciones hoy en día necesitan tener autenticación de usuarios y para eso es necesario tener una pantalla de autenticación, o pantalla de login, en estos casos es muy común ver el campo contraseña con un pequeño botón donde le indica al usuario que tocando en esa parte ellos pueden ver el valor que están ingresando.

Es un control extraño, ah usemos Custom Renderers!

Muchas veces lo primero que se nos viene a la mente cuando vemos controles un poco personalizados es usar Custom Renderers, de hecho, a mi parecer es lo mejor que ha podido crear Xamarin.Forms para poder lidiar con controles que son un poco peculiares y no se pueden conseguir con usando los controles compartidos.

Sin embargo, no es necesario usar Custom Renderers en todos los casos, muchas veces la plataforma nos ofrece formas de hacer nuestros controles sin la necesidad de usar esta característica y este es el caso.

A codificar!

Bien, lo primero que haremos es crear nuestro control. Es una manera muy sencilla de solo usar XAML, de hecho, solo haremos una superposición de controles:

Como veras, mi control principal es un Grid que contiene un Entry que será el core de nuestro control por así decirlo, y otro Grid alineado al lado derecho que contiene, a su vez, dos controles más que son el botón que usamos para mostrar u ocultar el valor de nuestro Entry y la imagen que muestra un icono.

Finalmente, usamos una propiedad llamada IsClippedToBounds para recortar las áreas de los elementos internos del Grid, para que todo se junte como un solo elemento en la interfaz de usuario.

Y cómo controlamos las acciones?

En el paso anterior creamos un control el cual tendría que cambiar una propiedad de nuestro Entry para poder visualizar su valor.

Bueno, es momento de usar un Trigger… Con esto nosotros podremos agregar acciones a los controles escrito en XAML, permitiendo realizar cambios de apariencia en ellos cuando una determinada acción ocurre. Exactamente lo que queremos hacer en este caso 😁

Como verás esta parte es sencilla, solo es decirle a nuestro Trigger que cuando se invoque cambie la propiedad IsPassword de nuestro Entry y cambiar la imagen del icono que estamos mostrando.

Lo siguiente es agregar el trigger al control en el cual queremos que se lance, entonces lo agregaremos al control Button de la siguiente manera:

<Button.Triggers>
    <EventTrigger Event="Clicked">
        <triggers:ShowPasswordTriggerAction
            EntryPasswordName="EntryPassword"
            IconImageName="ShowPasswordButtonIcon" />
    </EventTrigger>
</Button.Triggers>

Finalmente tendremos lo que necesitamos…

Conclusión

Como pudiste ver en este articulo te muestro como mostrar el valor de un campo contraseña sin la necesidad de usar Custom Renderers, que de por sí son muy útiles para crear controles personalizados, pero no hay que abusar mucho de ellos. También aprendimos, de manera muy rápida, como usar los Triggers y cuando debemos utilizarlos.

Recuerda que el código fuente de este ejemplo lo puedes obtener en mi cuenta de Github, nos leemos pronto 😉

Cuando una aplicación pasa a un estado de suspensión, es decir, cuando es reemplazada por otra aplicación y esta pasa a segundo plano, el sistema operativo toma una captura de pantalla y la usa como una vista previa de la aplicación.

En algunas ocasiones nosotros queremos ocultar información sensible de la aplicación, pero una manera de acceder; no por completo, pero sí parcialmente, es de la forma explicada arriba.

Para ser mas claro, la aplicación de WhatsApp últimamente incluyó la característica de usar la autenticación con huella para acceder a la aplicación, esto porque en muchos casos los usuarios no quieren que puedan ver sus conversaciones.

Sin embargo, cuando la aplicación pasaba a segundo plano y usábamos el administrador de tareas del teléfono, se podía ver parte de algunas de sus ultimas conversaciones, debido a que el sistema operativo por defecto toma una captura de lo último que hiciste en la aplicación y la usa como vista principal, este error ha sido solucionado y ahora se ve de esta manera:

En este ejemplo se muestra claramente como WhatsApp protege la información cuando la aplicación entra en estado de suspensión.

Tal vez no sea una característica tan importante en la mayoría de aplicaciones, pero en casos puntuales es un requerimiento esencial.

Supongamos que creamos una aplicación de autenticación donde en la pantalla principal se muestra todos códigos que uso para acceder a mis cuentas. Nuestra aplicación sería vulnerable al momento de entrar en estado de suspensión porque los códigos podrían ser vistos al momento de cambiar de aplicación.

Manos al código

Bueno, esta vez no seré muy enfático en mostrar como crear un proyecto ni en el diseño que va a tener, sino simplemente en como ocultar la información cuando nuestra aplicación entra en estado de suspensión. Igual tu puedes ver el código fuente de este post en mi cuenta de GitHub

Haremos el ejemplo de una aplicación que almacena códigos de autenticación, imaginemos que en esta aplicación está guardados los códigos para acceder a nuestra cuenta de Facebook, de Github, de tu correo etc.

Nuestra aplicación cuando la usamos se ve de la siguiente manera.

Pero cuando pasa a estado de suspensión, es decir a segundo plano, se ve de la siguiente manera:

Obviamente no queremos que nuestros códigos de autenticación se vean de esta manera, para eso vamos a escribir un poco de código…

Xamarin.iOS

En nuestro proyecto Xamarin.iOS hay varias maneras de hacerlo, la más fácil es poner un fondo blanco a nuestra ventana principal, pero a mi parecer eso no es muy agradable para el usuario.

En lugar de eso vamos a usar la imagen de SplashScreen para ponerla cuando nuestra aplicación está en suspensión. Para eso en el archivo AppDelegate.cs y agregaremos dos métodos sobrescritos.

El primero será OnResignActivation este método es llamado cuando la aplicación está a punto de suspenderse o cuando el usuario tiene alguna interrupción, como una llamada o un mensaje de texto.

Aquí lo que haremos es obtener la imagen de nuestro SplashScreen y convertirla en tipo UIImageView, luego de eso simplemente la agregamos a la vista principal de nuestra aplicación.

Ahora sobrescribimos el segundo método, OnActivated este método es llamado cuando se inicia la aplicación y cada vez que la aplicación vuelve al primer plano. Aquí solo quitaremos la imagen de nuestra vista principal.

Finalmente, cuando nuestra aplicación entra en estado de suspensión se ve de la siguiente manera:

Xamarin.Android

En Android, realmente no existe algo para hacer una superposición, así como lo hice en iOS, o al menos no que yo sepa 🤣 . Si tú conoces de alguna manera de hacer lo mismo que hicimos en Xamarin.iOS pues siéntete libre de enviar un PR a este proyecto o escribirme un tweet diciendo cómo se hacerlo.

Para este caso vamos a ir al archivo MainActivity.cs, en el método OnCreate, simplemente agregamos la bandera WindowManagerFlags.Secure, esto tenemos que hacerlo después que se haya cargado Xamarin.Forms, para asegurarnos de que no se sobrescriba.

Finalmente, cuando nuestra aplicación entra en estado de suspensión se ve de la siguiente manera:

Conclusión

Muchas aplicaciones necesitan ocultar información dentro de ellas, pero cuando entra en estado de suspensión el sistema operativo toma una captura de pantalla y la pone como vista principal.

En este articulo explicamos como ocultar dicha información cuando nuestra aplicación entra en estado de suspensión, recuerda que puedes encontrar el código fuente de este ejemplo en mi cuenta de Github. Nos leemos pronto! 😊

Hola, hoy en el trabajo a mi amigo Manuel Ruh (el buen Rugue 😊) y a mí se nos presentó un problema con la estructura de una vista en Xamarin. Los pongo en contexto:

La aplicación tiene una vista en donde tiene un ScrollView como uno de los contenedores principales, el cual tiene una animación al hacer scroll o deslizar hacia arriba. Entonces, es necesario tener el ScrollView como un contenedor principal.

Dentro de este ScrollView tenemos varios controles, como contenedores, botones, labels, etc. Pero adicionalmente era necesario agregar un ListView, entonces nació el problema!

Por definición general no se puede o no es recomendable poner un ListView dentro de un ScrollView debido a que el control ListView tiene su propio ScrollView por defecto, esto no arroja ningún error de compilación, ni una excepción. Xamarin a manera de que no haya problemas al momento de hacer scroll en dos controles similares lo que hace es darle por defecto la altura máxima al ListView y esto hace que el ListView a pesar de tener dos elementos en la lista se vea demasiado grande ocupando mucho espacio en la pantalla del dispositivo.

Algo parecido a esta vista:

Esta no es la vista que usamos, pero teníamos ese mismo problema.

San Google lo hizo de nuevo!

La primera idea que se nos vino a la cabeza es crear un CustomRenderer en el cual podamos deshabilitar el scroll del ListView, tal vez eso podía solucionar el problema, pero no funcionó xdxd 😅😅

Luego nos pusimos a ver algo en Google de como podríamos deshabilitar el scroll y discutíamos sobre que Xamarin.Forms debería tener la forma de deshabilitar esta propiedad habiendo tanta gente que necesita este feature.

Afortunadamente, nos topamos con un pedido de algo similar a lo que nosotros necesitábamos, este pedido lo hizo *Jeremy Wesley*, curiosamente en el 2016 😱😱 y SORPRESIVAMENTE tenía una respuesta que se había hecho en Setiembre de este año, ESTE AÑO (2018)!!

Básicamente, la respuesta era que ya habían agregado esta característica en la versión 3.1.0 de Xamarin.Forms pero al control ScrollView.

Peeero le dejo una recomendación de usar un control llamado **RepeaterView** y dejó el enlace de la issue registrada en Github, la cual fue solucionada en un excelente Pull Request 😍😍😍

Te lo dejo aquí:

Bindable layouts

Encontrando la solución

Habíamos visto que el Pull Request se había integrado a la rama principal y la primera opción era actualizar Xamarin.Forms pero vimos que aún no había sido agregado al paquete publicado en nuget entonces quedó descartada esa opción.

Pero gracias a ese Pull Request nos dio la idea básica de crear un control personalizado que tenga las propiedades de ItemsSource e ItemTemplate.

El control personalizado a manera general extiende de StackLayout y tiene dos BindableProperties.

Estas dos BindableProperties son las mismas que tiene un ListView, esto hace pueda recibir una lista de objetos y poder renderizarlas conforme a lo que declaras en el ItemTemplate.

Desde XAML podemos llamarlo como si fuese un ListView pero con todas las propiedades de un StackLayout, cual es la ventaja de eso? Que puedes crear un ListView con scroll horizontal solo cambiando la propiedad Orientation.

Finalmente, en el dispositivo se ve así:

Conclusión:

Bueno, lo que vimos hoy fue un problema que sin saberlo le pasaba a varios y que venía siendo pedido como característica desde el año 2016. Que en sí era poner un ListView dentro de un ScrollView con la posibilidad de deshabilitar la función de Scroll. Vimos que esta será una característica que se agregará en la próxima versión de Xamarin.Forms (3.4), solo para terminar quiero hacer énfasis en lo bueno que es hacer contribuciones de código abierto, esto ayuda a que la plataforma se haga mas robusta y que muchos desarrolladores puedan usar las nuevas características.

Aquí tienes el repositorio oficial de Xamarin.Forms, puedes ver que es de código abierto, es decir, puedes ver, aprender y modificar el código tú mismo.

Nos leemos pronto 😉😉

Hola, hace poco fue el Build 2018, el mayor evento para desarrolladores de Microsoft como se es de esperar en este evento hace lanzamientos de novedades y mejoras en sus plataformas. A mi parecer este año el protagonista fue la Inteligencia Artificial.

Empezando por el acuerdo de Microsoft y DJI para llevar el machine learning a los drones de esa compañía, el lanzamiento de Project Kinect for Azure y lo mejor de todo (a mi parecer) IA for Accessibility un programa que busca aprovechar la IA para crear un mundo más accesible para las personas con discapacidad.

En fin, hay muchos lanzamientos súper buenos en todo el entorno Microsoft. Si te perdiste el evento y los lanzamientos los puedes volver a ver aquí:

Por el lado de Xamarin, finalmente lanzaron la versión 3.0 de Xamarin.Forms la cual trae muchas mejoras y novedades, a mi parecer Xamarin está mejorando cada vez más y esto hace que la pasión que tengo por desarrollar en esta plataforma crezca conforme pasa el tiempo.

Si tú quieres ver las novedades de Xamarin en el Build puedes echarle un ojo a este artículo.

Try the Latest Release of Xamarin.Forms 3.0!

Hoy vamos hablar de una de ellas, seguro ya viste el titulo así que ya te imaginaras cual es… Sí, con Xamarin.Forms 3.0 tenemos la posibilidad de integrar archivos CSS para los estilos de nuestra aplicación, además de la forma ya existente de agregar estilos a nuestra aplicación mediante XAML.

Para ser sinceros esta nueva forma de estilos parecido a las aplicaciones Web, es decir con archivos CSS, viene desde la versión 2.6 en la rama nightly de Xamarin.Forms, pero no estaba tan estable como en la versión 3.0 y no se sabía si iba a ser una característica de esta nueva versión.

Aclaraciones

Para empezar, deben saber que esta forma de usar estilos con archivos CSS aún está en una versión no tan madura por consiguiente no podemos hacer algo más avanzando como con los archivos CSS en entornos Web.

Como esta forma de dar estilos a nuestras aplicaciones está en sus inicios es necesario saber que algunas propiedades y Selectors no son soportados, para tener más claro este tema te dejo dos tablas en las cuales explica que elementos soporta Xamarin.Forms 3.0.

Selectors:

Los siguientes selectors no son soportados:

[attribute]    
@media y @supports    
: y ::

Propiedades

Las siguientes propiedades no son soportadas:

all: initial.

Para los Layout (box o grid).

Propiedades abreviadas, cómo font y border.

Thickness (o el espesor para los margenes)

Esto es parecido a Xamarin.Forms

Un único valor, sería un espesor uniforme (por ejemplo, 2)

Dos valores, indican vertical y horizontal (por ejemplo, 2, 4)

Tres valores, indican el espesor superior, horizontal (izquierda y derecha), inferior (por ejemplo, 3, 4, 5)

Cuatro valores delimitados por comas, indica todos los lados. Sin embargo, los 4 valores están en una secuencia diferente. Arriba, derecha, abajo, izquierda. (por ejemplo, 2, 3, 4, 2) - TRBL en lugar de LTRB.

El nombre de los tamaños.

Estos nombres de los tamaños no son sensibles a mayúsculas y minúsculas:

default
micro
small
medium
large

El valor exacto de cada valor con nombre depende de la plataforma y depende de la vista.

Para encontrar más definiciones como las que te he comentado puedes revisar la documentación oficial por parte de los chicos de Xamarin, aquí también vas a encontrar ejemplos y muchas más novedades:

Styling Xamarin.Forms apps using Cascading Style Sheets (CSS)

Manos al código

Bueno, como es de costumbre yo he hecho un ejemplo para poder demostrar como funciona esta nueva característica de Xamarin.Forms 3.0. Vamos a realizar una pequeña calculadora y le asignaremos los estilos desde un archivo CSS.

Lo primero que haremos será crear un proyecto, vamos a la opción Archivo > Nuevo > Proyecto y elegimos la opción Xamarin.Forms usando .NetStandard

Ahora, para tener más ordenado nuestro proyecto borraremos el archivo MainPage.xaml y crearemos las siguientes carpetas:

En la carpeta Assets será donde podremos nuestros archivos CSS, las demás carpetas ya sabes para que las usamos.

Básicamente lo que explicaré hoy será usar archivos CSS en nuestros proyectos Xamarin.Forms así que la lógica de la aplicación quedará en un segundo plano. Sin embargo, si tú quieres saber la lógica de la aplicación puede encontrar este ejemplo en mi cuenta de GitHub.

Bueno, vamos a crear nuestro archivo CSS para eso vamos hacer clic derecho sobre la carpeta Assets, luego en agregar nuevo elemento y finalmente crear un archivo CSS.

Ahora vamos a escribir unos cuantos estilos para que nuestra aplicación pueda usarlos desde XAML:

Hacer referencia a estos estilos desde nuestro archivo XAML es fácil, solo tenemos que declarar este archivo en los recursos del ContentPage utilizado:

Como ves podemos hacer referencia de nuestros estilos solo dándole un nombre a nuestro control, en este caso tenemos un Label que se llama “result” el cual tomará automáticamente el estilo que hace referencia a él.

<StackLayout HorizontalOptions="EndAndExpand">
     <Label Text="{Binding DisplayOperation}" />
     <Label x:Name="result" Text="{Binding Result}" />
</StackLayout>

Otra forma de aplicar los estilos CSS es asignar la propiedad StyleClass y poner el nombre de nuestro estilo, para este ejemplo hacemos referencia al estilo isClear desde nuestro control tipo Button

<Button Grid.Row="0" CommandParameter="C" StyleClass="isClear" Grid.ColumnSpan="3" Text="C" Command="{Binding ClearCommand}" />

Además de esas dos formas están las más generales que simplemente es poner el nombre del control y automáticamente tomará el estilo al momento de ser creado, por ejemplo, este estilo se asignará a todos los StackPanel donde se haga referencia de este archivo.

Además, podemos aplicar otros estilos a los controles que sean hijos de otros, en el caso de este estilo se aplicará a los Labels que estén dentro de un StackPanel y tomará todas las propiedades declaradas.

Conclusión

Como pudiste ver, hoy Xamarin Forms tiene una forma más flexible de asignarle estilos a nuestras aplicaciones logrando integrar archivos CSS para este fin. En este tutorial pequeño expliqué como se utiliza esta nueva característica de Xamarin Forms en su versión 3.0 y cuales son las limitaciones de momento. Espero que te haya gustado, no te olvides de revisar el código del ejemplo aquí. Nos leemos pronto 😊

Hace unas semanas escribí la primera parte de este tutorial en el que te explico como crear, publicar y configurar un Bot para un restaurante ficticio que tenía traducción automática y se integraba con LUIS, todo esto usando Bot Framework.

Si no leíste el primer tutorial aquí te dejo su enlace:

Integrando Bot Framework con Xamarin.Forms - Parte 1

Hoy, voy a mostrarte como finalmente podemos integrar este Bot que está publicado en Azure con una aplicación Xamarin.Forms, como les adelanté vamos a integrar Bot usando Direct Line como canal de conexión.

Para facilitarnos algunas cosas, vamos a usar algunos complementos para Xamarin.Forms que harán más productiva nuestra codificación, los complementos que uso para este tutorial son:

• Newtonsoft.Json (Para la serialización)
• Plugins.Forms.ButtonCircle (Para mostrar botones circulares con iconos)
• Xam.Plugin.Connectivity (Para verificar la conectividad a internet)
• Xam.Plugin.Settings (Para guardar la sesión)
• Com.Airbnb.Xamarin.Forms.Lottie (Para la animación de carga)

Como lo dije desde un principio, el objetivo de este tutorial es realizar la integración de nuestro Bot ya publicado, con Xamarin.Forms, así que no entraré en demasiados detalles de la estructura de la aplicación, me centraré en las partes más importantes. Si tú no te sientes familiarizado con algo de lo que vas a ver en este tutorial puedes revisar el proyecto en mi repositorio de GitHub o escribirme un tweet directamente, yo estaré muy contento de responder tus dudas.

Empecemos

Lo primero que haremos será crear el servicio que se conectará al canal de nuestro Bot para mantener algunos conceptos básicos de programación vamos a crear una interface y la vamos a implementar en una clase llamada BotService.cs.

En esta interface se llamará IBotService.cs y vamos a declarar dos métodos en ella:

Task<Activity> Connect();
Task<Activity> SendMessage(Activity message);

La clase Activity nos ayudará a serializar los datos recibidos de nuestro canal, si deseas saber cuál es la estructura de esta clase puedes revisar este enlace.

Ahora, la implementación de estos dos métodos se realiza en la clase BotService.cs el primer método que vamos a implementar es Connect();

Este método como su nombre lo dice nos ayudará a conectarnos a nuestro Bot mediante el canal configurado, además, uno de sus objetivos principales es el obtener el primer mensaje que emite nuestro Bot.

Ahora vamos a implementar el método SendMessage(ActivityMessage message);

Este método es el que enviará un mensaje a nuestro Bot y que automáticamente él responderá con un mensaje relacionado a lo enviado.

Configuraciones adicionales

Para una mejor experiencia de usuario vamos a usar Lottie para animación que hace aparentar que nos está escribiendo, para hacer esta animación necesitamos un archivo tipo Json que es generado después de terminar la animación en After Effects.

Si quieres saber más acerca de Lottie puedes revisar la documentación oficial aquí.

Nosotros tenemos un control llamado AnimationView en nuestro archivo ChatView.xaml

Como verás el valor del atributo Animation hace referencia al archivo “loading.json” este archivo tiene diferente ubicación dependiendo del proyecto final.

Android

En nuestro proyecto Android lo tenemos que ubicar en la carpeta Assets

iOS

En nuestro proyecto iOs lo tenemos que ubicar en la carpeta Resources

Ejecutando nuestra aplicación

Finalmente, el resultado de nuestra aplicación es el siguiente:

Android

iOS

Como ves nuestro Bot responde igual como en la primera parte, traduce su respuesta automáticamente y da respuestas con sentido gracias a LUIS.

Conclusión

En esta segunda parte hemos integrado nuestro Bot publicado en la primera parte con Xamarin.Forms, nos hemos centrado en las partes más importantes de la aplicación, así que si tú tienes alguna pregunta no dudes en contactarme por twitter o cualquier otro medio, además, este proyecto está en mi repositorio de GitHub puedes revisar y modificar el código fuente a tu manera. Nos leemos pronto 😁

Hace poco en uno de mis tweets dije que estaba creando un Bot para ayudar a los programadores en dudas o errores que se le presentaban en el camino. El proyecto se está avanzando pueden seguirlo es de código abierto y está en Github.

El día de hoy voy a mostrarles cómo crear un Bot e integrarlo con Xamarin.Forms, de hecho, el objetivo más grande de este tutorial es la integración con tu aplicación móvil.

Lo más fácil sería agregar un control WebView y poner un iframe donde llame al servicio del Bot, pero lo más fácil no siempre es lo más recomendable. La forma de integrar nuestro servicio será mediante DirectLine y un objeto HttpClient para administrar la comunicación con nuestro Bot en Azure.

En esta primera parte vamos a ver la creación de nuestro Bot en Visual Studio, no quería hacer el típico “Hola Mundo” con este Bot así que lo he integrado para que hable varios idiomas y además tenga características de poder “entender” lo que dicen y responder correctamente al integrarlo con LUIS, como dije en un principio el objetivo de este tutorial no es explicar cómo funcionan los Bots o como integrarlos con LUIS o hacer que hable varios idiomas. Tal vez esto puede ser material de un próximo tutorial, pero si tú quieres aprender más acerca de estos temas puedes ver la documentación oficial:

Usando LUIS con plantillas para C#

Guía rápida para Microsoft Translator Text API con C#

Creando nuestros recursos en Azure

Creando nuestro Bot

Lo primero que vamos hacer es crear nuestro Bot en el portal de Azure, para eso vamos a la opción Crear un recurso, luego seleccionamos AI + Cognitive Service y finalmente elegimos la opción Web App Bot.

Aquí llenamos el nombre de nuestro Bot, elegimos nuestra suscripción, elegimos el grupo de recurso y seleccionamos Crear

Lo siguiente, no es lo más recomendable pero como les dije este tutorial se enfoca en cómo integrar el Bot creado en Azure con una aplicación Xamarin.Forms, entonces lo siguiente es descargar el código fuente de nuestro Bot recién creado, para eso dentro de nuestro Bot en Azure vamos a la opción Build y luego Descargar archivo zip y lo guardaremos para el siguiente paso.

Creando nuestra API de traducción

Como dije líneas arriba será un Bot que hable varios idiomas, es por eso que vamos a necesitar una API que haga esa función, maravillosamente Microsoft ha creado todos esos servicios para poder usarlo en nuestras aplicaciones y así darles un valor agregado.

Para crear nuestra API de traducción vamos a la opción Crear un recurso, vamos a la opción buscar y copiamos “Translator Text API” para poder acceder a este recurso. Y luego en Crear

Ahora simplemente ponle un nombre con sentido, elige tu suscripción, elige el plan que deseas y elige el grupo de recurso o crea uno nuevo.

Ahora para culminar con el portal de Azure ingresamos a nuestro nuevo recurso creado, luego a la opción Claves y copiamos la primera clave para luego utilizarla en la lógica de nuestro Bot.

A codificar

Vamos a abrir el proyecto que habíamos descargado del portal de Azure, la estructura del proyecto es muy similar a la de cualquier proyecto en Visual Studio.

Ahora, como para sentirnos poderosos vamos a ejecutar el proyecto, solo presionamos F5 y se ejecutará un proyecto tipo Web. Recuerda que nuestro Bot funcionará como una WebAPI entonces es necesario levantar un servicio web.

Para probar nuestro Bot no solo es necesario ejecutarlo en Visual Studio, sino también probar el servicio en un emulador. Afortunadamente este emulador está disponible para su descarga gratuita, tú puedes descargarlo aquí.

Una vez iniciado el emulador tenemos que colocar una url valida que sea la de nuestro Bot.

Una vez tengamos la URL de nuestro Bot le colocamos el sufijo api/messages para poder acceder a la API de los mensajes. Y a continuación le damos a Conectar

Esta es la plantilla básica que descargamos del portal de Azure así que por ahora nuestro Bot responde con la típica respuesta de “Dijiste:” seguido de lo que le escribimos.

Ahora vamos a hacer que nuestro Bot salude primero al momento de conectarnos a la conversación, para eso en nuestra clase MessageController.cs en el método HandleSystemMessage en la condición donde compara:

if (message.Type == ActivityTypes.ConversationUpdate)

Escribimos lo siguiente:

Ahora vamos a probar lo que agregamos, presionamos F5 y vamos a nuestro emulador.

Vean que el primer mensaje lo manda nuestro Bot, con las líneas de código que agregamos en el paso anterior.

Dando vida a nuestro Bot

Si eres lector de este blog desde hacer tiempo notarás que a mí siempre me gusta estructurar mi proyecto para llevar un mejor orden así que vamos hacer eso.

Para empezar, vamos a eliminar la clase llamada EchoDialog.cs ubicada en la carpeta Dialogs ya que nosotros usaremos una llamada RootDialog que será la que responda según el resultado de nuestro análisis con LUIS.

También vamos a crear algunas carpetas y clases adicionales:

Extensions -> StringExtension.cs
Helpers -> ChatReponse.cs
Models -> AddressKey.cs
Service -> TranslateService.cs

La estructura de nuestro proyecto quedará así:

Bot multilenguaje

Voy hacer este post un poco resumido ya que es un poco extenso, solo explicaré las partes más importantes de nuestro Bot. Bueno, primero como habla varios idiomas.

Toda la lógica de esta característica está en la clase TranslateService.cs y su principal función es consumir los servicios de la API de traducción de Azure (la cual creamos en los pasos anteriores).

Basicamente, tiene dos métodos principales: TranslateAsync() y DeterminLanguageAsync()

El método de traducción lo que hace es hacer un request a la API de traducción de Azure enviando como parámetros el texto, el idioma de origen y el idioma destino. Al recibir una respuesta leemos el contenido que viene en formato XML y del cual extraemos el String.

El método para determinar hace prácticamente lo mismo solo con la diferencia que se cambiar la URL a la que se hace la petición.

Integración con LUIS

Bot Framework ya nos da varias facilidades para poder integrarle LUIS a nuestro Bot. Para esta integración simple vamos a crear una clase llamada RootDialog.cs que dará una respuesta traducida según la clasificación que haga con los intentos creados.

Yo te voy a dejar el archivo json de mi proyecto en LUIS para que tu solo lo importes y lo empieces a usar, tú puedes acceder al archivo aquí.

Este es un método dentro de la clase RootDialog que según la calificación que responde LUIS nosotros podemos dar una respuesta adecuada. Es una forma sencilla de integrar LUIS a nuestro Bot, pero para empezar está más que bien.

Probar y conversar

Como verás el idioma por defecto de nuestro Bot es inglés, yo recomiendo crear el suyo en este idioma ya que es más simple que el castellano.

Si te fijas nuestro Bot traduce automáticamente su respuesta al idioma que le hablamos.

También a chino

Y también en idiomas combinados.

Activación el DirectLine de nuestro Bot

Para activar esta característica que nos permitirá integrar nuestro Bot en nuestra aplicación en Xamarin.Forms tenemos que regresar al portal, seleccionar nuestro Bot, seleccionar la opción Canales y luego la opción DirecLine

Aquí es donde estarán nuestras credenciales de acceso, simplemente aceptamos y listo, nuestro Bot ya está creado y habilitado para ser consumido desde una aplicación desarrollada con Xamarin.Forms.

Conclusión

Cómo has visto en esta primera parte te muestro como crear el Bot e integrarlo con unos servicios de Azure como el de traducción y el de LUIS. En la segunda parte integraremos nuestro Bot con una aplicación Xamarin.Forms, espero que les haya gustado. Recuerda que puedes encontrar el código de este post en mi cuenta de Github. Nos leemos pronto. 😊

Hola de nuevo, hace unas semanas escribí un artículo sobre un NavigationPage personalizado, para ser más específico que el fondo de la barra de navegación sea gradiente. Aquí expliqué como usar los Custom Renderers y definición bien básica de cómo funciona y en qué casos usarlos.

Si quieres leerle el artículo anterior lo puedes hacer aquí:

Personalizando un NavigationBar en Xamarin.Forms

En este articulo voy a mostrar cómo cambiar el icono de un control MasterDetail. Un control de este tipo es muy usado desde hace bastante tiempo atrás, es básicamente un menú, el menú hamburguesa…

Este menú es muy usado en muchas aplicaciones móviles y su funcionamiento radica en un menú desplegable de izquierda a derecha accionado por un botón en la parte superior izquierda (algunas veces derecha) del teléfono.

Lo que hoy haremos es personalizar el botón que muestra el menú, la verdad no sé si esto sea un bug en Xamarin Forms o esté configurado así, pero en teoría podríamos modificar la imagen de este botón desde nuestro archivo XAML en nuestro proyecto compartido.

En fin, si tú sabes cuál es la causa de este extraño caso no dudes en dejar un comentario para poder actualizar este artículo.

Manos al código

Empezaremos creando un MasterDetailPage de la siguiente forma:

<?xml version="1.0" encoding="utf-8" ?>
<MasterDetailPage  xmlns="http://xamarin.com/schemas/2014/forms"
         xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
         xmlns:local="clr-namespace:CustomIcon.Views;assembly=CustomIcon"
         Title="MainPage"
         Icon="newIcon.png"
         x:Class="CustomIcon.Views.MainPage">
    <MasterDetailPage.Master>
        <local:MasterPage x:Name="masterPage" />
    </MasterDetailPage.Master>
    <MasterDetailPage.Detail>
        <NavigationPage>
            <x:Arguments>
                <local:Page1 />
            </x:Arguments>
        </NavigationPage>
    </MasterDetailPage.Detail>
</MasterDetailPage>

Recuerda que este no es un tutorial de cómo crear un menú MasterDetail sino de como personalizar su icono así que voy a explicar cosas que tal vez no entiendas si estás iniciando con Xamarin Forms. Recuerda que puedes revisar el código de este ejemplo en Github si quiere saber cómo se ha creado este ejemplo.

Al tener creado nuestro control MasterDetail ahora podemos personalizar nuestro icono.

Android

En Android tienes que crear un Custom Renderer que extienda de MasterDetailPageRenderer e invocar a un ExportRenderer haciendo referencia a nuestra página principal, es decir la que tiene el control MasterDetail.

Ahora tenemos que sobre escribir el método OnLayout para poder reemplazar el icono, obtener el Toolbar y luego iterar entre todos los iconos que tenga y poner asignar la imagen que nosotros querramos.

Finalmente, nuestro control MasterDetail queda así:

#iOS

En teoría en iOS debería funcionar sin agregar ningún Custom Renderer, ya que iOS agrega la imagen que le asignamos en nuestro archivo MasterDetail.xaml pero extrañamente el mismo sistema operativo asigna el color a la imagen.

De hecho, eso no es lo que queremos para eso tenemos que crear un Custom Renderer que extienda de PhoneMasterDetailRenderer e invocar a un ExportRenderer haciendo referencia a nuestra página principal, es decir la que tiene el control MasterDetail.

Ahora tenemos que sobre escribir el método ViewDidLayoutSubviews para poder reemplazar el icono.

Finalmente, nuestro control MasterDetail queda así:

Conclusión

Bueno, esto ha sido un artículo super corto, pero creo que muy útil donde mostré como cambiar el icono hamburguesa de un control MasterDetailPage usando los Custom Renderer. Recuerda que este ejemplo lo puedes encontrar en mi repositorio de Github. Nos leemos pronto, sigan xamarineando. 😎

Esto articulo nace a partir de una pregunta en StackOverflow, normalmente yo entro al finalizar mi día a esta página de preguntas y respuesta donde de vez en cuando doy algunas sugerencias.

Hace unos días surgió una pregunta por un usuario en este portal, básicamente la ayuda que necesitaba era que quería saber cómo personalizar el NavigationBar de una aplicación Xamarin.Forms para Android y iOS. Este control también es conocido como AppBar en Android y UINavigationBar en iOS y este usuario necesitaba que quede de esta manera:

Lo primero que se nos debe venir a la mente cuando queremos personalizar un control en Xamarin.Forms es usar los Custom Renderers, esto te permite cambiar la apariencia y el comportamiento de los controles en cada plataforma.

Recuerda que las interfaces de usuario en Xamarin.Forms se representan con los controles nativos de la plataforma de destino, lo que permite que las aplicaciones de Xamarin.Forms conserven el aspecto para cada plataforma.

Los Custom Renderers permiten a los desarrolladores anular este proceso para personalizar el aspecto y el comportamiento de los controles de Xamarin.Forms en cada plataforma.

Bueno ahora que ya sabes algo básico acerca de los Custom Renderers es hora de aprender cómo se utilizan y que fue lo que hice para solucionar el problema de este usuario.

Manos a la obra

Lo primero que tenemos que hacer es crear una clase para este ejemplo le pondremos NavigationPageGradientHeader, esta clase que nosotros creamos tendrá que extender del control que queramos personalizar, en mi caso extenderá del control NavigationPage.

Ahora crearemos las BindableProperties que serán las encargadas de hacer Binding a los valores que nosotros referenciemos, un BindableProperty tiene la siguiente estructura:

propertyName: Es la propiedad a la cual hará referencia para asignar o retornar algún valor. En mi caso yo tengo dos propiedades una llamada RightColor que será el color con el cual comenzará el gradiente y LeftRight con el cual terminará.

returnType: Será el tipo de dato que retornará está propiedad, en nuestro caso será un tipo de la clase Xamarin.Forms.Color, pero si estás necesitas retornar cualquier otro tipo de dato puedes hacerlo.

declaringType: Es la clase donde se está declarando esta BindableProperty en este caso será la misma clase donde estamos, pero podemos declarar BindableProperties fuera de la clase y referenciarla por su nombre.

defaultValue: Es el valor por defecto que tendrá nuestra BindableProperty, como nuestro tipo de dato de retorno es de tipo Color, nuestro valor por defecto tendrá que ser del mismo tipo de dato.  En mi caso le puse Red.

Ahora creamos las propiedades que harán referencia nuestra BindableProperty ya sea para asignar u obtener el valor de esa propiedad.

Finalmente, nuestra clase queda de la siguiente manera:

Personalizando el control según la plataforma

Como te comenté líneas arriba un Custom Renderer permite cambiar la apariencia y el comportamiento de los controles en cada plataforma, este ejemplo está destinado solo para Android y iOS. No lo he hecho para UWP por dos razones, dejé de desarrollar hace mucho para UWP y no conozco mucho sus APIs y debido al primer motivo no sé ni por dónde empezar para personalizar el NavigationBar en UWP.

Ustedes pueden colaborar haciendo este que control personalizado soporte UWP enviando algún pull request al repositorio de Github.

Android

En Android es un tanto tedioso cambiar el control ActionBar, debido a que desde algunas actualizaciones la clase MainActivity extiende de FormsAppCompatActivity y esto de por sí ya tiene una propiedad llamada ToolbarResource la cual hace el típico SetActionBar() entonces crear una clase Renderer que extienda de PageRenderer sería inútil ya que no veríamos ningún cambio.

Para esto debemos crear un drawable llamado grandient.xml donde pondremos un shape que tenga el grandiente, este drawable tendrá la siguiente estructura:

Ahora solo en nuestro archivo Toolbar.axml ubicado en la carpeta layout haremos referencia a este drawable, finalmente nuestro Toolbar que de la siguiente manera:

Esto hará que nuestro ActionBar en Android se vea de esta forma:

iOS

En iOS es diferente y sí funciona lo de agregar un Renderer que extienda de PageRenderer en esta clase lo que haremos es crear un GradientLayer que será el que dará el efecto de gradiente a nuestro NavigationBar.

A este GradientLayer le vamos asignar los colores que serán asignados en nuestra PCL, para esto convertimos la propiedad Element en un objeto de nuestra clase principal y luego de eso solo llamamos a las propiedades correspondientes en nuestro caso RightColor y LeftColor. Recuerda que estás propiedades son del tipo de dato Xamarin.Forms.Color y el GradientLayer recibe el tipo CGColor, lo único que tenemos que hacer es invocar al método ToCGColor(), así de fácil podemos convertir nuestro tipo de dato de Xamarin.Forms a la plataforma nativa. Xamarin es maravilloso!

Ahora convertimos este GradientLayer a imagen y asignamos esta imagen a nuestro NavigationBar.

Esto hará que nuestro UINavigationBar se vea de esta forma:

Proyecto compartido

Debido a que este es un control que extiende de NavigationPage nosotros debemos de invocar a este control en nuestro archivo App.xaml.cs:

Conclusión

Bueno, este es un micro post que nació de una pregunta en StackOverflow, te expliqué un concepto básico de los Custom Renderers y como es la implementación en cada plataforma.

Recuerda que el código de este ejemplo está en mi repositorio de Github.

Además la pregunta de StackOverflow que hago referencia en este articulo la puedes encontrar aquí:

How to Add a Gradient in Xamarin forms Toolbar and UINavigationBar

El día de hoy voy a explicar de manera sencilla como crear botones circulares en Xamarin.Forms incluyendo un icono.

Yo vengo desarrollando apps desde hace mucho, con Xamarin desde hace algún tiempo y he tenido algunos proyectos en los cuales los diseñadores necesitaban este tipo de botones y yo como desarrollador tenía que ingeniármelas para lograr esos requerimientos. De hecho, muchos de ustedes son usuarios de aplicaciones móviles y de seguro han visto mucho de estos botones en las aplicaciones que usan.

Vamos a utilizar un control llamado ButtonCircle que de hecho fue creado por mí, como les comenté he tenido que ingeniármelas para realizar esa petición de los botones circulares que pedía el equipo de diseño. Es por eso que como buen desarrollador que piensa en los demás y no quiere que los demás sufran decidí crear este control para Xamarin.Form.

Para crear este control me basé en otro que tiene las mismas características, este control es ImageCircle creado por James Montemagno, pero aparte de la característica circular necesitaba que tenga un icono dentro del botón. Es por eso que vi la forma de utilizar una fuente de iconos creada por Google y que está a disposición de todos, y bueno básicamente lo que hice fue aplicar esta fuente al texto de nuestro botón.

En fin, si ustedes quieren revisar el código fuente de este control puedes revisar mi perfil de Github o ir directamente al repositorio de este control.

A codificar

Bueno, crear botones circulares ahora es más fácil usando este control. Al menos ya cumplí uno de mis primeros objetivos que era facilitarle la vida a los demás.

Lo primero que vamos hacer es crear un proyecto en Visual Studio.

Como siempre, la ruta es: Archivo -> Nuevo -> Proyecto en la ventana que aparece vamos a crear un proyecto de tipo Aplicación multiplataforma en este caso le vamos a poner como nombre “CircularButtonSample”, pero en tu caso puedes ponerle el nombre que quieras o simplemente agregar a un proyecto ya existente.

En la ventana siguiente lo único que tenemos que hacer es elegir si deseamos una aplicación en blanco o una de las plantillas, si deseamos Xamarin.Forms o una aplicación nativa, y si deseamos un proyecto compartido o una biblioteca de clases portable (PCL).

En este caso vamos a elegir lo que vemos en la imagen:

Ahora vamos a descargar e instalar el control creado, este control está disponible en nuget para que ustedes lo puedan descargar.

Hacemos clic derecho sobre nuestra solución y luego vamos a Administrar paquetes Nuget para la solución, ahora en la opción Navegar vamos a buscar el control “ButtonCircle”.

Selecciona las plataformas de destino que desees.

Una vez instalado podemos usar este control, en nuestra biblioteca de clases portable (PCL) vamos agregar un espacio de nombre en el archivo MainPage.xaml

Una vez agregado este espacio de nombre podemos empezar a utilizar nuestro control en este archivo que representa a la vista.

Ahora usamos el alias que le hemos puesto, en este caso “circularButton” para acceder a las propiedades de nuestro control.

Como puedes observar nuestro control tiene una propiedad llamada Icon la cual es la encargada de renderizar el icono que deseamos mostrar, para esto nosotros le pasamos el nombre del icono en formato String y el control se encargará de renderizar la figura.

La lista de nombres de los iconos está disponible aquí para que puedas usar los que más se apeguen a tus necesidades.

También puedes usar este control con la propiedad Text por si quieres solo mostrar texto en un botón circular.

Esta característica la agregó Austin Grigg en el siguiente pull request, pero con una pequeña falla que no mostraba los iconos cuando no asignábamos la propiedad Text. He solucionado ese problema agregando a la lista de iconos uno con el nombre ic_default que es icono en blanco y que la verificar el icono renderiza el texto como se debe hacer.

Es por eso que como ves en el ejemplo se puede obviar la propiedad Icon y solo usar la propiedad Text y viceversa, en ambos casos funciona bien.

Configuración de Android

Para poder renderizar este control en Android es necesario llamar al método Init() dentro de la clase MainActivity en el método OnCreate antes de llamar al método Init() de Xamarin.Forms.

protected override void OnCreate(Bundle bundle)
{
    TabLayoutResource = Resource.Layout.Tabbar;
    ToolbarResource = Resource.Layout.Toolbar;

    base.OnCreate(bundle);

    ButtonCircle.FormsPlugin.iOS.ButtonCircleRenderer.Init();
    
    global::Xamarin.Forms.Forms.Init(this, bundle);
    LoadApplication(new App());
}

Configuración en iOS

Al igual que en Android nosotros tenemos que llamar al método Init() dentro de la clase AppDelegate en el método FinishedLaunching antes de llamar al método Init() de Xamarin.Forms

public override bool FinishedLaunching(UIApplication app, NSDictionary options)
{
    global::Xamarin.Forms.Forms.Init();
    LoadApplication(new App());
    ButtonCircle.FormsPlugin.iOS.ButtonCircleRenderer.Init();
    return base.FinishedLaunching(app, options);
}

Además de hacer esto en iOS tenemos que hacer algo adicional, lo que tenemos que hacer es declarar la fuente que vamos usar para los iconos, si bien es cierto el formato .ttf de la fuente viene incluido en este Plugin en iOS es necesario declararlo agregando una llave en el archivo Info.plist de la siguiente manera:

<array>
  <string>materialicons.ttf</string>
  <string>fontawesome.ttf</string>
</array>

Demostración

Android

iOS

Windows

Algunos problemas

En Android 6.0 hay un problema de renderizado, esto lo reportó NGame1 hace unas semanas. La solución para esto es agregar la propiedad “BorderRadius” y asignar el mismo valor que la altura del botón.  Algo parecido a esto:

<local:CircleButton Icon="ic_directions_bike" 
                    FontSize="30" TextColor="Black"
                    HeightRequest="70" WidthRequest="70" 
                    BorderRadius="70" BackgroundColor="#DCDCDC"/>
<!--This button is not exactly circular-->
<local:CircleButton FontSize="30" TextColor="Black" 
                    HeightRequest="70" WidthRequest="200" 
                    BorderRadius="20" BackgroundColor="#DCDCDC"/>

Esta propiedad permite botones que no sean exactamente circulares como se ve en esta imagen.

Conclusión

Bueno, el tutorial de hoy fue algo pequeño. Básicamente les mostré como usar este plugin que creé hace poco, voy a estar muy contento si es que ustedes le hacen alguna mejora a este plugin, me gustaría agregar más tipos de iconos, poner iconos y textos a la vez y varias cosas más. Esperaré muy contento sus pull request. Al igual si tienen algún problema con el plugin repórtenlo en el repositorio de Github estaré encantando de darle una solución. Nos leemos pronto ❤