Episode
La solución C# y .NET
Important
This content is not available in English. The original version can be found in Spanish here.
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 Nat Friedman, 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 Xamarin Studio. Xamarin Studio es un IDE basado en OS X que permite desarrollar aplicaciones iPhone, iPad, Mac OS X y Android en la Mac. Xamarin Studio 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 utilizar Threads. 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 o Xamarin Studio – puesta en un proyecto separado. El proyecto puede ser alguno de los siguientes:
- Shared Asset Project (SAP). Este tipo de proyecto consiste de código y de otros archivos que pueden ser accesibles directamente desde otros proyectos y que se combinan en tiempo de compilación.
- Portable Class Library (PCL). Este tipo de proyecto encapsula en una biblioteca DLL todo el código común que después puede ser referenciado desde otros proyectos.
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 PCL.
El diagrama en el video 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 PCL accede a su propia versión del .NET Framework.
- El código del proyecto SAP utiliza la versión del .NET Framework 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, son simplemente 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.
Important
This content is not available in English. The original version can be found in Spanish here.
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 Nat Friedman, 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 Xamarin Studio. Xamarin Studio es un IDE basado en OS X que permite desarrollar aplicaciones iPhone, iPad, Mac OS X y Android en la Mac. Xamarin Studio 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 utilizar Threads. 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 o Xamarin Studio – puesta en un proyecto separado. El proyecto puede ser alguno de los siguientes:
- Shared Asset Project (SAP). Este tipo de proyecto consiste de código y de otros archivos que pueden ser accesibles directamente desde otros proyectos y que se combinan en tiempo de compilación.
- Portable Class Library (PCL). Este tipo de proyecto encapsula en una biblioteca DLL todo el código común que después puede ser referenciado desde otros proyectos.
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 PCL.
El diagrama en el video 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 PCL accede a su propia versión del .NET Framework.
- El código del proyecto SAP utiliza la versión del .NET Framework 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, son simplemente 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.
Have feedback? Submit an issue here.