apple ios vs google android adicto al androide

Hoy vamos a hablar de esto, pero viendo algunos de los cambios que padecerán los desarrolladores que pasen de iOS a Android. Dos sistemas distintos, cada uno con sus herramientas y sus secretos. Pasar de uno a otro es muchísimo más que copiar y pegar el código. De hecho ni siquiera sirve con adaptar cada una de las partes. Vamos a ver estas diferencias.

Contenidos de la página

Desarrollo iOS vs Android

Estructura del proyecto

La estructura de un proyecto en Xcode es muy libre, pues se crean carpetas y ficheros donde sea y se referencia luego todos ellos. A pesar de ello, hay cierta nomenclatura que se respeta (por ejemplo en iconos para diferentes resoluciones).

En contraposición, un proyecto Android es muy rígido. Hay muchísima nomenclatura que respetar tanto en ficheros como en carpetas, recursos… De esta forma, todo queda bien estructurado, especialmente para un correcto soporte en tanta cantidad de recursos diferentes que podemos encontrar (por ejemplo en resoluciones de pantalla).

Simuladores vs Emuladores

Aquí vemos una de las grandes sorpresas: el simulador de iOS es bastante más rápido comparado con el emulador de Android. Sin embargo, el emulador de iOS falla al dar una representación exacta de un dispositivo iOS.

El emulador de Android es una máquina virtual efectiva corriendo con una CPU virtualizada y memoria limitada, de forma que la simulación es mucho más realista que lo que ofrece el simulador de iOS. A pesar de ello, es altamente recomendable utilizar dispositivos físicos reales a la hora de desarrollar.

Te puede interesar:  Huawei P8, primeras impresiones

El lenguaje de programación

Quizá esta es la mayor de las diferencias, pues Apple utiliza su propio lenguaje de programación Objective-C / Swift, mientras que Android utiliza Java. A pesar de ser ambos lenguajes de orientación a objetos, entre ellos hay diferencias más que evidentes.

Petogotchi-ChangeColorcode adicto al androide

Gestión de memoria y recolector de basura

Este es uno de los temas que más quebraderos de cabeza traen. En Objective-C al principio la gestión de memoria era explícitamente gestionada por el desarrollador, pero han ido mejorando de tal forma que desde ARC es mucho más fácil para el desarrollador, aunque no deja de ser crítico.

En Android, también tenemos que tener en cuenta parte de la recolección de basura, aunque a priori no lo pueda parecer. Pero el uso de imágenes grandes, demasiadas vistas… nos lanzará el fatídico mensaje OutOfMemoryError al que tanto miedo tienen los desarrolladores de Android.

unfortunately adicto al androide

UIViewController vs Activity

Este es uno de los principales conceptos que debemos manejar, y es que al pasar a desarrollar para Android tendremos que habituarnos a la clase Activity, la clase que representa una pantalla en un dispositivo Android.

En el caso de iOS, el controlador UIViewController es un componente del núcleo de la aplicación, con el cual podemos gestionar los ciclos de vida de los eventos, subvistas... Como podemos intuir, es el controlador dentro del modelo vista-controlador.

Te puede interesar:  Android 7.0 Nougat ya llegó para el Moto G4 Play!

Y este es el mismo rol que realiza la clase Activity para el caso de Android, tal como hemos comentado. Aunque no es exactamente igual. De hecho, las principales diferencias vienen en el modo de gestión de los ciclos de vida de los eventos.

Delegate vs Adapter

El patrón de delegación es muy utilizado en iOS mediante el uso de protocolos delegados. Sin embargo, en Android este patrón es representado con un adaptador. Plataformas diferentes, conceptos similares. ¿Resultará que, a pesar de sus diferencias, no lo son tanto ambas plataformas?

UI vs Layouts

Aquí es donde viene una de las grandes diferencias, y es que las soluciones propuestas para la creación de una interfaz gráfica realmente no tienen nada que ver en este motivo.

layouts adicto al androide

Los ficheros XML en los que montamos las interfaces en Android pueden parecer similares a los ficheros XIB de iOS, salvo en que éstos no son legibles.

Sin embargo, en tema de animaciones, iOS está mucho mejor preparada que Android, a pesar de que éste se está poniendo las pilas últimamente, especialmente con la preview de Android L y Material Design.  En una forma de simplificar, Apple siempre se ha enfocado en animaciones suaves, complejas y potentes, mientras que Google se ha preocupado de ellas teniendo en cuenta el hardware. Con lo presentado en el anterior Google I/O el futuro de Android y su interfaz gráfica parece mucho más sólido.

Te puede interesar:  Xiaomi Mi5 por dentro

El botón back

Esta es sin duda otra de las grandes diferencias, y es que Android cuenta con el botón atrás, el cual no está incluido en iOS. Y como desarrolladores debemos pensar en darle un uso correcto, pero sobre todo en ¡dárselo! Y digo esto, porque al principio, a un desarrollador de iOS le cuesta trabajo asimilar esto.

No es extraño encontrarse con apps para Android con un apartado en la esquina superior izquierda donde se encuentra una tecla para ir a la pantalla anterior.  Intuitivo en algunos casos, innecesario en otros.

back android L adicto al androide

Más y más diferencias

Pero no todo acaba ahí, pues encontraremos muchas más, tales como:

  • Desbloquear el teléfono en Android será deslizando arriba (derecha para iOS)
  • Las preferencias y permisos están mejor agrupadas en iOS en las preferencias generales del dispositivo, mientras que en Android están más dispersas
  • En iOS podemos utilizar los mapas de Apple, mientras que en Android usaremos Google Maps (también podemos usarlo en iOS)

Pero así podríamos seguir escribiendo más y más diferencias. Aunque con esto tenemos para la reflexión al que queríamos llegar, y es que pasar de desarrollar iOS a Android no es tan simple como aprender a programar con la API de Android, sino que tendremos que habituarnos a la forma de pensar en Android y pensar en todos esos detalles que acabarán aportando lo que, para mí, es uno de los conceptos más importantes al programar: ser diferentes y aportar valor añadido.