Paleomovilidad Parte 2

Paleomovilidad Parte 2

Ya tuve la oportunidad de comentaros un poco como fueron los primeros tiempos del desarrollo software para dispositivos móviles anteriores a los que ahora manejamos en la entrada titulada “Paleomobilidad Parte 1”. Ahí comentaba las tecnologías que se decidieron utilizar para poder ir permitiendo que cada vez pudiesen ser de más utilidad al usuario más allá de simplemente comunicarse por voz o mensajes.

Ya solo faltaba, por parte de los desarrolladores, estudiar como poder explotar al máximo esas nuevas tecnologías para sacarle el mayor provecho a los nuevos prodigios tecnológicos que iban apareciendo en el mercado.

Para poder escribir los programas iban surgiendo diferentes herramientas aunque las de siempre, estilo IDE, seguían siendo las más útiles y desarrolladas debido a su ya prolongada implantación para Java y otros lenguajes. A pesar de Jbuilder y NetBeans, el que empezó a ser más utilizado en general por la comunidad fue Eclipse con el Java ME SDK instalado.

También aparecieron las J2ME Wireless Toolkit de Sun Microsystems, para facilitar tareas de testeo con su gama de emuladores, optimización y personalización para diferentes dispositivos.

Aquí una foto de familia del Mobile Devices Department, equipo con el que trabajé en GexTech (De izquierda a derecha: Arriba: Rómulo, Fabián, Xeleh -el jefe-, Parra, Chaky, Isra, Más Abajo: Pako, yo y Toni):

El resultado de desarrollar con estas herramientas, una vez depurado el código, se sometía a otras herramientas de composición y linkado surgidas para poder aprovechar lo más posible un código común para un número cada vez más creciente y dispar de dispositivos.
Estas herramientas, una vez configuradas, permitían automatizar la consecución de código ejecutable para un celular en concreto o una familia de ellos, según se solicitase, seleccionando el código fuente adecuado gracias a un ingenioso sistema de etiquetas y compilándolo y linkándolo con las librerías necesarias y los recursos adaptados a esas capacidades del dispositivo, tipo gráficos o audios, sacados de repositorios preparados para tal efecto.

Solían ser del estilo a la tecnología Antenna basadas en bloques de decisión escritos en XML.

Para mi gusto, la mejor solución de aquel entonces fue J2ME Polish por como supo entender las dificultades de aquel tipo de desarrollos en porting y como facilitó las cosas a los desarrolladores en la medida que los tiempos y la tecnología de entonces lo permitía.

Gracias a estas herramientas se pudo conseguir que desarrollar para aquellos incipientes precursores de los smartphones actuales fuese algo menos complicado y no solo posible sino también competitivo para fines comerciales.

Swift

Swift

Acabo de terminar de desarrollar mi primer proyecto enteramente escrito en el nuevo lenguaje de programación adoptado por Apple para las implementaciones nativas para iOS: Se trata se Swift. digo nuevo porque, aunque llevan ya más de dos años introduciendolo, ha evolucionado recientemente hacia su version 3, concretamente a día de hoy ya estamos en la 3.1.1. y es bastante diferente a las anteriores.

Lo primero que sentí, como imagino que le ocurrió a todo desarrollador iOS, fue incertidumbre, no ante lo desconocido, ya que estoy ya a estas alturas más que acostumbrado a afrontar nuevos retos, lenguajes, tecnologías y artefactos que tienen a bien lanzar por aquí y por allí como no puede ser de otra manera, se llama progreso. El problema más bien era temer por si se trataba de una nueva estravagancia de Apple.
No es que la estravagancia en si sea mala o reprochable, pero si hacen que se trate de “voy a ser diferente y muy cool aunque eso signifique complicar las cosas”, como ya a sido desde el principio la tendencia de Apple con iOS, entonces estariamos en un nuevo problema y sin razón aparente. Bastante tuvimos ya con tener que tragar con Objective-C como para que ahora… Pero no a sido así!!!

En muchos otros aspectos Apple parece ya haberse dado cuenta de que debe ir dejando de lado el lema “Antes muerta que sencilla” y auspiciar técnicas y tecnologías más prácticas y útiles. El cambio de lenguaje definitivamente va en esa linea.
Los cambios han ido siendo evidentes con la sucesiva llegada de las nuevas versiones de su IDE Xcode: primero fué intruducir un solicitado a voces control automático de memoria o Automatic Reference Counting (ARC), luego se pasó de los terribles .xib a los .storyboard para facilitar la implementación de los interfaces, unificando también el diseño para iPhone y iPad en todas sus variantes.
Más recientemente han sido temas ajenos a la programación pero que traian más aún de cabeza si cabe a la comunidad desarrolladora para iOS, como a sido la automatización de la firma y aplicación de certificados a una compilación que se pretende publicar, el desbloqueo absurdo a la utilización del famosisimo SVN para control de versiones y su total integración en Xcode… en definitiva sucesivas “bajadas de la burra” a las que se ha visto avocada la arrogancia heredada de su caprichoso Dios, el señor Jobs, en aras de un mejor y más rapido desarrollo de Apps.

Pues bien, ya puedo decir que el cambio de Objective-C a Swift no solo es otro de estos cambios en la misma linea de mejora… es quizá el mayor y más fuerte de estos cambios!!!

Ha resultado ser a mis ojos un gran lenguaje de programación, muy bien pensado, que puede seguir resultando algo raro o distinto a programadores consagrados en lenguajes mucho más famosos o extendidos, no olvidemos que seguimos en el mundo Apple y todo debe tener algún toque estrafalario como mandan sus canones, pero que nada tiene que ver con la falta de sentido común que arrastraba Objective-C a pesar de haber intentado evolucionarlo.

Swift es mucho más amigable, ¡sin punteros!, ¡sin corchetes!, ¡sin archivo de interfaz separados de la implementación!… en definitiva más rápido de escribir con codigo resultante más claro, entre otras cosas gracias a las nuevas APIs Foundation… ¡desaparece el prefijo NS que estaba en todo! clases tales como NSDate, NSTimer y NSURL ahora solo son Date, Timer y URL en el código Swift. Es el “nuevo paso” despues de NeXTStep que ya “olía”… son ahora compatibles con sistemas operativos basados en Linux gracias a la nueva y más simple sintaxis.

Se introduce el utilisimo manejo de errores con bloques “try” y “catch” que tanto echo de menos al salir de Java.
A pesar de ser un lenguaje fuertemente tipado, su declaración no siempre es necesaria gracias a su capacidad de inferir tipos, lo cual es útil en innumerables ocasiones, por ejemplo con variables de vida corta y poca relevancia en las que no queremos perder demasiado tiempo.

Son estas unas cuantas razones por las que a sido para mi muy grato el cambio de lenguaje. Podemos seguir diciendo que Apple sigue en muy buena linea arreglando desaguisados crónicos que habia cometido en su apartado iOS.

Si siguen en esta senda, por fin podremos dejar de criticar decisiones incomprensibles y queradá claro que se equivocaban desde el principio y que la realidad los esta obligando a poner las cosas en su sitio, eso si, también estaremos por fin ante una tecnología movil soberbia y de grandisima calidad con un entorno de desarrollo al fin a la altura de las circustancias, pero les queda aún algo de camino, o sino ¿a que viene que a estas alturas aun no se pueda refactorizar código Swift en el Xcode?!?!?!

Bricomóvil

Bricomóvil

Hace unos meses sufrí en mis propias carnes, o más bien en las de mi smartphone, unos de los principales males endémicos de estos nuevos aparatos, debido a sus dimensiones y a su sobreexposición, por tanto, a los elementos y rigores de la vida actual de sus propietarios: se me cayó y se partió en mil pedazos su pantalla.

Después de blasfemar un rato en arameo, lo normal en estos casos, quedó relegado en un cajón hasta decidir que hacer y fue sustituido temporalmente por un dispositivo más antiguo de los que ya vamos acumulando por los cajones.

Se trata de un Yiaju S3 Advanced de estos de marca china que tanto se están empezando a ver y con el que andaba yo muy contento por su espectacular relación rendimiento/precio. Era por eso que me resistía a relegarlo a simples funciones de rellenado de espacio en la cajonera de desechos tecnológicos.

El problema es que en estos casos, precisamente la razón por la que uno sale de los típicos circuitos de Samsung es por el bajísimo coste de la unidad (en mi caso 175€) y cualquier reparación por terceros puede costarte casi el precio de un dispositivo nuevo. Aunque seguiría siendo muchísimo menos en suma que lo que suelen pedir por móviles de igual gama de marcas más al uso, me daba mucha pena la poca vida útil de la que había disfrutado ese magnífico dispositivo, así que decidí lanzarme al movimiento DIY y salir por la vía de en medio: sería reparado pero lo iba a hacer yo mismo. Las ventajas eran claras: Más barato que adquirir otro terminal o enviarlo a reparación y el aprendizaje y recreo que la tarea que iba a reportar.

No tardé mucho en buscar y adquirir nueva pantalla en los mismos canales online donde compré el Yiaju. El problema es los tiempos de envío que si son a prueba de paciencias entrenadas como la mía. Me aseguré de que el repuesto contara con el necesario kit de mini herramientas tipo espátula de plástico, tiras adhesivas extrafinas especiales y micro destornilladores. Encontré varios distribuidores y me decante por uno muy completo y barato: todo lo necesario por 52€, gastos de envío incluidos.

Una vez con el material en casa me aseguré de contar con lo siguiente necesario: una tarde tranquila sin interrupciones de ningún tipo, buena música de fondo y algo para picar para los descansos.

Papá Youtube fue mi guía, aunque no había más que un par de videotutoriales no muy específicos de mi modelo y de factura más que mejorable. De hecho luego, demasiado tarde, caí en que hubiera sido muy buena idea aprovechar para crear uno yo con el proceso seguido y así poder ayudar a los usuarios de este S3 Advanced, que ya he dicho que es un gran móvil (no solo de tamaño, que también) pero cuyo talón de Aquiles desde mi punto de vista es la baja calidad de sus materiales y acabados, lo que quizá justifica su bajísimo precio y que según pude leer en varias fuentes tiende a ocurrirle lo mismo que me pasó a mi.

Pues una vez puse manos a la obra, a retirar tapa, SIM (solo llevo ahora una pero cabe recordar que uno de los potenciales de este móvil es que es dualSIM), MicroSD y batería, fuera tornillos exteriores y con la placa ya a la vista, con la espátula fui soltando los buses de datos y alimentación de cámaras frontal y trasera, altavoces y botonera lateral. Ya podía sacar los tornillos de la placa, que había que retirar por completo ya que la pantalla esta en el frontal unida a la placa por delante y hay que acceder por detrás. Lo bueno es que no se trata de demasiados componentes diferenciados, ya que todo esta integradísimo. Ya he nombrado todo lo que hay… no hay más así digamos… suelto.

Al sacar la placa de su encaje por fin quedaba al descubierto la maltrecha pantalla y se evidenciaba el bus que la unía a dicha placa y que también debía desprender. Simple al final, eso si, todo debía hacerse son sumo cuidado y delicadeza, pero al fin y al cabo más fácil de lo que esperaba, lo que me hizo alegrarme de la decisión tomada.

Si hubo que aplicar algo de fuerza para despegar la pantalla de la carcasa y luego era necesario limpiar bien los restos de pegamento residuales para que las nuevas tiras adhesivas encontraran la mayor superficie posible y evitar grosor extra innecesario, ya que el espacio en ínfimo y si agobia un poco que los márgenes de maniobra sean tan pequeños.

Aquí es el punto en que el proceso se invierte y una vez fijada la nueva pantalla a la carcasa, se trata de desandar lo andado: Unir bus de pantalla a placa, encajar placa, atornillarla bien sin dañar nada, colocar de nuevo botonera, altavoces y cámaras y unir cableado con cuidado, ya que las terminaciones son muy pequeñas y frágiles… y “et voilà”! Todo montados e nuevo… llegaba el momento de la verdad y de colocar la batería, tarjetas y tapa y… darle al botón!

Y EUREKA! FUNCIONABA!! Después de un tiempo viendo la pantalla quebrada, verla de nuevo perfecta era una maravilla!

Aún sigo a dia de publicar estas líneas con mi flamante JY-S3A y estoy muy contento con él, por lo que me alegro de haberlo resucitado. Me sirvió para conocer un poco más las tripas de la bestia insitu, entretenerme de forma diferente y por tanto animo a no desechar tan fácilmente tan buena tecnología convirtiendola en basura tan difícil de reciclar.

Paleomovilidad Parte 1

Paleomovilidad Parte 1

Corría finales de 2004 cuando comencé con el desarrollo móvil y estaba en pleno “boom” la descarga de juegos en los dispositivos móviles programables del momento.
La fiebre de los “politonos” ya había situado a los cada vez más cuantiosos usuarios de teléfonos móviles a la expectativa de cual sería la siguiente evolución de aquellos maravillosos cacharros cada vez más útiles y pequeños.

Hasta ese momento el entretenimiento y las utilidades incorporadas en esos aparatos estaban integrados de fábrica y escritos en código máquina en las memorias ROM.

Desde entonces, por un módico precio podías tener, por primera vez, varios juegos de tu elección instalados y jugar en tus tiempos muertos o cuando quisieras sin tener que esperar a llegar a tu casa y encender el ordenador o la consola.

Incluso las consolas portátiles tipo Game Boy se vieron superadas debido a su menor autonomía y mayor tamaño y precio, tanto del dispositivo como de los juegos, que además empezaron a tener menor oferta en sus catálogos, ya que el desarrollo de juegos para móviles y por tanto de la creación de empresas desarrolladas se disparaba exponencialmente y necesitaban cada vez más programadores, donde vi una muy buena oportunidad de incorporación al mercado laboral y además en un sector novedoso. Aquí aprovecho para tener un recuerdo al primer equipo con el que trabajé en European Software (De derecha a izquierda: MariCarmen, Iñigo, Bienve, Vania -el jefe- y yo):

Esta proliferación de empresas desarrolladoras de la que hablaba la impulsaba la gran demanda de las operadoras que necesitaban ofrecer cada vez más títulos, ya que para el usuario era, como he dicho, un precio muy asequible, pero multiplicado por la masa creciente de usuarios, las ganancias repentinas para estas compañías no tenía precedentes.

Pero todo esto necesitaba una base tecnológica sobre la que realizarse y funcionar.
Se había decidido poco tiempo antes utilizar mayoritariamente el lenguaje Java, que por aquel entonces iba de la mano de Sun Microsystems, aunque se lanzaron varias otras opciones como ExEn, Mophun o WGE y algunas perduraron paralelamente bastante en el tiempo y en ciertas regiones, como fue el caso de Brew basado en C, muy distribuido en los Estados Unidos, o Symbian auspiciado por Nokia que, aunque acabó conviviendo con Java, ofrecía la opción de instalar juegos únicos para este sistema operativo.

No tardó en imponerse Java en todo el mundo ya que era de los lenguajes más modernos de la época y por tanto no solo incorporaba todo lo más nuevo, como orientación a objetos y muy buen control de excepciones, sino que había aprendido de los errores de lenguajes de programación antecesores, por eso Java enmascara entonces el uso de punteros, cuenta con recuperador automático de memoria utilizada en desuso o “garbage collector” y se puede compilar en su famoso “bytecode”, que traía la novedad de ser independiente a la plataforma en la que se quisiera poner a funcionar, lo que era muy útil en un escenario de total falta de consenso entre fabricantes.

La adopción de Java y su adaptación a toda clase de plataformas hizo que los fabricantes vieran la posibilidad de utilizar un estándar sin impacto en sus procesos de fabricación. Por aquel entonces justo me encontraba inmerso en la programación en Java ya que fue un lenguaje que me enamoró desde mi primer contacto por el en la facultad de Informática por su evolución con respecto a otros lenguajes, así que en cuanto supe que los nuevos dispositivos eran por fin programables me lancé a ese sector.

El único problema que existía es que, a pesar de la rápida evolución de los móviles, aún eran muy carentes de capacidades de almacenamiento, memoria y procesamiento.
Este “bytecode” en el que se convertían los juegos y aplicaciones, por su capacidad multiplataforma, necesita para ser entendido con cada procesador dentro de cada tipo de móvil lo que se llama una JVM o máquina virtual que es la que adapta el software al hardware.
Esta JVM era demasiado extensa y sofisticada para poder ser introducida en aquellos primeros modelos que pretendían ejecutar Java, por lo que se les instaló una versión reducida denominada KVM.
La KVM, obligaba a renunciar a muchas funcionalidades ofrecidas por la JVM y por tanto de Java, pero se estudió muy bien a que se renunciaría y se consiguió sacar un subconjunto funcional y útil de Java denominado J2ME (Java2 Mobile Edition) que si podía correr sobre la KVM y dar el servicio adecuado, a pesar de su limitado acceso a bases de datos y capacidades gráficas, por ejemplo.

Junto a sus configuraciones CLDC de características y librerías básicas (Entrada/Salida, Red, Seguridad, operaciones en punto flotante…) y los perfiles MIDP que se fueron sucediendo (control de tamaño de pantalla, sonidos o de potencia de la batería) se pudo especificar y mejorar el uso de Java como soporte para posibilitar la instalación de software en dispositivos móviles como solo se había visto antes en ordenadores personales.

Se solucionó la falta de cobertura por parte de J2ME para algunas funcionalidades de entonces, como el control del Bluetooth, y añadidas a posteriori, como la vibración o el wi-fi, con la incorporación de librerías de código especificas para cada uso, que debían cumplir los protocolos JSR y que el programador añadía según las iba necesitando.
También existieron librerías propietarias de varios fabricantes para cubrir extras específicos que incorporaban algunos de sus dispositivos como podían ser segunda pantalla exterior o luces en los laterales, etc.

Una variante de mucho peso en Japón fue DoJa desarrollada por DoCoMo, que estaba basado en las especificaciones de J2ME.

La irrupción del iPhone en el mercado de la mano de Apple en 2007 y muy poco después del Android de Google y los smartphones arrasaron con todo lo anterior, en un momento en el que ya eran muy evidentes las carencias de J2ME para los nuevos tiempos. A partir de aquí la historia ya es conocida por todos 🙂