iOS SDK vs. Android SDK (II): Problema de terminales
Puestos en situación, vamos a seguir analizando puntos de estos kits de desarrollo, sus facilidades o no y lo que aporta al mundo del desarrollo, ya que se ha demostrado sobradamente que al final, elegir un sistema operativo depende en gran medida de sus aplicaciones, con lo que se define qué nos puede ofrecer cada uno de estos sistemas.
Hoy quiero centrarme en un problema de base que he observado se ha hecho bastante latente en los últimos meses, con la incipiente aparición de nuevos terminales para Android. Actualmente ya superan los 100 diferentes, desde los modelos básicos y primeros que aparecieron como HTC Dream o Magic, hasta los últimos HTC Desire HD/Z, por citar sólo alguno de los últimos. Si incluimos además tabletas como la Galaxy Tab o la Folio 100 de Toshiba, más razón aún. Esto es magnífico desde el punto de vista que Android se está posicionando claramente como la opción más repartida en el futuro, y tiene todas las papeletas para convertirse en el sistema operativo móvil por excelencia y el más usado. Me parece bien porque es un buen sistema operativo, pero…
¿Sabían ustedes que ya hay empresas en Estados Unidos que certifican cual App Store, las aplicaciones para Android y devuelven un informe exhaustivo de resultados a las empresas desarrolladoras? ¿Por qué existen? Pues porque más allá de la famosa fragmentación de versiones de Android, donde aún sigue habiendo una considerable diferencia de terminales con diferentes versiones de Android (aunque predominen la 2.1 y la 2.2), el mayor problema real es la fragmentación de terminales. De esos más de 100 terminales, ninguno es igual al otro, cada uno con los componentes que quiere, cada uno monta como quiere… Estas empresas te garantiza probar tu aplicación en TODOS y cada uno de los terminales Android del mercado. Para hacernos un símil, es como si siendo programadores Windows, tuvieran que contratar una empresa para que probara los desarrollos en todas y cada una de las posibles combinaciones de PC. Algo absurdo que demuestra que haber abierto tanto Android, no ha sido una buena idea a la larga.
Más datos. Una de las condiciones que Microsoft ha puesto para poner Windows Phone 7 a un terminal, es que este tenga una estructura y componentes concretos a todos los niveles. Sólo certifica la placa X, el chipset Y, el GPS Z o K, los procesadores gráficos C o H (con soporte de tal o cual librería)… ¿Por qué? Para evitar precisamente el problema latente que se ha generado en Android. Un desarrollo simple y básico, es más o menos seguro que irá en todos los terminales, pero ¿uno algo más complejo como un juego o una aplicación que haga uso de cosas muy específicas? En el terminal HIJK funciona a la perfección, porque es el que tiene el desarrollador independiente que lo ha hecho, y lo puede certificar. Puesto en Android Market, y probado en más de 100 terminales aparte del suyo, la aplicación empieza a fallar, tener bugs que un terminal existen y en otros no… un auténtico desastre que crea tal quebradero de cabeza a muchos desarrolladores, que finalmente deciden abandonar esta plataforma. El usuario final, el que se baja la aplicación del Android Market, no entiende de problemas de terminales. El tiene Android y no entiende por qué tal o cuál juego no funciona. Nada más.
iOS Vs. Android iOS SDK vs. Android SDK (II): Problema de terminales
Ahora vayamos a Apple. Ellos tienen 4 terminales de teléfono, 4 de reproducción musical y una tableta. Punto. En total 9. 2 de ellos no soportan iOS 4, por lo que podemos descartarlos si nuestra aplicación será para iOS 4 porque queremos usar alguna de las funcionalidades que nos ofrece. Un desarrollador independiente es normal que pueda tener en casa un iPad, un par de iPod Touch de diferentes generaciones y a lo mejor un par de iPhones. Si no, suponiendo que sólo tenga uno, Apple proporciona una herramienta en su SDK llamado Instruments, que nos permite hacer pruebas de estrés y rendimiento a las aplicaciones, y saber cómo van a funcionar en cada uno de los terminales. Por otro lado, Apple controla su hardware, y haciendo uso de las librerías o APIs públicas (de uso obligado), la capa de abstracción nos garantiza que siempre los dispositivos van a dar la misma funcionalidad y que una instrucción J siempre dará como resultado K, sea cual sea el terminal. En Android, no siempre es así. De hecho, en el jailbreak de iOS tampoco lo es, pero controlar 9 terminales es más fácil que más de 100.
Al final, nos encontramos con que si nos ceñimos a la APIs públicas en Android, haciendo uso de las recomendaciones de Google, nos libraríamos en parte del problema de los terminales, pero nos enfrentamos al problema de las versiones de Android que cambian métodos como quieren y provocan problemas de compatibilidad, mientras que Apple controla mucho más todo esto y garantiza la retrocompatibilidad de todos sus métodos de una versión a la siguiente. Pero como en Android no es obligatorio hacer uso de las APIs públicas, y en cuanto a temas gráficos es otro cantar, tal vez resulta que hacemos un juego que en el HTC Eris va genial, pero en el Motorola Droid, por algún motivo extraño, va más lento o no va, lo que impide que podamos dar una homogeneidad de resultados.
Como conclusión, Google debería limitar su SDK y su Market, para que realmente no se pudieran publicar aplicaciones que hicieran uso de APIs privadas (que proporcionan problemas de compatibilidad) o al menos advertirlo al bajar una. Tanta diversificación tanto de hardware como de software, mezclados ambos problemas, le hacen un flaco favor a Android y Google debería hacer algo para solucionarlo ahora que está a tiempo. Porque no hay que equivocarse, el problema es de Google y de su desarrollo de Android SDK, ya que ellos deberían controlar este tema y que los terminales no fueran un problema, de la misma forma que Microsoft lo controla con Windows Phone 7 o Apple con iOS.
Quiero notar, antes de cerrar el artículo, que lo que estoy exponiendo son hechos probados y conclusiones tomadas en base de pruebas empíricas y no opiniones de un fanboy que odia Android. Android es un gran sistema operativo con un gran futuro, pero no está carente de serios problemas que podrían ensombrecer en el futuro su estabilidad y fama de buen sistema. Es estúpido odiar algo que es bueno, y a día de hoy, no hay ningún sistema operativo móvil que sea malo, sólo los hay que se adaptan mejor o peor a lo que cada uno quiere. Pero en este punto comentado, el ecosistema Apple es más óptimo y apropiado que el de Google.
iOS SDK vs. Android SDK (II): Problema de terminales escrita en AppleWeblog el 15 November, 2010 por neotheone
Puestos en situación, vamos a seguir analizando puntos de estos kits de desarrollo, sus facilidades o no y lo que aporta al mundo del desarrollo, ya que se ha demostrado sobradamente que al final, elegir un sistema operativo depende en gran medida de sus aplicaciones, con lo que se define qué nos puede ofrecer cada uno de estos sistemas.
Hoy quiero centrarme en un problema de base que he observado se ha hecho bastante latente en los últimos meses, con la incipiente aparición de nuevos terminales para Android. Actualmente ya superan los 100 diferentes, desde los modelos básicos y primeros que aparecieron como HTC Dream o Magic, hasta los últimos HTC Desire HD/Z, por citar sólo alguno de los últimos. Si incluimos además tabletas como la Galaxy Tab o la Folio 100 de Toshiba, más razón aún. Esto es magnífico desde el punto de vista que Android se está posicionando claramente como la opción más repartida en el futuro, y tiene todas las papeletas para convertirse en el sistema operativo móvil por excelencia y el más usado. Me parece bien porque es un buen sistema operativo, pero…
¿Sabían ustedes que ya hay empresas en Estados Unidos que certifican cual App Store, las aplicaciones para Android y devuelven un informe exhaustivo de resultados a las empresas desarrolladoras? ¿Por qué existen? Pues porque más allá de la famosa fragmentación de versiones de Android, donde aún sigue habiendo una considerable diferencia de terminales con diferentes versiones de Android (aunque predominen la 2.1 y la 2.2), el mayor problema real es la fragmentación de terminales. De esos más de 100 terminales, ninguno es igual al otro, cada uno con los componentes que quiere, cada uno monta como quiere… Estas empresas te garantiza probar tu aplicación en TODOS y cada uno de los terminales Android del mercado. Para hacernos un símil, es como si siendo programadores Windows, tuvieran que contratar una empresa para que probara los desarrollos en todas y cada una de las posibles combinaciones de PC. Algo absurdo que demuestra que haber abierto tanto Android, no ha sido una buena idea a la larga.
Más datos. Una de las condiciones que Microsoft ha puesto para poner Windows Phone 7 a un terminal, es que este tenga una estructura y componentes concretos a todos los niveles. Sólo certifica la placa X, el chipset Y, el GPS Z o K, los procesadores gráficos C o H (con soporte de tal o cual librería)… ¿Por qué? Para evitar precisamente el problema latente que se ha generado en Android. Un desarrollo simple y básico, es más o menos seguro que irá en todos los terminales, pero ¿uno algo más complejo como un juego o una aplicación que haga uso de cosas muy específicas? En el terminal HIJK funciona a la perfección, porque es el que tiene el desarrollador independiente que lo ha hecho, y lo puede certificar. Puesto en Android Market, y probado en más de 100 terminales aparte del suyo, la aplicación empieza a fallar, tener bugs que un terminal existen y en otros no… un auténtico desastre que crea tal quebradero de cabeza a muchos desarrolladores, que finalmente deciden abandonar esta plataforma. El usuario final, el que se baja la aplicación del Android Market, no entiende de problemas de terminales. El tiene Android y no entiende por qué tal o cuál juego no funciona. Nada más.
iOS Vs. Android iOS SDK vs. Android SDK (II): Problema de terminales
Ahora vayamos a Apple. Ellos tienen 4 terminales de teléfono, 4 de reproducción musical y una tableta. Punto. En total 9. 2 de ellos no soportan iOS 4, por lo que podemos descartarlos si nuestra aplicación será para iOS 4 porque queremos usar alguna de las funcionalidades que nos ofrece. Un desarrollador independiente es normal que pueda tener en casa un iPad, un par de iPod Touch de diferentes generaciones y a lo mejor un par de iPhones. Si no, suponiendo que sólo tenga uno, Apple proporciona una herramienta en su SDK llamado Instruments, que nos permite hacer pruebas de estrés y rendimiento a las aplicaciones, y saber cómo van a funcionar en cada uno de los terminales. Por otro lado, Apple controla su hardware, y haciendo uso de las librerías o APIs públicas (de uso obligado), la capa de abstracción nos garantiza que siempre los dispositivos van a dar la misma funcionalidad y que una instrucción J siempre dará como resultado K, sea cual sea el terminal. En Android, no siempre es así. De hecho, en el jailbreak de iOS tampoco lo es, pero controlar 9 terminales es más fácil que más de 100.
Al final, nos encontramos con que si nos ceñimos a la APIs públicas en Android, haciendo uso de las recomendaciones de Google, nos libraríamos en parte del problema de los terminales, pero nos enfrentamos al problema de las versiones de Android que cambian métodos como quieren y provocan problemas de compatibilidad, mientras que Apple controla mucho más todo esto y garantiza la retrocompatibilidad de todos sus métodos de una versión a la siguiente. Pero como en Android no es obligatorio hacer uso de las APIs públicas, y en cuanto a temas gráficos es otro cantar, tal vez resulta que hacemos un juego que en el HTC Eris va genial, pero en el Motorola Droid, por algún motivo extraño, va más lento o no va, lo que impide que podamos dar una homogeneidad de resultados.
Como conclusión, Google debería limitar su SDK y su Market, para que realmente no se pudieran publicar aplicaciones que hicieran uso de APIs privadas (que proporcionan problemas de compatibilidad) o al menos advertirlo al bajar una. Tanta diversificación tanto de hardware como de software, mezclados ambos problemas, le hacen un flaco favor a Android y Google debería hacer algo para solucionarlo ahora que está a tiempo. Porque no hay que equivocarse, el problema es de Google y de su desarrollo de Android SDK, ya que ellos deberían controlar este tema y que los terminales no fueran un problema, de la misma forma que Microsoft lo controla con Windows Phone 7 o Apple con iOS.
Quiero notar, antes de cerrar el artículo, que lo que estoy exponiendo son hechos probados y conclusiones tomadas en base de pruebas empíricas y no opiniones de un fanboy que odia Android. Android es un gran sistema operativo con un gran futuro, pero no está carente de serios problemas que podrían ensombrecer en el futuro su estabilidad y fama de buen sistema. Es estúpido odiar algo que es bueno, y a día de hoy, no hay ningún sistema operativo móvil que sea malo, sólo los hay que se adaptan mejor o peor a lo que cada uno quiere. Pero en este punto comentado, el ecosistema Apple es más óptimo y apropiado que el de Google.
iOS SDK vs. Android SDK (II): Problema de terminales escrita en AppleWeblog el 15 November, 2010 por neotheone