Paleomovilidad Parte 3

Paleomovilidad Parte 3

Esta es la tercera entrega de esta sección que he denominado “Paleomobilidad” (las anteriores fueron  “Paleomobilidad Parte 1”. y “Paleomobilidad Parte 2”) y esta viene motivada por una limpieza a fondo que he decidido hacer en casa y que, con todo el dolor de mi corazón, va a conllevar, entre otras cosas, no solo que me deshaga de viejo hardware que ya es demasiado obsoleto, sino que también voy a decir adiós definitivamente a mucho viejo y buen libro que ya no voy a necesitar, también por su triste obsolescencia, y porque ocupa mucho espacio que voy necesitando para material más actual, pero me duele por lo importantes que han sido en mis comienzos en el desarrollo de software para dispositivos móviles y el tiempo que me llevan acompañando, aunque ya haga tiempo que dejase de consultarlos tanto como estuve mucho tiempo haciendo.

Ahí los teneis: desde los primeros para realizar juegos para J2ME, pasando por el de Polish y el de Bluetooth, que tanto me ayudaron a dar un paso más en la especialización en librerías JSR y en multicompilación para diferentes familias de dispositivos, hasta la nueva era en la que entré, cuando me actualicé de J2ME a Android e iOS.

Libros de grandísima calidad y de muy reconocidas editoriales como Ra-Ma o Apress, que en su momento instruían de forma rápida y efectiva en lo que por aquel entonces eran los últimos avances en desarrollo móvil y cuando, no lo olvidemos, el acceso a la cantidad de información que hoy día encontramos en Internet aún no era tan común.

Especial cariño les tengo a los que tuve la oportunidad de adquirir en Londres, en la impresionante librería Foyles del Soho donde encontré “Beguinning Mobile Phone Game programming” y “J2ME Games with MIDP2

El último libro que cayó en mis manos fue este para iOS, que ya ha quedado anticuado por la salida de swift 5, pero que sigue siendo muy recomendable.

Ya con la red de redes, el uso de libros de consulta y técnicos parece estar disminuyendo, aunque para mi sigue siendo una formula muy útil.

Manual del desarrollador iOS Parte 2: Más Herramientas

Manual del desarrollador iOS Parte 2: Más Herramientas

Ya publiqué una relación de herramientas para desarrollar proyectos con tecnología iOS, la siguiente lista es un complemento interesante de otras que he utilizado y que pueden ayudar muchísimo también.

– Instabug: recoge feedback de errores por parte del usuario. (https://www.instabug.com)

– Homebrew: instalador de paquetes y plugins no oficiales de Apple. (https://brew.sh/index_es)

– Diawi: para poder distribuir una compilación iOS fuera de TestFlight y del entorno de Apple. (https://www.diawi.com/)

– App Center: otra plataforma de distribución de versiones compiladas (antiguo HockeyApp) (https://appcenter.ms/)

– Jsonviewer: para poder formatear y enterner de forma más legible los paquetes Json. (http://jsonviewer.stack.hu/)

– Postman: para poder construir APIs y revisar llamadas a servicios. (https://www.postman.com/)

– Jazzy: creación de documentación de código automática (https://github.com/realm/jazzy)

– Appfigures: para recoger datos de analítica de uso entre otros. (https://appfigures.com/)

Por hoy ya esta bien, para que tengáis tiempo de asimilarlas. En cuanto tenga recopilado un nuevo paquete de herramientas útiles para el desarrollo iOS volveré para compartirlas con todos.

Enjoy coding!

Bricomóvil Parte 2

Bricomóvil Parte 2

De nuevo la suerte quiso que me encontrara en la situación de romper la pantalla de mi actual smartphone en un descuido. Esta vez se trataba de mi iPhone 6s, mi dispositivo actual. Palabras mayores. Ya no es un dispositivo barato o gama baja. Estaba claro que merecía mucho la pena arreglarlo.

Me planteé desde el principio lanzarme al “Do It Yourself” e intentarlo por mi cuenta. Vi en internet los kits que existen, que aunque no son por supuesto originales de Apple, sirven para dejarlos como nuevos y traen todo lo necesario para la tarea a realizar, asique me hice con uno de ellos.

De nuevo, como en el caso del Jiayu al que ya le cambié la pantalla, Youtube fue mi guía, aunque casi no fue necesario ya que el pack que adquirí traia incluidas buenisimas instrucciones sobre lo spasos a realizar.

Realmente no fue nada dificil el proceso: retirada de tornillos cerca del conector lightning, luego los que unian el malogrado cristal con la pantalla, desconexión de los pequeños buses de datos y alimentación del microfono y del botón del touchId, y vuelta a ensamblarlo todo esta vez con la pantalla nueva.

El kit no contaba con touchIdButton real, por lo que tube que integrar en la pantalla el anterior, quizá eso fue lo unico así más delicado. Una vez vi que no entrañaba dificultad esa intervención, me lancé a hacer lo mismo con el bloque de sensores y mocrófono, ya que preferí volver a montar el original que habia funcionado siempre sin problemas que fiarme del que venía cpn el kit.

Y con los tornillos finales volvía a contar con un iPhone 6s 100% operativo y de nuevo podía leer en pantalla todo sin problemas. ¡Que gusto da cuando finalizas este tipo de tareas y vuelves a tener tu dispositivo como nuevo!

He de confesar una cosa: esta vez he contado con ayuda. Os dejo una foto en la que aparece mi ayudante espontaneo al que desde el primer momento le llamó muchisimo la atención mi ocupación esa tarde 🙂

Manual del desarrollador iOS Parte 1: Herramientas

Manual del desarrollador iOS Parte 1: Herramientas

Si vas a desarrollar proyectos con tecnología iOS, la siguiente relación de herramientas a utilizar puede ser muy interesante para ti.

Herramientas generales

Para comunicaciones:

1. Mail (o su cliente de correo preferido con su cuenta de correo electrónico corporativo)
2. Skype (https://www.skype.com/es/download-skype/skype-for-computer/) (crea una nueva cuenta y compártela con tu equipo)
3. Slack (https://slack.com/)
4. Screenhero (para compartir pantalla) (primero debes registrarte aquí: https://screenhero.com/login/)
6. MirrorOp (http://www.mirrorop.com/)(https://prezi.com/hs3g-xjf8esx/interactuar-con-mirrorop-para-android-y-windows/)(https://itunes. apple.com/es/app/mirrorop-presenter/id808539605?mt=8)

Para la gestión de proyectos:

1. Confluence (https://es.atlassian.com/software/confluence)
2. JIRA (https://es.atlassian.com/software/jira)
3. Bitbucket (https://bitbucket.org/)

Software de desarrollo

Esta es la lista de software que puedes usar para implementar tu entorno:

1. Xcode (https://developer.apple.com/xcode/).
2. CocoaPods (https://cocoapods.org/).
3. SourceTree (https://www.sourcetreeapp.com/).
4. TestFlight (https://developer.apple.com/testflight/)
5. FireBase (https://firebase.google.com/)
6. Fabric (https://get.fabric.io/).
7. Crashlytics (http://try.crashlytics.com/).
8. Realm Browser (https://itunes.apple.com/es/app/realm-browser/id1007457278?mt=12)(https://realm.io/).

Y este es para crear interfaces de calidad y rápido:

1. Sketch (https://www.sketchapp.com/)
2. Supernova (https://supernova.studio/)
3. Zeplin (https://zeplin.io/).

Software personal

Esta es una lista de software que necesita para otros fines además del desarrollo:

1. EnPass (https://www.enpass.io/) Si necesitas almacenar tus contraseñas de forma segura.
2. MacTex (http://www.tug.org/mactex/) para leer y crear documentos.
3. Sublime (https://www.sublimetext.com/3) para BDD (Gherkin)

Credenciales corporativas de desarrollador de Apple:

Esto es necesario para acceder a nuestro programa corporativo de desarrollo de Apple (https://developer.apple.com/):
1. ID de Apple: crea uno asociado a tu cuenta de correo electrónico.
2. Certificado de iOS: crea el tuyo para fines de desarrollo y súbelo al web del Programa de Desarrollo de Apple (https://developer.apple.com/).

Ayuda en la red:

Aquí puede encontrar un sitio útil con información esencial para aprender o actualizar conceptos rápidos e iOS para desarrollar:
Introducción a Xcode: https://developer.apple.com/videos/play/wwdc2016/413/
Y siempre puedes escribirme y preguntarme. Estaré encantado de ayudarte! 🙂

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 🙂