En primer lugar vamos a tratar de explicar cual es la principal diferente entre la forma de trabajar antigua y la forma de trabajar nueva.

Hasta ahora, si teníamos una aplicación que tenía un total de 3 pantallas, en lo referente a la capa de vista, debíamos tener 3 archivos de Interface Builder, donde se elaboraba visualmente la estructura y elementos de cada pantalla. Para poder establecer navegación entre una vista y otra, la única manera era mediante código, con funciones como la que sigue:

[self.navigationController pushViewController:myViewController animated:YES];

Al encontrarse la lógica de navegación en el código, no había una forma rápida de entender la misma, sino que era necesario ir viendo cada ViewController y averiguar qué botón llama a qué pantalla, etc.

Ahora, con Storyboarding, esos múltiples ficheros de Interface Builder, se sustituyen por un único fichero .storyboard. Este fichero se edita desde el propio Xcode, al haberse “eliminado” Interface Builder con la salida de Xcode 4.

En este storyboard no solo podemos ver gráficamente cada una de las vistas de nuestra aplicación, sino que podemos conocer cual es la navegación que se establece entre cada una de ellas.

Esto quizás al principio pueda resultar un poco extraño, pero os puedo asegurar que con el ejemplo que vamos a ver al final de este artículo vais a poder comprobar la potencia de esta nueva forma de trabajar.

Escena: una escena es lo que podríamos denominar una vista de nuestra aplicación, es decir, cada pantalla.

Segue (pronunciado Seg-way): es la navegación/transición entre una escena y otra.

En Xcode sin una sola letra de código vamos a poder establecer cual es la navegación para cada uno de los elementos de la interfaz, e incluso personalizar la forma en que se produce la transición entre los mismos (con una serie de efectos que vienen predefinidos y pudiendo establecer los nuestros personalizados).

Ejemplo práctico

Vamos a hacer un ejemplo de aplicación, donde tengamos un TabBarController inicial con dos pestañas. En la primera de ellas tendremos un sencillo botón que abre una ventana modal en la cual hay un botón que nos permite volver a cerrarla enviándole cierta información. En la segunda pestaña tendremos un TableViewController con su correspondiente pantalla de detalle.

En primer lugar abriremos Xcode y crearemos un nuevo proyecto de tipo “Single View Application”.

A continuación cumplimentaremos la información del proyecto, asegurándonos de chequear en la parte inferior las opciones ARC y Storyboarding.

Una vez se haya creado el proyecto, veremos en nuestra vista “Project Navigator” que la plantilla ha creado automáticamente un fichero con el nombre “MainStoryboard.storyboard”. Pulsando sobre el fichero veremos que nos abre la funcionalidad de Storyboarding, que ahora mismo únicamente cuenta con un ViewController.

Dado que necesitamos tener en primer lugar un TabBarController en nuestra aplicación, podemos añadirlo manualmente desde el Panel de Objetos, pero existe una forma aun más comoda de hacerlo.

Si teniendo seleccionado nuestro ViewController vamos al menú “Editor / Embed in / Tab Bar Controller” será Xcode quien haga todos los pasos por nosotros.

Ahora ya tenemos el TabBarController pero aún nos falta una segunda pestaña que como decíamos en el enunciado deberá ser de tipo TableViewController con un NavigationController que nos permita posteriormente incluir una pantalla de detalle.

Desde el panel de objetos vamos a añadir un nuevo TableViewController.

Una vez añadido, lo seleccionaremos, y pulsaremos el menú “Editor / Embed in /  Navigation Controller”, y obtendremos un resultado como el que sigue.

Como se puede observar, el Navigation Controller esta completamente desvinculado del Tab Bar Controller. Para incluirlo como una nueva pestaña deberemos hacer Ctrl clic en el Tab Bar Controller y arrastrar y soltar en el Navigation Controller como cuando creamos un Outlet.

Al soltar nos saldrá una ventaja emergente con las siguientes opciones:

Deberemos seleccionar la opción “Relationship – ViewControllers”. Una vez hecho esto veremos que se ha incluido una nueva conexión entre ambos, y que en el Tab Bar Controller figuran ya dos pestañas.

Dado que en nuestro ejemplo no vamos a tener un DataSource para el TableView, vamos a hacer uso de una nueva funcionalidad de iOS 5 y Xcode 4, que son las Static Cells.

En un próximo artículo hablaremos en mas detalle de esta funcionalidad y de la de prototipado de Celdas desde Storyboarding.

Ahora solo haremos lo mínimo necesario para completar nuestra navegación.

Seleccionando el Table View, nos iremos al Attributes Inspector y seleccionaremos la opción Static Cells.

Con ello veremos que Xcode nos crea varias celdas en nuestro Table View. Eliminaremos todas, dejando solo la primera.

Teniendo seleccionada la celda que nos ha quedado en el table View, nos vamos de nuevo al Attributes Inspector y seleccionamos el tipo Basic.

Ahora vamos a añadir por último un ViewController destinado a la pantalla de detalle del Table View Controller.

Desde el panel de objetos añadimos un View Controller y al igual que hicimos hace un momento, arrastramos desde la celda del TableViewController hasta el ViewController creado. Esta vez seleccionaremos la opción Push que nos permitirá dar uso al NavigationController en el que nos encontramos en ese punto.

Ahora mismo ya tenemos todas las escenas que necesita nuestra aplicación, y como habéis podido observar, hemos establecido su navegación sin una sola letra de código.

Si ejecutamos en este punto la aplicación veremos que ya tenemos las pestañas, tenemos el TableView e incluso pulsando sobre la celda que hemos creado como estática, accedemos a la pantalla de detalle.

Como habréis podido observar, la potencia de Storyboarding es algo excepcional.

Por último vamos a ver como se implementaría el último de nuestros requisitos para este ejemplo: hacer que en la primera pestaña haya un botón que abra una ventana modal, en la cual haya otro botón que cierra dicha ventana devolviendo ciertos datos.

Dado que para hacer esta operativa si que vamos a necesitar algo de código a implementar, vamos a crearnos una clase ViewController para nuestra primera pestaña.

Para ello, añadimos una nueva clase a la que llamaremos PrimerViewController que deberá extender a UIViewController.

Una vez creada la clase, seleccionamos dentro del Storyboard el ViewController correspondiente a la primera pestaña (el que no es un Navigation Controller) y en la pestaña de Identity Inspector seleccionamos como Class PrimerViewController.

A continuación añadimos a nuestro Storyboard un nuevo ViewController desde el panel de objetos. Seguidamente creamos una nueva clase en nuestro proyecto a la que llamaremos SegundoViewController, y tal y como hicimos en la pestaña Identity Inspector de este nuevo View Controller seleccionamos como Class SegundoViewController.

Ahora añadiremos un UILabel y un UIButton al Primer View Controller y hacemos Ctrl clic hasta el SegundoViewController donde soltamos y seleccionamos Modal.

En SegundoViewController creamos un UITextField y un UIButton.

En este punto quizás podríais pensar que para poder ir al PrimerViewController al pulsar el botón Seleccionar bastaría con crear un nuevo Segue. La verdad es que no es posible hacer eso, dado que lo que ocurriría sería que nos crearía una nueva instancia de PrimerViewController, y podríamos hacer que el usuario entrara en un bucle en el cual se crean ViewControllers pero nunca se destruyen.

¿Y entonces como hago para enviar información desde la segunda ventana a la primera y cerrar la ventana modal?

Pues bien, vamos a necesitar crear un protocolo en el SegundoViewController, y nuestro PrimerViewController hará de Delegate e implementará dicho protocolo.

Para ello el código quedaría de la siguiente manera:

SegundoViewController.h

#import <UIKit/UIKit.h>

@class SegundoViewController;

@protocol SegundoViewControllerDelegate <NSObject>
- (void)devolverValor:(NSString *)texto;
@end

@interface SegundoViewController : UIViewController

@property (strong, nonatomic) IBOutlet UITextField *cajaTexto;

@property (nonatomic, weak) id <SegundoViewControllerDelegate> delegate;

- (IBAction)volver:(id)sender;

@end

SegundoViewController.m

#import "SegundoViewController.h"

@implementation SegundoViewController

@synthesize cajaTexto;
@synthesize delegate;

- (IBAction)volver:(id)sender {
    [delegate devolverValor:self.cajaTexto.text];
}

- (void)viewDidUnload {
    [self setCajaTexto:nil];
    [super viewDidUnload];
}
@end

PrimerViewController.h

#import <UIKit/UIKit.h>
#import "SegundoViewController.h"

@interface PrimerViewController : UIViewController <SegundoViewControllerDelegate> {
}
@property (strong, nonatomic) IBOutlet UILabel *etiqueta;

@end

PrimerViewController.m

#import "PrimerViewController.h"

@implementation PrimerViewController
@synthesize etiqueta;

- (void)devolverValor:(NSString *)texto {
    self.etiqueta.text = texto;
    [self dismissModalViewControllerAnimated:YES];
}

- (void)viewDidUnload {
    [self setEtiqueta:nil];
    [super viewDidUnload];
}
@end

Ahora bien, ya tenemos todo preparado, pero nos falta un pequeño detalle: indicar a SegundoViewController que su delegate es PrimerViewController.

Y aquí es donde vamos a ver una pequeña pega, o elemento a mejorar en Storyboarding, y es que para poder definir esta relación, debemos obligatoriamente hacer uso de código.

Concretamente vamos tener que asignarnos como delegate en el momento en que se construye el SegundoViewController antes de mostrarse.

Para ello, existe un método denominado prepareForSegue, que nos permite justamente eso. Preparar el nuevo ViewController antes de mostrarlo, ya sea para incializar valores, cargar en el información procedente del ViewController en que nos encontramos, o como es el caso, para definirnos como delegate del mismo.

Para ello incluiremos en nuestro PrimerViewController.m el siguiente método:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {

SegundoViewController * segundoViewController = segue.destinationViewController;

segundoViewController.delegate = self;

}

Como se puede ver el método cuenta con un parámetro segue de tipo UIStoryboardSegue de donde podemos entre otras cosas obtener el ViewController al que vamos a ir al ejecutar esta navegación.

En algunos casos, en los que un ViewController tenga navegación a través de botones por ejemplo a varios lugares, preguntar cual es el Segue concreto que se esta ejecutando.

Para ello deberemos identificarlos previamente en el Attributes Inspector.

Esto lo haremos situándonos sobre el icono correspondiente al Segue que queremos identificar.

Una vez hecho esto, dentro de nuestro método prepareForSegue podremos preguntar por el identificador del Segue que se esta ejecutando, y poder así establecer diferentes salidas para cada uno de ellos:

if ([segue.identifier isEqualToString:@"PantallaDetalle"]){

}

Pues esto ha sido todo, y espero que este artículo os sirva para quitaros el miedo con esta potente herramienta que es el Storyboarding.

Una vez se prueba a trabajar así, ya no hay vuelta atrás.

Espero vuestros comentarios.

Quizás uno de los cambios más abrumadores de iOS ha sido la inclusión de ARC (Automatic Reference Counting), lo cual facilita al desarrollador la gestión de memoria, uno de los puntos mas conflictivos del desarrollo iOS.

Por entender la diferencia, hasta iOS 4, el programador debía hacerse cargo de hacer el RELEASE de las variables que ya no fuera a utilizar, y de los RETAIN de aquellas que quiera que se conserven. Concretamente cuando un objeto se esta utilizando desde varios sitios, se produce lo que se llama Reference Counting, que no es mas que un contador de los sitios donde se esta utilizando dicho objeto. De este modo, cuando las diferentes partes de nuestra aplicación van liberando este objeto mediante su método RELEASE, el contador va disminuyendo, y al llegar a cero, se destruye automáticamente liberando ese espacio en memoria.

¿Y que ocurría si por cualquier motivo no estuviéramos realizando correctamente los RELEASE de dicho objeto? Pues bien, que al no llegar dicho contador a cero, la memorial consumida por el objeto nunca se liberaba.

Quizás esta problemática de la memoria, en una aplicación pequeña y sin gran cargas de proceso, pueda parece una finura innecesaria. Sin embargo, en aplicaciones donde la carga de memoria sea superior, es básico realizar una buena gestión de la memoria.

Ahora con iOS 5, llega ARC, que hace todo este trabajo por nosotros de forma automática, garantizando así las buenas prácticas en lo que a memoria se refiere. ARC es una funcionalidad proporcionada por LLVM 3.0, que es el nuevo compilador incorporado por Apple como predeterminado en Xcode 4.2.

ARC realizará por nosotros todas las operativas de RETAIN y RELEASE sin que tengamos que preocuparnos por ello.

La regla es realmente sencilla, ya no tenemos que hacer RETAIN de los objetos, sino que simplemente al establecer un puntero a un objeto, este implicara que el objeto se conserve.  En el momento que liberemos dicho puntero, el objeto se liberará automáticamente si no existen otros punteros al mismo.

Un concepto que deberemos tener siempre en mente es el tipo de relación que queremos establecer entre el puntero y los objetos a los que apunta. Ésta podrá ser de dos tipos dependiendo de su naturaleza:

• Strong: un puntero de este tipo, implica que nuestra variable será la dueña del objeto al que apunta el puntero, y por tanto no se liberará el mismo mientras el puntero sigua activo.

• Weak: es un puntero que no implica que nuestra variable sea dueña del objeto apuntado. De este modo, si por cualquier motivo el objeto apuntado fuera liberado, nuestro puntero pasaría ser automáticamente NIL (esto evita que se produzcan errores por apuntar a direcciones de memoria inexistentes).

Para establecer que un objeto tiene un puntero de estos tipos, se puede utilizar el prefijo __weak y __strong al declarar los mismos, de la siguiente manera:

__strong NSString *nombre = self.cajaTexto.text;

Dado que las variables por defecto son de tipo STRONG, este código realmente no tiene mucho sentido.

Tambien podemos definir el tipo de relación en la creación de properties dentro de nuestras clases:

@property (nonatomic, strong) NSString *nombre;

El hecho de que al eliminar un objeto que tuviera un puntero de tipo WEAK apuntándole este puntero pase automáticamente a ser NIL es un gran ventaja, que permite implementar códigos que antes eran realmente imposibles al producir errores de ejecución.

ARC tiene también algunas limitaciones que es necesario conocer:

• Sólo es posible utilizar ARC en Objective-C. En caso de utilizar Core Foundation  o sentencias como MALLOC o FREE, deberemos ser nosotros los que nos encarguemos de la gestión de memoria.

• Aunque ARC hace mucho del trabajo de gestión de memoria por nosotros, no debemos pensar que podemos olvidarnos por completo de dicha gestión. Si tenemos punteros que ya no estamos utilizando, y olvidamos cambiar el valor de los mismos a NIL, éstos permanecerán en memoria ocasionando los mismos problemas de recursos que teníamos antes de ARC.

Ahora mismo la utilización de ARC es algo opcional que puede configurarse en la creación de un proyecto X-Code. Sin embargo, parece que esta forma de trabajar va a ser la predeterminada en el futuro y por tanto es bueno que nos vayamos acostumbrando a su uso.

Si tenemos un proyecto realizado sin ARC, y queremos migrarlos a esta nueva estrategia, Apple nos provee de un sencillo asistente que hace todos los cambios por nosotros mismos. Este asistente se encuentra en el menú “Edit / Refactor / Convert to Objective-C ARC”.

Dependerá del volumen e implementación de vuestro código que este proceso sea mas o menos sencillo. En aplicaciones sencillas no se requiere la intervención del usuario, pero en otros casos, os aseguro que será necesario modificar manualmente el código que pueda resultar problemático para la migración a ARC.

Espero que este artículo al menos os sirva de introducción a esta nueva metodología de trabajo que Apple ha introducido con ARC.

Desde la salida de la AppStore al mercado en el año 2008, se han ido incorporando al catalogo de licencias de desarrollados múltiples opciones que me gustaría comentar en este artículo.

En la actualidad, existen cuatro opciones de licencia de desarrollo Apple:

• Apple Developer: esta opción es completamente gratuita, y únicamente requiere registrarse como desarrollador desde la propia Web de Apple. Nos da a acceso a:
• Documentación técnica (versión final del SO y iOS)
• Herramientas de desarrollo (versiones finales)
• Solo podemos probar las aplicaciones en el Simulador de XCode.

• iOS University Program: esta opción es completamente gratuita, aunque solo aplica a determinadas universidades que estén incluidas dentro del programa. Obliga a que no haya ánimo de lucro, y que todo se destine a la formación de alumnos en las herramientas de Apple. Ofrece así mismo la opción de probar nuestras aplicaciones en nuestros dispositivos.

• iOS Developer Program: esta opción tiene un coste de 99 dólares al año, y nos ofrece adicionalmente las siguientes opciones:
• Documentación técnica (de versiones beta)
• Herramientas de desarrollo (de versiones beta)
• Descarga de firmwares beta para probar nuestras app.
• Permite instalar aplicaciones en nuestros dispositivos registrándolos previamente en la Web de Apple.
• Permite publicar en la AppStore nuestras aplicaciones y comercializarlas con unos beneficios del 70% sobre el precio de venta que establezcamos.

• iOS Developer Enterprise Program: esta opción tiene un coste de 299 dólares al año, y esta orientada al desarrollo de aplicaciones de tipo In-house (aplicaciones corporativas privadas). Nos ofrece las siguientes opciones:
• Permite publicar de forma privada a la empresa, aplicaciones que puedan ser instaladas en los dispositivos de los diferentes empleados.

Como veis, todo un abanico de posibilidades a las que acogernos.

Desde luego, una recomendación que os haría a todos aquellos que estéis ahora aterrizando en el mundo del desarrollo para iOS, es que no os enroléis en el iOS Developer Program hasta que tengáis realmente un proyecto de aplicación que vayáis a publicar en la AppStore.  Para aprender, basta con registraros en la Web de Apple y descargar XCode desde la Mac App Store.

Es cierto, que para probar determinadas funcionalidades, necesitaréis desplegar la aplicación en un dispositivo real, pero existen multitud de funcionalidades que podréis probar y trabajar que no tienen esta limitación.

Sin duda una de las ventajas que mas hacen a muchos dar el salto a la versión de pago, es la posibilidad de descargar documentación y herramientas para versiones que aún no se han publicado en el mercado.

De esta forma, como desarrolladores podemos incorporar las funcionalidades de iOS 6 (imaginemos) para que así, nuestra aplicación sea completamente compatible el día que se lance oficialmente dicho SO.

Otras personas aprovechan esta oportunidad para formarse en la nueva plataforma, e impartir cursos de formación de forma inmediata a la salida del producto final.

Espero que hayáis resuelto las dudas sobre las diferentes opciones que Apple ofrece al desarrollador.

En este artículo vamos a ver paso por paso como implementar comunicación entre varios dispositivos iOS mediante la tecnología Bluetooth.

Como en este caso, una imagen vale más que mil palabras, os adjunto un pequeño video donde se aprecia cual será el comportamiento de la aplicación que vamos a implementar:

Con la salida de GameKit, Apple incorpora una serie de clases que nos permiten establecer todo lo necesario para realizar comunicaciones peer to peer entre dos o mas dispositivos.

Esta comunicación tiene ciertas limitaciones que es necesario conocer:

• Dado que el Simulador de XCode no soporta Bluetooth, para poder probar nuestra aplicación, necesitaremos dos dispositivos iOS.
• Al tener que instalar la aplicación en nuestro dispositivo, también necesitaremos pertenecer al iOS Developer Program (es decir fotografiarse con 79€ al año).
• Requiere como mínimo iOS 3.0 (porque fue en esta versión del SO donde se incorporó GameKit).
• El número máximo de conexiones entre clientes y un servidor es de 16.
• El tamaño máximo de un paquete de datos enviado entre dos dispositivos es 87 kilobytes. En caso de necesitar enviar más información será necesario fragmentarla en paquetes de este tamaño o inferiores.

Bueno, después de todas las “pegas” para este ejemplo, vamos con la parte buena, y es que vamos a poder comprobar en estado puro la potencia que proporcionan algunos frameworks de los suministrados con iOS como es en este caso GameKit.framework.

Principalmente vamos a utilizar estas clases del framework:

• GKPeerPickerController: esta clase nos permite con un par de líneas de código y de forma automática presentar al usuario toda una serie de pantallas que facilitan la solicitud de activación del Bluetooth en caso de que el usuario no la tenga activada, seleccionar al dispositivo al que queremos conectarnos, y finalmente establecer la conexión con el mismo. Una carencia que he encontrado en la utilización de este Picker (evitando implementar nosotros mismos toda la lógica), es que lo textos que ofrece en pantalla están en inglés, y al menos yo, he sido incapaz de poder modificarlos para este ejemplo.

• GKSession: esta clase gestiona el hilo de comunicación que se establece entre ambos dispositivos, y es a través de dicha sesión a través de donde podremos transmitir información entre ambos dispositivos.

• GKPeerConnectionState: esta clase nos controla cual es el estado de la conexión con el dispositivo. De esta forma podremos ocultar o mostrar los botones correspondientes a las acciones de Conectar y Desconectar.

Vamos a analizar los diferentes componentes de nuestra pequeña aplicación:

BluetoothViewController.h

#import <UIKit/UIKit.h>
#import <GameKit/GameKit.h>
@interface BluetoothViewController : UIViewController {

GKSession *currentSession;

IBOutlet UITextField *txtMessage;

IBOutlet UIButton *connect;

IBOutlet UIButton *disconnect;

}

@property (nonatomic, retain) GKSession *currentSession;

@property (nonatomic, retain) UITextField *txtMessage;

@property (nonatomic, retain) UIButton *connect;

@property (nonatomic, retain) UIButton *disconnect;

-(IBAction) btnSend:(id) sender;

-(IBAction) btnConnect:(id) sender;

-(IBAction) btnDisconnect:(id) sender;

@end

Nuestro interfaz va a tener únicamente los siguientes elementos:

• txtMessage: que va a ser una caja de texto UITextView donde podremos indicar el texto que queremos transmitir al otro dispositivo.
• Connect: que va a ser el botón para establecer la conexión.
• Disconnect: que nos permitirá desconectar.
• Send: que nos va a permitir enviar el texto indicado a traves de la sesión abierta.

Como a estas alturas seguro que ya conocéis, el único elemento que no tiene definido un IBOutlet es el botón de Send. Esto es debido a que desde código vamos a necesitar ocultar los botones de Connect y Disconnect, sin embargo el botón Send únicamente lo utilizaremos para lanzar el método btnSend. Por este motivo no es necesario crear el IBOutlet para este elemento.

Ahora vamos a ver los métodos que deberemos implementar en nuestro fichero BluetoothViewController.m

BluetoothViewController.m

En primer lugar deberemos importar la librería GameKit y hacer los synthesize de los properties definidos anteriormente:

#import <GameKit/GameKit.h>
@implementation BluetoothViewController

@synthesize currentSession;

@synthesize txtMessage;

@synthesize connect;

@synthesize disconnect;

Para implementar la lógica del evento Connect, debemos incluir lo siguiente:

-(IBAction) btnConnect:(id) sender {

picker = [[GKPeerPickerController alloc] init];

picker.delegate = self;

picker.connectionTypesMask = GKPeerPickerConnectionTypeNearby;

[connect setHidden:YES];

[disconnect setHidden:NO];

[picker show];

}

Simplemente inicializamos la clase GKPeerPickerController, establecemos el tipo de conexión, y lanzamos la interfaz asociada a dicho elemento mediante su método show.

Al utilizar el Picker, y asignarnos a nosotros mismos (self) como delegate del Picker, deberemos implementar los siguientes dos métodos:

- (void)peerPickerController:(GKPeerPickerController *)picker

didConnectPeer:(NSString *)peerID

toSession:(GKSession *) session {

self.currentSession = session;

session.delegate = self;

[session setDataReceiveHandler:self withContext:nil];

picker.delegate = nil;

[picker dismiss];

}

- (void)peerPickerControllerDidCancel:(GKPeerPickerController *)picker

{

picker.delegate = nil;

[connect setHidden:NO];

[disconnect setHidden:YES];

}

También vamos a necesitar un método para poder desconectar y asociar al botón Disconnect:

-(IBAction) btnDisconnect:(id) sender {

[self.currentSession disconnectFromAllPeers];

currentSession = nil;

[connect setHidden:NO];

[disconnect setHidden:YES];

}

Al indicar en el método peerPickerController que somos delegate del objeto Session, estamos obligados a implementar los siguientes dos métodos:

- (void)session:(GKSession *)session

peer:(NSString *)peerID

didChangeState:(GKPeerConnectionState)state {

switch (state)

{

case GKPeerStateConnected:

NSLog(@"connected");

break;

case GKPeerStateDisconnected:

NSLog(@"disconnected");

currentSession = nil;

[connect setHidden:NO];

[disconnect setHidden:YES];

break;

}

}

- (void) mySendDataToPeers:(NSData *) data

{

if (currentSession)

[self.currentSession sendDataToAllPeers:data

withDataMode:GKSendDataReliable

error:nil];

}

Por último deberemos implementar la lógica asociada al botón Send, y que nos permitirá utilizar la sesión para comunicar el texto introducido al otro dispositivo. Así mismo, el método receiveData nos permite recoger los datos recibidos en el dispositivo.

-(IBAction) btnSend:(id) sender

{

//---convert an NSString object to NSData---

NSData* data;

NSString *str = [NSString stringWithString:txtMessage.text];

data = [str dataUsingEncoding: NSASCIIStringEncoding];

[self mySendDataToPeers:data];

}

- (void) receiveData:(NSData *)data

fromPeer:(NSString *)peer

inSession:(GKSession *)session

context:(void *)context {

//---convert the NSData to NSString---

NSString* str;

str = [[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding];

UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Data received"

message:str

delegate:self

cancelButtonTitle:@"OK"

otherButtonTitles:nil];

[alert show];

}

Quizás este ejemplo puede parecer muy laborioso, pero claramente se demuestra la gran potencia que ofrecen los frameworks que vienen incluidos en iOS y de los cuales podemos hacer uso en nuestras aplicaciones sin a penas esfuerzo.

Para los que queráis el código completo de la aplicación, podéis descargarlo desde aquí.

Desde la aparición de iOS 5 en el mercado, la integración con Twitter se ha simplificado considerablemente. Aún así, vamos a dedicar este artículo a describir las posibilidades de esta nueva funcionalidad.

Para el ejemplo, crearemos un proyecto sencillo, con un simple botón, y nos centraremos en conocer el código necesario para realizar la llamada al Compositor de Twitter de iOS 5.

En mi primer lugar, debemos incluir en nuestro proyecto un nuevo framework: Twitter.framework.

Para ello, recordar que deberemos pulsar en el nombre de nuestra aplicación en el explorador de la parte izquierda de la pantalla, y posteriormente seleccionar la pestaña “Build Phases”, “Link Binary With Libraries”.

Allí podemos pulsar el botón “+” y seleccionar “Twitter.framework”.

Una vez hecho esto bastará con incluir la clase “Twitter” en nuestro View Controller.

#import <Twitter/Twitter.h>
@implementation TwitterViewController

Ahora vamos a ver lo sencillo que es incluir una llamada a la API del Framework Twitter.

- (IBAction)enviarTweet:(id)sender {
	if ([TWTweetComposeViewController canSendTweet])
	{
		TWTweetComposeViewController *tweetSheet =
		[[TWTweetComposeViewController alloc] init];

		[tweetSheet setInitialText:@"Enviando
		un tweet desde migueldiazrubio.com! :·)"];

		[self presentModalViewController:tweetSheet animated:YES];
	}
else
	{
		UIAlertView *alertView = [[UIAlertView alloc]
			initWithTitle:@"Lo siento"
			message:@"No puede enviar un Tweet en estos momentos."
			delegate:self
			cancelButtonTitle:@"OK"
			otherButtonTitles:nil];

		[alertView show];
	}
}

Como podéis observar, hacemos una comprobación previa mediante el método “canSendTweet” para verificar que el usuario cumple las siguientes condiciones:

• Dispone de Internet en estos momentos
• Dispone de una cuenta Tweet configurada correctamente en Ajustes/Twitter (esto en el simulador deberéis configurarlo para poder verificar el funcionamiento).

Adicionalmente es posible adjuntar imagenes, enlaces, etc en los Tweets. Para ello os recomiendo echar un vistazo a la propia Web de Apple sobre el Twitter Framework: Twitter Framework Reference.

Podéis descargar todo el código fuente de este artículo este enlace.

En este artículo vamos a ver como hacer uso de una API pública basada en el formato JSON para incorporar información a nuestra aplicación.

En este ejemplo, utilizaremos un servicio gratuito que nos provee la web punchfork.com en la siguiente url:

http://punchfork.com/api

JSON es un formato ligero para intercambiar información, similiar a XML pero con una considerable reducción en cuanto al tamaño de los archivos.

A continuación vamos a ver dos ejemplos en XML y JSON para que podáis apreciar la diferencia:

XML

<recetas>
<receta>
<nombre>Huevos fritos</nombre>
<puntuacion>5</puntuacion>
<ingredientes>Huevos, aceite, sal</ingredientes>
<fecha>20/12/2011</fecha>
</receta>
</recetas>

JSON

“recetas”: [
{
“nombre” : “Huevos fritos”
“puntuación”: 5
“ingredientes”: “Huevos, aceite, sal”
“fecha”: “20/12/2011”
}

Como se puede observar en este ejemplo, el tamaño en el archivo JSON es notablemente inferior. Quizás esto pueda ser un matiz sin importante para este ejemplo, pero imaginemos que tenemos que descargar de internet 20.000 recetas. ¿No será mejor descargar 800 kb que 2,5 mb?

Podéis consultar más información sobre JSON en:
http://es.wikipedia.org/wiki/JSON

Pues bien, como comentábamos antes, para este ejemplo deberemos inscribirnos en la web PunchFork para obtener gratuitamente una API KEY que podamos utilizar para este ejemplo. La API KEY ofrecida gratuitamente por esta empresa, esta limitada a un total de 500 peticiones al día. Si queréis utilizar esta API de forma comercial sin límite, podéis consultar los plantes de precios en la propia web.

El código que aquí os facilito es útil tanto si utilizáis PunchFork, como para cualquier otra fuente de datos JSON.

En nuestro ejemplo, para el parseo o lectura del fichero JSON utilizaremos una librería OpenSource que podéis descargar desde aqui.

Incluir la librería de JSON en nuestro proyecto

En primer lugar deberemos incluir en nuestro proyecto la librería de JSON, y que esta formada por dos directorios:

• JSON
• JSON-URL

Para ello, haremos clic con el botón secundario en nuestro proyecto y pulsaremos la opción “Add Files to XXXXXX”. Seleccionaremos los dos directorio indicados anteriormente y pulsaremos el botón “Add”. (Para facilitar la posterior distribución de vuestra App, recordar seleccionar la opción “Copy ítems to destination group si tenéis esta librería en un directorio distinto a vuestro proyecto).

Creación de una clase Receta

Para poder obtener y recorrer la información obtenida de JSON, necesitaremos una clase especifica que albergue la información de cada receta.

Crearemos una nueva clase mediante el botón secundario en nuestro proyecto “New file…”.

La nueva clase deberá ser un Objective-C class, y su clase padre deberá ser NSObject.

Para el ejemplo la llamaremos “Receta”.

Receta.h

#import 

@interface Receta : NSObject

@property (nonatomic, retain) NSString *nombre;
@property (nonatomic, retain) NSString *imagen;
@property (nonatomic) int contadorTwitter;

@end

Receta.m

#import "Receta.h"

@implementation Receta

@synthesize nombre, imagen, contadorTwitter;

@end

Creamos un método que recupere la lista de recetas del servicio

En primer lugar importaremos la librería en la cabecera de nuestro ViewController:

#import “myJson.h”

A continuación creamos el método:

// Método que obtiene la lista de recetas de la API de PunchFork
-(void) cargarRecetas {

    NSString *url =
@"http://api.punchfork.com/recipes?key=VUESTRA_API_KEY&q=";
    Json *jsonParser = [[Json alloc] init];

    [jsonParser startLoadingObjectWithUrl:url andDelegate:self];
}

// Método que es llamado una vez se ha descargado el fichero JSON (delegado)
-(void)dataRequestCompletedWithJsonObject:(id)jsonObject {

    NSDictionary *recetasDictionary = (NSDictionary *)jsonObject;
    NSArray *recetasArray = (NSArray *)[recetasDictionary objectForKey:@"recipes"];

    for (NSDictionary * dic in recetasArray) {
        Receta *receta = [[Receta alloc] init];
        [receta setNombre:[dic objectForKey:@"title"]];
        [receta setImagen:[dic objectForKey:@"thumb"]];
        [receta setContadorTwitter:[[dic objectForKey:@"twc"] intValue]];
        NSLog(receta.nombre);
    }
}

Como véis, la librería que estamos utilizando requiere que nuestro ViewController implemente un Delegate denominado “myJsonDelegate”.

De este modo, una vez se descargue correctamente el fichero JSON de internet, el segundo método será llamado automáticamente.

Recordar que para declarar nuestro ViewController como delegado de la clase, es necesario incluir el siguiente código en la definición de la cabecera de nuestra clase:

@interface XXXXXX : UIViewController

En el ejemplo mostrado anteriormente, se describe como obtener diferentes tipos de atributos de la receta como son NSString o Integer.

Si ejecutáis el Simulador con el código aquí indicado podréis comprobar que en la Consola de vuestro Xcode se pinta algo similar a esto:

Baked Potato Soup
Parmesan Roasted Potatoes
Bacon & Cheese Wrapped Tater Tots with Tabasco
…

El parseo del fichero JSON dependerá de la propia estructura del fichero y por tanto, la información aquí recogida solo aplica a nuestro ejemplo.

Espero que os haya resultado interesante el artículo y que le hayáis perdido el miedo por completo al parseo de ficheros JSON.

Podéis descargar todo el código fuente (sin el API KEY) de este artículo desde aquí.

Aunque se que se sale un poco de la temática habitual de los artículos que publico en este blog personal, he creído interesante transmitir cual es mi opinión sobre Lion, ahora que ya han pasado unos días desde su lanzamiento y se ha comentado bastante acerca del asunto.

Deciros que la salida de Lion me ha pillado de vacaciones y por tanto no pude instalarlo el mismo día de la salida, sino que tuve que esperar casi una semana a mi regreso a los madriles. Esto, aunque para un ansioso como yo es una faena, por otro lado me ha permitido documentarme un poco sobre el asunto de la instalación.

En primer lugar comentar, que unos días antes de irme de vacaciones, no aguanté más y tuve que instalar mediante actualización la Golden Master de Lion. Por tanto, la situación fue que cuando salió al mercado Lion, yo ya tenia la Golden Master (que es la misma versión que ha salido al público).

La verdad es que cuando actualice Snow Leopard a Lion GM, me pareció que el sistema funcionaba bastante bien, y que el rendimiento denotaba una ligera mejoría con respecto a su predecesor de las nieves. Nada mas lejos de la realidad, dado que funcionaba bien, pero podía funcionar aún mucho mejor.

Como mi intención era comprar legalmente el SO, y sobretodo asociar a la Mac App Store dicha compra para poder actualizar todo desde ahí correctamente, y además había leído que el rendimiento era mejor partiendo de un disco vacío, me decidí a instalar desde cero.

El resultado mejor imposible por los siguientes motivos:

1. Nos permite formatear el disco a bajo nivel, estableciendo ceros en todo el disco duro. Proceso que tarda un par de horas en mi caso (500 gb) pero que merece la pena.
2. La instalación en limpio garantiza residuos cero Snow Leopard, e incluso del anterior Leopard.
3. Nos permite plantearnos de nuevo que aplicaciones necesitamos y cuales no. En mi caso por ejemplo, tenía hasta 3 aplicaciones para descomprimir archivos, una para el RAR, otra para el ZIP, y The Unarchiver porque lo vi en la AppStore y me gustó. Ahora solo tengo 1.

Por estos tres motivos, os recomiendo que hagáis un backup de la librería de iPhoto, iTunes, carpetas personales, etc, e instaléis desde cero Lion, el resultado no os va a dejar indiferentes.

No es revolución, se llama evolución

Siendo realistas Mac OS Lion no es ninguna revolución, aunque muchos comentarios de las valoraciones de la Mac App Store indiquen lo contrario con comentarios que tachan de revolucionario y sorprendente el sistema.

Por otro lado, hay muchos comentarios de gente que opina que es lo mismo que Snow Leopard, que no cambia nada, que no merece la pena, y que debería ser gratis.

Lo que es gratis es opinar, por eso se tiene que leer uno estos comentarios tan bipolares.

Lion, no es una revolución, es una evolución, que afirma los pasos ya dados en Snow Leopard, y que además establece las reglas del juego de lo que parece ser Mac para los próximos años.

La evolución se apoya a mi modo de ver en tres pilares: aprovechamiento del espacio, desligamiento del sistema de archivos, integración de gestos.

En cuanto al aprovechamiento del espacio, Apple ha dado algunos pasos como son, la eliminación de scrolls de todo tipo en Lion, así como la inclusión de la funcionalidad de pantalla completa. Muchos dirán que esta última no es ninguna novedad, porque ya había antes aplicaciones a pantalla completa. Sin embargo, con la inclusión de Mission Control (que auna Spaces + Expose) y algunos nuevos gestos se ha cerrado el círculo, y ahora podemos navegar entre aplicaciones a pantalla completa de una forma fácil y usable.

Muy posiblemente esto ha venido motivado por la salida en los últimos años de notebooks de pulgadas inferiores a lo habitual como Macbook Air 11 pulgadas. Aún así, esta decisión permitirá el aprovechamiento para todas las pantallas de la gama de notebooks. Si os fijáis en las aplicaciones que utilizáis en el día a día, veréis que en muchos casos, entre un 15%  y un 20% de vuestra pantalla se sacrifica con el menú superior de Mac, el Dock y en muchos casos pequeños márgenes a ambos lados. Sin embargo, una vez que las aplicaciones se adecuen al funcionamiento en pantalla completa, el aprovechamiento de la pantalla será total.

En segundo lugar, tenemos un desligamiento del sistema de archivos. Ahora, será la propia aplicación la que se encargue de guardar nuestros documentos de forma automática, acabándose por fin el famoso, ¡uy se ha colgado! ¿hacía mucho que no grababas?. Además, con la funcionalidad de Versiones, ahora tendremos sin esfuerzo alguno, todas y cada una de las versiones de nuestro documento, para poder consultar, restaurar, o copiar información de cualquiera de ellas.

Si recordáis, en la keynote del WWDC 2011, se habló de la nueva posibilidad de desarrollar aplicaciones para Mac utilizando el denominado Sandbox. Esta metodología, ya aplicada como sabréis en iOS desde sus inicios, obliga a las aplicaciones a limitar su visibilidad sobre el HD a un determinado espacio reservado y del cual es propietario, denominado Sandbox. Este espacio es solo para esta aplicación, y en principio ninguna otra podrá acceder al contenido del mismo. Adicionalmente, se habilita la posibilidad de dar permisos a la aplicación sobre elementos ajenos a su Sandbox, previo reporte y revisión por parte de Apple antes de su publicación en el App Store.

Este sistema de sandboxing evidentemente es muy seguro, e impide que una aplicación pueda dañar otras aplicaciones o incluso el propio SO.

¿Os imagináis cuales podrían ser los siguientes pasos de Apple en este sentido?

1. La utilización de sandboxing primeramente es opcional en el Mac App Store.
2. Obligación a utilizar sandboxing si queremos publicar nuestra App en la Mac App Store.
3. Obligar a que todas las aplicaciones de Mac y sus actualizaciones pasen por la Mac App Store

¡Cha!¡Chan!

¡Ojo! Esto no tiene porque ser malo para Mac, aunque queda sujeto a la opinión de cada uno. En mi opinión es preferible renunciar a cierta libertad, siempre que eso garantice una seguridad y fiabilidad mayor. La eterna discusión… ¿abierto o cerrado?

Por último se produce una integración de los gestos multitáctiles ya disponibles en iOS. Esto nos permite aprovechar el trackpad, ya no como un ratón avanzado, sino como si de una pantalla táctil se tratase. Para ello Apple ha incluido cambios como por ejemplo la inversión del movimiento de los scrolls, que simulan al usuario que está empujando el contenido hacia arriba, no bajando el scroll hacia abajo.

En futuras revisiones de los Macbook, que nadie se extrañe si el trackpad asume algo más de protagonismo, ganando en dimensiones.

Para cerrar el artículo, os insto a que leáis entre líneas el lanzamiento de este nuevo SO, y que lejos de resistiros al cambio, lo adoptéis, y disfrutéis.

Hace tiempo, en una entrevista que hicieron a Bill Gates en el periódico El Mundo, le preguntaba cual era el futuro de la informática,  ¿ordenadores aún mas rápidos? Y el dijo: el futuro no esta en el sistema, sino en como el usuario interactúa con el mismo.

En los últimos años, tecnologías como la WII, el iphone, las cámaras con reconocimiento facial, la captura de movimiento, las pantallas táctiles y multitáctiles, sensores de proximidad, geoposicionamiento, acelerómetro, giroscopio y otros tantos inventos han permitido eso mismo, que el usuario interactúe de manera más eficaz con el sistema.

¿Os imagináis un trackpad con un botón izquierdo y otro botón derecho?¿Os imagináis tener que estar guardando un documento importante cada 5 minutos por si perdemos los cambios? ¿Os imagináis tener que utilizar una pequeña barrita a la derecha del navegador para poder desplazarnos por la página Web que estamos viendo?¿Os imagináis tener que utilizar solo un 80% de vuestras pantallas? ¿Os imagináis que por instalar una aplicación os deje de funcionar otra o incluso el SO?

¿A que ya no?

¡Apple tampoco!

Si tuviera que destacar que es lo que mas me ha costado entender hasta la fecha en lo que respecta al desarrollo para iOS, sin duda la respuesta sería: como implementar callbacks.

Seguro que alguna vez os habéis encontrado que tenéis un TableViewController que tiene un botón + para añadir elementos al mismo. Al pulsar ese botón se abre una ventana modal con el formulario de alta. En esa ventana hay un botón guardar que graba en Core Data el nuevo registro.

Pues bien, imaginemos que queremos que al guardar este nuevo registro, dicho objeto se envie de nuevo al TableViewController que ha abierto la ventana modal, para realizar cualquier tipo de operación con él.

Una posible forma es compartir a través del AppDelegate algunas properties que nos ayuden a intercambiar información entre los diferentes controladores. Esto no es muy recomendable porque en muchos casos impide reutilizar estos controladores en diferentes puntos de la aplicación o incluso en otras aplicaciones.

Lo forma más optima de acometerlo sería, que desde nuestra pantalla de alta, podamos comunicar a nuestra otra clase lo que necesitemos, incluso haciendole llegar objetos en dicha comunicación.

En este artículo vamos a aprender los dos métodos más comunes para implementar un CallBack:

• Mediante NSNotificationCenter
• Mediante Delegados y Protocolos personalizados

NSNotificationCenter

NSNotificationCenter es una clase de tipo Singleton que nos permite gestionar notificaciones que son enviadas por una clase, y recibidas por otra cualquiera que quiera suscribirse a la misma.

Vamos a ver en primer lugar un ejemplo simple donde se reciba un aviso pero no se intercambie información en el mismo.

Definición de la notificación (clase A)

// En este ejemplo nuestra notificación se denomina con la clave “metodoDelegado”.
// Además definimos qué método debera invocarse cuando se
// produzca dicha notificación mediante el atributo selector.

[[NSNotificationCenter defaultCenter] addObserver:self
       selector:@selector(metodoDelegado) name:@"metodoDelegado" object:nil];

Publicación de la notificación (clase B)

// En otro punto cualquier de nuestra aplicación, necesitamos invocar
// al método asociado a la notificación que hemos creado. Para ello
// invocamos dicha notificación mediante la utilización del nombre
// clave que hemos definido previamente.

[[NSNotificationCenter defaultCenter] postNotificationName:@"metodoDelegado"
       object:nil];

Como hemos comentado anteriormente es posible que necesitemos anexar información en dicha notificación. Para ello haremos lo siguiente:

Definición de la notificación (clase A)

[[NSNotificationCenter defaultCenter] addObserver:self
       selector:@selector(metodoDelegado:) name:@"metodoDelegado" object:nil];

Publicación de la notificación (clase B)

[[NSNotificationCenter defaultCenter] postNotificationName:@"metodoDelegado"
      object:@"mensajito"];

Método invocado

- (void) metodoDelegado : (NSNotification *) notification {

// El método recibe un objeto de tipo NSNotification cuya propiedad object
// alberga el objeto pasado como parametro. En este caso hacemos un casting
// del objeto a NSString.

NSString *cadena = (NSString *)[notification object];
NSLog(@"%@",cadena);
}

Delegados y Protocolos personalizados

La segunda opción, quizas mas compleja pero en muchos caso más aconsejable, sería definir nuestro controlador hijo mediante un protocolo y posteriormente hacer a la clase padre delegada del mismo. De este modo, los métodos del hijo definidos en el protocolo se ejecutarían en el padre, tal y como cuando implementamos métodos como cellForRowAtIndexPath en un TableView.

En primer lugar deberemos definir en nuestro ViewController hijo (en el ejemplo SegundoViewController) el protocolo de la siguente forma:

Cabecera

// Definimos el nombre del protocolo
@protocol SegundoViewControllerDelegate;

@interface SegundoViewController : UIViewController {
    // Definimos un atributo delegate del tipo que acabamos
    // de indicar en el protocolo
    id  delegate;
}

// Definimos un atributo delegate del tipo que acabamos de
// indicar en el protocolo
@property (nonatomic, retain) id  delegate;

- (IBAction)llamarAlDelegado:(id)sender;

@end

// En la parte inferior de la cabecera definimos aquellos
// métodos optional y required que nuestro delegado
// quiera o deba implementar.
@protocol SegundoViewControllerDelegate
@optional
- (void) metodoDelegado;
@end

Implementación

@implementation SegundoViewController

// Hacemos synthesize de la propiedad
@synthesize delegate;

- (IBAction)llamarAlDelegado:(id)sender {
    NSLog(@"Voy a llamar al método delegado");
    // En este punto llamamos al método “metodoDelegado” para que sea ejecutado
    // por parte del que se haya agregado como delegado de nuestro protocolo.
   [delegate metodoDelegado];
}

En segundo lugar, haremos que nuestra clase padre sea el delegado de este protocolo que hemos definido en nuestra clase hijo.

Cabecera

// Con esto indicamos que nuestra clase quiere hacer de delegado para el protocolo
@interface DelegadosViewController : UIViewController <SegundoViewControllerDelegate>

@end

Implementación

@implementation DelegadosViewController

// Este es el método que hemos definido dentro del
//  protocolo y que se ejecutará invocandose desde
// el hijo
- (void) metodoDelegado {
    NSLog(@"Estoy escribiendo desde el método delegado");
}

// IMPORTANTE: En mi caso como utilizo Storyboarding,
// en el método prepareForSegue accedemos al
// viewController destino y seteamos con el método
// setDelegate a nuestra clase padre como delegado.
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {

    SegundoViewController *segundoViewController =
              (SegundoViewController *)[segue destinationViewController];
    [segundoViewController setDelegate:self];

}

El pasado día 6 de Junio de 2011 Apple presentó, de la mano del ya asiduo Scott Forstall, la nueva major version de su sistema operativo para dispositivos móviles iOS.

Esta nueva versión, más que una revolución del sistema, supone un asentamiento del mismo sobre sus pilares originales, y la incorporación al core del sistema de ciertas funcionalidades que hasta ahora requerían aplicaciones de terceros.

Entre estas nuevas funcionalidades estan:

• Notifications: un lavado de cara muy necesario para la que era de unas funcionalidades más en boga y con menos estilo del SO. Inspirado en la competencia, pero con el toque personal de usabilidad de Apple.
  
• iMessage: el Blackberry Messenger de Apple para sus dispositivos iOS. Aunque pudiera parecer la desaparición de aplicaciones como WhatApp, eso no es así, dada la no multiplataforma de este sistema de mensajería (solo permite comunicación entre dispositivos iOS).
• Newsstand: un kiosko en forma de aplicación que va a permitir a los editores tener su propia RevistaStore, ajena al actual iBooks.
• Reminders: una aplicación de Tareas/GTD donde poder recopilar los temas que tenemos pendientes, e incluso definir avisos para que se produzcan en base a nuestra posición GPS.
• Twitter: integración en el sistema de Twitter, permitiendo desde aplicaciones como Fotos publicar facilmente nuestros tuits sin necesidad de otras aplicaciones.
• Camera: ahora la aplicación nativa nos permite determinadas labores de edición, que ya no requieren otras aplicaciones en nuestro dispositivo.

Además de éstas, hay hasta un total de 200 nuevas funcionalidades de usuario en el sistema.

Una que cabe destacar dado que puede que sea el pilar para muchas aplicaciones en el futuro próximo es iCloud. La apuesta de Apple por la nube, permitira a los desarrolladores muy facilmente ubicar información en la nube y sincronizarla entre los diferentes dispositivos del usuario facilmente. Un universo de posibilidades que seguro que las primeras apps de iOS 5 empiezan a explotar.

Pero claro, ¿que otras novedades nos depara iOS 5 a los desarrolladores de aplicaciones iOS?

Pues bien, aunque todavía no he podido trabajar con ellas a fondo (estoy ansioso por ver cuando Apple publique todos los videos del WWDC para que podamos ver todo esto en detalle), voy a tratar de daros una breve introducción a las que serían las novedades más notables:

• Almacenamiento en iCloud: un abanico de APIs que nos permitirán obtener y publicar información en la iNube de Apple muy facilmente. Tendremos la opción de utilizar clases de reciente creación como UIDocument que permite esta integración con iCloud de forma automática. Aunque tambien dispondremos de la opción de publicar elementos de tipo clave y valor. Esto último por ejemplo permitiría compartir las preferencias de usuario para nuestra aplicación entre los diferentes dispositivos del usuario. Se podría por ejemplo guardar la página por la que va el usuario, la foto galeria de fotos que tiene abierta, el contacto que tiene seleccionado, o cualquier otra información funcional y compartirla entre dispositivos. Por último también podremos realizar búsquedas facilmente entre los documentos que tengamos en iCloud.
• iCloud Backup: ahora nosotros como desarrolladores podremos adecuar nuestra aplicación para que guarde las preferencias del usuario, puntuaciones, configuración, etc. en iCloud y de este modo tener un backup asociado a nuestra app por si el usuario requiriera restaurar su dispositivo desde cero. ¡Se acabo que al borrar una app de nuestro equipo iOS y volver a instalarla tengamos que pasarnos de nuevo todas las pantallas de Angry Birds! O incluso, si la tenemos en el iPhone y en el iPad, ahora podremos sincronizar nuestro avance entre ambos dispositivos.
• Automatic Reference Counting: opcionalmente Apple nos ofrece la posibilidad de olvidarnos en nuestro desarrollo de andar contando el número de referencias y tener que gestionar manualmente los retain o release que hacemos de nuestros objetos. Arma de doble filo donde las hayas, pero que facilita el desarrollo a aquellos programadores que hayan visto estos temas de memoria un reto imposible para adentrarse en el desarrollo de iOS.
• Storyboards: esta es sin duda una de las funcionalidades que mas quiero investigar, porque creo que Apple ha dado un salto muy importante al respecto. Si nuestra aplicación tiene dos pantallas solo, es facil gestionar la navegación entre ellas, pero… ¿que pasa si nuestra aplicación tiene 15 pantallas?¿como gestionamos 15 ficheros de Inteface Builder?¿porque pantallas paso para ir de la 3 a la 9? ¿Imposible no? Pues bien, ahora podremos configurar en un solo fichero (aunque opcionalmente en varios) la relación de pantallas, la navegación de las mismas y lo que aún es más, las transiciones entre ellas, y todo sin necesidad de tener un fichero XIB para cada una de ellas. A cada pantalla de esos flujos Apple la denomina ahora Escena… ¿os suena?¿Cocos2D? ;·)
• Soporte para Newsstand: APIs de soporte para poder publicar contenidos en el nuevo kiosko de Apple.
• Mejoras en Airplay: ahora nuestra aplicación podra gestionar la nueva opción de iPad 2 de mirroring en Apple TV, y gestionar esta nueva pantalla como si de otra pantalla se tratase. Es decir que por ejemplo, un juego podría mostrar el juego en el Apple TV y utilizar el iPad como mando con información adicional como vueltas que quedan para acabar a la carrera, el espejo retrovisor, o cualquier cosa que se nos ocurra. ¿Os imaginais las posibilidades?

Además de todo esto, Apple pone a nuestra disposición una relación de nuevos frameworks que podremos incluir en nuestros desarrollos y que nos facilitaran la vida en muchos aspectos:

• GLKit Framework: un framework para facilitar la labor de Open GL en nuestra aplicación. Poco a poco, Open GL va estando mas al alcance de los humanos.
• Core Image Framework: un potener framework que nos permitirá la utilización de filtros para manipular tanto videos como fotografías. Con funcionalidades como Reconocimiento Facial y detección de objetos. Todos estos filtros se aplican de modo no destructivo, lo que quiere decir que podemos aplicarlo y luego desaplicarlos volviendo a la situación original. La gran ventaja es que haremos uso de forma automática de CPU y GPU logrando rendimientos muy buenos con poco esfuerzo.
• Twitter Framework: no hay mucho que decir acerca de este framework. Claramente la apuesta de Apple por Twitter impulsará más aún esta “red social”, dado que todas las aplicaciones tendran facilmente la posibilidad de integrarse con ella.
• Accounts Framework: muy relacionada con la anterior, dado que facilita el concepto de Single Signon entre diferentes aplicaciones, no teniendo que proporcionar las credenciales de usuario una y otra vez.

Por último, pero no menos importante, con la salida de iOS 5, tambien se incluye el lanzamiento de XCode 4.2 que incluye así mismo nuevas mejoras entre las que cabe destacar:

• Nuevas plantillas de proyecto para por ejemplo la realización de revistas electrónicas para Newsstand.
• Novedades en el simulador como la capacidad de simular posicionamiento. Hasta ahora todo este tipo de pruebas había que realizarlas en el dispositivo físico.
• Interface Builder ahora permite la creación y gestión de StoryBoards.

Y un largo etcétera que seguro que iremos descubriendo poco a poco…

Apple siempre tiene un gesto muy inteligente hacia los desarrolladores sacando versiones beta de sus nuevas versiones de SO meses antes (tres meses en este caso) de su salida al público. Recordemos que otros como Android, lanzan nuevas versiones del sistema operativo, y el usuario se tira días probando que todo lo que ya funcionaba, siga funcionando, mientras que los desarrolladores tienen que adecuar sus aplicaciones a marchas forzadas.

Por tanto hay que aprovechar esta ventaja que Apple nos brinda para que cuando iOS 5 salga al mercado, nuestras actuales aplicaciones funcionen perfectamente con este nuevo sistema, y además quizás podamos aportar a la AppStore alguna nueva aplicación que haga uso de las nuevas posibilidades del sistema.

Una nueva oportunidad para triunfar con nuestras innovadoras ideas en un mercado con más de 200 millones de usuarios.

En el anterior artículo veíamos en que consistía una escena, y que CCDirector es el responsable de la gestión de dichas escenas, y en definitiva de la navegación que ofrece nuestra aplicación entre sus diferentes pantallas.

En este artículo vamos a ver como tener un menú principal que nos permita desplazarnos a otras escenas, y cambiar de una a otra de manera simple, e incluso aplicando efectos de transición muy visuales que nos ofrece Cocos2d para incorporar a nuestras aplicaciones.

Vamos a crear un nuevo proyecto de tipo “Cocos2D Application”, lo cual permitirá a la plantilla de proyecto, crearnos un HelloWorldLayer.h y HelloWorldLayer.m que contienen un CCLabel con el texto “Hello World” de forma automática.

Dado que necesitamos dos pantallas sobre las cuales actuar, vamos a crear una segunda clase a la que denominaremos SegundaPantallaLayer.h y SegundaPantallaLayer.m, y que deberá ser una copia de HelloWorldLayer. Para crear esta copia, bastara con crear una nueva clase en X-Code que sea una subclase de CCLayer. Una vez creada, copiaremos todos los métodos existentes en la clase HelloWorldLayer a nuestra nueva clase, modificando necesariamente el nombre de la clase en algunos métodos.

Adicionalmente modificaremos en nuestra nueva clase el texto que pinta el CCLabel por el literal “Segunda pantalla” para que podamos identificar esta nueva escena fácilmente.

Ya tenemos dos escenas, pero ahora necesitamos implementar un menú de selección en nuestra clase.

Cocos2d nos facilita la creación de menús mediante la clase CCMenu, y para cada uno de los menús utilizaremos subclases de CCMenuItem como son CCMenuItemFont, CCMenuItemImage, etc.

Cada uno de los hijos de nuestro CCMenu será un menú de la aplicación, y podrá disponer de un método que se ejecutará al ser pulsado.

Vamos a ver como quedaría el método init de nuestra clase HelloWorldLayer.m (reemplazando el código que incluye por defecto cocos2d):

-(id) init {

if ((self =[super init])) {

// Obtenemos el tamaño de la pantalla de nuestro dispositivo

CGSize size = [[CCDirector sharedDirector] winSize];

// Establecemos las propiedades por defecto para nuestros menus.

[CCMenuItemFont setFontSize: 26];

// Creamos nuestro primer menú

CCMenuItemFont *item1 = [CCMenuItemFont itemFromString:@”Menu 1”

target:self selector:@selector(menu1pulsado:)];

// Creamos nuestro segundo menú

CCMenuItemFont *item2 = [CCMenuItemFont itemFromString:@”Menu 2”

target:self selector:@selector(menu1pulsado:)];

// Creamos la clase CCMenu y añadimos a los hijos

CCMenu *menú = [CCMenu menuWithItems:item1,item2,nil];

// Situamos el menú en pantalla

menu.position = CGPointMake(size.width / 2, size.height / 2);

// Establecemos la separación entre los diferentes submenus para

// evitar que se situen unos encima de los otros

[menu alignItemsVerticalyWithPadding:40];

// Añadimos a nuestra escena el CCMenu

[self addChild:menu];

}

}

Vamos a analizar algunas de las líneas de código que hemos añadido a nuestra primera escena.

Siempre que creamos un menú, mediante delegación asignamos un método, en este caso de la misma clase, que será el que se ejecutará al pulsar dicha opción de menú. En nuestro ejemplo, y dado que es una simple prueba, ambos menús ejecutarán el mismo método. En otros casos, puede que queráis identificar en este método qué menú ha sido pulsado mediante (id)sender, o incluso que existan métodos independientes para cada uno de los menús implementados.

En nuestro ejemplo utilizamos la clase CCMenuItemFont porque queremos crear textos para los menús, pero también podríamos utilizar otras opciones como CCMenuItemImage donde cada menú será una imagen.

Otro punto importante, es que a la hora de añadir los submenús a nuestro menú, y como ocurre en otras muchas situaciones dentro de Objective-C, al utilizar el método menuWithItems, debemos concluir nuestra lista siempre con un nil, en caso contrario recibiremos un error en tiempo de ejecución.

Otra línea a analizar es aquella en la que situamos el menú de navegación perfectamente centrado en pantalla. Es importante que esto se haga mediante la clase CCDirector y su método winSize, que permite independizar el centrado en pantalla de las dimensiones del dispositivo. Si centráramos el menú mediante coordenadas fijas, en un ipad o un iphone 4 con retina display seguramente no obtendríamos el resultado esperado.

El método alignItemsVerticalyWithPadding nos permite separar los menús entre ellos de forma automática. Existen otras opciones como alignItemsInRows, alignItemsHorizontally, alignItemsInColumns, etc. Todas estas opciones las podéis consultar en la API de cocos2d.

Por último y como ya hemos hecho en artículos anteriores, para poder añadir un objeto de cualquier tipo a nuestra escena, deberemos utilizar el método addChild de nuestra clase.

Ahora vamos a crear el método que permitirá navegar a nuestra segunda escena, al pulsar cualquiera de las opciones de menú que hemos incluido.

- (void) menu1pulsado(id)sender {

// Creamos una instancia de nuestra segunda pantalla

SegundaPantallaLayer *segundaPantalla = [SegundaPantallaLayer node];

// Navegamos a la segunda pantalla de forma sencilla

[[CCDirector sharedDirector] replaceScene:segundaPantalla];

}

Para que éste método funcione, debemos hacer un import de SegundaPantallaLayer.h en nuestra clase.

Simplemente con esto, al pulsar cualquier opción de menú nuestra aplicación nos debería trasladar automáticamente a la segunda pantalla con el CCLabel que indica “Segunda pantalla”.

Ahora bien, si queremos que el cambio de pantalla se realice mediante una transición más visual, cocos2d como os decía ofrece muchas posibilidades.

El método quedaría de la siguiente manera:

- (void) menu1pulsado(id)sender {

// Creamos una instancia de nuestra segunda pantalla
SegundaPantallaLayer *segundaPantalla = [SegundaPantallaLayer node];

// Creamos una transición
CCTransitionFade *trans =

[CCTransitionFade transitionWithDuration:1 scene:segundaPantalla];

// Navegamos a la segunda pantalla mediante la transición
[[CCDirector sharedDirector] replaceScene:trans];

}

Con el ejemplo que os propongo, la transición elegida es un simple Fade entre ambas pantallas, pero existen multitud de opciones que podéis consultar en la API de cocos2d como son: CCTransitionCrossFade, CCTransitionFlipAngular, CCTransitionFlipX, etc.

Ahora que ya sabéis crear varias escenas, navegar entre ellas mediante menús, es el momento de trastear con las diferentes opciones, que ya veréis que es muy sencillo.

Espero que os haya gustado este nuevo artículo, y nos vemos en el próximo.