Parte de la presentación que hice en línea a alumnos de la carrera de Ingeniería en Sistemas Computacionales del Tecnológico Nacional de México en Celaya (asignatura: Desarrollo de Aplicaciones para Dispositivos Móviles). Temas: * Dependency Service * Custom Renderers * Effects * Styles

1. Tópicos Selectos de Xamarin
Dependency Service, Custom Renderer, Effects y Styles
Luis Beltrán
@darkicebeam
luis@luisbeltran.mx
luis.beltran@itcelaya.edu.mx

2. • Mexicano
• Microsoft MVP en Developer Technologies
• Xamarin Certified Mobile Developer
• Estudiante de doctorado en la Universidad
Tomas Bata en Zlin (República Checa)
• Docente en el Tecnológico Nacional de México
en Celaya.
luisbeltran.mx
Luis Beltrán

3. • Xamarin.Forms es una plataforma increíble para crear aplicaciones
móviles que funcionan en Android, iOS y Windows.
• De una manera ágil y dinámica, utilizamos un solo lenguaje para la
funcionalidad (C#) y para el diseño (XAML, o también C#) de manera
tal que el código de la lógica es compartido por los proyectos y los
elementos visuales se mapean a elementos nativos y
comportamientos propios de cada plataforma.
• ¿Podemos extender Xamarin.Forms en caso de ser necesario? Las
necesidades de extensión incluyen:
• Modificar aspectos de la UI.
• Aprovechar a fondo las capacidades que nos ofrece cada plataforma.
• Crear nuevos controles o páginas.

4. Dependency Service
Accediendo a funcionalidad nativa con Xamarin.Forms
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/dependency-service/

5. • Cada plataforma expone funcionalidad importante (y en ocasiones
crítica) que no es directamente accesible desde el API de alto nivel
en Forms. Por ejemplo:
• Acceso a la cámara
• Notificaciones locales
• Uso de sensores (GPS, batería, …)
• Etc.
• Conceptos como Dependency Injection y Dependency Service llegan
al rescate para extender la funcionalidad de nuestras apps móviles
desarrolladas en Xamarin.Forms ☺
Justificación

6. Dependency Service
• Es una técnica que permite a las
apps acceder a funcionalidad
específica de plataforma desde el
código compartido.
• De esta manera, los desarrolladores
pueden crear apps que hagan todo
lo que una app nativa puede hacer
exponiendo un servicio que
encuentra una implementación
específica de una interfaz.

7. ¿Cómo funciona?
Se requieren 4 componentes para utilizar Dependency Service:
• Interfaz. La funcionalidad requerida es definida a través de una interfaz en el
proyecto de código compartido.
• Implementación por cada plataforma. Las clases que implementan la interfaz
deben ser agregadas en cada proyecto de plataforma.
• Registro. Cada clase implementada debe ser registrada con Dependency Service
a través de un atributo de metadatos. El registro permite a encontrar la clase a
implementar y suministrarla en lugar de la interfaz en tiempo de ejecución.
• Llamada al Dependency Service. El código compartido necesita llamar
explícitamente a Dependency Service para preguntar por implementaciones de
la interfaz.

9. 1) Interfaz (en el código compartido)
2) Implementación
(proyecto de Android)
3) Registro (atributo en el namespace)
4) Llamada (en el código compartido)

11. 2) Implementación (proyecto de iOS)
3) Registro (atributo en el namespace)
2) Implementación
(proyecto de UWP)
3) Registro (atributo en el namespace y
en App.xaml.cs después de Forms.Init)

12. Demo
https://github.com/icebeam7/DirectorioTecNMCelaya

13. Custom Renderers
Personalización de la apariencia y comportamiento de controles en cada plataforma
https://docs.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/custom-renderer/

14. Justificación
• Las interfaces de usuario en Xamarin.Forms son renderizadas
utilizando los controles nativos de cada plataforma, de manera que
las apps retienen una apariencia y experiencia de usuario natural
(look & feel).

15. Justificación
• En ocasiones, sin embargo, se necesita personalizar la apariencia y el
comportamiento de la interfaz de usuario por ejemplo para
incrementar la funcionalidad de algún control o estandarizar el
diseño de la UI en las diferentes plataformas.
• Custom Renderers permite sobrescribir el proceso predeterminado
de renderizado de la UI realizado por Xamarin.Forms para diseñar
controles personalizados en cada plataforma.

16. Custom Renderer
• Es una extensión de Xamarin.Forms con la
cual los desarrolladores pueden implementar
sus propias clases Renderer personalizadas
para individualizar la apariencia y/o el
comportamiento de un control.
• Utilizarlos permite sacar mejor provecho a
las mejoras y personalizaciones que ofrece
cada plataforma de manera específica.

17. ¿Cómo funciona?
Para utilizar Custom Renderers se requieren 4 componentes:
• En el código compartido se crea un nuevo control Xamarin.Forms derivado de:
• Un control existente
• View (si es un nuevo tipo de control)
• Por cada plataforma se crea un view renderer donde se sobrescribe el evento
OnElementChanged. Utiliza:
• Un renderer existente como clase base para personalizar un control ya existente
• ViewRenderer<TView, TNative> (para crear un nuevo estilo de control).
• Asociar el renderer al control a través del atributo [ExportRenderer]
• Utilizar el control personalizado en el código de proyecto compartido.

19. 1) Nuevo control (en el código compartido)
2) Renderer (proyecto de iOS)
3) Asociación (atributo en el namespace)
4) Uso (en el código compartido)

20. 2) Renderer (proyecto de Android)
3) Asociación (atributo en el namespace)
2) Renderer (proyecto de UWP)
3) Asociación (atributo en el namespace)

21. OnElementChanged
• Element proporciona una referencia al nivel del control de
Xamarin.Forms.
• NewElement contiene una referencia al control de Xamarin.Forms
• OldElement contiene una referencia al renderer asociado al control de
Xamarin.Forms
• Control proporciona un enlace al nivel de controles nativos. Sus
propiedades son las que se “inyectan” con los nuevos valores.

22. Demo

23. Effects
Una manera ligera de personalizar la apariencia de controles por plataforma

24. Justificación
• Implementar un Custom Renderer para realizar un cambio muy
simple al personalizar el diseño de un control es con frecuencia una
tarea que puede impactar el tiempo de respuesta de una UI.
• Cuando se desea implementar cambios sencillos en los estilos de un
control a través de las diversas plataformas se recomienda utilizar
Effects debido a que simplifican el proceso de implementación y el
tiempo de carga de la UI se ve beneficiado.

25. Effects
• Los Effects permiten personalizar la
apariencia de un control nativo sin la
necesidad de implementar un Custom
Renderer, simplificando el proceso.
• Normalmente son utilizados para realizar
pequeños cambios en los estilos de un
control.
• Además, son reutilizables y pueden ser
parametrizados y así aumentar su nivel de
reutilización.

26. Effects
• Todo lo que se puede lograr con un Effect también se puede
implementar a través de un Custom Renderer, si bien estos últimos
ofrecen más flexibilidad y configuración.
• Los Custom Renderers son ideales cuando se desea personalizar de
forma profunda la UI en cada plataforma.

27. ¿Cómo funciona?
Para utilizar Effects se requieren 2 componentes:
• Crear un efecto en cada plataforma objetivo a través de una clase que hereda de
PlatformEffect. Se sobrescriben 2 métodos:
• OnAttached: llamado cuando un efecto se adjunta a un control de Xamarin.Forms y aquí se
personaliza el control y se manejan excepciones en caso de que el efecto no se pueda aplicar
al elemento especificado.
• OnDetached: llamado cuando un efecto se separa de un control de Xamarin.Forms y aquí se
realiza la limpieza de efectos (por ejemplo, resetear valores o anular el registro del elemento
de un controlador de eventos).
• Registrar el efecto con los atributos ResolutionGroupName y ExportEffect
• Consumir el efecto adjuntándolo en el control de Xamarin.Forms apropiado en el
proyecto compartido.

29. 1) Efecto (proyecto de Android)
2) Registro (atributos en el namespace)
1) Efecto (proyecto de iOS)
4) Consumo (proyecto compartido)

30. 1) Efecto (proyecto de UWP)
2) Registro (atributos en el namespace)

31. Demo

32. Styles

33. Justificación
• Con frecuencia, las aplicaciones de Xamarin.Forms contienen múltiples
controles que deben tener una apariencia idéntica a lo largo de la app.
• Configurar la apariencia de cada control de forma individual es una
tarea repetitiva y propensa a errores.
• Definiendo un Style es posible personalizar la apariencia de la UI
agrupando y configurando las propiedades disponibles en los diversos
tipos de control visual.

34. Styles
• Permiten personalizar la apariencia de los
elementos visuales. Se definen para un tipo
específico y contienen valores para las
propiedades disponibles en ese tipo.
• La clase Style agrupa una colección de
valores de propiedad en un objeto que luego
puede aplicarse a múltiples instancias de
elementos visuales, reduciendo la repetición
de código XAML (o de C#) y simplificando el
cambio de apariencia en una app móvil.

35. • Las instancias Style creadas en XAML se definen típicamente en un
ResourceDictionary que es asignado a la colección de Resources de
un control, página o a la colección Resources de la aplicación.
• Las instancias Style creadas en C# se definen típicamente en la clase
de la página o en una clase accesible globalmente.
• La ubicación de un estilo define su alcance:
• Los estilos definidos a nivel de control sólo se aplican al control y a sus
elementos secundarios (children).
• Los estilos definidos a nivel de página sólo se aplican a la página y a sus
elementos secundarios (children).
• Los estilos definidos a nivel de aplicación se aplican en toda la aplicación.

36. • Al definir un Style siempre se debe especificar un TargetType, que no es
otra cosa más que el control al cual se aplicará el estilo.
• Cada instancia de Style contiene una colección de uno o más objetos
Setter, cada uno de los cuales contiene un Property y un Value asignado.
• La Property es el nombre de una propiedad enlazable al elemento del cual
se está aplicando el estilo, mientras que el Value es el valor aplicado a la
propiedad.
• Para aplicar un estilo previamente creado, se asigna la propiedad Style de
un control.

37. • Los estilos inferiores en la jerarquía de vistas tienen prioridad sobre
aquellos definidos en una capa superior.
• Por ejemplo, configurar un estilo que establece Label.TextColor en Red a
nivel de aplicación será anulado por un estilo a nivel de página que
establece Label.TextColor en Green.
• De manera similar, un estilo a nivel de página será reemplazado por un
estilo a nivel de control.
• Además, asignar directamente un valor para TextColor en el control Label
tendrá prioridad sobre cualquier estilo.

38. ¿Qué opciones hay para definir estilos?
Existen varios tipos de estilos disponibles en Xamarin.Forms:
• Estilos explícitos
• Estilos implícitos
• Estilos globales
• Estilos heredados
• Estilos dinámicos
• Estilos de dispositivo

39. Estilos explícitos
• Son estilos aplicados selectivamente a un control a
través del atributo x:Key.

40. Estilos implícitos
• Son estilos utilizados por todos los controles con el
mismo TargetType, por lo que no se require que
cada control haga referencia al estilo.

41. Estilos globales
• Son estilos definidos en el diccionario de recursos
de la aplicación, lo que los hace accesibles a toda la
app y evitando duplicidad de estilos a lo largo de las
páginas o controles.

42. Estilos heredados
• Los estilos son capaces de reutilizar otros estilos a
través de la herencia para definir una apariencia
más personalizada a través del atributo BasedOn.

43. Cadena de Herencia:
• Un estilo solo puede heredarse de estilos en el mismo nivel o superior
en la jerarquía de vistas. Esto significa que:
• Un recurso de nivel de aplicación solo puede heredar de otros recursos de
nivel de aplicación.
• Un recurso de nivel de página puede heredar de los recursos de nivel de
aplicación y otros recursos de nivel de página.
• Un recurso de nivel de control puede heredar de recursos de nivel de
aplicación, recursos de nivel de página y otros recursos de nivel de control.

44. Estilos dinámicos
• De forma predeterminada, los estilos no
responden a los cambios en los valores
de las propiedades y permanecen
estáticos durante la ejecución de una
app. Esta limitación se puede eliminar a
través de los recursos dinámicos.

46. Estilos de dispositivo
• Xamarin.Forms incluye 6 estilos dinámicos
conocidos como estilos de dispositivo en la clase
Device.Styles. Sólo son aplicables a controles Label.
• BodyStyle
• CaptionStyle
• ListItemDetailTextStyle
• ListItemTextStyle
• SubtitleStyle
• TitleStyle

47. Demo

48. https://www.facebook.com/groups/xamarindiplomadoitc/
https://www.meetup.com/CelayaMobileDevelopers/
https://university.xamarin.com/

49. Tópicos Selectos de Xamarin
Dependency Service, Custom Renderer, Effects y Styles
Luis Beltrán
@darkicebeam
luis@luisbeltran.mx
luis.beltran@itcelaya.edu.mx
¡Muchas gracias por
tu atención!