Ocio Electrónico

Últimamente estoy comenzando a conocer los productos de Apple, algo que comencé cuando con ciertas dificultades compré un iPhone.

Yo soy de esas personas que a su manera, cuando algo le gusta, tiene que ver la forma de la rosca de sus tornillos y como esto no podía ser menos decidí ver como se programaba para este aparato. A continuación me gustaría contaros la experiencia.

No pretendo publicar una “receta”, tan común en internet, aun que se pudiera parecer e igualmente, la exactitud o completa corrección no entran del objetivo de este texto, si no algo que pudiera leer alguien al que le pudiera interesar el tema y quiere tener unas nociones básicas de su mecánica y quizá a animar a conocerlo en mayor detalle o incluso animar al lector a inscribirse en el programa oficial de desarrollo.

Igualmente, si lees este texto y encuentras errores (que seguramente contendrá), no dudes en hacérmelo saber y poco a poco lo iré perfeccionando.

Alternativas

En un principio existen 2 caminos:

- El camino oscuro, utilizando software privativo, como es el caso de xcode.
- El camino luminoso, utilizando software libre (toolchain).

Como ya había utilizado toolchain para hacer pequeños pinitos del wrt54g, del comtrend 536+ y del NSLU2 me decidí por probar el “bando de los malos” (el del software cerrado). Esta opción, pese a que acabo de nombrarla como “el camino oscuro” es oscuro por su karma, no por su luz o color . Y a todo esto se sumaron mis ganas por probar OSX un poco más lejos de verlo “en un escaparate”.

Igualmente también existen caminos intermedios como utilizar xcode para compilar con Toolchain (que imagino que es lo que hará la mayoría de los mortales que programan aplicaciones de consola).

Instalando el SDK

Una de las primeras cosas que me disgustó del desarrollo para iPhone, es que este SDK oficial sólo está disponible para el sistema operativo de Apple, por lo que o lo instalas para OSX o no lo instalas .

Partiendo de tener instalado OSX, sólo necesitaremos obtener el SDK de iPhone para empezar a programar. El firmware actual es el 2.2.1 y el firmware beta es el 3.0 beta 5 y ambos tienen SDKs diferentes siendo el primero gratuito y costando 100$ el acceso al segundo (y siguientes betas).

Para obtener el SDK gratuito de la versión 2.2.1 utilizaremos la misma cuenta que seguramente tendremos en iTunes y en el iphone dev center podemos descargar el instalador del sdk 2.2.1 9m2621a.

Una vez instalado el sdk, podemos arrancar xcode, que generalmente se encontrará en /Developer/Applications/Xcode.app

Escogiendo una plantilla

En Xcode, los proyectos se inician en base a una serie de plantillas predefinidas. Estas serían las opciones que nos da:

Estas plantillas incluirán líneas de código y recursos, siendo si no me equivoco “Window-Based Application” la más ligera.

En un principio me sorprende que no exista una forma de crear “aplicaciones de consola”, pero imagino que Apple, pretende impulsar el uso de la interfaz gráfica. Y por si alguien duda de “Utility Application” tiene un nombre un poco engañoso, pero no es una aplicación de consola si no una plantilla con 2 vistas que se intercambian con un efecto de giro.

Si hubiéramos escogido utilizar ToolChain en lugar de xcode, probablemente si podríamos haber escrito aplicaciones de consola para ejecutar en un terminal, pero recordemos que entre las políticas de Apple está el no poder ejecutar programas dentro de programas. Por lo que tiene sentido que Apple nos esconda esas opciones. A mi me parece algo injusto esconder esa opción, por que una cosa es lo que hagas tu con tu iPhone y otra lo que envíes al AppStore.

En general encontraremos que las plantillas incluyen una serie de ficheros entre los que tendremos los xib (que son diseños del GUI), un main.m, un *AppDelegate.h + *AppDelegate.m que es a más alto nivel donde se controla la aplicación y probablemente un *ViewController.h + *ViewController.m en el que estará el código que gestionarán las diferentes “vistas” incluidas en la plantilla.

Compilando la plantilla

Compilar la aplicación, es tan sencillo como hacer click en Build o Build and Go, para lanzarlo en el iPhone o en el Simulador de iPhone incluido en el SDK.

Cabe destacar, que las plantillas nos permiten escoger diferentes “targets”, escogiendo: Firmware, Debug/Release, Simulador/iPhoneOS. Siendo Firmware el firmware en el que esperamos que funcione la aplicación, Debug/Release las diferentes formas de compilar nuestro código (que imagino que en las plantillas en un principio serán la misma o casi) y Simulador/iPhoneOS.

Dentro de estas opciones, escoger Simulador/iPhoneOS diferenciará si se ejecuta en el Simulador o si la aplicación se copiará a un iPhone para hacer debug desde la propia máquina.

Lanzando tu aplicación en un iPhone

Creo que en esta parte es donde encontré la mayor “espina”. Una “espina” ideológica más que técnica. No pretendo que quien lea este texto acepte “los dogmas” que planteo o los de Apple, si no que tenga consciencia de que dicha discrepancia existe y que probablemente en otros teléfonos como los diferentes “Google Phones” no exista o sea diferente.

Para poder ejecutarlo en un iPhone, debemos de tener instalado en el ordenador, un certificado digital para firmarla de forma que el teléfono lo acepte como software legítimo. Ese certificado se obtiene de Apple apuntándose como desarrollador y pagando los 100$ que mencioné antes.

En caso de no tener dicho certificado obtendríamos un maravilloso “CodeSign error: Code Signing Identity ‘iPhone Developer’ does not match any code-signing certificate in your keychain.  Once added to the keychain, touch a file or clean the project to continue.“.

Como por ahora no he podido pagar esos 100$ y todavía no tengo ese certificado he tenido que crakear el teléfono. Para ello he tenido que hacer exactamente lo mismo que se haría si quisiera instalar software crakeado (y aun que no entraré en detalles no me refiero sólo a liberar el teléfono o a tener acceso a cydia o installer). Igualmente, también necesitaremos realizar cambios en nuestro proyecto para que sea capaz de enviar la aplicación compilada al iPhone.

Realmente esto me parece bastante molesto, por que he comprado el teléfono, apple me ha dado xcode, tengo mi código fuente,… no hay nada con copyright de otra gente. ¿Por qué Apple se cree con derecho a decidir si yo puedo o no ejecutar MI aplicación en MI teléfono? ¿Por qué me obligan a crackearlo (Jailbreak + MobileInstallation Patch)?

Sinceramente dudo muchísimo que Apple pueda defender en un juicio su “derecho” a impedir que ejecutes tu programa completamente legal sin su firma.

A efectos de lo que Apple espera que hagas o no con el SDK conviene leerse el iPhone SDK Agreement, en el que a mi modo de ver, destaca el apartado 3.2 Use of the SDK y 3.3 Program Requirements for Applications (que vienen siendo 2 folios y medio de las 10 que tiene el documento). Resumiéndolo e interpretándolo en 3 frases saltándome cosas también importantes: “No hagas Aplicaciones que crackeen el teléfono”, “No utilices funciones privadas del API” y “No espíes al usuario”.

Dudo que algún tribunal en alguna parte del mundo considerase válido la totalidad de este acuerdo, especialmente cuando el usuario sólo tenga intención de crear aplicaciones sin maldad alguna, pero si es importante cumplirlo si esperamos poder publicar algo en el AppStore (que si andas algo despistado, te diré que es el sitio oficial donde haces públicas tus aplicaciones).

El Simulador de iPhone

La palabra “Simulador” llama un poco la atención. Es un simulador por que simula, pero no llega a ser un emulador, por que no es capaz de ejecutar aplicaciones nativas del iPhone. Xcode realmente compila una versión especial para procesadores intel que correrá dentro del “Simulador”.

Así “luciría” la plantilla sin hacer nada en el Simulador sobre OSX:

El fondo blanco es la plantilla (concretamente el fichero MainWindow.xib de la plantilla) en la que no hemos incluido nada.

Si editamos ese fichero con el Interface Builder (que arranca haciendo doble click en el desde xcode) podemos añadir elementos a la interfaz sólo con un par de clicks. Por ejemplo, añadiendo un UILabel y haciendo doble click en el podemos cambiarle el texto, lo cual se vería reflejado en la aplicación al compilar:

En un principio la ejecución del Simulador y la ejecución nativa en el teléfono son muy parecidas. Las principales diferencias que he encontrado se encuentra en el cambio de las rutas, la falta de alguna aplicación accesoria en el simulador (como pudiera ser por ejemplo la aplicación de mapas) o el hardware que evidentemente no tiene.

Gestión de memoria

Quizá no he leído la documentación adecuada para entender este comportamiento con claridad. Recordemos que estoy contando mis impresiones. Algo que me ha resultado incómodo a la hora de adaptarme a Objective C es la gestión de memoria, no por que sea bueno o malo, si no por que es diferente. Quizá mi problema pasase por que las “recetas” que he leído tampoco lo aplicaban con claridad o que el comportamiento “esperable” cambiase entre versiones.

En general el concepto es el mismo que en Java, una vez un objeto tiene 0 referencias este puede ser destruido en cualquier momento. Sin embargo en ocasiones he encontrado con que mis maravillosos objetos dejaban de existir al cambiar de contexto. En un principio esto podría evitarse aumentando el número de referencias con [objetoEnCuestion retain] (o reduciéndolas con [objetoEnCuestion release]), pero es algo que todavía veo algo borroso. Quizá por que se pueden crear con 1 referencias pero también con 0 referencias o quizá por el código que incluía la plantilla que estaba utilizando.

No quiero explayarme en exceso en esto, tengo una idea de como podría funcionar, pero no tengo tan claro que funcione realmente así, por lo que prefiero dejarlo con esta somera explicación de mi actual tropiezo del que espero levantarme muy pronto. Para mi es el gran problema de aplicar “recetas”: en ocasiones quedan lagunas de cosas que deberían de ser obvias. Así que si realmente te interesa programar una aplicación para el iPhone o para OSX te recomendaría que leyeras un poco más que esas simples “recetas” para que no tengas las lagunas que hoy tengo yo.

Interacción código-GUI

Dicha interacción se puede hacer de varias formas, los tutoriales de iniciación suelen utilizar el entorno gráfico, para enlazar las funciones que se desencadenan al interactuar con el interfaz y los objetos del código con los objetos del interfaz. De esta forma escogemos elemento a elemento cual “cacho de código” se relaciona con que elemento del interfaz y viceversa.

Otros tutoriales hacen uso de protocolos que casi se podría entender como “un interface”. De forma que un objeto creado en el interface builder o incluso uno creado dinámicamente “delega” su comportamiento en una clase que implementa dicho protocolo, de este modo, todos los eventos que desencadene dicho elemento del GUI deberían de estar implementados en la clase en la que delega.

A demás, como los elementos del interfaz irán colocados dentro de “vistas”, el código correspondiente irá por norma general en el “Controller” de esa vista.

Una única clase puede implementar diferentes protocolos de elementos de diferente naturaleza, pero recordemos que sin llegar a delegar completamente el comportamiento, podríamos escoger dentro de la misma clase que el “Botón A” hace una cosa y el “Botón B” hace otra y del mismo modo un mismo .xib puede llevar varios “Controller” (por ejemplo, podrías tener un listado en un UITableView con un “Controller” propio.

Igualmente, la forma de crear elementos del GUI no tiene por que ser a través del Interface Builder, si no que también podríamos crearlos por código y organizarlos por código en la pantalla, pero seguramente que lo idóneo sea algo intermedio, puesto que XCode viene listo para que tu aplicación incluya localización, de tal forma que ajustes los tamaños en función del idioma (piensa en la típica palabra que en un idioma es enorme y en otro son 3 letras).

Conclusiones

Tras ver como funciona un pequeño proyecto el sabor de boca que me ha quedado es más bien dulce que amargo.

Desventajas:

- La sintaxis de “Objective C” me resulta más o menos:

mi_opinion = [NSString initWithFormat:@"%@ es extraño",objectiveC];

- Me queda por entender bien por que en ocasiones se me liberan algunos objetos al cambiar de contexto y por que otros no se liberan (como comenté en el apartado de gestión de memoria)

mi_opinion = invalid

- Alguien que no es desarrollador autorizado, no puede firmar aplicaciones para un iPhone sin crackear (tenemos incluso que llegar a parchear el MobileInstallation).

- El SDK sólo está disponible para OSX. Lo cual explica que la mayor parte de las aplicaciones de soporte relacionadas con el iPhone funcionen casi siempre en OSX (y no sean multiplataforma).

Ventajas:

- Me ha animado a conocer mejor el sistema operativo de Apple y conocer las alternativas debe de ser algo obligatorio para cualquier informático.

- He tomado una ración individual de “Objective C”. Lo cual me lleva a la conclusión de la anterior ventaja.

- Me ha encantado la integración entre los editores, compilador, debugger y Simulador.

- Al fin he utilizado sqlite para algo mio

- Al fin puedo llevar conmigo un dispositivo que puedo programar a gusto y con gran conectividad.

Y tu ¿habías programado alguna vez para tu teléfono móvil?