Currently browsing: Objective-C

Introducing… MawKit

Recently I’ve released two iOS games (with Javier Rodríguez Vidal‘s and Víctor Grau Moreso‘s help). Both games use Cocos2d-x engine and a custom open source framework built on top of it named MawKit which I want to introduce in this post.

Why another framework?

We started developing Hop Raider last year’s November. At that moment there was a beta project called SDKBox focused on providing cross-platform plugins to Cocos2d-x but our experience was pretty frustrating: ads plugins which used outdated third-party APIs and spammy log-level, leaderboards/achievements plugins really buggy, almost no support for OS X, not-well documented plugins and features missing.

So we decided to develop our own solution, originally focused on offering a cross-platform (Android, iOS, OS X) implementation for ads and leaderboards/achievements, and called it MawKit. We developed the first version as we wrote Hop Raider and refactored it to make it open-source when we developed Blimp Journey.

It is written in C++, Java and Objective-C++ and offers callbacks to handle asynchronous operations, avoiding busy-waiting and global variables. MawKit is fully documented with Doxygen although we are working on improving Github’s documentation at the moment.

What does MawKit offer?

MawKit includes platform-specific implementation for features like:

  • Leaderboards and achievements (Google Play Games on Android and GameCenter on iOS/OS X).
  • Ads (Admob and AdColony on both iOS and Android – noop implementation for OS X as there is no oficial SDK for this platform).
  • In-app purchases.

As well as cross-platform utilities like:

  • Mathematical helpers (random number generator, ranges).
  • A simple key-value database with local persistence.
  • Additional FiniteTimeActions (move a node to the position of a different node, regardless it is static or in movement, shake a node, etc).
  • Logging utilities (prepending prefixes to the logged message to easily identify their priority)
  • Infinite parallax nodes (both vertical and horizontal).
  • Device utilities (get screen’s size, hardware performance and motion sensors coming soon).
  • Fabric‘s Answer (all platforms) and MixPanel (iOS) support.

Here are some nice snippets:

  • Storing money with KVDatabase:
  • Reporting new score:
  • Checking whether an achievement is unlocked:
  • Showing an ad:
  • Throwing a dice:
  • Moving a node to the position of another moving node (bonus: this snippet is part of Hop Raider):
  • Getting current language:

Ideas, suggestions, contributions…

… are welcomed as Github issues or pull requests.

 

 

Actualización 2.0.1 de Music Maniac

Beware: This post was published 6 years ago and its content may be outdated.

Icono de Music Maniac Lite 2.0En cuestión de horas estará disponible la versión 2.0.1 de Music Maniac en el AppStore. Esta actualización corrige algunos errores de la versión 2.0, entre los que se encuentran:

  • Un error en la traducción al español.
  • Errores diversos al tener pocas canciones en la biblioteca de iTunes (o pocos metadatos sobre las mismas).
  • Un error que no iluminaba la respuesta correcta al terminar una ronda y no seleccionar ninguna canción.
  • Se ha mejorado el consumo de capacidad de almacenamiento que requiere Music Maniac para guardar ciertas estadísticas.

También incluye otros cambios menores, como que al jugar Offline y salir de un concurso, en lugar de perder los avances, se carga la vista de estadísticas y se guardan los puntos obtenidos durante el tiempo que se jugó.

Además esta actualización también afecta a Music Maniac Lite, pudiendo disfrutar de las novedades de la versión 2.0 en la versión reducida de Music Maniac.

Guardar objetos en archivos con Objective-C

Beware: This post was published 6 years ago and its content may be outdated.

Ayer Carmen Parra preguntaba en un comentario cómo se pueden guardar los datos introducidos por el usuario en un archivo. Como el proceso es demasiado largo como para publicarlo en un comentario, he decidido escribir este pequeño tutorial.

NSArray, NSDictionary, NSString, NSNumber, NSData y otros

Resultado del código de ejemploHay dos métodos sencillos para almacenar un objeto en un archivo y poder recuperarlo cuando nos convenga. El primero no se puede aplicar a cualquier objeto, sino a objetos de algunas clases de Objective-C que responden a dos métodos llamados writeToFile:atomically: y writeToURL:atomically:. El uso de estos métodos es muy sencillo, basta con llamarlos en el momento en el que queramos que el objeto se guarde en un archivo.

A continuación teneís un ejemplo comentado. Básicamente creamos una matriz, le añadimos algo de contenido, la imprimimos, la guardamos en un archivo y nos deshacemos de ella. A continuación creamos otra matriz que lea el contenido del archivo y comprobamos que tiene el mismo contenido que la anterior. El resultado que obtendréis será similar al de la imagen de la derecha.

NSMutableArray *array = [[NSMutableArray alloc] init]; // Creamos una matriz
	[array addObject:@"¡Hola"]; // Añadimos un objeto
	[array addObject:@"mundo!"]; // Añadimos otro objeto
	NSLog(@"Matriz original: %@", array); // Imprimimos la matriz original
	[array writeToFile:@"filename" atomically:YES]; // Escribimos en el archivo filename el contenido de la matriz
	[array release]; // Liberamos memoria
	NSMutableArray *arrayFromFile = [[NSMutableArray alloc] initWithContentsOfFile:@"filename"]; // Esta matriz tiene el mismo contenido que tenía la matriz anterior
	NSLog(@"%@", arrayFromFile); // Imprimimos la matriz recuperada del archivo
	[arrayFromFile release]; // Liberamos memoria

Del mismo modo que se puede guardar en un archivo un objeto de la clase NSArray, también se puede usar con objetos NSDictionary, NSString, NSData y NSNumber, entre otros. Sin embargo no se puede usar con objetos de una clase creada por nosotros (en la mayoría de los casos).

Clases creadas por nosotros

Para guardar en un archivo un objeto de una clase creada por nosotros, tendremos que hacer que el objeto sigua el protocolo NSCoding. Tras esto, mediante las clases NSKeyedArchiver y NSKeyedUnarchiver podremos guardar en un archivo y leer de un archivo nuestro objeto. Este protocolo tiene dos métodos necesarios: initWithCoder: y encodeWithCoder:.

Vamos a suponer que hemos creado la clase Empleado, que tiene la siguiente interfaz:

@interface Empleado : NSObject
@property (nonatomic, retain)	NSString	*nombre, *apellidos;
@property						NSUInteger	edad;
@property						BOOL		esEmpleadoDelMes;
@end

Para poder almacenar este objeto en un archivo tendremos primero que hacer que siga el protocolo NSCoding. Modficaremos la interfaz y la dejaremos así:

#define kNombre				@"Nombre"
#define kApellidos			@"Apellidos"
#define kEdad				@"Edad"
#define kEsEmpleadoDelMes	@"esEmpleadoDelMes"
@interface Empleado : NSObject
@property (nonatomic, retain)	NSString	*nombre, *apellidos;
@property						NSUInteger	edad;
@property						BOOL		esEmpleadoDelMes;
@end

Básicamente hay dos cambios: hemos indicado que la clase sigue el protocolo NSCoding y hemos definido una serie de constantes que usaremos más adelante y que entenderéis en seguida su utilidad.

Ahora pasamos a la implementación. Esta es la implementación original de la clase Empleado, antes de seguir el protocolo NSCoding:

@implementation Empleado
@synthesize nombre, apellidos;
@synthesize edad;
@synthesize esEmpleadoDelMes;
- (void)dealloc
{
	[nombre release];
	[apellidos release];
	[super dealloc];
}
@end

Ahora vamos a añadir los dos métodos que necesitamos para seguir el protocolo NSCoding. Estos métodos nos permiten archivar nuestro objeto. El método encodeWithCoder: tiene por parámetro un objeto de la clase NSCoder. En este objeto archivaremos las propiedades del nuestro, asignándole a una serie de claves las propiedades del objeto.

Por ejemplo, si queremos hacer que la propiedad nombre se archive en la clave clave, el método tendría el siguiente aspecto:

- (void)encodeWithCoder:(NSCoder *)coder {
    [coder encodeObject:self.nombre forKey:@"clave"];
}

No todas las propiedades se archivan de la misma forma. Los objeto se archivan a través del método encodeObject:forKey:, los números enteros se archivan con encodeInteger:forKey: y los valores booleanos con encodeBool:forKey:. Las claves son muy importantes, ya que el método initWithCoder: va a desarchivar el objeto usando las mismas claves para acceder a las propiedades, por eso hemos definido una serie de constantes que serán las claves que usaremos para archivar y desarchivar las propiedades.

Nota: Tenéis una lista de todos los métodos para archivar objetos, así como una explicación del proceso de archivar y desarchivar objetos en la documentación de Apple (en inglés).

Nuestro método encodeWithCoder: quedará así:

- (void)encodeWithCoder:(NSCoder *)coder {
    [coder encodeObject:self.nombre forKey:kNombre];
	[coder encodeObject:self.apellidos forKey:kApellidos];
	[coder encodeInteger:self.edad forKey:kEdad];
	[coder encodeBool:self.esEmpleadoDelMes forKey:kEsEmpleadoDelMes];
}

El método initWithCoder: es muy similar al anterior, sólo que su funcionamiento es el contrario: a partir de un objeto archivado se obtienen las propiedades y se crea un objeto de la clase Empleado (en este caso) con las propiedades que tenía el objeto al archivarse. En este caso enviaremos el mensaje decodeObjectForKey:@”clave” a coder y asignaremos el valor devuelto a la propiedad de nuestro objeto. De nuevo, se usan métodos diferentes para decodificar número enteros, valores booleanos y otros tipos de variables. Nuestro método initWithCoder: quedará así:

- (id)initWithCoder:(NSCoder *)coder {
    if ((self = [super init])) {
		self.nombre = [coder decodeObjectForKey:kNombre];
		self.apellidos = [coder decodeObjectForKey:kApellidos];
		self.edad = [coder decodeIntForKey:kEdad];
		self.esEmpleadoDelMes = [coder decodeBoolForKey:kEsEmpleadoDelMes];
	}
    return self;
}

Resultado del ejemploAhora pasemos a crear un objeto Empleado, a guardarlo en un archivo y a comprobar que funciona correctamente. Primero incluímos la interfaz de la clase Empleado en el archivo en el que vamos a crear el objeto, en mi caso, y al tratarse de una “Command Line Tool“, lo incluiré en el archivo main.m. El siguiente código comentado crea un objeto de la clase Empleado, le asigna algunos valores sus propiedades, lo archiva y después crea un nuevo objeto con el contenido del archivo en el que se ha guardado antes el objeto:

Empleado *trabajador = [[Empleado alloc] init]; // Creamos el objeto
	trabajador.nombre = @"Juan"; // Le damos un nombre
	trabajador.apellidos = @"García López"; // Unos apellidos
	trabajador.edad = 26; // Una edad
	trabajador.esEmpleadoDelMes = YES; // Y lo hacemos empleado del mes
	NSLog(@"%@ %@ tiene %lu años", trabajador.nombre, trabajador.apellidos, trabajador.edad); // Imprimimos sus datos
	[NSKeyedArchiver archiveRootObject:trabajador toFile:@"empleado"]; // Lo guardamos en el archivo empleado
	[trabajador release]; // Liberamos memoria
	Empleado *trabajadorRecuperado = [NSKeyedUnarchiver unarchiveObjectWithFile:@"empleado"]; // Creamos un objeto a partir del archivo empleado
	NSLog(@"%@ %@ tiene %lu años", trabajadorRecuperado.nombre, trabajadorRecuperado.apellidos, trabajadorRecuperado.edad); // Imprimimos sus datos

Así se puede guardar un objeto de cualquier clase en un archivo, de forma que puede ser recuperado en cualquier momento. Los objetos más complejos pueden necesitar métodos más complejos a la hora de archivarlos. Del mismo modo no se tienen por qué archivar todas las propiedades si no se quiere.

Por último dejo a vuestra disposición los archivos del proyecto que he creado mientras escribía el tutorial, por si os atascáis y necesitáis un empujoncito.

Music Maniac 2.0 en el AppStore

Beware: This post was published 6 years ago and its content may be outdated.

Ya está disponible Music Maniac 2.0 en el AppStore como una actualización de Music Maniac. Las novedades ya las resumí hace unos días, que son en definitiva nuevos modos de juego, nueva interfaz, modo multijugador online y otras mejoras que no se pueden resumir en un solo párrafo.

La versión Lite de Music Maniac estará disponible muy pronto.

Página de Music Maniac en Sumolari.com | Galería de imágenes de Music Maniac | Music Maniac en el AppStore.

Music Maniac 2.0 muy pronto en el App Store

Beware: This post was published 6 years ago and its content may be outdated.

Music Maniac 2.0Music Maniac 2.0 ha sido aprobada en el App Store.  Estará disponible como actualización para todos los usuarios de Music Maniac cuando haya sido aprobada la versión Lite. Mientras tanto, y a falta de unos días (u horas) para que esté disponible esta nueva versión, voy a resumir las principales novedades.

Reescrita desde 0

Esta no es una actualización cualquiera. He comenzado desde 0 la aplicación y la he vuelto a programar al completo, eliminando cualquier error de la versión anterior y añadiendo nuevas funciones. La interfaz también ha cambiado. Ahora el jugador puede añadir concursos a Music Maniac, configurando las rondas, los modos de juego y las preguntas. No hay ningún límite de concursos, y por defecto hay tres concursos (que por supuesto, pueden modificarse o eliminarse). Se pueden desplazar los concursos para ver otros.

En la parte inferior de la pantalla hay una serie de trucos e indicaciones. El menú de la aplicación se despliega al hacer un doble toque en la parte superior de la pantalla, e imita la forma de la barra de multitarea de iOS 4. Cada icono lleva a una sección diferente de la aplicación, generalmente para añadir, ordenar o editar concursos.

Modo multijugador

Se ha rediseñado el modo multijugador. A partir de ahora se podrá jugar hasta con 4 jugadores, vía Game Center o compartiendo el mismo dispositivo. La interfaz se adapta al número de jugadores para mostrar las puntuaciones de cada uno en todo momento. Además se puede pausar el juego y salir en cualquier momento.

Se ha mejorado el modo online. Ahora Music Maniac crea una caché del Top 50 de la iTunes Store y te permite jugar tanto en solitario como con amigos con estas canciones. La primera descargar puede tardar un poco, ya que se deben descargar alrededor de 50 MB, no obstante las siguientes son más rápidas, ya que Music Maniac aprovecha las canciones que ya se han descargado y siguen en el Top 50 de la iTunes Store  para agilizar la siguiente sincronización.

Rendimiento mejorado

Music Maniac es ahora más estable y más rápida. Se puede jugar en cualquier dispositivo que soporte iOS 4 y con bibliotecas grandes. El modo online ofrece además un redimiento mejorado al descargar y procesar todas las canciones para que durante las partidas el dispositivo tenga que hacer el minimo esfuerzo posible y se pueda mantaner un ritmo trepidante.

Universal

La aplicación sigue siendo universal, es decir, la diversión no se queda en el iPhone o iPod touch, sino que se puede jugar en el iPad con una interfaz mejorada para su pantalla. Los gráficos también están preparados para la Retina Display del iPhone 4 y los iPod touch de última generación.

Desde la aplicación Ajustes se puede cambiar el idioma de Music Maniac, traducido por completo al inglés, español y catalán. Puedes jugar con Music Maniac en inglés aunque tengas tu dispositivo en español… ¡o en ruso!

Nuevo sistema de juego

En Music Maniac se pueden crear los concursos más flexibles vistos en iOS. Ya no se establece el número de rondas por concurso, sino el número de veces que quieres jugar con un modo. Así es posible crear un concurso con una sola ronda para el modo rápido y muchas más rondas para el modo estándar. Además Music Maniac ofrece un nuevo modo de juego: el modo apuesta. Cuanto más puntos se arriesguen más puntos se pueden ganar.

Game Center

Además de soportar el modo multijugador hasta 4 jugadores a través de Game Center, Music Maniac incluye logros y tablas de clasificación en las que poder lucirse, También lleva un recuento de los aciertos y al final de cada concurso online que se juegue muestra la lista de las canciones que han sonado, por si te ha gustado alguna y quieres acerte con ella.

Imágenes

Estas son las imágenes que aparecerán en el App Store. Hay más imágenes en la página de Music Maniac.

Se buscan Beta-Testers para Music Maniac 2.0

Beware: This post was published 6 years ago and its content may be outdated.

Music Maniac 2.0

Nota: Ya se han registrado suficientes probadores para Music Maniac 2.0. Muchas gracias a todos por mostrar vuestro interés.

El desarrollo de Music Maniac 2.0 va a buen ritmo, y ya ha llegado el momento de buscar voluntarios interesados en probar la aplicación, reportar errores y hacer sugerencias para mejorar aún más esta versión.

¿Qué se ofrece?

Colaborar en la creación de una aplicación para iOS, ser escuchado y ver las sugerencias que sean propuestas implementadas en la la versión final de la apliación. Poder sentir que se ha sido parte del proyecto y aparecer en los créditos de la aplicación, además de recibir una copia de la aplicación, incluidas todas las futuras actualizaciones de la misma.

¿Qué se necesita para ser probador?

Un dispositivo que soporte y tenga instalado iOS 4.0 (iPod Touch 2G/3G/4G, iPhone 3G/3GS/4 o iPad), con conexión a Internet vía Wi-Fi o 3G (imprescindible conexión a Internet en el dispositivo para poder instalar las Betas). Los dispositivos a los que se les ha realizado el Jailbreak no están excluidos, aunque no he comprobado que se puedan instalar las Betas en ellos.

¿En qué consiste la aplicación?

Se trata de la reescritura desde 0 de Music Maniac, el concurso musical para iOS. Describiendo a grandes rasgos la aplicación, he reescrito todo el código desde 0, he rediseñado toda la aplicación y la he reestructurado para hacerla estable, rápida y atractiva. Pero de momento quiero guardar en secreto las novedades, hasta tener lista la versión final.

¿Cómo inscribirse?

Ya se han registrado suficientes probadores y no se admiten más inscripciones. ¡Gracias por mostrar tu interés!

Presentando… Music Maniac

Beware: This post was published 6 years ago and its content may be outdated.

Vale, pensaba que no tendría tiempo y que tendría que retrasar la aplicación hasta verano, pero no, al final con un esfuerzo extra y un par de días de completa dedicación al proyecto, he podido acabar la aplicación hace apenas un semana (el resto del tiempo ha estado en revisión). Así que hoy toca presentación de la aplicación.

¿Qué es Music Maniac?

Icono de Music Maniac¿Recordáis el juego del concurso musical de los antiguos iPod Video? Para los que no os suene, se trataba de un juego muy sencillo en el que  sonaba durante unos segundos una canción y se te ofrecían una serie de títulos entre los que elegir. Si acertabas el título conseguías puntos y si fallabas, no. Además, cuánto más rápido acertases más puntos ganabas, así que la velocidad era importante.

Music Maniac es mi idea de cómo debería haber sido ese juego llevada a iOS. ¿Y qué tiene de nuevo Music Maniac? Para empezar, más flexibilidad: se puede jugar con sólo los títulos de las canciones, con los nombres de los álbumes, con los nombres de los artistas, con las carátulas de los álbumes o con combinaciones de los anteriores. También se puede personalizar la duración de las canciones o el número de rondas.

Se puede jugar tanto con canciones de nuestra biblioteca de iTunes (a las que será necesario añadirle los datos del título, artista, álbum y carátula, ya que de algún sitio tiene que sacar la información sobre la canción Music Maniac) como con las canciones más populares de la iTunes Store. Sin embargo los modos de juego son diferentes: en el modo offline podemos jugar las rondas que queramos, hasta cansarnos o hasta fallar por primera vez, mientras que en el modo online sólo podemos jugar 10 rondas (esto es porque deben descargarse las canciones y el proceso requiere tanto tiempo para descargarlas como memoria libre para almacenarlas).

Como aliciente al modo offline, se puede jugar con amigos con un sólo dispositivo, pasándolo al terminar cada ronda y viendo después quién ha conseguido más puntos. Pero la competición no acaba en el modo offline, ya que Music Maniac tiene clasificaciones y logros de Game Center, con lo cual podrás ver quién conoce mejor su música y quién los éxitos de la iTunes Store. También podrás desbloquear logros acertando rondas en pocos segundos o acumulando cierta cantidad de puntos.

Music Maniac estará disponible en unas horas de forma gratuita en una versión Lite, en la que sólo se puede jugar en el modo offline, sin personalizar las rondas y sin enviar las puntuaciones a Game Center y en versión completa por 0.99$ (0.79€).

La aplicación es universal: está adaptada tanto a iPod Touch y iPhone (también a la Retina Display del iPhone 4) como a iPad. Además está traducida al inglés, catalán y español (lo siento, no hablo más idiomas, así que lo dejo en esos tres).

Próximas actualizaciones

Seguramente habréis visto por la App Store muchas aplicaciones que comienzan con una versión 1.0 y al cabo de un tiempo lanzan la versión 2.0 como aplicación independiente de la anterior. Esto no va a pasar con Music Maniac. Music Maniac sólo habrá una, se actualizará (sí, habrá versión 2.0, me gustaría desarrollarla en verano) y sus actualizaciones serán gratuitas para todo aquel que comprase la versión anterior y tendrá el mismo precio que la aplicación original para aquellos que no la comprasen.

También aviso que no habrá cambios de precio, ni subidas ni bajadas. La aplicación costará siempre 0.99$ (a no ser que Apple me impida ponerle ese precio), así que no os precupéis por posibles subidas de precio futuras: no las habrá.

Introducción a Objective-C: El paradigma de la POO

Beware: This post was published 6 years ago and its content may be outdated.

Siguiendo con los tutoriales de Objective-C, voy a explicar el paradigma de la Programación Orientada a Objetos. En la POO de Objective-C hay 5 conceptos clave:

  • Objeto: Los objetos son el pilar fundamental en la POO. Los objetos contienen variables, responden a métodos, tienen una dirección de memoria en la que están almacenados, pertenecen a una clase y pueden implementar protocolos.
  • Clases: Un objeto pertecen a una clase, y sólo a una. Por el contrario varios objetos pueden pertenecer a la misma clase. En otros lenguajes de programación los objetos pueden heredar de varias clases, pero en Objective-C no. Cuando un objeto pertecene a una clase, el objeto contiene todas las variables de la clase, y responde a todos los métodos de instancia a los que responde la clase (veremos qué es esto más adelante). A su vez, una clase puede heredar de otra clase (de hecho lo más común es que las clases que creemos hereden de NSObject, al menos a nuestro nivel), cuando esto sucede, la nueva clase responde a todos los métodos a los que respondía la clase “padre” y los objetos de esta clase también tienen las variables de instancia de la clase “padre”.
  • Variables de instancia: Los objetos, a pesar de ser por sí mismos variables, pueden contener a otras variables, que pueden ser variables simples como las de C (por ejemplo, números enteros o de coma flotantes) u objetos de cualquier clase. Las variables de instancia son diferentes en cada objeto, por lo que si tenemos dos objetos de la clase rueda y accedemos a la variable presiónDeLaRueda, cada uno devolverá un valor diferente de presión.
  • Métodos de instancia: Los métodos de instancia son las funciones que puede ejecutar el objeto de una clase determinada. Cada clase define unos métodos de instancia diferente. Por ejemplo, la clase coche podría tener un método que fuese encenderMotor, al que se accedería desde un objeto determinado.
  • Métodos de clase: Los métodos de clase son funciones a las que sólo se puede acceder desde la propia clase. Un método de clase típico es alloc, al que sólo se puede acceder desde una case, nunca desde un objeto.

Puede que no os hayan quedado claros del todo los conceptos con esta introducción, los explicaré mejor un poco más adelante.

Creando una nueva clase

Creando una nueva clase

Creando una nueva clase - Paso 2

Creando una nueva clase - Paso 2

En Objective-C las clases se definen mediante dos archivos: NOMBRECLASE.h y NOMBRECLASE.m. Los archivos .h contienen la interfaz de la clase y los archivos .m su implementación. La interfaz de la clase es una especie de índice: indica todas las varibles de instancia de la clase y todos los métodos a los que responde. La implementación es donde se desarrolla el código de las funciones. No es necesario dividir las clases en dos archivos, pero es altamente recomendable para hacer más claro el código.

Para añadir un nuevo archivo a nuestro proyecto basta con ir al menú File » New file… o pulsar Comando + N. En la ventana que nos aparecerá seleccionaremos Mac OS X » Cocoa Class » Objective-C Class (Subclass of NSObject). En  File Name introduciremos el nombre de nuestra nueva clase, en este caso Coche, acabado en .m. También marcaremos la casilla Also create “Coche.h”, para mantener más limpio el código.

En el archivo Coche.h encontraremos el siguiente código:

#import <Cocoa/Cocoa.h>
@interface Coche : NSObject {
}
@end

La primera línea ya la vimos en la primera parte de los tutoriales, e importa el Framework Cocoa. En la siguiente línea comienza la interfaz de la clase. Veamos su sintaxis:

  • @interface: Inicia la interfaz
  • Coche: El nombre de la clase que estamos definiendo
  • : : Separado entre el nombre de la clase y la clase de la que hereda.
  • NSObject: La clase de la que hereda nuestra clase.
  • { : Abre el bloque donde se definen las variables de instancia.
  • } : Cierra este bloque.
  • @end: Indica el fin de la implementación.

Como podéis ver, las clases pueden ser “hijas” de otras clases, y es algo realmente común. De hecho es muy conveniente que nuestras clases sean hijas de al menos NSObject. La clase NSObject es la clase básica e incluye las funciones esenciales de gestión de memoria (la veremos más tarde), entre otras cosas.

Si nuestra clase es hija de una clase que es hija de NSObject, esta nueva clase también tendrá acceso a los métodos de la clase NSObject.

Ahora bien, imaginemos que queremos que queremos que nuestra clase tenga alguna variable de instancia, como por ejemplo, el color del vehículo y el número de puertas. Definiremos dos variables: color y numPuertas. La primera, color, será un objeto de clase NSString (cadena de texto). La segunda, numPuertas, será una variable de tipo NSUInteger (a nuestro nivel, equivalente a un unsigned int de C, o en palabras llanas, un número entero sin signo).

#import <Cocoa/Cocoa.h>
@interface Coche : NSObject {
 NSString    *color;
 NSUInteger    numPuertas;
}
@end

Fijáos en la sintaxis para definir varibles de instancia:

NOMBRE_DE_LA_CLASE_DEL_OBJETO *NOMBRE_DEL_OBJETO;
NOMBRE_DEL_TIPO_DE_VARIABLE NOMBRE_DE_LA_VARIABLE;

Al defnir un objeto siempre antepondremos un asterisco (“*”) al nombre del objeto.

Y ahora, ¿cómo obtenemos el valor de estas variables? Pues bien, tendremos que crear un método de instancia para asignar este valor. Los métodos se definen entre el corchete de cierre (“}”) y el @end. Creemos dos métodos de instancia: getColor y getNumPuertas. Creemos otro más llamado imprimirDetalles que muestre en la consola los valores devueltos por getColor y getNumPuertas.

#import <Cocoa/Cocoa.h>
@interface Coche : NSObject {
 NSString    *color;
 NSUInteger    numPuertas;
}
- (NSString *)getColor;
- (NSUInteger)getNumPuertas;
- (void)imprimirDetalles;
@end

Fijáos de nuevo en la sintaxis:

- (CLASE_DEL_OBJETO_QUE_VAMOS_A_DEVOLVER *)NOMBRE_DE_LA_FUNCION;
- (TIPO_DE_LA_VARIABLE_QUE_SE_DEVOLVERA)NOMBRE_DE_LA_FUNCION;
- (VOID)NOMBRE_DE_LA_FUNCION_QUE_NO_DEVUELVE_NADA;

Como antes, cuando un método devuelve un objeto, se añade un asterisco al nombre de la clase del objeto que se devolverá. Cuando no es un objeto, no es necesario añadir el asterisco. Cuando una función no devuelve nada, se utiliza el valor void para indicárselo al compilador.

El guión (“-“) que precede a los métodos sirve para indicar que se trata de métodos de instancia. Si se tratase de métodos de clase (que veremos más adelante), estarían precedidos por un sigo +.

Pero aún nos faltan dos métodos para establecer el valor de las dos variables de instancias. Para ello definiremos dos métodos llamados setColor y setNumPuertas que acepten un parámetro que será el nuevo valor.

#import <Cocoa/Cocoa.h>
@interface Coche : NSObject {
 NSString    *color;
 NSUInteger    numPuertas;
}
- (NSString *)getColor;
- (NSUInteger)getNumPuertas;
- (void)imprimirDetalles;
- (void)setColor: (NSString *)nuevoColor;
- (void)setNumPuertas: (NSUInteger)nuevoNumPuertas;
@end

Analicemos la sintaxis de estas funciones. Como podéis ver, ninguna de las dos devuelve ningún valor, luego en el primer paréntesis escribiremos void. Los nombres están claros, pero al final de estos hay dos puntos (“:”). Esto indica que a continuación se encuentra un parámetro. Los parámetros tienen dos partes: la clase del objeto que es el parámetro o el tipo de la variable que es el parámetro y el nombre del mismo. La sintaxis es igual que la del tipo de valor que devuelve la función: El tipo de variable o la clase de objeto entre paréntesis (si es un objeto el parámetro se añade un asterisco) y a continuación el nombre del mismo. Las funciones pueden admitir varios parámetros, y pueden haber funciones con el mismo nombre pero diferentes parámetros. A continuación tenéis un ejemplo.

- (void)miFuncion;
- (void)miFuncionConUnParametro: (NSUInteger)miParametro;
- (NSString *)miFuncionConUnParametro: (NSUInteger)miParametro queAdemasDevuelveUnaCadenaDeTextoYRequiereOtroParametro: (NSUInteger)elSegundo;

Esto presenta un problema: ¿Cómo se llaman las funciones, si puede haber dos iguales hasta el primer parámetro? Pues bien, las funciones anteriores se llamarían así:

miFuncion
miFuncionConUnParametro:
miFuncionConUnParametro:queAdemasDevuelveUnaCadenaDeTextoYRequiereOtroParametro:

De este modo no son iguales los nombres a pesar de ser bastante parecidos (al menos en principio).

Con esto hemos creado la interfaz de nuestra clase: el índice de variables y métodos a los que responde. Sin embargo aún tenemos que escribir el código de estas funciones, así que vayamos al archivo Coche.m y comencemos a implementarlas. En el archivo .m veremos el siguiente código:

#import "Coche.h"
@implementation Coche
@end

Os suena, ¿verdad? Como en el caso anterior, vemos como se importa un archivo, en este caso la interfaz de nuestra clase. También vemos como se inicia la implementación con un código similar a la interfaz. Como podéis suponer, entre @implementation Coche y @end es donde escribiremos nuestras funciones.

Antes de implementar nuestras funciones, añadid el siguiente código después de @implementation Coche. Se trata de un método para la gestión de memoria que veremos en otro tutorial. Así de forma rápida, el método dealloc se llama cuando un objeto va a ser eliminado de la memoria. Los objetos tienen un contador interno que se aumenta con el método retain y se disminuye con el método release. Cuando el contador llega a 0, se llama automáticamente al método dealloc y se elimina el objeto de la memoria. De momento basta con que lo copiéis sin preguntar, ya lo explicaré más adelante.

- (void)dealloc
{
 [color release];
 [super dealloc];
}

Aprovechando este código os explicaré cómo se sobreescriben funciones ya existentes en la clase padre. Como he comentado, una clase que hereda de otra recibe las funciones de la clase padre, pero ¿qué sucede si queremos que en la clase hija la función heredada sea diferente? Pues nada, escribimos la nueva función como cualquier otra. La sintaxis es sencilla:

- (TIPO_DE_VALOR_QUE_SE_DEVUELVE)NOMBRE_DE_LA_FUNCION
{
// Código de la función
}

¿Qué ocurre si queremos que además de ejecutarse nuestro código se ejecute también el método (por si no os habéis dado cuenta, utilizo método y función para referirme a lo mismo, tal vez no es lo más correcto, pero estoy más acostumbrado a hablar de función y no de método, así que me sale sin pensar) de la clase padre que estamos sobreescribiendo? Pues añadimos [super NOMBRE_DE_LA_FUNCION]; en el lugar en el que queramos que se ejecute.

- (TIPO_DE_VALOR_QUE_SE_DEVUELVE)NOMBRE_DE_LA_FUNCION
 {
// Podemos ejecutar el método de la clase padre antes que nuestro código
[super NOMBRE_DE_LA_FUNCION];
// Código de la función
// O después
[super NOMBRE_DE_LA_FUNCION];
}

Veamos ahora cómo quedaría la implementación de nuestra clase tras añadir todos los métodos que hemos definido en la interfaz:

#import "Coche.h"
@implementation Coche
- (void)dealloc
{
 [color release];
 [super dealloc];
}
- (NSString *)getColor
{
}
- (NSUInteger)getNumPuertas
{
}
- (void)imprimirDetalles
{
}
- (void)setColor: (NSString *)colorNuevo
{
}
- (void)setNumPuertas: (NSUInteger)nuevoNumeroDePuertas
{
}
@end

Fijáos en que he cambiado el nombre de las variables de los argumentos de las dos últimas funciones. Las variables de los argumentos no tienen por qué tener el mismo nombre en la interfaz y en la implementación, pero tampoco pasa nada porque tengan el mismo nombre.

La función getColor y getNumPuertas tan sólo devuelven el valor de las variables correspondientes, así que añadiremos return VARIABLE; para que el método devuelva el valor de la variable. return no requiere asterisco si se devuelven objetos, se usa exactamente igual con objetos que con variables sencillas.

En la función imprimirDetalles utilizaremos la función NSLog para imprimir en la consola los valores de las variables. La función NSLog admite varios parámetros. El primero siempre es una cadena de texto (@””), pero esta cadena admite combinaciones de caracteres específicas que indican que se deben reemplazar por otro valor. Así un %d se reemplazará por un número entero, un %f por un número decimal y un %@ por otra cadena de texto (se puede usar tranquilamente un objeto también, lo veremos más adelante). Si usamos estas combinaciones, tras la cadena de caracteres, y separadas por comas (“,”) debemos introducir las variables o los objetos que reemplazarán las combinaciones. A continuación tenéis las tres funciones que hemos explicado:

- (NSString *)getColor
{
 return color;
}
- (NSUInteger)getNumPuertas
{
 return numPuertas;
}
- (void)imprimirDetalles
{
 NSLog(@"Este coche es de color %@ y tiene %d puertas", [self getColor], [self getNumPuertas]);
}

Fijáos en la última función, concretamente en [self getColor] y [self getNumPuertas]. Esta es la sintaxis para enviar mensajes a los objetos. Enviar un mensaje a un objeto es, básicamente, pedirle a un objeto que ejecute el método con ese nombre. Así, cuando escribimos [self funcion] le pedimos al objeto self que ejecute el método funcion. El objeto self es un objeto especial y hace referencia al objeto actual, de modo que lo que hacemos en esta última función es pedirle al objeto de clase Coche que ejecuta el método imprimirDetalles que ejecute el método getColor y getNumPuertas.

Las funciones setColor y setNumPuertas son bastante sencillas. Simplemente asignaremos (mediante “=”) el valor que se pasa como parámetro (o argumento) a la variable correspondiente. Aquí los tenéis completos:

- (void)setColor: (NSString *)colorNuevo
{
 color = colorNuevo;
}
- (void)setNumPuertas: (NSUInteger)nuevoNumeroDePuertas
{
 numPuertas = nuevoNumeroDePuertas;
}

Y este es el aspecto final de la implementación de nuestra clase Coche:

#import "Coche.h"
@implementation Coche
- (void)dealloc
{
 [color release];
 [super dealloc];
}
- (NSString *)getColor
{
 return color;
}
- (NSUInteger)getNumPuertas
{
 return numPuertas;
}
- (void)imprimirDetalles
{
 NSLog(@"Este coche es de color %@ y tiene %d puertas", [self getColor], [self getNumPuertas]);
}
- (void)setColor: (NSString *)colorNuevo
{
 color = colorNuevo;
}
- (void)setNumPuertas: (NSUInteger)nuevoNumeroDePuertas
{
 numPuertas = nuevoNumeroDePuertas;
}
@end

Ahora modificaremos nuestra aplicación para que cree un objeto de clase coche, establezca su color en azul y su número de puertas en 5 y que a continuación imprima en la consola la información sobre el mismo.

Vamos al archivo NOMBREPROYECTO.m, que debería tener el siguiente código:

#import <Foundation/Foundation.h>
int main (int argc, const char * argv[]) {
 NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 // insert code here...
 NSLog(@"Hello, World!");
 [pool drain];
 return 0;
}

E importamos el archivo Coche.h justo después de importarse Foundation:

#import "Coche.h"

A continuación añadimos, entre NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; y [pool drain];:

Coche *miCoche = [[Coche alloc] init];
 [miCoche setColor:@"Azul"];
 [miCoche setNumPuertas:5];
 [miCoche imprimirDetalles];
 [miCoche release];

Vayamos línea a línea:

Coche *miCoche = [[Coche alloc] init];

En esta línea creamos el objeto miCoche, de clase Coche. Fijáos como se le envía a  la clase Coche el mensaje alloc y al objeto resultante de ese mensaje se le envía el mensaje init. Los mensajes se pueden encadenar tanto como se quiera, aunque esto hace más complicado de leer el código, así que no es muy recomendable.

[miCoche setColor:@"Azul"];
[miCoche setNumPuertas:5];

En estas dos líneas se envía el método setColor: y setNumPuertas: al objeto miCoche, con el parámetro @”Azul” como nuevo color y 5 como número de puertas.

[miCoche imprimirDetalles];

En esta línea se le manda al objeto el mensaje imprimirDetalles, lo que hará que muestre por terminal los valores de las variables.

 [miCoche release];

Por último esta línea elimina el objeto. En realidad es algo más complejo, y lo explicaré más adelante en otro tutorial. De momento con saber que se elimina el objeto nos vale.

El código resultante de MIPROYECTO.m será:

#import <Foundation/Foundation.h>
#import "Coche.h"
int main (int argc, const char * argv[]) {
 NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 // insert code here...
 NSLog(@"Hello, World!");
 Coche *miCoche = [[Coche alloc] init];
 [miCoche setColor:@"Azul"];
 [miCoche setNumPuertas:5];
 [miCoche imprimirDetalles];
 [miCoche release];
 [pool drain];
 return 0;
}

Y si compilamos y ejecutamos la aplicación veremos el siguiente resultado:

Resultado de la segunda aplicación

Esto no está mal, pero, ¿para qué llamar a dos métodos para establecer las variables y otro más para iniciar el objeto (init)? ¿No podríamos juntar esos tres métodos en uno? Sí, podemos. Vayamos al archivo Coche.h y añadamos el siguiente método:

- (Coche *)initWithColor: (NSString *)nuevoColor andNumPuertas: (NSUInteger)nuevoNumPuertas;

Quedando así la interfaz:

#import <Cocoa/Cocoa.h>
@interface Coche : NSObject {
 NSString    *color;
 NSUInteger    numPuertas;
}
- (Coche *)initWithColor: (NSString *)nuevoColor andNumPuertas: (NSUInteger)nuevoNumPuertas;
- (NSString *)getColor;
- (NSUInteger)getNumPuertas;
- (void)imprimirDetalles;
- (void)setColor: (NSString *)nuevoColor;
- (void)setNumPuertas: (NSUInteger)nuevoNumPuertas;
@end

En la implementación añadiremos lo siguiente:

- (Coche *)initWithColor: (NSString *)nuevoColor andNumPuertas: (NSUInteger)nuevoNumPuertas
{
 if (self = [super init])
 {
 [self setColor:nuevoColor];
 [self setNumPuertas:nuevoNumPuertas];
 }
 return self;
}

Analicemos este código. La primera línea de la función, if (self = [super init]) sirve para comprobar que el objeto se ha creado correctamente. Es posible (aunque raro) que por algún motivo el objeto no pueda crearse correctamente (por ejemplo, por falta de memoria), así que en caso de que no se cree correctamente, no estableceremos el valor de ninguna variable (pues de otra manera haríamos fallar la aplicación). Dentro de la condición se envía los mensajes que ya conocemos al objeto y finalmente se devuelve el objeto self. Como podéis ver, esta función devuelve un objeto de clase Coche.

El código final de nuestra implementación será:

#import "Coche.h"
@implementation Coche
- (Coche *)initWithColor: (NSString *)nuevoColor andNumPuertas: (NSUInteger)nuevoNumPuertas
{
 if (self = [super init])
 {
 [self setColor:nuevoColor];
 [self setNumPuertas:nuevoNumPuertas];
 }
 return self;
}
- (void)dealloc
{
 [color release];
 [super dealloc];
}
- (NSString *)getColor
{
 return color;
}
- (NSUInteger)getNumPuertas
{
 return numPuertas;
}
- (void)imprimirDetalles
{
 NSLog(@"Este coche es de color %@ y tiene %d puertas", [self getColor], [self getNumPuertas]);
}
- (void)setColor: (NSString *)colorNuevo
{
 color = colorNuevo;
}
- (void)setNumPuertas: (NSUInteger)nuevoNumeroDePuertas
{
 numPuertas = nuevoNumeroDePuertas;
}
@end

¿Cómo aplicamos estos cambios a nuestra aplicación? Vayamos al archivo NOMBREPROYECTO.m y reemplacemos el siguiente código:

Coche *miCoche = [[Coche alloc] init];
 [miCoche setColor:@"Azul"];
 [miCoche setNumPuertas:5];

Por este otro:

Coche *miCoche = [[Coche alloc] initWithColor:@"Azul" andNumPuertas:5];

Como veis, hemos convertido tres líneas de código en sólo una, y el resultado es idéntico.

Esto tan sólo es una breve introducción al paradigma de la programación orientada a objetos. Espero que os haya aclarado un poco los conceptos. En los próximos tutoriales iremos viendo más características de la POO en Objective-C.

Introducción a Objective-C: Nuestra primera aplicación

Beware: This post was published 6 years ago and its content may be outdated.

¿Qué es Objective-C? ¿Qué es Cocoa? ¿Qué es la Programacion Orientada a Objetos (POO)? ¿Y la arquitectura de Modelo Vista Controlador (MVC)? Dar los primeros pasos en la programación para Mac OS X, iPhone y iPad puede ser algo complicado si no sabes dónde buscar la información (y aún más difícil si no sabes inglés, imprescindible en el mundo de la informática). Hace año y medio, cuando yo comencé a aprender a programar para el iPhone (no tengáis prisa, sigo haciéndolo y me queda para mucho rato), el primer problema que tuve fue encontrar fuentes de información para dar los primeros pasos, así que he decido escribir esta serie de tutoriales para facilitar la tarea a aquellos que, como yo, quieran aprender a programar para el iPhone (extensible a Mac OS X y iPad). Tampoco esperéis ser unos maestros de Objective-C después de haber leído esta serie de tutoriales (que iré publicando cuando vaya teniendo tiempo para redactarlos), pues mis conocimientos son fruto del autodidactismo y seguramente no utilice los términos adecuados ni profundice del todo en los conceptos que trate. Sin embargo espero que os sirva para dar el primer paso y poder continuar después con textos mejor redactados, más exactos y más profundos. Read more →

Hasta luego y gracias por el pescado

Beware: This post was published 7 years ago and its content may be outdated.

Tal día como hoy, hace dos años, decidí transformar lo que entonces era un proyecto de portal de videojuegos en un blog sobre informática, y tras estos dos años escribiendo prácticamente a diario me ha quedado claro que no era tan mala idea, y que era la mejor forma de continuar con Sumolari.com. Estas últimas semanas he vuelto a pensar sobre el futuro de Sumolari.com y me he dado cuenta de que no puedo mantener el ritmo que he llevado durante estos dos últimos años (94 artículos cada 100 días son muchos artículos).

El futuro del blog

Si en un mes como agosto, que tenía todo el día libre, tan sólo he llegado a publicar 20 artículos, no quiero ni imaginarme los pocos que habría publicado en un mes como junio, que además de tener los exámenes finales, este año para mí tendría un nuevo reto más: la Prueba de Acceso a la Universidad. Sin lugar a dudas, habría publicado muy pocos artículos y de una calidad muy pobre (sí, más aún que los que publico ahora mismo). Seguramente el principal motivo por el que cada vez escribo más artículos es que el tiempo libre del que dispongo (que cada vez es menos) tengo que compartirlo con cada proyecto en el que trabajo, lanzando nuevas versiones de mis proyectos según va siendo necesario, y lanzando proyectos nuevos de vez en cuando.

Así que he decidido darle un nuevo enfoque a Sumolari.com. Si en un principio el blog fue el centro de la página y mis proyectos eran algo accesorio, ahora será al contrario: mis proyectos pasarán a ser el centro de Sumolari.com y el blog estará en segundo plano. Dejaré de publicar noticias en el blog, y tan sólo publicaré tutoriales y reseñas de cosas que me parezcan interesantes. Es decir, a partir de ahora cabe esperar muchos menos artículos al mes, pero más útiles y menos repetitivos.

De todos modos, el blog tampoco ha sido un gran éxito dentro de lo que cabe. Mi principal plugin para WordPress, WP Carousel consiguió superar ayer las 16.000 descargas, superando a razón de casi 16:1 a los comentarios del blog. Creo que es mucho mejor que dedique el tiempo que tengo a proyectos como WP Carousel y publique de vez en cuando tutoriales útiles. Curiosamente, los artículos más comentados no son ni de lejos los que he publicando más recientemente, como por ejemplo el tutorial de cómo crear un carrusel con jQuery o  el truco para evitar conflictos entre jQuery y Mootools o la explicación de cómo crear varias sidebars en WordPress o la forma de validar formularios con jQuery, ninguno de ellos publicado en 2010.

La calidad del blog, definitivamente, ha ido decayendo durante estos 2 años, y me parece que en esta ocasión es mejor calidad que cantidad, de modo que, en resumen, el blog pasará a segundo plano, los proyectos serán el centro de Sumolari.com y publicaré menos artículos pero de más calidad y centrados en la temática que quise tratar originalmente en el blog: tutoriales de informática.

Presentando… Chuck Facts

Y hasta aquí llega la parte “triste” del artículo, ahora toca presentar el proyecto en el que he trabajo durante este verano. Creo que lo he dicho en varias ocasiones, pero desde junio del año pasado, cuando me pasé a Mac, he estado intentando aprender a programar para Mac y para el iPhone / iPod Touch (y de paso iPad, aunque cuando comencé aún no existía). Ese verano me aventuré a comprar un libro de programación para el iPhone para torpes. Lamentablemente acabó el verano, septiembre y parte de octubre antes de que llegase a casa, así que no pude aprender nada.

A lo largo de este año he estado recopilando libros para aprender programación en Objective-C y orientada al iPhone / iPod Touch, y finalmente, tras dos meses veraniegos de dedicar todo el día a leer y estudiar diversos libros de programación, he aprendido lo básico para crear una aplicación para el iPhone (aún me quedan muchos libros muy interesantes por leer, pero me temo que se quedarán para el verano que viene). Tras rescatar la lista de proyectos que me gustaría llevar a cabo para el iPhone / iPod Touch y revisar los que tenía conocimientos suficientes para llevar a cabo, decidí comenzar a desarrollar mi primera aplicación y la primera de la App Store sobre Hechos de Chuck Norris.

Ya está terminada y desde ayer enviada para que la revisen y la aprueben (espero) o no en la App Store. No sé si la aprobarán finalmente o no, así que voy a explicar en qué consiste la aplicación en este artículo, por si finalmente resulta rechazada. Se trata de una aplicación que permite ver hechos de Chuck Norris almacenados en el servidor de Sumolari.com. Los hechos se encuentran organizados por categorías y pueden localizarse tanto hechos individuales como categorías desde el buscador de la aplicación (hay un buscador en cada lista de hechos de Chuck Norris). La cosa no acaba ahí ya que la gracia reside en que todos los usuarios pueden enviar sus propios hechos de Chuck Norris, que aparecerán en la aplicación tras mi aprobación (para evitar hechos duplicados u ofensivos).

El contenido de la aplicación se obtiene de internet, pero está siempre disponible offline. Además también dispone de un mapa donde ver desde qué lugares se han enviado más contribuciones (para mantener la privacidad de los usuarios, tan sólo se muestra el recuento de hechos de Chuck Norris enviados desde el lugar, además las coordenadas se redondean para más privacidad, y es imposible saber desde la aplicación el lugar desde el que se ha enviado un hecho de Chuck Norris). Aunque claro, siempre se puede contribuir sin compartir tu posición simplemente seleccionando la opción de “no permitir” que aparece la primera vez que se contribuye.

No es una aplicación del nivel de otras de la App Store, pero es realmente divertida, y viene genial para distraerse en algunos momentos: con tan sólo agitar el dispositivo la aplicación nos mostrará un hecho escogido al azar, de modo que no hace falta revisar listas ni seleccionar nada, tan sólo agitar y leer. Por supuesto, todo esto de forma totalmente gratuita (y preparada para definición estándar y Retina Display), tan sólo hay unos anuncios (iAd) en la parte superior de la pantalla pero no molestan nada y en general son distraídos.

También me gustaría desarrollar una versión para el iPad, pero por falta de tiempo y por la inseguridad sobre el proceso de aprobación de Apple lo dejaré para más adelante. La aplicación también tiene lista una pequeña página mostrando sus virtudes, pero hasta que no la aprueben no haré la página pública. Podéis ver las capturas de la aplicación que he enviado a Apple a continuación:

Y esto es todo, bastante para un sólo artículo. Ha sido un placer escribir aquí casi a diario durante estos dos últimos años, y estoy muy contento de los más de 1100 regalos que habéis hecho algunos de los lectores del blog durante este tiempo. Espero poder publicar algún tutorial interesante de aquí a final de año, pero como de costumbre, no voy a prometer nada. En cuanto a los usuarios de mis proyectos, estoy realmente sorprendido de la cantidad de gente que ha llegado a usarlos, he visto algunos de mis themes en los lugares más insospechados. Esto no es un adiós, es un “Hsata luego y gracias por el pescado”.