MODULO 1

Acerca del módulo

En este módulo se presenta una introducción a Xamarin.Forms y sus objetivos. Se describen las
herramientas de desarrollo requeridas y la estructura de una solución Xamarin.Forms incluyendo los
proyectos de cada plataforma y sus valores de configuración más importantes. Se muestra la forma
de iniciar una aplicación para depuración utilizando emuladores y la aplicación Xamarin Live
Player.
En este módulo se describen las estrategias para compartir código que Xamarin.Forms puede utilizar
para compartir archivos de la interfaz de usuario y código independiente de la plataforma.
El módulo finaliza describiendo la forma de construir la interfaz de usuario mediante código XAML
basándose en una jerarquía de elementos visuales.
Objetivos
Al finalizar este módulo, los participantes contarán con las habilidades y conocimientos para:

 Describir qué es Xamarin.

 Describir qué es Xamarin.Forms.
 Configurar el entorno de desarrollo de aplicaciones Xamarin.Forms.
 Crear soluciones Xamarin.Forms.
 Depurar y probar la ejecución de aplicaciones en el entorno de desarrollo.
 Describir las distintas estrategias para compartir código.
 Construir interfaces de usuario básicas de aplicaciones Xamarin.Forms.
Los temas que se cubren en este módulo son:
 Lección 1: Introducción.
 Lección 2: Creando soluciones Xamarin.Forms.
 Lección 3: Depurando y probando aplicaciones localmente.
 Lección 4: Compartiendo código entre plataformas.
 Lección 5: Construyendo la interfaz de usuario.
Lección 1: Introducción
En esta lección se presenta una introducción a Xamarin y Xamarin.Forms, se presenta también
información necesaria para configurar el ambiente de desarrollo en un equipo Windows e
información necesaria para configurar un equipo Mac requerido para desarrollar aplicaciones iOS.
Objetivos de la lección
Al finalizar esta lección, los participantes podrán:
 Describir qué es Xamarin.
 Describir qué es Xamarin.Forms.
 Configurar un ambiente de desarrollo de aplicaciones Xamarin.Forms con Visual Studio
sobre Windows 10.
 Configurar un equipo Mac para desarrollar aplicaciones iOS.
Introducción a Xamarin

En la actualidad, predominan dos plataformas móviles de tabletas y teléfonos inteligentes:

 La familia Apple de teléfonos iPhone y de tabletas iPad, todos ellos ejecutando el sistema
operativo iOS.

 El sistema operativo Android desarrollado por Google y que está basado en el Kernel de
Linux ejecutándose en una variedad de teléfonos y tabletas.

Otra plataforma de desarrollo, aunque no es tan influyente en el mundo móvil es Windows 10.
Windows 10 nos permite desarrollar aplicaciones para dispositivos IoT, tabletas y de escritorio. En
los últimos años, Microsoft ha estado unificando las APIs de sus plataformas. Los dispositivos
Windows 10 están basados en la Plataforma Universal de Windows (Universal Windows Platform –
UWP) donde una única aplicación UWP puede ser desplegada en distintos tamaños de pantalla.

Para los desarrolladores de software, la estrategia optima es desarrollar para varias plataformas en
lugar de desarrollar para una sola plataforma. Sin embargo, esta no es una tarea fácil ya que existen
4 obstáculos principales a los que los desarrolladores de aplicaciones multiplataforma deben
enfrentarse:

1. Diferentes paradigmas de Interfaz de Usuario.

2. Diferentes ambientes de desarrollo.

3. Diferentes interfaces de programación.

4. Diferentes lenguajes de programación.

Diferentes paradigmas de Interfaz de Usuario

Las 3 plataformas incorporan formas similares de representar la interfaz de usuario gráfica

(Graphical User Interface - GUI) y la interacción con el dispositivo a través de la característica
multitáctil, sin embargo, existen algunas diferencias entre ellas.

Cada plataforma tiene diferentes maneras de navegar entre aplicaciones y páginas, diferentes
convenciones para la representación de datos, diferentes formas de invocar y desplegar menús, e
incluso, diferentes enfoques del uso la característica táctil.
Los usuarios están acostumbrados a interactuar con aplicaciones sobre una plataforma particular y
también esperan aprovechar ese conocimiento con nuevas aplicaciones. Cada plataforma adquiere su
propia cultura y esas convenciones culturales tienen que ser consideradas por los desarrolladores.

Diferentes ambientes de desarrollo

Actualmente los programadores están acostumbrados a trabajar en ambientes de desarrollo integrado

(IDEs) sofisticados. Existen IDEs en las tres plataformas, pero cada uno diferente de los otros:

 Para el desarrollo iOS existe Xcode sobre Mac.

 Para el desarrollo Android existe Android Studio o Eclipse sobre una variedad de
plataformas.

 Para el desarrollo Windows existe Visual Studio sobre PC.

Diferentes interfaces de programación

Las 3 plataformas están basadas en diferentes sistemas operativos con diferentes APIs. En la mayoría
de los casos, las 3 plataformas implementan tipos similares de objetos para la interfaz de usuario con
diferentes nombres. Por ejemplo, las 3 plataformas tienen “algo” que permite al usuario seleccionar
un valor booleano:

 En iPhone o iPad se tiene un “view” llamado UISwitch.

 En dispositivos Android se tiene un “widget” llamado Switch.

 En la API Windows Runtime se tiene un “control” llamado ToggleSwitch.

Por supuesto, más allá de los simples nombres, las diferencias se encuentran en las interfaces de
programación mismas.

Diferentes lenguajes de programación

Los desarrolladores tienen un poco de flexibilidad para seleccionar un lenguaje de programación para
cada una de las 3 plataformas, pero, en general, cada plataforma está asociada con un lenguaje de
programación particular:

 Objective-C o Swift para iPhone y iPad.

 Java para dispositivos Android.

  C# para Windows.

Objective-C, Java y C# son parecidos debido a que todos ellos son lenguajes orientados a objetos
descendientes de C, sin embargo, las características particulares de cada lenguaje hacen que sean
como primos lejanos.

Por estas razones, una empresa que quisiera desarrollar para las tres plataformas podría emplear tres
diferentes equipos de programadores, cada uno de ellos calificado y especializado en un lenguaje y
API particular.

Este problema de lenguaje es el problema más importante que resolver. Si pudiéramos utilizar el
mismo lenguaje de programación para estas tres plataformas, podríamos al menos compartir algo de
código entre ellas. Este código compartido no podría ser de la interfaz de usuario debido a que cada
plataforma tiene diferentes APIs, sin embargo, podría ser código de la aplicación que no tenga que
ver del todo con la interfaz de usuario, por ejemplo, el código que implemente la lógica de negocios
de la aplicación.

La solución C# y .NET

Al igual que Java, C# es un lenguaje influenciado por C++ pero con una sintaxis más clara.
Anunciado en el año 2000, C# es un lenguaje relativamente nuevo en comparación con Objective-
C y Java.

Desde su concepción, C# ha estado estrechamente asociado con el Microsoft .NET Framework. A

nivel bajo, .NET proporciona una infraestructura para los tipos básicos de C#
(int, double, string, decimal, etc.). La biblioteca de clases del .NET Framework proporciona el
soporte para la funcionalidad que podemos encontrar en diferentes lenguajes de programación. Esto
incluye entre otros lo siguiente:

1. Funciones matemáticas (Math).

2. Herramientas para depuración (Debugging).

3. Herramientas para análisis de metadatos (Reflection)

4. Colecciones (Collection).

5. Globalización (Globalization).

6. Operaciones con archivos.

7. Redes (Networking).

8. Seguridad.

9. Manejo de Hilos (Threading).

10. Servicios Web.

11. Manejo de datos.

12. Lectura y escritura de XML y JSON

Poco después de que Microsoft anunciara el .NET Framework en junio del año 2000, la
empresa Ximian fundada por Miguel de Icaza y NatFriedman, inició un proyecto de código abierto
llamado Mono para crear una implementación alternativa del compilador de C# y el .NET
Framework que pudiera correr sobre Linux.

Una década después, en 2011, los fundadores de Ximian, que fue adquirida por Novell,
fundaron Xamarin. Xamarin aun contribuye a la versión de código abierto de Mono y lo ha adaptado
para formar la base de las soluciones móviles multiplataforma.

En mayo 28 de 2014, Xamarin introdujo Xamarin.Forms que permite a los desarrolladores escribir
código de interfaz de usuario que puede ser compilado para dispositivos iOS, Android y Windows.

En marzo de 2016, Microsoft adquirió Xamarin con el fin de proporcionar una opción de desarrollo
móvil multiplataforma a la extensa comunidad de desarrolladores Microsoft. Xamarin.Forms se
encuentra ahora disponible de forma gratuita a todos los usuarios de Visual Studio.

Un solo lenguaje para todas las plataformas

Durante los 3 primeros años de su existencia, Xamarin se enfocó principalmente en tecnologías de

compilación y en 3 conjuntos básicos de bibliotecas .NET:

 Xamarin.Mac, que es una evolución del proyecto MonoMac.

 Xamarin.iOS, que es una evolución de MonoTouch.

 Xamarin.Android, que es una evolución de Mono para Android también conocido

como MonoDroid.

Colectivamente, esas bibliotecas son conocidas como la plataforma Xamarin. Las bibliotecas
contienen versiones .NET de las APIs nativas Mac, iOS y Android. Los programadores que utilicen
esas bibliotecas pueden escribir aplicaciones en C# para acceder a las APIs nativas de esas 3
plataformas, pero, además como un bono adicional, pueden acceder a la biblioteca de clases del .NET
Framework.

Los desarrolladores pueden utilizar Visual Studio para construir aplicaciones Xamarin para iOS y
Android, así como para las distintas plataformas Windows. Sin embargo, el desarrollo para iPhone y
iPad también requiere de una Mac conectada a la PC a través de la red. La Mac debe
tener Xcode instalado, así como Visual Studio para Mac. Visual Studio para Mac es un IDE basado
en OS X que permite desarrollar aplicaciones iPhone, iPad, Mac OS X y Android en la Mac. Visual
Studio para Mac no permite desarrollar aplicaciones para la plataforma Windows.

Compartiendo código

La ventaja de desarrollar para múltiples plataformas con un solo lenguaje de programación radica en
la habilidad de compartir código entre las aplicaciones.

Antes de que el código pueda ser compartido, la aplicación debe ser estructurada para ese propósito.
De forma particular, debido al amplio espectro de interfaces de usuario gráficas disponibles, los
programadores han entendido la importancia de dividir el código de la aplicación en diferentes capas.
Probablemente, la división más útil es la separación del código de la interfaz de usuario, la lógica de
negocios y la lógica de acceso a datos. El patrón de arquitectura de software MVC (Model-View-
Controller) originado en 1980, formaliza esa separación de código en el Model (lógica de acceso a
datos y lógica de negocios), View (la representación visual de los datos) y el Controller (encargado
de interactuar con el usuario).

Más recientemente, la arquitectura MVVM (Model-View-ViewModel) ha modernizado a MVC

basado en interfaces de usuario modernas. MVVM separa el código en el Model (lógica de acceso a
datos y lógica de negocios), View (la interfaz de usuario, incluyendo elementos visuales y de entrada
de datos) y el ViewModel (encargado de administrar el paso de datos entre el Model y View).

Cuando un programador desarrolla una aplicación para múltiples plataformas móviles, la arquitectura
MVVM sirve de guía al programador para la separación del código en dos capas:

 View. Código especifico de la plataforma que requiere interactuar con las APIs de la
plataforma.

 Model y ViewModel. Código independiente de la plataforma.

Frecuentemente, el código independiente de la plataforma necesita utilizar colecciones, acceder a

archivos, acceder a la red o utilizarThreads. Normalmente estas tareas podrían ser consideradas como
parte de la API de un sistema operativo, sin embargo, también son tareas que pueden hacer uso de la
biblioteca de clases del .NET Framework. Y si además el .NET Framework está disponible en cada
plataforma, entonces ese código es efectivamente independiente de la plataforma.

La parte de la aplicación que es independiente de la plataforma puede ser entonces aislada y – en el

contexto de Visual Studio – puesta en un proyecto separado. El proyecto puede ser alguno de los
siguientes:

 Shared Asset Project (SAP). Este tipo de proyecto contiene código y otros archivos que
pueden ser accesibles directamente desde otros proyectos y que se combinan en tiempo de
compilación.

 .NET Standard. Este tipo de proyecto encapsula en una biblioteca DLL todo el código
común que después puede ser referenciado desde otros proyectos.

Anteriormente era utilizado el tipo de proyecto Portable Class Library (PCL) que al igual que el
tipo .NET Standard, encapsula en una biblioteca DLL todo el código común. Este proyecto ya ha
sido discontinuado y en su lugar la recomendación es el uso de proyectos .NET Standard.

Independientemente del método que utilicemos para compartir código, el código común tiene acceso
a la biblioteca de clases del .NET Framework, por lo que podemos realizar operaciones con archivos,
acceder a la red, manejar globalización, acceder a servicios Web, trabajar con XML, trabajar con
JSON, utilizar Threads y muchas otras tareas.

Esto significa que podemos crear una única solución Visual Studio que contenga varios proyectos C#
para crear aplicaciones para las 3 plataformas móviles, todos ellos con acceso a un proyecto común
SAP o .NET Standard.

El siguiente diagrama ilustra las relaciones entre los proyectos de Visual Studio, las bibliotecas
Xamarin y las APIs de cada plataforma. La tercera columna se refiere a cualquier plataforma
Windows basada en .NET independientemente del dispositivo.
Los cuadros en el segundo renglón (iOS App, Android App y Windows App) son las aplicaciones
específicas de la plataforma. Estas aplicaciones hacen llamadas en el proyecto común y también (en
el caso de iOS y Android) a las bibliotecas Xamarin que implementan las APIs nativas de la
plataforma.

El diagrama no muestra las llamadas del proyecto común hacia la biblioteca de clases del .NET
Framework. La versión invocada del .NET Framework depende del código común:

 El código del proyecto .NET Standard accede a su propia versión .NET.

 El código del proyecto SAP utiliza la versión .NET incorporada dentro de cada plataforma
particular.

En el diagrama, las bibliotecas Xamarin.iOS y Xamarin.Android parecen ser sustanciales, y mientras

que son ciertamente importantes, sonsimplemente enlaces de lenguaje que no afectan
significativamente el rendimiento de la aplicación durante las llamadas a las APIs.

Cuando la aplicación iOS es compilada, el compilador C# de Xamarin genera código intermedio (IL)
como es usual, pero además hace uso del compilador Apple en la Mac para generar código de máquina
iOS nativo de la misma forma en que lo hace el compilador de Objective-C. Las llamadas que la
aplicación hace hacia las APIs iOS son similares a las que hace una aplicación escrita directamente
con Objective-C.

Para la aplicación Android, el compilador C# de Xamarin genera código IL que se ejecuta sobre una
versión de Mono en el dispositivo junto con el motor de Java, pero las llamadas a las APIS desde la
aplicación son similares a las que hace una aplicación escrita en Java.

Para aplicaciones móviles que tienen necesidades muy específicas de la plataforma, pero también una
cantidad importante de código compartido independiente de la plataforma, Xamarin.iOS y
Xamarin.Android proporcionan excelentes soluciones. Los desarrolladores tienen acceso a la API
completa de la plataforma con todo el poder y responsabilidad que implica.

Para aplicaciones que no necesiten mucho código especifico de la plataforma, existe una alternativa
que simplifica un poco más la vida del programador: Xamarin.Forms.
Xamarin.Forms
En mayo 28 de 2014, Xamarin introdujo Xamarin.Forms que permite a los desarrolladores escribir
código de interfaz de usuario que puede ser compilado para dispositivos iOS, Android y Windows.
Xamarin.Forms soporta distintas plataformas de aplicaciones:

 iOS para programas que se ejecutan sobre iPhone, iPad y iPod Touch.
 Android para programas que se ejecutan sobre teléfonos y tabletas Android.
 La Plataforma Universal de Windows (UWP) para aplicaciones que se ejecutan sobre
dispositivos Windows 10.
De manera general, una aplicación Xamarin.Forms en Visual Studio consta de 3 proyectos
independientes para cada una de las 3 plataformas más un cuarto proyecto conteniendo el código
común. Los 3 proyectos de las plataformas por lo general son muy pequeños, a menudo contienen
simplemente un poco de código de inicio repetitivo. Los proyectos SAP o .NET Standard contienen
el resto de la aplicación, incluyendo el código de la interfaz de usuario.
El siguiente diagrama muestra las plataformas iOS, Android y UWP.
Las bibliotecas Xamarin.Forms.Core y Xamarin.Forms.Xaml implementan la
API Xamarin.Forms. Dependiendo de la plataforma,Xamarin.Forms.Core hace uso de una de las
bibliotecas Xamarin.Forms.Platform. Estas librerías son en su mayoría una colección de clases
llamadas Renderizadores (Renderers) que transforman los objetos de la interfaz de
usuario Xamarin.Forms en la interfaz de usuario especifica de la plataforma.
Por ejemplo, supongamos que necesitamos un objeto de interfaz de usuario que permita al usuario
seleccionar un valor booleano. Cuando programamos para Xamarin.Forms, el objeto que utilizamos
se llama Switch, y una clase llamada Switch es implementada en la bibliotecaXamarin.Forms.Core.
En los renderizadores individuales de las 3 plataformas, este objeto Switch es mapeado a
un UISwitch en el iPhone, un Switch en Android y un ToggleSwitch en Windows.
Xamarin.Forms.Core también contiene una clase llamada Slider para mostrar una barra horizontal
que el usuario manipula para seleccionar un valor numérico. Los renderizadores en las bibliotecas
específicas de cada plataforma mapean esta clase en un UISlider en iPhone, un SeekBar en Android
y un Slider en Windows.
Esto significa que cuando escribimos un programa Xamarin.Forms que utilice un Switch o un Slider,
lo que finalmente se muestra es el objeto correspondiente implementado en cada plataforma.
Es probable que cada objeto de interfaz de usuario tenga una apariencia distinta dependiendo de cómo
sea renderizado por el renderizador de cada plataforma. Incluso, objetos como barras de herramientas
pueden ser renderizados en posiciones físicas distintas en cada plataforma. Por ejemplo, el
objeto ToolBarItem es renderizado en iPhone como un objeto UIBarButtonItem en la parte superior
de la página, en Android como elemento de un ActionBar en la parte superior de la página y en
Windows 10 como elemento de unCommandBar en la parte inferior de la página.
El ActionBar de Android tiene elipsis vertical y el CommandBar de la Plataforma Universal de
Windows tiene elipsis horizontal.
Aunque originalmente Xamarin.Forms fue concebido como una API para dispositivos móviles
independiente de la plataforma, Xamarin.Forms no está limitado a teléfonos. Una aplicación
Xamarin.Forms puede ser ejecutada en tabletas o en equipos de escritorio como en Windows 10
Desktop.
Las distintas implementaciones de la barra de herramientas revelan que Xamarin.Forms es una API
que virtualiza no solo los elementos de la interfaz de usuario de cada plataforma, sino también los
paradigmas de la interfaz de usuario.
Configurando una Mac
Las políticas de Apple establecen que una computadora Mac es requerida para desarrollar una
aplicación. La razón de esto es debido a que solo es permitido ejecutar el proceso de compilación con
el ambiente de desarrollo Xcode y los SDKs de Apple.
Para la realización de pruebas y depuración, Xamarin ha creado la aplicación Xamarin Live
Player que puede ser descargada e instalada en dispositivos iOS y Android. Xamarin Live Player
puede ser emparejada con Visual Studio para procesos de depuración y pruebas, sin embargo, para
otro tipo de procesos como el firmado de código, configuración de perfiles o la publicación de
aplicaciones al App Store, seguimos necesitando una computadora Mac.
Es posible utilizar una computadora Mac local en la red que nos permitirá realizar pruebas y
depuración en dispositivos físicos o podemos utilizar una computadora Mac remota. En ambos casos,
macOS debe ser configurado con los siguientes requerimientos de software:
 Sistema operativo macOS Sierra 10.12 o posteriores.
 Xcode y los SDKs de Apple.
 El motor Xamarin.iOS.
La manera más facil de configurar Xamarin de forma apropiada sobre una Mac es instalando Visual
Studio for Mac.
Visual Studio se conectará a la Mac para lanzar el compilador Xcode y los SDKs de Apple por lo que
debe habilitarse las conexiones remotas sobre la Mac.

A partir de Visual Studio 2017 versión 15.6, la característica Emparejar con

Mac (Pairto Mac) de Visual Studio proporciona automáticamente al equipo Mac el
software necesario para compilar aplicaciones de Xamarin.iOS: Mono, Xamarin.iOS
(elframework de software, no el IDE de Visual Studio para Mac) y diversas herramientas
relacionadas con Xcode (pero no Xcode). Pair to Mac realiza las instalaciones o
actualizaciones de software necesarias cuando Visual Studio 2017 se conecta al equipo
Mac.

En la siguiente página de la documentación oficial de Xamarin puedes obtener

información importante y actualizada que te ayudará a configurar una computadora
Mac. En esa página se explica cómo configurar perfiles y certificados asi como la
forma de utilizar Xcode para realizar configuraciones preliminares.
Emparejar con Mac
Lección 2: Creando soluciones Xamarin.Forms

Creando soluciones Xamarin.Forms

En esta lección se describe el proceso de creación de una solución Xamarin.Forms asi como la forma
de integrar el framework Xamarin.Forms en la solución. Se examina la estructura de una solución
Xamarin.Forms incluyendo el proyecto común de código compartido asi como los proyectos
correspondientes a cada una de las plataformas: Android, iOS y UWP.
Objetivos de la lección
Al finalizar esta lección, los participantes podrán:
 Crear una solución Xamarin.Forms utilizando Visual Studio.
 Describir la estructura de una solución Xamarin.Forms.
 Describir la forma en que se integra el framework Xamarin.Forms en una solución
Xamarin.Forms.
 Describir el código de inicialización del Framework Xamarin.Forms en el proyecto
Android.
 Describir el código de inicialización del Framework Xamarin.Forms en el proyecto iOS.
 Describir el código de inicialización del Framework Xamarin.Forms en el proyecto UWP.
La biblioteca Xamarin.Forms
Técnicamente hablando, Xamarin.Forms es una biblioteca .NET de código abierto que expone sus
objetos a través de un espacio de nombres raíz llamado Xamarin.Forms.Xamarin.Forms se hace
disponible en un paquete NuGet que Visual Studio instala automáticamente en todos los proyectos
cuando se crea una nueva soluciónXamarin.Forms.
Puedes acceder al código fuente de Xamarin.Forms en el siguiente enlace de GitHub:
Xamarin.Forms

En este laboratorio exploraremos la biblioteca Xamarin.Forms.

1. Abre la solución creada en el laboratorio anterior en caso de que la hayas cerrado.
2. Selecciona la opción Manage Nuget Packages for Solution… del menú contextual del
nombre de la solución. La pestaña Installed muestra los paquetesNuGet instalados en la solución.
Puedes notar que se encuentra el paquete Xamarin.Forms.

Es recomendado que al crear una nueva solución Xamarin.Forms actualicemos el

paquete NuGet a la última versión estable disponible.
3. Selecciona la pestaña Updates para ver si se encuentra una versión más reciente de
Xamarin.Forms.
 Al momento de crear este laboratorio se encontraba disponible la versión
estable 3.0.0.482510 de Xamarin.Forms.
4. Selecciona el paquete Xamarin.Forms yMicrosoft.NetCoreUniversalWindowsPlatform si
estos se encuentran disponibles en la pestaña Updates.

Después de unos segundos los paquetes habrán sido actualizados.