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: 

 Funciones matemáticas (Math). 

 Herramientas para depuración (Debugging). 
 Herramientas para análisis de metadatos (Reflection) 
 Colecciones (Collection).
 Globalización (Globalization). 
 Operaciones con archivos.
 Redes (Networking).
 Seguridad.
 Manejo de Hilos (Threading). 
 Servicios Web. 
 Manejo de datos.

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.NetCoreUniversalWindowsPlatfo
rm si estos se encuentran disponibles en la pestaña Updates.  
Después de unos segundos los paquetes habrán sido actualizados.
Laboratorio: Hola Xamarin.Forms
Hola Xamarin.Forms 
Una vez que hayamos instalado y configurado nuestro entorno de desarrollo, el
siguiente paso es empezar a crear aplicaciones Xamarin.Forms. 
En este laboratorio crearás una solución Xamarin.Forms utilizando Visual Studio
y Windows 10. 

Abre Visual Studio bajo el contexto de administrador. 

Selecciona la opción File > New > Project… para abrir la ventana que nos

permitirá crear un nuevo proyecto. 
Selecciona el nodo Visual C# > Cross-Platform. 

Podrás observar la plantilla de proyecto Mobile App (Xamarin.Forms). Esta

plantilla es la que utilizamos para desarrollar aplicaciones móviles
multiplataforma. 
Selecciona la plantilla Mobile App (Xamarin.Forms). 
Proporciona HelloXamarinForms como nombre del proyecto, elije la
ubicación y haz clic en OK para continuar.

Visual Studio mostrará una pantalla que te permitirá seleccionar entre una
plantilla de aplicación vacía (Blank App) y una plantilla Maestro
Detalle (Master Detail). La plantilla Master Detail genera una interfaz de
usuario básica basada en páginas y elementos visuales implementando el
patrón de navegación master-detail.  

Selecciona la plantilla Blank App. 
El grupo Platform nos permite seleccionar la plataforma a la que irá
dirigida la aplicación mientras que el grupo CodeSharing Strategy nos
permite seleccionar el tipo de estrategia que utilizaremos para compartir
el código común. 
Selecciona las 3 plataformas, la estrategia .NET Standard para compartir el
código común y haz clic en OK para continuar. 
Después de unos segundos, la solución Xamarin.Forms habrá sido creada. En el
explorador de soluciones podrás notar que la solución está compuesta por 4
proyectos. 

Selecciona la opción Properties del menú contextual del primer proyecto, en

nuestro ejemplo, el proyecto HelloXamarinForms. Podrás notar que el
proyecto es una biblioteca de clases .NET Standard. 
Este proyecto contiene el código que puede ser compartido entre las
plataformas y es el lugar donde escribiremos toda la interfaz de usuario de la
aplicación y todo el código que no requiera interactuar con APIs nativas.  
El segundo proyecto cuyo sufijo es Android es un proyecto nativo
Xamarin.Android. 

Expande el nodo References del segundo proyecto. Este proyecto contiene

una referencia al código compartido y a Xamarin.Forms. 

Este proyecto implementa la infraestructura requerida por la aplicación para

poder ejecutarse en dispositivos Android. 
El tercer proyecto cuyo sufijo es iOS es un proyecto nativo Xamarin.iOS.  
Expande el nodo References del proyecto Xamarin.iOS. Este proyecto también
contiene una referencia al código compartido y a Xamarin.Forms. 
Este proyecto implementa la infraestructura requerida por la aplicación para
poder ejecutarse en dispositivos iPhone y iPad. 
El cuarto y último proyecto es un proyecto nativo Universal Windows Platform
(UWP). 

Expande el nodo References del proyecto UWP. Este proyecto también

contiene una referencia al código compartido y a Xamarin.Forms. 

Este proyecto implementa la infraestructura requerida por la aplicación para

poder ejecutarse en dispositivos Windows 10 tanto en equipos de escritorio
como en dispositivos móviles.  

En los siguientes laboratorios exploraremos con más detalle cada uno de los
distintos proyectos de plataforma para tener un conocimiento básico de sus
propiedades, esto será muy importante debido a que necesitaremos afinar las
propiedades del proyecto cada vez que volvamos a crear una nueva solución
Xamarin.Forms. 
Laboratorio: La biblioteca Xamarin.Forms
 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ón Xamarin.Forms. 

En este laboratorio exploraremos la biblioteca Xamarin.Forms. 

Abre la solución creada en el laboratorio anterior en caso de que la hayas
cerrado. 
Selecciona la opción Manage Nuget Packages for Solution… del menú
contextual del nombre de la solución. La pestaña Installedmuestra los
paquetes NuGet 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.
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. 
Selecciona el
paquete Xamarin.Forms y Microsoft.NetCoreUniversalWindowsPlatform 
si estos se encuentran disponibles en la pestaña Updates.  

Haz clic en Update para iniciar la actualización. El proceso de actualización

será iniciado y es probable que te sea solicitada la aceptación de los cambios a
realizar y el acuerdo de licencias. 
Acepta los cambios a realizar y el acuerdo de licencias cuando te sea
solicitado. 
Después de unos segundos los paquetes habrán sido actualizados. 
Laboratorio: El proyecto Xamarin.Android
El proyecto Xamarin.Android 

Xamarin.Android hace posible que una solución Xamarin.Forms se ejecute en

dispositivos Android.  

En este laboratorio exploramos los elementos principales del proyecto

Xamarin.Android. 

1. Abre la solución creada en el laboratorio anterior en caso de que la

hayas cerrado. 

2. Localiza el archivo MainActivity.cs. Este archivo representa

la Activity de inicio de la aplicación Android que Xamarin genera.