Después de leer los comentarios de la entrada de esta tarde, me ha quedado claro, por lógica, que no todo el mundo tiene un concepto claro a nivel de cómo se programan nuestros dispositivos favoritos, sean Apple o Google, por lo que voy a empezar una pequeña serie de posts, para intentar explicar conceptos básicos, intentando usar un lenguaje lo más cercano posible, para que así sea más fácil entender determinadas cosas que afectan, en este caso, a los dispositivos de Apple o que usen el sistema operativo móvil de Google.
De esta manera, entre otras cosas, podréis entender mejor la enorme diferencia que va a haber, ahora que los tablets llegan al mercado, entre las aplicaciones para iOS y las aplicaciones para Android. Así mismo, servirá para entender un poco mejor por qué, en algunos casos, las aplicaciones para Android son sombras de las versiones de las mismas para iOS, véase, Facebook, Evernote, Remember the Milk y muchas otras. También por qué a veces son tan diferentes a todos los niveles, y ofrecen incluso funcionalidades diferentes.
Básicamente Android ofrece muchas más posibilidades pero llegar a ellas es mucho más complejo que con iOS que te limita un poco más, pero facilita mucho el trabajo para sacar el máximo rendimiento a lo que nos ofrece el sistema operativo.
Las APIs o librerías de desarrollo
Como herramientas de desarrollo, Android tiene una ventaja (según se mire) con respecto a iOS. En Android podemos hacer uso de las librerías del sistema (las llamadas APIs) que queramos, tanto las públicas como las privadas.
Las APIs públicas son librerías que no varían en sus llamadas (salvo para ampliar argumentos o métodos que se incorporan), que garantizan compatibilidad con versiones anteriores (normalmente), y son las que trabajan sobre elementos básicos del sistema operativo a todos los niveles, como por ejemplo, el dibujado de elementos, el control de los acelerómetros, detección de pulsaciones, etc... Son los elementos que todo buen programador debería usar como herramienta, usando sólo esas.
Las APIs privadas son las que controlan los elementos físicos del dispositivo (el hardware) de una manera más cercana a este y con mejor rendimiento. Es una capa inferior que usan las APIs públicas para llegar al dispositivo, pero estas sufren modificaciones constantes que no garantizan la compatilibidad de métodos, argumentos, llamadas... Un método para controlar la inclinación del teléfono, en la versión 2 puede llamarse AcelerometerPos y tener dos argumentos x e y que nos den la inclinación. En la versión 2.1, puede pasar a llamarse AcelerometerPosition y usar cuatro en vez de dos argumentos, que sean a, b, c y d. Esto es por poner un ejemplo básico, no real. Estas no debería usarlas nadie, porque provoca el problema, de hacer necesario tener implementaciones que, detectando la versión, trabajen de una manera u otra. Esto al final, reduce rendimiento a la aplicación.
Android nos permite usar unas y otras indistintamente, y es responsabilidad del programador asegurar que su aplicación, use lo que use, funcione bien en todas las versiones. Google recomienda usar las públicas, pero no prohibe las privadas.
En Apple eso no es así. Si en iOS hacemos uso de las APIs privadas del sistema, Apple rechazará sistemáticamente nuestra aplicación. Es uno de los famosos motivos por el que nuestra aplicación será condenada al sitio donde sí podemos publicar aplicaciones que usen las APIs privadas, que nos pueden permitir incluso modificar el propio sistema operativo y sus elementos: Cydia. La argumentación de Apple a este respecto es bien sencilla: garantía de funcionamiento en futuras versiones de iOS y la NO modificación o manipulación de elementos del dispositivo o su sistema operativo, sin su consentimiento. Ellos son los dueños y sólo ellos pueden tocar esa parte.
Un ejemplo de aplicación de estas características sería el famoso MyWi que crea una red Wifi en cualquier iPhone con la conexión 3G. Cuando salió iOS 4, el cambio en las APIs de Wifi hizo que MyWi dejara de funcionar, y tuvieron que readaptarlo, porque este programa usa directamente la API privada que controla el chip de comunicación de la red Wifi y lo "reprograma" para sacar la señal 3G a través de él. Sin embargo, en Android Market podemos encontrar aplicaciones así sin ningún problema, como mi favorita Wifi Tether, que además, para más curiosidad, requiere que el teléfono tenga acceso root (que tenga hecho el equivalente al jailbreak de iOS, pero en Android) para ejecutarse. Y está en el Market y legal.
Dibujado de interfaces
La interfaz de una aplicación, es lo que vemos de la misma. La cara al usuario de la aplicación y que nos muestra y pide información. Pues bien, para trabajar con esas interfaces, Android tiene una única librería (una API, pública en este caso) que es la que permite dibujar interfaces de programas, para poner elementos usando las características del sistema operativo, como campos de texto, etiquetas, botones, campos de selección, etc. En el caso de Apple pasa igual.
Pero tenemos una clara diferencia que nos da a entender que las cosas para los programadores no van a estar nada fácil, a no ser que Google arregle esto en futuras versiones de su kit de desarrollo. Android, liberado de la atadura de la resolución (no cómo iOS) utiliza un muy inteligente método para adaptar el tamaño de los campos a la pantalla según la resolución. Es algo parecido al uso de posiciones y tamaños relativos dentro de hojas de estilo y páginas web, de forma que nosotros no definimos el tamaño en pixels de un campo, sino su tamaño relativo en función de toda la pantalla. De esta forma, la misma aplicación se verá prácticamente igual en cualquier dispositivo, sea su resolución 320x240 como 1024x600. Esto sin duda, es un gran adelanto.
En el caso de iOS, los elementos de la interfaz están servidos por el tipo de aplicación que queramos hacer. Si queremos hacer una aplicación iPad tenemos una estructura y elementos, y si queremos una de iPhone tenemos otra, con la posibilidad de aportar o activar de una manera muy sencilla (usando un método en la definición de la interfaz) para activar o no el soporte de retina display para la tipografía de nuestra aplicación. Según si usa un iPhone 4 o no, se dibuja con más o menos resolución y se usan los gráficos a resolución completa o se adaptan a una resolución menor, pudiendo tener dos versiones diferentes del mismo gráfico, una para cada modo. Lo importante en este caso, es que las APIs de interfaz para iPad son OTRAS diferentes a las de iPhone (por eso incluso el teclado en las aplicaciones iPhone en iPad es el teclado de iPhone y no el de iPad, entre otras cosas). Apple tiene unas librerías específicas para generar interfaces para iPad, aprovechando la resolución de la pantalla y su tamaño.
Cuando Android se enfrente a un tablet sus aplicaciones van a verse mucho mejor que se ven ahora las del iPhone en un iPad, pero no dejarán de ser las aplicaciones de móvil, porque seguirán usando la misma librería que en dispositivos más pequeños. No cambian en su estructura, presentación... Mientras que programando para el iPad, tenemos a nuestros servicio una serie de recursos que nos permiten dibujar interfaces adaptados a la pantalla del iPad, con varios scrolls de pantalla, definiendo una especie de divisiones de la pantalla con su propia autonomía, etc.
En Android eso es algo que el programador tendrá que hacer él desde 0, ya que NO se lo da el kit de desarrollo. Él tendrá que generar todo eso, por lo que cada uno lo hará a su manera, creando nuevas APIs propias, y al final tendremos una diferencia importante en la implementación de cada aplicación, cuando con iPad tenemos una homogeneidad que da mayor facilidad al programador, por tener su propia API de desarrollo de la parte de interfaz y visual.
Primeras conclusiones
Al final, Android SDK, no deja de ser programar en java usando una serie de librerías concretas, y donde tenemos la opción de usar un IDE (un programa que facilita la programación) como Eclipse, que no es de Google ni siquiera, y que está pensado para trabajar con java en cualquier plataforma.
En el caso del iOS SDK, tenemos programas específicos para trabajar con ella, tenemos muchos más métodos y librerías que facilitan la vida al programador, y muchas cosas como controlar el giro del teléfono, el pinch y muchos elementos más, se basan, en muchos casos y literalmente, en una línea más o menos en nuestro programa.
En resumen, Android es más artesanal, lo que da posibilidades casi infinitas en desarrollo pero dificulta más este porque hay que trabajarlo todo por uno mismo, e iOS es más "dirigido" y específico, lo que da menos libertad pero aporta mucha facilidad a la hora de desarrollar ideas.
Seguiremos en próximas entregas...