Nuevo capítulo: ¿cómo programamos nuestra aplicación o nuestro juego? ¿cuándo empezamos? Bueno, para empezar, desde que di la introducción al curso han pasado muchas cosas: ha pasado Lion, Xcode 4.1 para Lion se ha vuelto gratuito y un maravilloso framework para iOS que usaremos en este curso, como Cocos2D, ha llegado a su versión estable 1.0.
Pero hay que tener una cosa tremendamente clara: picar el mejor código de la historia no va a hacer una gran aplicación. Lo importante es que tengamos un buen diseño. Apple es único en este aspecto y no tenemos más que echar un vistazo a sus aplicaciones para iOS como GarageBand o la suite iWork, para darnos cuenta que el nivel de calidad y acabado que tienen sus aplicaciones y sus interfaces, está muy lejos de la calidad del resto de aplicaciones de la propia App Store. Todo es por una razón muy sencilla: lo más importante de una aplicación es su diseño.
El desarrollar el código necesario para realizar ese diseño, en muchas ocasiones es lo de menos. No existe el código de aplicación perfecto, existen miles de soluciones al problema: algunas mejores, otras peores. Si conseguimos un código que sea bueno, pero el diseño no está a la altura, poco haremos. Si el diseño es bueno, pero el código hace que no funcione muy bien, todo puede arreglarse pero la base está a la altura. Lo ideal, como es lógico, es tener un buen diseño y un buen código, y entonces tendremos el binomio perfecto para estar orgullosos de nuestros trabajo y tener más oportunidades de proyección de nuestra aplicación, juego o lo que sea que hayamos realizado.
En el caso de iOS, tenemos dos formas de afrontar el reto:
– La primera es siguiendo los elementos de diseño de interfaz que Apple pone a nuestra disposición, disponibles en el constructor de interfaces incluido en Xcode 4. Estos elementos son aquellos que ya conocemos todos como listas, radios, botones, cajas de texto, etiquetas… Componen una serie de elementos, funcionales tanto para iPhone como para iPad (cada uno en su versión y tamaño) y con ello construimos los interfaces estándar que tan acostumbrados estamos a ver en cualquier aplicación. – La segunda es sin seguir estos elementos y creando los nuestros propios, usando cualquiera de las motores gráficos. Este es el normalmente se usa en los juegos, por razones obvias, pero también podemos crear interfaces gráficas o elementos personalizados que construyan nuestros interfaces. A este tipo de interfaces Apple les echa un buen vistazo cuando mandamos nuestra aplicación para aprobar.
En el primero de los casos, podemos ayudarnos de herramientas muy útiles como OmniGraffle o el propio Adobe Photoshop. Existen librerías específicas para estos programas (PSD en el caso de Photoshop) que contienen los elementos estándar del interfaz, y nos pueden ayudar a crear la aplicación que queramos. Para el caso de OmniGraffle (una herramienta de dibujo vectorial y diseño sobresaliente) podemos acceder a la web graffletopia.com y descargar los stencils (librerías de elementos gráficos) que nos permitirán diseñar nuestras interfaces previamente.
Debemos primero crear un diagrama genérico de qué hará cada pantalla y como se llamará la una a la otra, para después dibujar las opciones y ponerlas dentro del diagrama. De esta forma, tendremos el mapa de navegación de nuestra aplicación, con todas sus opciones disponibles, y como cada opción tiene su origen y su destino.
De igual forma, si nuestra aplicación va a utilizar o grabar datos de alguna forma, hemos de decidir qué base de datos va a utilizar, cuál será el mejor modelo de datos que podemos usar para grabarlos (es decir, la estructura de las tablas o diagrama entidad-relación) y la mejor forma de gestionarlo. En este caso, por ejemplo, imaginad que tenemos un juego con mucho texto, que será bilingüe. ¿Qué es más fácil? ¿Poner el texto en cada línea de código según esa español o inglés, o crear una base de datos con los textos y que se recuperen según un etiquetado concreto? Evidemente, es mejor el último.
En iOS, podemos usar dos tipos de motores diferentes de bases de datos. El propio de Apple llamado CoreData, y la implementación de código abierto SQLite3, que será el que usemos en principio pues es más sencillo y fácil de modularizar.
Por lo tanto, ya sabéis, debéis empezar a fraguar vuestras ideas, hacer los mapas de diseño y diseñar la interfaz. Id comprando OmniGraffle si no lo tenéis ya (podéis comprarlo en el Mac App Store, aunque no es barato es un grandísimo programa), usar el Adobe Photoshop o cualquier otro. En la próxima lección veremos los pasos en detalle de una aplicación de ejemplo.
