Cinco puntos donde iOS debería copiar de Android

Imagen de Diego Brouard

Apple prácticamente comenzó un mercado nuevo con la salida de su primer iPhone. Años más tarde, nos encontramos con un mercado maduro y un sistema del programación y desarrollo muy completo, pero como todo es mejorable, aquí tenemos cinco puntos referentes al desarrollo de apps para móviles, que, en la muy personal opinión de este equipo, Apple debería copiar a Google. ¡Empezamos! 

1. Layout dinámico

Cuando un programador empieza a trabajar con Xcode, se encuentra con la agradable sorpresa de ver lo sencillo que es montar la interfaz de usuario de forma visual; es rápido, cómo y sencillo, hasta que te encuentras con contenidos cuyas dimensiones varían en tamaño en función de los contenidos, como por ejemplo, un simple campo de descripción.

El motivo es que Xcode usa por defecto un sistema de coordenadas absolutas donde cada elemento tiene cuatro parámetros definidos para poder visualizarse: ancho, alto, coordenada horizontal y coordenada vertical y en el momento en el que, por ejemplo, tienes una ficha con la descripción de un lugar y los textos varían, ya la has liado.

Para añadir cierto control, Xcode usa los constraints, pero en nuestra opinión es una mala solución a un problema que no debería existir. Personalmente, prefiero la librería CSLinearLayoutView que permite montar filas y columnas de una forma relativamente sencilla ... siempre que sepas programar sin el Interface Builder de Xcode.

Android resuelve este problema de una manera muy elegante con las filas y columnas del objeto LinearLayout ( horizontal y vertical ). Objeto que Apple debería copiar ya mismo y dejarse de historias.

2. Cajas de texto

LA pesadilla. Cuando editas un texto y aparece la caja del teclado virtual, esperas siempre varios comportamientos estándar como:

  • que se cierre cuando le des a "OK"
  • que se cierre cuando le des a cualquier punto de la pantalla
  • que se mueva la pantalla hacia arriba para que el teclado virtual no tape el texto que estás escribiendo

Pues bien, Apple considera que esto es responsabilidad del programador y se lava las manos. Señores, cuando algo debe funcionar de esta manera SIEMPRE Y en todos los casos, creo que es responsibilidad del framework.

3. Publicación de versiones de desarrollo y testing

Este punto se está empezando a arreglar con la compra de Testflight por parte de Apple, aún así, probar una app android es trivial:

  • pon el móvil en modo "desarrollo"
  • acepta "otras fuentes"
  • copia el fichero APK

En Apple, tienes que crackear el iPhone, pero como esto no es una opción seria, te toca pasar por el todo el proceso de los "provisioning profiles", etc, etc ... En resumen, es un auténtico infierno que la mitad de las veces falla sin que sepas por qué, mientras que el sistema de la Google App Console para alpha, beta y production y beta-testers es simplemente FÁCIL.

4. Expandable list view

Un elemento muy útil en Android que Apple no tiene ( http://developer.android.com/reference/android/widget/ExpandableListView.html ). Es una lista con un título en el que, al hacer click cerramos o abrimos su contenido. Hay un objeto que no es de Apple con el que podemos conseguirlo ( https://github.com/vladinecko/accordion-uitableview ), pero vamos, Apple a ver si lo copias.

5. Recursos de layout reutilizables

Esto está muy bien logrado en Android. Se trata de estructuras de layout en xml que podemos reutilizar en diferentes pantallas de una forma muy sencilla. De esta manera, al inicio del proyecto definimos las dos o tres que necesitamos: ( elemento de lista simple, elemento de lista con image, elemento de grid ) y los usamos en todas partes. En Apple, pues eso, a mano.

 

Resumiendo, Apple dispone de un sistema de desarrollo nativo realmente completo y rápido para trabajar pero que tiene algunas lagunas que en ciertos casos son incomprensibles. En todo caso Android también tiene las suyas, y en este artículo ( 5 temas donde Android debería copiar de iOS ) nos ocupamos de ellas.

También te interesa