Desarrollo multiplataforma IOS vs Android con Xamarin

Texto completo

(1)PROYECTO FIN DE CARRERA PLAN 2000 º E.U.I.T. TELECOMUNICACIÓN. TEMA:. DESARROLLO DE APLICACIONES MÓVILES. TÍTULO: DESARROLLO MULTIPLATAFORMA IOS VS ANDROID CON XAMARIN AUTOR: ALBERTO ESTEBAN BLANCO. DEPARTAMENTO:. DTE. Miembros del Tribunal Calificador: PRESIDENTE: VOCAL:. MARGARTIA MILLAN VALENZUELA ANTONIO DA SILVA FARIÑA. Vº Bº.. VOCAL SECRETARIO: JESUS MORENO BLAZQUEZ DIRECTOR: Fecha de lectura: Calificación:. El Secretario,. RESUMEN DEL PROYECTO:. En la última década, la tecnología incorporada a los teléfonos móviles ha provocado una disrupción en el mercado, convirtiendo estos dispositivos en máquinas muy potentes, a la vez que asequibles para la mayor parte de la población mundial. Existen gran variedad de sistemas operativos móviles, y por tanto, una gran variedad de formas de desarrollar aplicaciones. El objetivo del PFC es docente. Consiste en una serie de lecciones prácticas de desarrollo con el entorno Xamarin y su librería Xamarin.Forms. Serán planteadas de forma incremental, buscando completar un recorrido por todos los elementos básicos que es necesario conocer para el correcto desarrollo de una aplicación comercial..

(2) 2.

(3) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Superior Técnica de Ingeniería y Sistemas de Telecomunicación INGENIERÍA TÉCNICA DE TELECOMUNICACIÓN TELEMÁTICA. PROYECTO FINAL DE CARRERA. DESARROLLO MULTIPLATAFORMA IOS VS ANDROID CON XAMARIN AUTOR: ALBERTO ESTEBAN BLANCO TUTOR: ANTONIO DA SILVA FARIÑA.

(4) 4.

(5) Agradecimientos Quiero agradecer profundamente a todas las personas que me han apoyado y ayudado en mi formación. A todos aquellos que han aportado su granito de arena para que finalice mi carrera universitaria. No puedo nombrar a todos, pero quiero mencionar especialmente: A mi familia, por su apoyo desde la distancia. Siempre me hicieron presente el valor del trabajo y el estudio. A mi profesor y tutor, Antonio Da Silva, que me ha dado la oportunidad de realizar este proyecto. Gracias por su ayuda. A mis compañeros de Universidad, por tantas horas vividas en los laboratorios, buscando ayudarnos los unos a los otros. A Adrián por compartir conmigo la Universidad, el trabajo y la locura por las aplicaciones. A Celestino y Marta, por hacer de Pepito Grillo cuando se necesita. Y sobre todo, a mi abuela, que es la mejor.. 5.

(6) 6. "Somos lo que pensamos, todo lo que somos se levanta con nuestros pensamientos. Con ellos, creamos el mundo." Dhammapada.

(7) Resumen En la última década, la tecnología incorporada a los teléfonos móviles ha provocado una disrupción en el mercado de las telecomunicaciones. Esta tecnología ha convertido a los dispositivos en máquinas muy potentes, a la vez que económicamente asequibles para la mayor parte de la población mundial. Ello ha provocado la aparición de un nuevo mercado en el sector del desarrollo, las aplicaciones móviles. Para el año 2019, se espera alcanzar cinco mil millones de dispositivos activos. Como veremos más adelante, existen gran variedad de sistemas operativos móviles, y por tanto, también existe una gran variedad de formas de desarrollar aplicaciones. En la introducción plantearemos que consecuencias tiene el ecosistema actual en el desarrollo de aplicaciones móviles y por qué se ha elegido el entorno de desarrollo Xamarin como tema de este Proyecto Fin de Carrera. Se analizará seguidamente el marco tecnológico de las aplicaciones móviles, centrado en los sistemas operativos móviles con mayor penetración en el mercado, así como las diferentes formas en las que se pueden desarrollar aplicaciones para estos sistemas. En el capitulo Xamarin, se analizará en profundidad la plataforma, su historia, evolución y arquitectura, así como sus componentes fundamentales y los de Xamarin.Forms. Con ello se pretende dar una base solida desde la que poder afrontar los siguientes capítulos de este Proyecto Fin de Carrera. Las lecciones prácticas se han planteado de forma incremental, buscando realizar un recorrido completo por todos los elementos básicos que es necesario conocer para el correcto desarrollo de una aplicación comercial. El resultado final será una aplicación móvil, desarrollada con Xamarin y su librería Xamarin.Forms, para los sistemas operativos Android e iOS. Esta aplicación, haciendo uso de la información abierta que ofrece OpenData Madrid, mostrará las diferentes estaciones de medición de calidad del aire de la ciudad de Madrid y los valores de las mediciones realizadas por las mismas en tiempo real, geoposicionándolas en un mapa.. 7.

(8) 8.

(9) Abstract Over the last decade, the technology embedded in mobile phones, has converted these devices in very powerful machines, causing a disruption in the telecommunications market. In the meantime, they became more affordable to the majority of the world population generating a high demand, converting the mobile applications in a new business opportunity in the Information Technologies development market. By the year 2019, it is expected to reach 5 billion of active devices. As we will see, there is a wide variety of mobile operating systems, and therefore there is also a wide variety of application development platforms. Introduction chapter will present the current ecosystem, its problems and consequences on the mobile application development and the reason for selecting Xamarin as main theme of this PFC. A specific chapter analysis the technological framework of mobile applications, as well as the development methodologies, with particular emphasis on the operating systems with the highest penetration in the market, currently iOS and Android. The Xamarin platform and Xamarin.Forms library are presented in a dedicated chapter. Its history, evolution and fundamentals components are described to set the basis to approach the next chapters of this PFC. The practical lessons have been structured incrementally to bring up all the basic elements needed to properly develop a commercial application. Each practice will serve as a basis for the next, growing in difficulty and ending in a single solution that gathers all previous lessons. The result will be a mobile application, for iOS and Android operative systems, developed with Xamarin and the library Xamarin.Forms. It will be able to provide the measuring stations and the real time air quality values given by the Madrid's OpenData platform. Also will provide the GPS positions of the stations, placing them on a map, as well as the position of the phone itself.. 9.

(10) 10.

(11) Índice general Índice de figuras. 15. Fragmentos de Código. 17. Índice de tablas. 19. Acrónimos. 21. 1. Introducción 23 1.1. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2. Marco tecnológico 2.1. Dispositivos móviles . . . . . . . . . . . . . . . . . . . . . 2.2. Sistemas operativos móviles . . . . . . . . . . . . . . . . 2.2.1. Android . . . . . . . . . . . . . . . . . . . . . . . 2.2.2. iOS . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3. Otros sistemas operativos . . . . . . . . . . . . . 2.2.3.1. Windows Mobile . . . . . . . . . . . . . 2.2.3.2. BlackBerry OS . . . . . . . . . . . . . . 2.3. Tecnologías de desarrollo de aplicaciones multiplataforma 2.3.1. Apache Cordova . . . . . . . . . . . . . . . . . . . 2.3.2. Appcelerator Titanium . . . . . . . . . . . . . . . 3. Xamarin 3.1. Introducción . . 3.2. Historia . . . . 3.3. Arquitectura . . 3.3.1. Android 3.3.2. iOS . . . 3.4. Xamarin.Forms. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 11. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . .. 27 28 28 28 30 31 31 31 32 32 34. . . . . . .. 37 38 38 41 41 42 43.

(12) 12. ÍNDICE GENERAL 3.4.1. 3.4.2. 3.4.3. 3.4.4.. Introducción . . . . . . . . . . . . . . Estructura de la aplicación . . . . . . XAML . . . . . . . . . . . . . . . . . MVVM . . . . . . . . . . . . . . . . 3.4.4.1. Data Binding . . . . . . . . 3.4.4.2. Modelo . . . . . . . . . . . 3.4.4.3. VistaModelo . . . . . . . . 3.4.4.4. Vista . . . . . . . . . . . . 3.4.5. Inyección de dependencias y Servicios plataforma . . . . . . . . . . . . . . . 3.4.6. Elementos UI Xamarin.Forms . . . . 3.4.6.1. Pages . . . . . . . . . . . . 3.4.6.2. Layouts . . . . . . . . . . . 3.4.6.3. Views . . . . . . . . . . . . 3.4.6.4. Cells . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . de la . . . . . . . . . . . . . . . . . .. 4. Lecciones propuestas Xamarin 4.1. Practica 0: Instalación del entorno y aplicación Hola Mundo 4.1.1. Instalación en Mac OS . . . . . . . . . . . . . . . . . 4.1.2. Instalación en Windows . . . . . . . . . . . . . . . . 4.1.2.1. Visual Studio . . . . . . . . . . . . . . . . . 4.1.2.2. Xamarin Mac Agent . . . . . . . . . . . . . 4.1.2.3. Visual Studio Emulator . . . . . . . . . . . 4.1.3. Creación de la solución . . . . . . . . . . . . . . . . . 4.1.4. Proyecto compartido . . . . . . . . . . . . . . . . . . 4.1.5. Ejecución de la aplicación . . . . . . . . . . . . . . . 4.2. Practica 1: interfaces básicas y arquitectura MVVM . . . . . 4.2.1. MVVM . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3. VistaModelo . . . . . . . . . . . . . . . . . . . . . . . 4.2.4. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5. Ejecución de la aplicación . . . . . . . . . . . . . . . 4.3. Práctica 2: interfaces avanzadas . . . . . . . . . . . . . . . . 4.3.1. Navegación . . . . . . . . . . . . . . . . . . . . . . . 4.3.2. NavigationPage . . . . . . . . . . . . . . . . . . . . . 4.3.3. Propiedad Navigation . . . . . . . . . . . . . . . . . . 4.3.4. Inclusión de una nueva página . . . . . . . . . . . . . 4.3.5. Ejecución de la aplicación . . . . . . . . . . . . . . . 4.4. Práctica 3: Código compartido . . . . . . . . . . . . . . . . . 4.4.1. Shared Project . . . . . . . . . . . . . . . . . . . . . 4.4.2. PCL: Portable Class Library . . . . . . . . . . . . . .. . . . . . . . .. 43 44 45 46 46 47 48 49. . . . . . .. 50 51 51 54 58 65. . . . . . . . . . . . . . . . . . . . . . . . .. 67 68 68 69 69 70 71 72 73 74 75 76 76 77 79 80 81 81 82 83 83 86 88 88 88.

(13) 13. ÍNDICE GENERAL 4.4.3. Implementación PCL . . . . . . . . . . . . . . . . 4.4.4. Ejecución de la aplicación . . . . . . . . . . . . . 4.5. Práctica 4: Código dependiente de la plataforma . . . . . 4.5.1. Inyección de dependencias . . . . . . . . . . . . . 4.5.1.1. Interfaz . . . . . . . . . . . . . . . . . . 4.5.1.2. Implementación Android . . . . . . . . . 4.5.1.3. Implementación iOS . . . . . . . . . . . 4.5.1.4. Registro y resolución del Contenedor de yección de dependencias . . . . . . . . . 4.5.2. Inclusión del mapa . . . . . . . . . . . . . . . . . 4.5.3. Ejecución de la aplicación . . . . . . . . . . . . .. . . . . . . . . . . . . . . in. . . . . .. . . . . . . .. 90 92 94 94 94 95 97. . 98 . 99 . 101. 5. Conclusiones y trabajos futuros 103 5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . 104 Bibliografía. 105.

(14) 14. ÍNDICE GENERAL.

(15) Índice de figuras 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9.. Logo Android Nougat . . . . . . . . . . Distribución de versiones Android en el Logo iOS 10 . . . . . . . . . . . . . . . Logo Windows 10 Mobile . . . . . . . . Logo BlackBerry 10 . . . . . . . . . . . Logo Apache Cordova . . . . . . . . . Arquitectura Apache Cordova . . . . . Logo Appcelerator Titanium . . . . . . Arquitectura Appcelerator Titanium .. 3.1. Logo Xamarin . . . . . . . . . . . . 3.2. Logo del proyecto Mono . . . . . . 3.3. Arquitectura Xamarin.Anroid . . . 3.4. Arquitectura Xamarin.iOS . . . . . 3.5. Compilación AOT . . . . . . . . . . 3.6. Estructura de capas Xamarin.Forms 3.7. Interacción entre elementos MVVM 3.8. Inyección de dependencias . . . . . 3.9. Tipos de Page . . . . . . . . . . . . 3.10. Visualización TemplatedPage . . . 3.11. Visualización ContentPage . . . . . 3.12. Visualización MasterDetailPage . . 3.13. Visualización NavigationPage . . . 3.14. Visualización TabbedPage . . . . . 3.15. Visualización CarouselPage . . . . . 3.16. Tipos de Layout . . . . . . . . . . . 3.17. Visualización ActivityIndicator . . 3.18. Visualización Button . . . . . . . . 3.19. Visualización DatePicker . . . . . . 3.20. Visualización Entry . . . . . . . . . 3.21. Visualización ListView . . . . . . . 15. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . mercado, Mayo 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. 29 29 30 31 32 32 33 34 35. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. 38 39 41 42 43 44 46 51 52 52 52 53 53 54 54 55 58 59 59 60 61. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . ..

(16) 16. ÍNDICE DE FIGURAS 3.22. Visualización 3.23. Visualización 3.24. Visualización 3.25. Visualización 3.26. Visualización 3.27. Visualización 3.28. Visualización 3.29. Visualización 3.30. Visualización 3.31. Visualización. ProgressBar SearchBar . Slider . . . . Stepper . . . Switch . . . TableView . EntryCell . . SwitchCell . TextCell . . ImageCell .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 4.1. Android Virtual Device Manager vacío . . . . . . . 4.2. Creación de un nuevo emulador Android . . . . . . 4.3. Selección de opciones de instalación Visual Studio . 4.4. Xamarin Mac Agent . . . . . . . . . . . . . . . . . 4.5. Xamarin Mac Agent enlazado . . . . . . . . . . . . 4.6. Listado de Dispositivos Virtuales Android en Visual 4.7. Creación de la solución Práctica 0 . . . . . . . . . . 4.8. Jerarquía de la solución Práctica 0 . . . . . . . . . 4.9. Detalle archivos XAML y CS . . . . . . . . . . . . 4.10. Ejecución Práctica 0 . . . . . . . . . . . . . . . . . 4.11. Patrón MVVM . . . . . . . . . . . . . . . . . . . . 4.12. Binding flow . . . . . . . . . . . . . . . . . . . . . . 4.13. Ejecución Práctica 1 . . . . . . . . . . . . . . . . . 4.14. Pila de navegación: Push . . . . . . . . . . . . . . . 4.15. Pila de navegación: Pop . . . . . . . . . . . . . . . 4.16. Creación de una nueva ContentPage . . . . . . . . . 4.17. Práctica 2 Android . . . . . . . . . . . . . . . . . . 4.18. Práctica 2 iOS . . . . . . . . . . . . . . . . . . . . . 4.19. Shared Project . . . . . . . . . . . . . . . . . . . . 4.20. Portable Class Library . . . . . . . . . . . . . . . . 4.21. Instalación paquete Nuget . . . . . . . . . . . . . . 4.22. Estructura del proyecto PCL . . . . . . . . . . . . 4.23. Práctica 3 Android . . . . . . . . . . . . . . . . . . 4.24. Práctica 3 iOS . . . . . . . . . . . . . . . . . . . . . 4.25. Esquema de inyección de dependencias . . . . . . . 4.26. Práctica 4 Android . . . . . . . . . . . . . . . . . . 4.27. Práctica 4 iOS . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 62 62 62 63 63 64 65 65 66 66. . . . . . . . . . . . . . . . . . . . . Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 68 69 70 71 71 72 73 73 74 75 76 79 81 82 82 84 87 87 88 89 91 92 93 93 94 102 102.

(17) Fragmentos de Código 3.1. Ejemplo 3.2. Ejemplo 3.3. Ejemplo 3.4. Ejemplo 3.5. Ejemplo 3.6. Ejemplo 3.7. Ejemplo 3.8. Ejemplo 3.9. Ejemplo 3.10. Ejemplo 3.11. Ejemplo 3.12. Ejemplo 3.13. Ejemplo 3.14. Ejemplo 3.15. Ejemplo 3.16. Ejemplo 3.17. Ejemplo 3.18. Ejemplo 3.19. Ejemplo 3.20. Ejemplo 3.21. Ejemplo 3.22. Ejemplo 3.23. Ejemplo 3.24. Ejemplo 3.25. Ejemplo 3.26. Ejemplo 3.27. Ejemplo 3.28. Ejemplo 3.29. Ejemplo 3.30. Ejemplo 3.31. Ejemplo. de código XAML . . . . . DataBinding XAML . . . DataBinding C# . . . . . Modelo . . . . . . . . . . . VistaModelo . . . . . . . . Vista fichero C# . . . . . Vista fichero XAML . . . de ScrollView XAML . . . de Frame XAML . . . . . de AbsoluteLayout XAML de Grid XAML . . . . . . de StackLayout XAML . . de RelativeLayout XAML de ActivityIndicator . . . de BoxView . . . . . . . . de Button . . . . . . . . . de DatePicker . . . . . . . de Entry . . . . . . . . . . de Editor . . . . . . . . . de Image . . . . . . . . . . de Label . . . . . . . . . . de ListView . . . . . . . . de Picker . . . . . . . . . . de ProgressBar . . . . . . de SearchBar . . . . . . . de Slider . . . . . . . . . . de Stepper . . . . . . . . . de Switch . . . . . . . . . de TableView . . . . . . . de TimePicker . . . . . . . de WebView . . . . . . . . 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45 47 47 47 48 49 50 55 56 56 57 57 58 58 59 59 60 60 60 61 61 61 62 62 62 63 63 63 64 64 64.

(18) 18. FRAGMENTOS DE CÓDIGO 3.32. Ejemplo 3.33. Ejemplo 3.34. Ejemplo 3.35. Ejemplo. de de de de. EntryCell . SwitchCell TextCell . ImageCell. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 65 65 65 66. 4.1. Modelo Station . . . . . . . . . . . . . . . . . . . . 4.2. VistaModelo StationsViewModel . . . . . . . . . . 4.3. Vista XAML . . . . . . . . . . . . . . . . . . . . . 4.4. TextCell bindings . . . . . . . . . . . . . . . . . . . 4.5. Vista C# . . . . . . . . . . . . . . . . . . . . . . . 4.6. Inclusión de NavigationPage . . . . . . . . . . . . . 4.7. Modelo Measure . . . . . . . . . . . . . . . . . . . . 4.8. MeasuresPage.xaml . . . . . . . . . . . . . . . . . . 4.9. MeasuresPage.cs . . . . . . . . . . . . . . . . . . . 4.10. Método OnSelection . . . . . . . . . . . . . . . . . 4.11. Binding del método OnSelection . . . . . . . . . . . 4.12. Json Stations . . . . . . . . . . . . . . . . . . . . . 4.13. Método getStations ViewModel . . . . . . . . . . . 4.14. Clase Location . . . . . . . . . . . . . . . . . . . . 4.15. Interfaz iGPS . . . . . . . . . . . . . . . . . . . . . 4.16. Implementación ILocationListener . . . . . . . . . . 4.17. Implementación IGPS Android . . . . . . . . . . . 4.18. Implementación IGPS iOS . . . . . . . . . . . . . . 4.19. Registro de inyección de dependencias . . . . . . . . 4.20. Resolución de dependencias en StationsViewModel 4.21. Ejemplo de layout con Map . . . . . . . . . . . . . 4.22. Ejemplo de Map en C# . . . . . . . . . . . . . . . 4.23. Método toggleView . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. 77 78 79 79 80 83 84 85 85 86 86 90 92 95 95 96 97 98 98 99 100 100 101.

(19) Índice de tablas 3.1. Histórico de versiones Xamarin.iOS . . . . . . . . . . . . . . . 40 3.2. Histórico de versiones Xamarin.Android . . . . . . . . . . . . . 40 4.1. Métodos de la interfaz INavegation . . . . . . . . . . . . . . . 83. 19.

(20) 20. ÍNDICE DE TABLAS.

(21) Acrónimos AOT Ahead of Time 38, 39 API Application Programming Interface 37, 38, 41 CLI Common Language Infrastructure 34 CLR Common Language Runtime 38 IDE Integrated Development Environment 30, 34, 35 JIT Just in Time 38 JNI Java Native Interface 37 JSON JavaScript Object Notation 30, 88–90 MVVM Modelo-Vista-VistaModelo 40, 42, 74 PCL Portable Class Library 40, 41, 89, 92, 104 SAP Shared Asset Project 40, 41 SDK Software Development Kit 30, 34 XAML Extensible Application Markup Language 40–42, 46, 51, 71, 82, 84 XML Extensible Markup Language 30, 41, 71. 21.

(22) 22. Acrónimos.

(23) Capítulo 1 Introducción En este capítulo de introducción, se da una visión general sobre el mundo de la tecnología móvil, además de explicar los objetivos que se buscan completar con la realización del presente proyecto.. 23.

(24) 24. 1.1.. CAPÍTULO 1. INTRODUCCIÓN. Visión general. Los dispositivos móviles han evolucionado de forma imparable en las dos últimas décadas, incluyendo nuevos sensores y capacidades, llevando a que el uso como terminal de telefonía no sea el servicio más utilizado. Los terminales actuales han alcanzado una capacidad de computación tal, que cualquiera de los terminales actualmente en el mercado tienen más potencia que los ordenadores encargados de llevar las misiones Apollo a la Luna [12]. Si a esto sumamos el abaratamiento de los terminales, se puede comprender su amplia distribución, llegando a superar el mercado de ordenadores portátiles en 2007 [17]. Ya en el año 2015 los teléfonos móviles se convirtieron en el principal punto de acceso a Internet para los españoles, según el estudio La Sociedad de la Información en España 2016 [16] de la Fundación Telefónica. Este estudio también refleja la evolución de la penetración en el mercado de los diferentes sistemas operativos móviles. En Junio de 2016, Android alcanzó una cuota de mercado del 92,1 % e iOS un 8,2 %, mientras que Windows Phone perdía casi la totalidad de su cuota, retrocediendo del 4 % de un año antes a un 0,4 %. Con estos datos podemos afirmar que para cubrir la práctica totalidad del mercado con una aplicación, al menos será necesario desarrollarla para los sistemas operativos Android e iOS. Esto supone una gran inversión de tiempo y dinero. Como veremos en el capitulo Marco Tecnológico, existen diferentes tecnologías para realizar un único desarrollo para ambas plataformas. Sin embargo, el resultado de la interacción no alcanza las mismas cotas de calidad que los desarrollos nativos. Este es el motivo para elegir Xamarin como tema de este proyecto. Permite realizar un único desarrollo manteniendo el nivel de calidad de una aplicación nativa, ahorrando tiempos de desarrollo y asegurando la mantenibilidad y escalabilidad de los desarrollos multiplataforma. Por todo esto, considero que es una tecnología interesante de aprender y con un gran presente y futuro.. 1.2.. Objetivos. El objetivo de este Proyecto Fin de Carrera es crear una serie de lecciones prácticas, que servirán como punto de partida básico con el que poder aprender el funcionamiento de la plataforma Xamarin. No se estudiarán todos los aspectos que puede abarcar una aplicación, pero si aquellos fundamentales y que permitirán al estudiante completar el aprendizaje por cuenta propia una vez haya finalizado las lecciones..

(25) 1.2. OBJETIVOS. 25. El resultado final será una solución Xamarin, que permitirá exportar la aplicación a los sistemas operativos Android e iOS. La aplicación mostrará todas las estaciones de medición de calidad del aire de la ciudad de Madrid y sus mediciones, en formato lista y geoposicionado. Estos datos son públicos y se obtienen en tiempo real del Portal de Datos Abiertos del Ayuntamiento de Madrid. Las tres primeras prácticas muestran los conceptos más básicos: como montar el entorno de trabajo, la arquitectura de Xamarin, y como desarrollar interfaces que permitan obtener una aplicación con una estructura de navegación compleja. Por último, las dos prácticas finales abordan la creación de código compartido y código dependiente de la plataforma, siendo dos de los aspectos más interesantes a estudiar de la plataforma Xamarin..

(26) 26. CAPÍTULO 1. INTRODUCCIÓN.

(27) Capítulo 2 Marco tecnológico Este capítulo pretende mostrar el estado actual de las tecnologías relacionadas con el desarrollo de aplicaciones móviles.. 27.

(28) 28. 2.1.. CAPÍTULO 2. MARCO TECNOLÓGICO. Dispositivos móviles. Los dispositivos móviles son aparatos con capacidad computacional y con un tamaño tal, que permite transportarlos con nosotros cómodamente. La gran mayoría dispone de un medio de conexión a Internet, directo o a través de otros dispositivos, así como un sinfín de medios de entrada/salida como teclados, pantallas táctiles, cámaras fotográficas, wifi, bluetooth, etc. Todo esto ha provocado que los dispositivos móviles revolucionen nuestra sociedad en la última década. Elementos con una funcionalidad clara e inmutable durante décadas o siglos, han ampliado sus capacidades redefiniendo su uso, como por ejemplo, el teléfono móvil, el reloj inteligente o el brazalete de control biométrico. Centrándonos en el tema de este proyecto, los teléfonos móviles han dejado de ser un dispositivo con una única funcionalidad, las llamadas de voz a través de la red telefónica. Actualmente disponen de tantas utilidades como podamos imaginar, gracias a las aplicaciones móviles. Haciendo uso de la nueva tecnología incorporada a los terminales, las aplicaciones se encargan de proveer nuevos usos o funcionalidades a los teléfonos móviles. Como por ejemplo, el GPS que permitió utilizar el teléfono como navegador para la conducción. El auge de estos terminales ha generado un gran mercado, con una gran variedad de modelos de teléfono móvil y, como consecuencia, de sistemas operativos móviles.. 2.2.. Sistemas operativos móviles. A continuación, estudiaremos los dos sistemas operativos que nos ocupan en este proyecto, Android e iOS, que como se ha comentado anteriormente, representan casi el 100 % del mercado.. 2.2.1.. Android. Android es el sistema operativo móvil de Google. Posee licencia Apache y esta basado en el kernel de Linux, por lo que es un sistema abierto. Comenzó a ser desarrollado en 2004 por Android Inc, que fue comprada por Google más tarde. El desarrollo fue completado por la propia Google y el consorcio de empresas tecnológicas Open Handset Alliance, que finalmente lanzarían su primera versión en 2008. Actualmente se encuentra en la versión 7.1.2, llamada Nougat. Utiliza como lenguaje principal de programación Java, pudiendo ser utilizado con-.

(29) 2.2. SISTEMAS OPERATIVOS MÓVILES. 29. juntamente con C o C++. También es posible desarrollar aplicaciones en Go, aunque todavía es una posibilidad un poco limitada respecto de Java. Por último, Google ha anunciado en Mayo de 2017, que dará soporte al lenguaje de programación Kotlin para desarrollar aplicaciones Android.. Figura 2.1: Logo Android Nougat Al ser un sistema abierto, ha sido utilizado por un sinfín de compañías fabricantes de terminales, colonizando todas las gamas del mercado, desde los terminales más novedosos y caros a los más económicos, convirtiéndose así en el claro dominador mundial. Sin embargo, este hecho le acarrea uno de sus mayores inconvenientes, la inabarcable cantidad de dispositivos con diferente hardware así como lo fragmentada que se encuentra la distribución del sistema operativo.. Figura 2.2: Distribución de versiones Android en el mercado, Mayo 2017.

(30) 30. CAPÍTULO 2. MARCO TECNOLÓGICO. Esto provoca que, para que la experiencia de usuario alcance altas cotas de calidad, se debe invertir mucho tiempo en el desarrollo. El tiempo se consume principalmente en control de errores en las diferentes versiones del sistema operativo, que aun se encuentran en funcionamiento, y en ajustar la interfaz a los diferentes tipos de terminales. Dicho esto, Android es el sistema ideal para realizar betas para un solo sistema por dos motivos: costes y distribución. Los costes son bajos ya que existen terminales muy económicos y no es necesaria una licencia. La distribución es sencilla, ya que no es necesario utilizar el canal oficial Google Play, es posible exportar la aplicación e instalarla en cualquier terminal directamente. Esto confiere de gran agilidad al desarrollo, pues no hay tiempos de espera ni controles de terceros.. 2.2.2.. iOS. iOS es el sistema operativo creado por Apple Inc. para sus dispositivos móviles iPhone, iPad e iPod Touch. Es un sistema cerrado y exclusivo de estos dispositivos. De esta forma, según Apple, los terminales son más seguros, y además les permite proveer de una experiencia de usuario perfecta. La primera versión de iPhone OS fue presentada por Apple en 2007, basándose en el kernel XNU de Darwin (BSD). Cada año desarrollan una nueva versión del sistema, por lo que actualmente nos encontramos en la versión iOS 10.. Figura 2.3: Logo iOS 10 Los lenguajes utilizados para programar en este sistema son Swift y Objective-C, pudiendo escribir algunas partes en C o C++. Apple ejerce un control férreo sobre las aplicaciones desarrolladas para sus dispositivos, ya que solo se pueden desarrollar disponiendo de un ordenador con sistema operativo Mac OS. Además para distribuir las aplicaciones a través del canal oficial, la App Store, deben pasar una revisión exhaustiva tanto del código como de los contenidos que mostrarán. Todo lo comentado anteriormente, ha generado un ecosistema seguro, pero con unos costes altos tanto en la compra de los terminales como en el desarrollo de aplicaciones. Esto provoca, que se deba desarrollar para este.

(31) 2.2. SISTEMAS OPERATIVOS MÓVILES. 31. sistema si se quiere abarcar todo el mercado, pero que sea una opción muy poco interesante para desarrollar betas o productos que aun se encuentran en una fase de definición o que requerirán de muchas iteraciones sobre el desarrollo.. 2.2.3.. Otros sistemas operativos. Existen otros sistemas aparte de los mencionados anteriormente. Sin embargo, estos sistemas a pesar de contar con una larga trayectoria, o nunca llegaron a ocupar una cuota considerable del mercado, o la incapacidad de adaptación les hizo perderla. 2.2.3.1.. Windows Mobile. Windows Mobile es el sistema operativo de Microsoft, desarrollado basándose en el kernel de Windows NT. Es cerrado y propietario. Fue presentado en 2010, llegando a ocupar la tercera posición del mercado, a distancia de iOS y Android. Su momento de mayor expansión llegó gracias a la expectación generada por su alianza con Nokia, aunque finalmente no dio los resultados esperados y se separaron. Su actual versión es Windows 10 Mobile. En el ultimo año ha perdido la gran mayoría de su cuota, pasando a ser residual en comparación con los líderes del mercado.. Figura 2.4: Logo Windows 10 Mobile 2.2.3.2.. BlackBerry OS. BlackBerry OS es el sistema operativo de BlackBerry Limited, desarrollado basándose en QNX OS. Es cerrado y propietario. Fue presentado en el año 1999, convirtiéndose en uno de los dominadores del mercado y líder absoluto en el sector corporativo. Al igual que en el caso de iOS, solo montaba su sistema en sus propios teléfonos, siendo el principal argumento la seguridad. Gracias a ello, a la buena integración con el correo electrónico corporativo y a otros motivos, como un teclado físico que fue revolucionario en su momento, este ecosistema gozó de un gran éxito, sobre todo en la década de los 2000. Sin embargo, la entrada de nuevos competidores que redefinieron el segmento de la telefonía móvil y la reticencia al cambio de la propia BlackBerry, fueron paulatinamente haciéndole caer en ventas hasta prácticamente desaparecer..

(32) 32. CAPÍTULO 2. MARCO TECNOLÓGICO. Figura 2.5: Logo BlackBerry 10 Su desarrollo se ha detenido, aunque la compañía sigue dando soporte y proveyendo de actualizaciones a sus usuarios. Actualmente BlackBerry se encuentra centrada en la fabricación de terminales con sistema operativo Android.. 2.3.. Tecnologías de desarrollo de aplicaciones multiplataforma. En esta sección vamos a analizar las diferentes opciones que ofrece el mercado para el desarrollo de aplicaciones móviles multiplataforma.. 2.3.1.. Apache Cordova. Anteriormente conocido como PhoneGap, Apache Cordova es el entorno de desarrollo más extendido para desarrollar aplicaciones multiplataforma. Originalmente desarrollado por Nitobi Software, fue adquirido por Adobe en 2011[1]. Coincidiendo con la adquisición, fue liberado su código fuente mediante licencia Apache[6] y pasó a conocerse por su actual denominación.. Figura 2.6: Logo Apache Cordova Apache Cordova combina la posibilidad de programar la interfaz de la aplicación mediante JavaScript, HTML5 y CSS3, con el acceso a la API del dispositivo también mediante JavaScript. A este tipo de aplicaciones se les denomina híbridas, ya que si bien su comportamiento es similar a un sitio.

(33) 2.3. TECNOLOGÍAS DE DESARROLLO DE APLICACIONES MULTIPLATAFORMA33 web, también son capaces de acceder a la API del teléfono y se instalan y acceden como una aplicación corriente.. Figura 2.7: Arquitectura Apache Cordova En la figura 2.7 [5] podemos observar el esquema de la arquitectura de una aplicación Apache Cordova. La pieza central de la arquitectura es la WebView. Se encarga de comunicar la WebApp y los plugins con el sistema operativo y de renderizar la interfaz de usuario. La WebApp contiene el código de la aplicación y sus recursos (imágenes, ficheros, etc), definiendo la interfaz de la aplicación y su comportamiento. Por último, los plugins, los cuales son parte fundamental de la plataforma. Ofrecen acceso directo a las APIs nativas del dispositivo a través de JavaScript, simplificando el desarrollo. En este punto, debemos diferenciar dos tipos de plugins, aquellos que son considerados parte de los fundamentos de Cordova y los realizados por terceros. Mientras los últimos tienen múltiples propósitos, los plugins que forman parte del núcleo de Cordova facilitan el trabajo con los componentes del teléfono como pueden ser cámara, Bluetooth, acelerómetros, GPS, etc. Apache Cordova define su filosofía como “escribe una vez”, objetivo al cual se enfoca su arquitectura. Sin embargo, al igual que con los navegadores de escritorio, estas aplicaciones acaban necesitando ajustes para cada plataforma, especialmente si se quiere optimizar el resultado final en cuanto.

(34) 34. CAPÍTULO 2. MARCO TECNOLÓGICO. a aspecto y rendimiento, el cual se resiente con las rutinas multitarea, las interfaces complejas o el uso de la cámara[9]. Como conclusión, destacar que si bien Apache Cordova se acerca bastante a su objetivo, no lo alcanza completamente. Para obtener un resultado profesional se deberán realizar ajustes en cada plataforma, vigilando que el rendimiento de la aplicación no decaiga. Además, la interfaces están construidas con elementos HTML y no con elementos nativos, por lo que el comportamiento no será exactamente el esperado en una aplicación. Por todos estos motivos, se ha considerado más interesante Xamarin como tema a desarrollar en el presente proyecto.. 2.3.2.. Appcelerator Titanium. Appcelerator Titanium es un entorno de desarrollo de aplicaciones multiplataforma de código abierto. Desarrollado por Appcelerator, fue lanzado inicialmente para aplicaciones de escritorio únicamente. En 2009 introdujo el desarrollo para Android e iOS, separando el desarrollo móvil y escritorio en 2012. En 2016 Appcelerator fue comprada por la compañía Axway.. Figura 2.8: Logo Appcelerator Titanium. Titanium provee de un IDE basado en Eclipse, así como un SDK, con el cual programar en Javascript como lenguaje de alto nivel. Utiliza XML para la construcción de las vistas y TSS (Titanium Style Sheet) para los estilos. Los archivos TSS son similares a JSON, y definen los estilos que más tarde serán utilizados como atributos del XML de la vista. El resultado de la exportación será una interfaz bastante similar a las interfaces nativas..

(35) 2.3. TECNOLOGÍAS DE DESARROLLO DE APLICACIONES MULTIPLATAFORMA35. Figura 2.9: Arquitectura Appcelerator Titanium Titanium se define a si mismo como un puente entre el sistema operativo nativo y el código de la aplicación, como puede observarse en la figura 2.9. En el nivel inferior tenemos el sistema operativo correspondiente y en la parte superior la aplicación codificada en Javascript, encontrándose Titanium entre ambos. La aplicación solicitará la creación de elementos de la interfaz, nuevas pantallas, etc a través de las APIs de Titanium que se encargarán de interpretar las peticiones, para servírselas al sistema operativo. Así mismo, Titanium se encargará de hacer accesibles a la aplicación los eventos generados en el sistema operativo, completando la comunicación bidireccional entre sistema operativo y la aplicación Javascript. Como conclusión, podemos decir que Appcelerator ha adoptado una solución muy similar a Xamarin. Ambos proveen como producto final una aplicación nativa, y no una web encapsulada en una aplicación. Sin embargo, en el caso de Titanium esta definición no es exacta. Los objetos nativos son compilados como código nativo, pero no la lógica de negocio que se mantendrá en Javascript y será interpretada en tiempo de ejecución por JavaScriptCore. Por lo tanto, siendo superior en rendimiento a PhoneGap, no es comparable a las cotas de rendimiento alcanzadas por Xamarin..

(36) 36. CAPÍTULO 2. MARCO TECNOLÓGICO.

(37) Capítulo 3 Xamarin En este capitulo se realizará un recorrido a través de las bases de Xamarin. El objetivo es alcanzar un mejor conocimiento de la plataforma Xamarin y de su paquete Xamarin.Forms.. 37.

(38) 38. 3.1.. CAPÍTULO 3. XAMARIN. Introducción. Xamarin es un entorno de desarrollo de aplicaciones multiplataforma, tanto para desarrollos de escritorio como móvil. La compañía Xamarin Inc., con sede en California, es propiedad de Microsoft. Actualmente trabajan en la compañía más de 350 empleados y cuentan con 1.4 millones de desarrolladores que utilizan su plataforma de desarrollo por todo el mundo[20].. Figura 3.1: Logo Xamarin Su misión es que desarrollar aplicaciones móviles geniales sea fácil, rápido y divertido, mediante la creación de las mejores herramientas de desarrollo software en el mundo. Para ello, suministran su plataforma de código abierto, liberada bajo licencia MIT, que incluye tanto Xamarin SDK como sus plugins e IDEs. A partir de un solo desarrollo en C#, Xamarin permite crear aplicaciones nativas para los entornos Android, iOS, Windows Mobile, macOS y Windows. Dependiendo de la vía elegida para el desarrollo, la cantidad de código compartido podrá ser la totalidad del mismo o limitarse a la lógica de negocio, como veremos en los siguientes apartados.. 3.2.. Historia. Los inicios de Xamarin se remontan más allá de la fundación de la compañía. Era el año 2000, Microsoft acababa de lanzar .NET y CLI se había publicado como un standard abierto. Miguel de Icaza y Nat Friedman, fundadores de Xamarin, vieron en ello una oportunidad para mejorar la productividad de los desarrollos y se centraron en crear una versión para Linux desde su anterior compañía, Ximian. El proyecto se llamaría Mono, pero dado que no contaban con los recursos necesarios para completarlo, en 2001 decidieron publicarlo como código abierto para obtener la ayuda de otros desarrolladores..

(39) 39. 3.2. HISTORIA. Figura 3.2: Logo del proyecto Mono Tras varios años de desarrollo, se publicó Mono 1.0. Había pasado de tener su único foco en el desarrollo de aplicaciones Linux, a soportar una amplia variedad de sistemas. Ximian fue comprada por Novell en 2003, un año antes de la publicación de Mono. Durante este periodo el proyecto creció, lanzando las primeras versiones de MonoTouch y Mono For Android, en 2009 y 2011 respectivamente. Novell dio soporte a la plataforma hasta 2011. Aquel año, Novell fue comprada por Attachmate, anunciando el despido de una gran cantidad de los desarrolladores del proyecto Mono. A raíz de estos acontecimientos, Miguel de Icaza anunció que continuaría el desarrollo y soporte de Mono desde una nueva compañía, Xamarin. Fue un periodo de incertidumbre, de Icaza había perdido su equipo de trabajo y la licencia de Mono pertenecía a Attachmate. Llegó incluso a plantearse la posibilidad de volver a realizar los desarrollos por completo desde cero, pero seguía sin aclararse como demostrarían que los nuevos desarrollos de Xamarin no hacían uso de la tecnología desarrollada en Mono. Sin embargo, todo se acabó solucionando poco tiempo después. Novell anunció que entregaba una licencia a perpetuidad a Xamarin y gran parte del antiguo equipo del proyecto Mono se unió a de Icaza en esta nueva aventura. El proyecto continuó evolucionando, lanzando actualizaciones periódicas, algunas casi simultáneas al lanzamiento de las nuevas versiones de los sistemas operativos, como puede observarse en las tablas 4.1 y 3.1. En la búsqueda de hacer que los desarrollos fueran más sencillos, crearon su propio IDE, Xamarin Studio, y un plugin para Visual Studio. Finalmente, en Febrero de 2016 fue adquirida por Microsoft, que decidió abrir el código bajo licencia MIT y pasó a ofrecer gratuitamente muchos de los servicios del nivel Enterprise. Además, posicionó Xamarin como su producto estrella para el desarrollo móvil dentro del entorno de Visual Studio,.

(40) 40. CAPÍTULO 3. XAMARIN. incluyendo el paquete Xamarin en la instalación por defecto, preinstalando algunos de sus componentes y ofreciendo una fácil integración con los servicios de Microsoft Azure.. Versión. Notas. Fecha. MonoTouch 1. Versión inicial. 09/2009. MonoTouch 2. Soporte para iPad. 04/2010. MonoTouch 3. Soporte para iPhone 4. 04/2010. MonoTouch 4. Soporte para iOS 4. 04/2011. MonoTouch 5. Soporte para iOS 5. 10/2011. MonoTouch 6. Soporte para iOS 6. 09/2012. Xamarin.iOS 6.2. Soporte para Visual Studio. 02/2013. Xamarin.iOS 7. Soporte para iOS 7. 09/2013. Xamarin.iOS 8. Soporte para iOS 8. 09/2014. Xamarin.iOS 9. Soporte para iOS 9. 09/2015. Xamarin.iOS 10. Soporte para iOS 10. 09/2016. Tabla 3.1: Histórico de versiones Xamarin.iOS. Versión. Notas. Fecha. Mono For Android 1. Versión inicial (Android 2.2). 04/2011. Mono For Android 4. Soporte para Android 3 y 4. 12/2011. Xamarin.Android 5. Soporte para Android 5. 04/2015. Xamarin.Android 6. Soporte para Android 6. 11/2015. Xamarin.Android 7. Soporte para Android 7. 09/2016. Tabla 3.2: Histórico de versiones Xamarin.Android.

(41) 3.3. ARQUITECTURA. 3.3.. 41. Arquitectura. En esta sección estudiaremos la arquitectura de la plataforma para cada uno de los sistemas operativos y su interacción dentro del entorno de ejecución Mono. Nótese que cuando se habla de código administrado, es aquel que corre en el entorno Mono y código nativo aquel que corre específicamente en la plataforma nativa.. 3.3.1.. Android. La base de la arquitectura de Xamarin.Android es el kernel Linux. Sobre él, corren los entornos Mono y ART (Android Runtime). Ambos se encargan de hacer accesibles a los desarrolladores las APIs que posibilitan la interacción con el sistema operativo. Mono brinda la posibilidad de usar todas las librerías de .NET, así como Android Runtime hace accesible el uso de las librerías de Java y Android. Esto permite el uso de las herramientas del sistema operativo mediante un acceso de bajo nivel, ya sea a través de Mono o de ART.. Figura 3.3: Arquitectura Xamarin.Anroid Como puede verse en la figura 3.3, existe una comunicación bidireccional entre el código administrado y ART. Cuando Android necesita invocar código en la aplicación recurre a los ACWs (Android Callable Wrappers). Son los encargados de registrar los tipos, ya que ART no permite el registro de tipos en tiempo de ejecución. Cada vez que ART quiere ejecutar un método que ha sido sobrescrito o implementado en el código administrado, Xamarin.Android debe resolverlo para proveer a ART el método correcto. De igual manera sucede con los MWCs (Managed Callable Wrappers), aunque en sentido contrario. Son un puente JNI que permite que el códi-.

(42) 42. CAPÍTULO 3. XAMARIN. go administrado invoque, sobrescriba e implemente los métodos de Java y Android.. 3.3.2.. iOS. La base de la arquitectura de Xamarin.iOS es el kernel XNU. Sobre él corren los dos entornos de ejecución, Full AOT (Mono) y Objective-C. Ambos se encargan de hacer accesibles a los desarrolladores las APIs que posibilitan la interacción con el sistema operativo, como se ha visto anteriormente en el caso de Android.. Figura 3.4: Arquitectura Xamarin.iOS. Al compilar una aplicación Xamarin, Mono compilará el código en C# obteniendo código MSIL (Microsoft Intermediate Language), que a su vez será compilado por CLR (.NET Common Language Runtime) usando el compilador JIT (Just in Time). El resultado de la compilación de JIT será finalmente compilado como código nativo en tiempo de ejecución..

(43) 3.4. XAMARIN.FORMS. 43. Figura 3.5: Compilación AOT Esta estructura tan compleja nace de la restricción de seguridad de Apple, que no permite la ejecución de código generado dinámicamente. Debido a ello, Full AOT tiene algunas limitaciones especialmente con el uso de tipos genéricos. En el caso de Xamarin.iOS, la comunicación bidireccional se realiza mediante Selectores y Registradores. Los Selectores permiten al código administrado acceder al entorno de Objective-C. Un Selector es un mensaje que se envía a una clase o instancia de Objective-C. Los Registradores hacen accesible el código administrado a Objective-C. Esto se consigue gracias a la creación de un listado con todas las clases que derivan de NSObject. Durante el arranque de la aplicación se registrarán dinámicamente las clases, categorías y protocolos. También existen registradores estáticos, creados en tiempo de compilación, que mejoran la velocidad del arranque de la aplicación.. 3.4.. Xamarin.Forms. Xamarin.Forms es una librería Xamarin que permite crear interfaces nativas con una sola codificación. En esta sección analizaremos y estudiaremos en profundidad que nos ofrece Xamarin.Forms.. 3.4.1.. Introducción. Xamarin lanzó Xamarin.Forms en 2014 para simplificar el proceso de creación de interfaces nativas. Permite abstraerse de las plataformas en las que se esta trabajando, eliminando la necesidad de codificar una interfaz.

(44) 44. CAPÍTULO 3. XAMARIN. diferente por plataforma. También incluye herramientas para la inyección de dependencias, navegar por la aplicación o utilizar el patrón Modelo-VistaVistaModelo, como veremos en las siguientes secciones de este capítulo.. 3.4.2.. Estructura de la aplicación. Solución es el nombre que da Xamarin al espacio de trabajo de una aplicación. La solución de una aplicación construida con Xamarin.Forms estará formada por tantos proyectos como sistemas operativos deba soportar la aplicación, más otro proyecto adicional que contendrá el código compartido escrito en C# y XAML. Este proyecto puede ser un Shared Asset Project (SAP) o una Portable Class Library (PCL).. Figura 3.6: Estructura de capas Xamarin.Forms.

(45) 3.4. XAMARIN.FORMS. 45. Las librerías Xamarin.Forms.Core y Xamarin.Forms.Xaml contienen la implementación de la API de Xamarin.Forms en la que se apoya nuestro proyecto SAP o PCL. Estas a su vez hacen uso de las librerías específicas de cada plataforma Xamarin.Forms.Platform, las cuales se encargan de transformar las interfaces de Xamarin.Forms en las interfaces nativas correspondientes.. 3.4.3.. XAML. Extensible Application Markup Language (XAML) es un lenguaje desarrollado por Microsoft, basado en XML, cuyo propósito es la instanciación e inicialización de objetos. En el caso de Xamarin.Forms es el encargado de la creación y configuración de las interfaces de usuario, mediante su definición jerárquica en árbol. <?xml version="1.0" encoding="utf-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" Title="Ejemplo"> <AbsoluteLayout HorizontalOptions="FillAndExpand" VerticalOptions="FillAndExpand"> <Label Text="Ejemplo XAML" IsVisible="True" HorizontalTextAlignment="Center" VerticalOptions="CenterAndExpand" TextColor="Black"/> </AbsoluteLayout> </ContentPage>. Fragmento de Código 3.1: Ejemplo de código XAML Las clases de Xamarin.Forms son elementos en XAML, así como sus propiedades son atributos. Por ello, como veíamos en el fragmento de código 3.1, la clase Label aparece como un elemento de XAML y sus propiedades, por ejemplo isVisible, pasan a ser atributos. Para poder ser instanciadas en XAML las clases deben disponer de un constructor sin parámetros y para que las propiedades puedan ser usadas como atributos, deben disponer de un método set público. El uso de XAML no es obligatorio, ya que cualquier cosa que se pueda hacer con XAML se puede hacer con C#..

(46) 46. 3.4.4.. CAPÍTULO 3. XAMARIN. MVVM. MVVM es un patrón de presentación diseñado para controlar la separación entre la interfaz de usuario y el resto de la aplicación. El patrón cuenta con cuatro elementos principales: Modelos, Vistas, VistaModelos y Data Binding.. Figura 3.7: Interacción entre elementos MVVM. 3.4.4.1.. Data Binding. Data Binding es la conexión de dos objetos de tal forma que siempre se encuentren sincronizados. En MVVM el ejemplo más claro son los DataBindings entre propiedades presentes en la Vista y el VistaModelo. Así, cuando la propiedad es modificada en la Vista, es actualizada en el VistaModelo y viceversa. Juega un papel fundamental en el patrón MVVM. Para ello es necesario que el objeto destino apunte su BindingContext al objeto de origen. Además, el objeto destino debe llamar al método setBinding indicándole que propiedades quiere enlazar, ya sea invocando el método en C# o con la extensión de marcado Binding en XAML. La propiedad a enlazar debe heredar de BindableObject. En el fragmento de código 3.2 podemos ver un ejemplo de DataBinding en XAML. El BindingContext de ContentPage (Vista) referencia a MyViewModel (VistaModelo), mientras que Label enlaza su propiedad Text con la propiedad Name de MyViewModel..

(47) 3.4. XAMARIN.FORMS. 47. <ContentPage Title="Ejemplo Binding XAML"> <ContentPage.BindingContext> <viewModels:MyViewModel/> </ContentPage.BindingContext> <Label Text="{Binding Name}"/> </ContentPage>. Fragmento de Código 3.2: Ejemplo DataBinding XAML La creación de un DataBinding en C# se muestra en el fragmento de código 3.3. El BindingContext de la variable Label referencia a la variable data, y su propiedad Text es enlazada con la propiedad Name de data. var label = new Label (); label.SetBinding (Label.TextProperty, "Name"); var data = new {Name = "Pepe"}; label.BindingContext = data; Debug.WriteLine (label.Text); //Mostrará "Pepe". Fragmento de Código 3.3: Ejemplo DataBinding C# 3.4.4.2.. Modelo. Los modelos representan entidades de la aplicación. Encapsulan la lógica de negocio y los datos, asegurando la consistencia y validez de los mismos mediante las reglas de negocio y la lógica de validación. No deben referenciar la Vista ni el VistaModelo, sino que se deben implementar las interfaces INotifyPropertyChanged e INotifyCollectionChanged, responsables de notificar al VistaModelo los cambios que se produzcan en el Modelo. namespace EjemplosMVVM.Models { public class Item { public Item (){} public int Id { get;set;} public string Name { get;set;} } }. Fragmento de Código 3.4: Ejemplo Modelo.

(48) 48. CAPÍTULO 3. XAMARIN. 3.4.4.3.. VistaModelo. Los VistaModelos actúan de intermediarios de la comunicación entre Modelo y Vista. Controlan y modifican las vistas, actuando como contexto de la información. El VistaModelo no tiene referencia de la Vista ni conoce su implementación, es la Vista quien lo referencia a él. Un VistaModelo esta compuesto por propiedades y comandos. Estas propiedades, pertenecientes a los modelos, se encuentran enlazadas a las vistas, ya sea para proveerlas de información a mostrar o para recoger la información introducida por el usuario. Los comandos son acciones que se ejecutan al dispararse los eventos producidos en la vista. namespace EjemplosMVVM.ViewModels { //El VistaModelo implementa la interfaz INotifyPropertyChanged public class ItemViewModel : INotifyPropertyChanged { //Método que gestionará el evento cuando la propiedad cambie public event PropertyChangedEventHandler PropertyChanged; //ObservableCollection implementa INotifyCollectionChanged private ObservableCollection<Item> items = new ObservableCollection<Item>(); public ObservableCollection<Item> Items { get { return items; } set { items = value; OnPropertyChanged(); } } public ItemViewModel(){} public void OnPropertyChanged([CallerMemberName] string propertyName = "") { //Comprobamos si ha cambiado de valor y es válido var changed = PropertyChanged; if (changed == null)return; //Lanzamos el evento changed(this, new PropertyChangedEventArgs(propertyName)); } } }. Fragmento de Código 3.5: Ejemplo VistaModelo.

(49) 3.4. XAMARIN.FORMS 3.4.4.4.. 49. Vista. Las vistas representan las pantallas de una aplicación, con todos los elementos que la componen, definiendo su estructura y aspecto. En una implementación ideal, el código de la Vista solo contendrá un constructor que llamará al método InitializeComponent. Este método es el encargado de realizar la inicialización e instanciación de todos los objetos definidos en el fichero XAML de la Vista. La Vista solo debe implementar en código aquellas acciones que sean demasiado complejas para definirse en XAML, como por ejemplo las animaciones. La Vista recibe la información a mostrar del VistaModelo. Para poder recibir las notificaciones de los cambios que se produzcan en los datos, la Vista debe referenciar al VistaModelo correspondiente a través de la propiedad BindingContext.. namespace EjemplosMVVM.Views { public partial class ItemPage : ContentPage { public ItemViewModel ViewModel { get { return BindingContext as ItemViewModel; } } public ItemPage() { InitializeComponent(); BindingContext = new ItemViewModel(); } } }. Fragmento de Código 3.6: Ejemplo Vista fichero C#. En el fragmento de código 3.6 vemos como el constructor de la vista inicializa los componentes de la Vista, presentes en el fichero XAML, y como referencia el BindingContext al VistaModelo. En Xamarin.Forms las vistas se definen en dos ficheros, uno en C# y otro XAML..

(50) 50. CAPÍTULO 3. XAMARIN. <?xml version="1.0" encoding="utf-8"?> <ContentPage Title="Ejemplo Vista" xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" xmlns:local="clr-namespace:EjemplosMVVM" x:Class="Views.ItemPage">  <ListView x:Name="listView" ItemsSource="{Binding Items}"> <ListView.ItemTemplate> <DataTemplate>  <TextCell Text="{Binding Name}" Detail="{Binding Id}"/> </DataTemplate> </ListView.ItemTemplate> </ListView> </ContentPage>. Fragmento de Código 3.7: Ejemplo Vista fichero XAML En el fichero XAML del fragmento de código 3.7 podemos ver la estructura de la interfaz de ItemPage. Se ha incluido una Lista enlazada con la colección del VistaModelo, produciendo un listado con los Items. A su vez, cada celda ha sido enlazada con las propiedades del objeto Item. Así hemos conectado la comunicación entre Vista y VistaModelo, y cada vez que la información cambie en la colección, cambiará la lista.. 3.4.5.. Inyección de dependencias y Servicios específicos de la plataforma. La inyección de dependencias es un servicio que ofrece Xamarin.Forms para poder definir comportamientos específicos en cada plataforma. El responsable de encontrar la implementación adecuada para cada plataforma será el DependencyService. Para poder hacer uso del DependencyService se debe contar con los siguientes elementos: • Interfaz: define la funcionalidad que pretende hacer uso del DependencyService. Debe estar presente en el código compartido. • Implementación específica: la funcionalidad definida en la interfaz debe ser implementada en cada uno de los proyectos de las plataformas. Si.

(51) 3.4. XAMARIN.FORMS. 51. una de las plataformas no implementara la interfaz provocaría un fallo cuando se intentase ejecutar. • Registro: cada implementación de la interfaz debe registrarse en el DependencyService para poder ser resuelta y servida en tiempo de ejecución. • Llamar a DependencyService: para poder ejecutar la funcionalidad específica debemos solicitar al DependencyService que resuelva la interfaz. La solicitud se realiza explícitamente con la estructura DependencyService.Get<Interfaz>().método().. Figura 3.8: Inyección de dependencias. 3.4.6.. Elementos UI Xamarin.Forms. En este apartado vamos a hacer un recorrido por los diferentes elementos con que cuenta Xamarin.Forms para construir interfaces. 3.4.6.1.. Pages. La clase Page es un elemento visual que ocupa toda la pantalla y que tiene una única vista hija. A continuación veremos los diferentes tipos de clases Page y sus funcionalidades..

(52) 52. CAPÍTULO 3. XAMARIN. Figura 3.9: Tipos de Page TemplatedPage es una clase Page que muestra el contenido a pantalla completa. Es la base de la clase ContentPage.. Figura 3.10: Visualización TemplatedPage ContentPage es una clase que hereda de TemplatedPage. Muestra una sola vista, normalmente un contenedor como un layout o un ScrollView.. Figura 3.11: Visualización ContentPage.

(53) 3.4. XAMARIN.FORMS. 53. MasterDetailPage es una clase Page con dos paneles. El primero maneja la información a alto nivel (por ejemplo una lista) y el segundo panel muestra la información en detalle. Para que muestre la barra de navegación es necesario encapsularla en una NavigationPage.. Figura 3.12: Visualización MasterDetailPage. NavigationPage es una clase Page capaz de manejar la navegación a través de la pila de Pages, encapsulándolas como su contenido y mostrando el estado en su propia barra de navegación.. Figura 3.13: Visualización NavigationPage. TabbedPage es una clase que hereda de MultiPage. Esta clase permite navegar mediante pestañas por sus hijos, los cuales también son clases Page ..

(54) 54. CAPÍTULO 3. XAMARIN. Figura 3.14: Visualización TabbedPage. CarouselPage es una clase que hereda de MultiPage. Permite navegar por sus hijos mediante gestos. Las Page hijas se desplazan horizontalmente, creando un efecto carrusel.. Figura 3.15: Visualización CarouselPage. 3.4.6.2.. Layouts. Los layouts son vistas contenedoras, que pueden contener layouts o vistas, permitiendo decidir la posición y tamaño de las vistas contenidas. A continuación se ofrece una descripción de los mismos y ejemplos XAML para los más complejos..

(55) 3.4. XAMARIN.FORMS. 55. Figura 3.16: Tipos de Layout TemplatedView es un layout que muestra el contenido con un Control Template, el cual reemplazará los estilos existentes previamente. Es la clase padre de ContentView. ContentPresenter es un administrador de layouts para TemplatedViews. Hereda directamente de la clase Layout. Se usa conjuntamente con ControlTemplate para decidir donde se muestran los contenidos. ContentView es un layout que hereda de TemplatedView y muestra un único contenido. No es de gran utilidad por si mismo, pero es un buen punto de partida para crear layouts personalizados. ScrollView es un layout cuya principal capacidad es desplazarse horizontal o verticalmente tanto como sea necesario para mostrar todo el contenido que encapsula. <ContentPage.Content> <ScrollView></ScrollView> </ContentPage.Content>. Fragmento de Código 3.8: Ejemplo de ScrollView XAML.

(56) 56. CAPÍTULO 3. XAMARIN. Frame es un layout que hereda de ContentView. Contiene un único hijo y provee de diferentes posibilidades de enmarcado.. </ContentPage.Content> <Frame OutlineColor="Black"> <Label Text="Xamarin" /> </Frame> </ContentPage.Content>. Fragmento de Código 3.9: Ejemplo de Frame XAML. AbsoluteLayout es un layout que permite posicionar a sus hijos de forma absoluta. Se puede realizar mediante coordinadas proporcionales, coordinadas de la pantalla del dispositivo o una combinación de ambas.. <ContentPage.Content> <AbsoluteLayout> <BoxView BackgroundColor="Red" AbsoluteLayout.LayoutBounds="20, 100, 40, 30"></BoxView> <Label Text="Xamarin" AbsoluteLayout.LayoutBounds="200, 200, Autosize, Autosize"></Label> </AbsoluteLayout> </ContentPage.Content>. Fragmento de Código 3.10: Ejemplo de AbsoluteLayout XAML. Grid es un layout que permite organizar las vistas hijas en columnas y filas, que pueden ser de diferentes anchuras y alturas..

(57) 3.4. XAMARIN.FORMS. 57. <ContentPage.Content> <Grid Padding="5" HeightRequest="50" VerticalOptions="Start"> <Grid.RowDefinitions> <RowDefinition Height="Auto"> </RowDefinition> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="30"> </ColumnDefinition> <ColumnDefinition Width="*"> </ColumnDefinition> </Grid.ColumnDefinitions> <Grid.Children> <Image Source="xamarin.png" Grid.Column="0"> </Image> <Label Text="Xamarin" Grid.Column="1"> </Label> </Grid.Children> </Grid> </ContentPage.Content>. Fragmento de Código 3.11: Ejemplo de Grid XAML StackLayout es un layout que apila las vistas de forma horizontal o vertical. No es necesario indicar la posición de las vistas hijas, lo calculará StackLayout, por lo que cualquier indicación de posición será sobrescrita. <ContentPage.Content> <StackLayout Orientation="Vertical"> <Label Text="Left"></Label> <Label Text="Center"></Label> <Label Text="Right"></Label> </StackLayout> </ContentPage.Content>. Fragmento de Código 3.12: Ejemplo de StackLayout XAML RelativeLayout es un layout que permite posicionar y dar tamaño a sus vistas hijas en relación a otros componentes. Por ejemplo, posicionar el borde superior de una vista a la misma altura que el borde superior del RelativeLayout o que la anchura de la vista sea la mitad de la anchura del RelativeLayout..

(58) 58. CAPÍTULO 3. XAMARIN. <ContentPage.Content> <RelativeLayout> <BoxView RelativeLayout.XConstraint= "{ConstraintExpression Type=RelativeToParent, Property=Width, Factor=0.3}" RelativeLayout.YConstraint="{ConstraintExpression Type=RelativeToParent, Property=Height, Factor=0.2}" RelativeLayout.WidthConstraint="{ConstraintExpression Type=RelativeToParent, Property=Width, Factor=0.3}" RelativeLayout.HeightConstraint="{ConstraintExpression Type=Constant, Property=Height, Constant=100}" /> </RelativeLayout> </ContentPage.Content>. Fragmento de Código 3.13: Ejemplo de RelativeLayout XAML 3.4.6.3.. Views. En Xamarin cualquier objeto visible se llama vista. Todos estos elementos tienen en común que heredan de la clase View. A continuación se presentan las vistas más comunes en ambos sistemas. • ActivityIndicator: control visual para indicar que existe actividad, que algo esta en progreso.. Figura 3.17: Visualización ActivityIndicator. <ActivityIndicator Color="Red" IsRunning="true" />. Fragmento de Código 3.14: Ejemplo de ActivityIndicator • BoxView: vista empleada para dibujar rectángulos..

(59) 3.4. XAMARIN.FORMS <BoxView Color="Red" />. Fragmento de Código 3.15: Ejemplo de BoxView. • Button: una vista botón que reacciona ante los eventos táctiles.. Figura 3.18: Visualización Button. <Button Text="Click me!"/>. Fragmento de Código 3.16: Ejemplo de Button. • DatePicker: una vista que permite seleccionar fechas.. Figura 3.19: Visualización DatePicker. 59.

(60) 60. CAPÍTULO 3. XAMARIN. <DatePicker VerticalOptions="CenterAndExpand" Date="{x:Static sys:DateTime.Now}"> <DatePicker.Format>yyyy-MM-dd</DatePicker.Format> <DatePicker.MinimumDate> <sys:DateTime x:FactoryMethod="Parse"> <x:Arguments> <x:String>Jan 1 2000</x:String> </x:Arguments> </sys:DateTime> </DatePicker.MinimumDate> <DatePicker.MaximumDate> <sys:DateTime x:FactoryMethod="Parse"> <x:Arguments> <x:String>Dec 31 2050</x:String> </x:Arguments> </sys:DateTime> </DatePicker.MaximumDate> </DatePicker>. Fragmento de Código 3.17: Ejemplo de DatePicker • Entry: vista de entrada de texto de una única línea.. Figura 3.20: Visualización Entry. <Entry Text="I am an Entry" />. Fragmento de Código 3.18: Ejemplo de Entry • Editor: vista de entrada de texto con capacidad multilinea. <Editor Text="I am an Editor" />. Fragmento de Código 3.19: Ejemplo de Editor • Image: vista que muestra una imagen..

(61) 3.4. XAMARIN.FORMS. 61. <Image Source="xamarin.jpg" />. Fragmento de Código 3.20: Ejemplo de Image • Label: vista que muestra texto no editable. <Label FontSize = "20" Text="Hello world!" />. Fragmento de Código 3.21: Ejemplo de Label • ListView: vista que hereda de ItemView. Muestra una colección en formato lista vertical.. Figura 3.21: Visualización ListView. <ListView> <ListView.ItemTemplate> <DataTemplate> <TextCell Text="Hello world!"/> </DataTemplate> </ListView.ItemTemplate> </ListView>. Fragmento de Código 3.22: Ejemplo de ListView.

(62) 62. CAPÍTULO 3. XAMARIN • Picker: vista que permite la selección de un elemento de una lista. <Picker> <Items> <x:String>"A"</x:String> <x:String>"B"</x:String> </Items> </Picker>. Fragmento de Código 3.23: Ejemplo de Picker • ProgressBar: vista que permite saber el progreso de una tarea.. Figura 3.22: Visualización ProgressBar. <ProgressBar Progress="0.5"/>. Fragmento de Código 3.24: Ejemplo de ProgressBar • SearchBar: vista que permite realizar búsquedas textuales.. Figura 3.23: Visualización SearchBar. <SearchBar Placeholder="Search" SearchCommand="{Binding SearchCommand}">. Fragmento de Código 3.25: Ejemplo de SearchBar • Slider: vista que permite al usuario introducir un valor lineal.. Figura 3.24: Visualización Slider.

(63) 3.4. XAMARIN.FORMS. 63. <Slider ValueChanged="OnSliderValueChanged" />. Fragmento de Código 3.26: Ejemplo de Slider. • Stepper: vista que permite al usuario introducir un valor discreto, dentro de un rango.. Figura 3.25: Visualización Stepper. <Stepper ValueChanged="OnStepperValueChanged"/>. Fragmento de Código 3.27: Ejemplo de Stepper. • Switch: una vista que permite conmutar entre dos estados o valores.. Figura 3.26: Visualización Switch. <Switch IsToggled="True"/>. Fragmento de Código 3.28: Ejemplo de Switch. • TableView: una vista formada por filas de celdas..

(64) 64. CAPÍTULO 3. XAMARIN. Figura 3.27: Visualización TableView. <TableView> <TableRoot> <TableSection Title="Example"> <TextCell Text="Hello world!"/> </TableSection> </TableRoot> </TableView>. Fragmento de Código 3.29: Ejemplo de TableView • TimePicker: una vista que permite seleccionar una hora. <TimePicker Time="{x:Static sys:DateTime.Now}"/>. Fragmento de Código 3.30: Ejemplo de TimePicker • WebView: una vista que presenta contenido HTML. <WebView WidthRequest="1000" HeightRequest="1000" />. Fragmento de Código 3.31: Ejemplo de WebView.

(65) 3.4. XAMARIN.FORMS 3.4.6.4.. 65. Cells. Una celda es un elemento especializado que hereda de Element. No es una vista, sino que describe como crear una vista y sus vistas hijas. Todos los elementos que veremos a continuación heredan de la clase Cell y se usan principalmente en ListViews y TableViews. • EntryCell: es una celda que contiene un etiqueta y una caja para introducir texto. <EntryCell Label="{Binding comment}" Text="{Binding name}" />. Fragmento de Código 3.32: Ejemplo de EntryCell. Figura 3.28: Visualización EntryCell • SwitchCell: es una celda que contiene un etiqueta y una conmutador. <SwitchCell Text="{Binding name}" On="{Binding isOn}" />. Fragmento de Código 3.33: Ejemplo de SwitchCell. Figura 3.29: Visualización SwitchCell • TextCell: es una celda con dos textos. Típicamente como titulo y descripción. <TextCell Text="Xamarin" Detail="Cross Platform Apps"/>. Fragmento de Código 3.34: Ejemplo de TextCell.