Vol Remote: la construcción de una app en iOS desde cero

Vol RemoteEsta aplicación es un control remoto que permite cambiar el volumen de un PC o un Mac desde el iPhone. Tiene una interfaz sencilla y es muy fácil de usar. Su creador, Andrés Botero, comparte con toda la comunidad de mejorando.la el proceso de construcción, desde el chispazo de su idea inicial hasta la publicación en AppStore. Un buen relato que te ayudará a entender el proceso de creación y la forma en que deben explorarse las soluciones a las dificultades técnicas.¿Cómo empecé?Todo empezó hace un par de años porque vi un curso de iTunes U. A partir de estos conocimientos (y de muchas otras cosas que conocí en el proceso) desarrollé una utilidad a partir de una necesidad personal: cambiar el volumen de mi Mac desde el iPhone. Con el curso de iTunes U descubrí que había muchas tecnologías que no conocía, entonces aprendí sockets, Bonjour, In-App Purchases y Cocos.Mi primer paso fue un curso gratuito que hay en iTunes U llamado 'iOS Development', dictado por Paul Hegarty en la Universidad de Stanford. Aprendí cómo funcionaba iOS, el modelo MVC, los detalles de Objective-C que lo hacen un lenguaje mucho más poderoso que otros. El curso estuvo muy completo y me sirvió de referencia durante los primeros meses.A mediados de julio del 2012 detecté una necesidad personal: estaba acostado en la cama y quería subirle o bajarle el volumen a la música en el Mac desde el iPhone. Pensé fue que debía existir una app para eso pero resultó no ser así: busqué en el App Store y no existía una sola aplicación que lo hiciera. Entonces decidí que la haría para iOS. Al tener en claro lo que quería que hiciera la aplicación establecí tres factores clave a tener en cuenta para arrancar: 1. La aplicación debería ser fácil de manejar, sin configuraciones complicadas o un montón de menús. Entre menos opciones confusas para el usuario, mejor. 2. La aplicación debería ser rápida. Como la app realmente era una utilidad lo ideal sería que cuanto menos tiempo tuviera que pasar el usuario en la aplicación, mejor. Debía solucionar su necesidad desde la primera pantalla que se le mostraba, así podría volver más rápido a lo que estaba haciendo. 3. La aplicación debería ser bonita y llamativa. Esto es sumamente importante en las aplicaciones de iOS. El Human Interface Guidelines de Apple es muy insistente en que, además de cumplir una tarea o una función, usar una aplicación debe ser un acto placentero para el usuario, pues esto hará que la app se destaque frente a otras que hacen lo mismo, ahí puede estar el factor de decisión del usuario. Además se supone que una persona que se siente a gusto con la aplicación la recomendará más fácilmente a sus amigos si cree que es bonita. Después decidí empezar a planear cómo se vería y funcionaría mi aplicación. Empecé a proponer la forma en que el usuario navegaría los ViewControllers, qué vería en cada caso, cómo debía organizar la información, etc. El ideal básico era que en la pantalla principal apareciera un control de volumen y que en alguna pantalla secundaria se pudiera configurar una conexión al computador al que se quisiera conectar.Al empezar a trabajar en la aplicación no sabía exactamente qué iba a necesitar. Aunque sabía cómo mostrar ViewControllers, agregar Views y administrar las navegaciones, había muchas cosas respecto a redes, API's de iOS y OSX que no sabía como funcionaban. Así que antes de ponerme a armar la aplicación, probé cómo construir cada pedacito para luego integrarlo todo. Lo que más me preocupaba en principio era encontrar la manera de conectar el celular con el computador. Al investigar sobre networking entre computadores me encontré el concepto de Sockets, cómo funcionan, TCP y UDP, las ventajas y desventajas de cada uno, etc. Después de entender su funcionamiento de forma general encontré una librería llamada CocoaAsyncSocket. Ésta se encargaba de toda la conexión de bajo nivel y exponía un API orientada a objetos muy fácil de usar.Allí empecé a pensar cómo se debían comunicar. Sencillamente haría un servidor en el Mac que abriera un puerto, se ejecutara en Background y esperara conexiones. Cuando se conectara un celular este enviaría los datos al servidor. Era un dato sencillo que enviaba codificado en un JSON desde el celular al computador, simplemente el celular enviaba {‘newVolume’:0.5} y el servidor en el computador debía encargarse de cambiar el volumen. Adicionalmente, si yo cambiaba el volumen en el computador, se debía actualizar en el celular. Esto fue fácil, simplemente era hacer que el servidor enviara al celular un mensaje con la misma estructura para informarle que había cambiado el nivel de volumen del computador.Cuando ya tenía la versión beta en mi celular mucha gente me preguntaba cómo se conectaba. Me parecía una pregunta rara, pero después entendí que no lo era tanto, ya que hay muchas formas de conexión inalámbrica, Wi-Fi (red local), bluetooth, Internet. Pensé en soportar conexiones por bluetooth, pero se complicaba un poco el asunto, pues pensé que muy poca gente lo usaría pues generalmente apagan esta funcionalidad para ahorrar pila, tanto en el computador como el celular, además muchas PC's no la tienen disponible, entonces el wi-fi era la mejor opción.Luego de lograr conectar el teléfono con el computador y ver que los mensajes que mandaba de un lado llegaban al otro, me di cuenta de que siempre me tocaba hacer algo incómodo: buscar manualmente la IP del computador y ponerla en el celular para conectarme. Esto me parecía particularmente grave porque elevaría la curva de aprendizaje en un 500%, y ahí podría estar la diferencia entre que el usuario usara o no la aplicación. Además muchas veces la gente iba a querer usar la aplicación pero estaría lejos del computador, así que tener que buscar la IP en el computador anularía todo el propósito de usarlo como control remoto.Entonces busqué cómo podría el teléfono encontrar al computador sin necesidad de saber su IP. Encontré una infraestructura buenísima que se inventó Apple y también está disponible en Linux, pero lastimosamente Microsoft no ha querido implementarla nativamente. Se llama Bonjour y funciona de una manera muy sencilla.Bonjour es un sistema para encontrar servicios en redes locales. Por ejemplo, tengo un servidor con Bonjour en una red local, ya no necesito saber la IP, él mismo se anuncia a todos los otros clientes de la red. Esto era justamente lo que necesitaba. Cuando el usuario abría el servidor en su Mac el servidor se encargaba de anunciarse a todos los otros dispositivos de la red, entonces esto permitía que cuando en el teléfono me iba a conectar al servidor ya no mostraba un campo de texto que preguntaba la IP sino que mostraba una lista con todos los computadores locales ejecutando el servidor. Después busqué cómo cambiar el volumen en OSX. No es una tarea tan obvia, pero tampoco me tomó mucho tiempo, no es algo que sea muy difícil de configurar. En Internet encontré fácilmente cómo lo hizo otra persona. Era un código en C nativo, que se encargaba de abrir una conexión al dispositivo de audio, ajustar el volumen a un número y cerrar la conexión.Después de este proceso me hacía falta que la aplicación fuera bonita. Me inspiré mucho en las texturas metálicas circulares con brillo anisotrópico y traté de replicar el efecto con CoreGraphics. El problema es que CoreGraphics usaba la CPU y el efecto se veía a 5fps. Así que aprendí temas básicos de Cocos2d y a poner un shader personalizado para que usara la GPU. Al final se veía bien y con poco uso de procesador.Para ese momento lo que quedaba era configurar las In-App Purchase para acceder a características Premium de la aplicación que en realidad ofrecen más soluciones a los usuarios. Éstas activaban la auto-conexión para que el usuario no tuviera que escoger servidor cada vez y para evitar que el dispositivo se durmiera si el usuario no lo quería. En este punto, aunque la documentación es clara, los mensajes de error son precarios. En un momento yo no sabía que pasaba con mi aplicación porque no funcionaban las IAP. Después de mucho buscar en Internet me di cuenta de que no funcionaban si uno no tenía una cuenta bancaria asociada a la cuenta de iTunes Connect.Desarrollar este proyecto fue una experiencia que me gustó mucho porque no fue sencillo. Aprendí muchas cosas que normalmente no se aprenden. No solamente iOS sino también un poco de OSX y C#(.net) para los Servers en Windows y Mac.¿Qué herramientas he usado?Para desarrollar en iOS solamente he usado Xcode. Aunque al comienzo no es tan fácil, a medida que uno lo usa se da cuenta de las ventajas tanto del lenguaje como del IDE. También participé en el desarrollo de un juego de Unity para iOS (zombie crasher), aunque este no es precisamente en Objective C. Aún así usamos tecnologías de IAP e integración con redes sociales para compartir.¿Cómo fue el proceso de publicación desde Colombia?Publicar desde Colombia no fue una experiencia sencilla pero tampoco es imposible ni una limitación para el desarrollo de un proyecto de esta clase. El mayor problema al principio fue comprar un Developer Program. Para un desarrollador Colombiano este es el paso más incómodo, porque Apple lo hace confuso.La primera vez que lo intenté puse mi dirección de Colombia, datos de contacto y residencia de manera correcta. Pero para que hacer el cobro a la tarjeta de crédito, si uno ha puesto que es colombiano, le piden llenar un formulario como si uno fuera a comprar por Internet, luego hay que imprimirlo y mandarlo por fax (proceso que es incómodo) y que a mi personalmente no me resultó. Mandé el fax dos veces y nunca cobraron ni activaron ningún plan.Entonces decidí registrarme de nuevo, con otro correo, pero poniendo la dirección de un familiar de US. Cuando lo estaba haciendo me pidieron los datos de la tarjeta de crédito, de inmediato facturaron y empezó a correr mi plan. No hubo ningún inconveniente esta vez. Después de eso actualicé mis datos, puse mi dirección de Colombia y no hubo ningún problema. No sé si aún sea requisito hacer esta maniobra o si ya se pueda hacer más fácilmente.Después de este registro el proceso de publicación desde Colombia no fue diferente al de cualquier otro país. Uno crea una nueva aplicación en iTunes Connect, sube íconos, sube screenshots, sube la aplicación, espera 'Review' y escoge fecha de publicación con el costo de la app. El único problema que tuve, más por falta de documentación que por dificultad, fue en este paso de hacer In-App Purchases. Es necesario tener una cuenta bancaria registrada. Pero de resto el proceso de publicación fue fácil.