Antes cuando queríamos comunicarnos con Twitter y obtener datos y actualizarlos había que hacer una conexión a través de OAuth con unos tokens y secret-keys, esto normalmente se hacía más digerible usando algún framework o clase externa que servía de interfaz de conexión entre el cliente y el servicio. Desde la llegada del framework de Twitter y la integración con iOS 5 las cosas se pusieron extraordinariamente más fáciles, esto nos permitió el intercambio de datos con Twitter en tan solo pocos pasos.

En el Social Framework tenemos una clase llamada SLRequest, muy similar a TWRequest del framework de twitter. Esta clase encapsula las propiedades de una petición HTTP en métodos fáciles de utilizar, con los cuales enviamos peticiones a Twitter para poder obtener y actualizar datos de nuestras cuentas configuradas en el dispositivo.

Básicamente enviamos una petición HTTP con unos parámetros que configuran lo que queremos llevar a cabo en el servicio, si Twitter dice que no pasa nada, recibimos una respuesta con unos datos que tenemos que manipular y mostrar al usuario, caso contrario recibimos una información de error.

Autenticando la petición

Como les decía párrafos atrás, antes había que usar tokens y secret-keys para autenticarnos en Twitter y así poder validar nuestras peticiones. Con el Social Framework hacemos lo mismo pero de forma automática, más transparente al usuario, y en cierta forma al desarrollador, ya que en ningún momento tenemos que manipular tokens.

Desde iOS 5 tenemos el Accounts Framework, el cual provee un sistema centralizado de cuentas de usuario. A través de el se almacenan todas las cuentas de Twitter (Y de otros servicios) configuradas en el dispositivo: información de usuario y contraseña y demás, esto nos permite saltarnos esa típica ventana de inicio de sesión sin tener que preocuparnos por proveer un sistema para almacenar nosotros mismos las credenciales.

Hay pocas cosas que podemos hacer sin autenticación de usuario, y obtener el timeline es una de ellas. No obstante para hacer que esto funcione con cualquier cuenta, centralizaremos todas las peticiones en las cuentas obtenidas de la base de datos de cuentas del dispositivo. Empecemos:

Lo primero será importar los frameworks:

#import <Accounts/Accounts.h>
#import <Social/Social.h>

Luego hacemos la mágia de obtener las cuentas del dispositivo con el Accounts Framework:

ACAccountStore *accountStore = [[ACAccountStore alloc] init];

// creamos un objeto accountType especificando que solo queremos obtener
// las cuentas de Twitter
ACAccountType *accountType = [accountStore
              accountTypeWithAccountTypeIdentifier:ACAccountTypeIdentifierTwitter];

[accountStore requestAccessToAccountsWithType:accountType
                                      options:nil
                                   completion:^(BOOL granted, NSError *error)
{
    if (granted)
    {
        // guardamos las cuentas de twitter en un array
        NSArray *accountsArray = [accountStore accountsWithAccountType:accountType];
        // armamos la petición aquí
    }
    else {
        NSLog(@"Error no se pudo acceder a las cuentas");
    }
}];

Lo que hacemos aquí es crear una instancia de la base de datos de cuentas. Luego a través de la clase ACAccountType decimos que solo queremos las cuentas de Twitter, pasándole la constante ACAccountTypeIdentifierTwitter como argumento en la inicialización. Acto seguido pedimos acceso a las cuentas con el método requestAccessToAccountsWithType:options:completion:. Este método tiene como argumento el bloque completion:, el cual es un handler (Un objeto “manipulador” por así decirlo) en cuyos parámetros es devuelta la respuesta del método. Si todo va bien almacenamos todas las cuentas obtenidas en el array accountsArray o mostramos un error en caso contrario. Simple.

Recueda esta dinámica de ejecutar un método y recibir una respuesta para ser manipulada en un bloque, porque lo verás muy a menudo desde ahora.

Contruyendo la petición para obtener el timeline

Con el Social Framework es definitivamente mucho más fácil construir una petición HTTP. Sabemos que está compuesta por:

1. Una URL que identifica la operación que queremos realizar en el servicio.
2. Un método de petición, que puede ser GET, POST o DELETE.
3. Y unos parámetros de configuración.

El método requestForServiceType:requestMethod:URL:parameters: pasa todos estos datos como sus argumentos y esto nos permite crear la petición en tan solo una línea de código si así lo deseamos.

Lo que nosotros queremos es obtener el timeline, por lo tanto necesitamos ir a la documentación oficial para ver lo que tenemos que usar. Al entrar en el enlace y seleccionar la operación de la que queremos ver los detalles (en este caso es: GET statuses/home_timeline), veremos en el apartado Resourse Information cierta información muy importante:

Tenemos el método de la petición (GET), el formato de respuesta (JSON) y el objeto de respuesta (Tweets). Luego está el apartado Resource URL que es la URL que le pasaremos y el apartado Parameters, que contiene los parámetros para configurarla. Usando esta información construimos la petición:

// guardamos la cuenta
ACAccount *twitterAccount = [accountsArray objectAtIndex:0];
self.cuenta = twitterAccount;

// creamos la petición
NSURL *url = [NSURL URLWithString:
                    @"https://api.twitter.com/1.1/statuses/home_timeline.json"];

NSDictionary *parametros = [NSDictionary dictionaryWithObjectsAndKeys:
                                @"25", @"count", nil];

SLRequest *request = [SLRequest requestForServiceType:SLServiceTypeTwitter
                                        requestMethod:SLRequestMethodGET
                                                  URL:url
                                           parameters:parametros];

// asociamos la cuenta a la petición
[request setAccount:twitterAccount];

Por motivos de brevedad tan solo utilizaremos la primera cuenta de las que hay en el array.

He creado la propiedad cuenta de tipo ACAccount, en ella almacenamos esta cuenta para posteriormente poder enviarla al controlador desde el que publicaremos un mensaje de estado (lo que es un Tweet) a nuestro timeline, esto más adelante.

Como pueden ver tenemos un diccionario para los parámetros. El mío solo tiene una key: count, esta nos permite limitar la cantidad de tweets que nos va a devolver el timeline que por defecto es 20, pero yo la he puesto a 25. En la documentación de la API están todos los parámetros que podemos usar para configurar la petición.

Lo siguiente es asignarle a la propiedad account de nuestra petición, la cuenta que hemos elegido del array y con la que queremos trabajar para mostrar el timeline y demás cosas.

Enviando la petición y manipulando los resultados

Una vez construida la petición procedemos a enviarla. Para esto usamos el método performRequestWithHandler: que envía la petición y recoge los resultados en su único argumento. Este es a su vez un bloque, el cual es ejecutado una vez están disponibles los datos de la respuesta.

// realizamos la petición especificando un método para manipular la respuesta
[request performRequestWithHandler:
^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error)
{
    if (responseData != nil)
    {
        self.tweets = [NSJSONSerialization JSONObjectWithData:responseData
                                                      options:kNilOptions
                                                        error:&error];
    }
}];

Este bloque tiene 3 parámetros, el más importante es responseData, porque es el que va a contener los tweets. Estos tweets están en formato JSON como vimos antes, por lo tanto necesitamos parsearlos y así pasarlos a un formato manipulable en Objective-c. Para hacer esto existe la clase NSJSONSerialization, que coge los datos en NSData (en este caso responseData), los parsea y devuelve. Estos datos devueltos los almacenamos en el array tweets, que a continuación usaremos para mostrarlos al usuario.

Mostrando los resultados

Bien, ya tenemos hecho casi todo el trabajo, ahora solo nos queda mostrar los resultados, y para esto tenemos el objeto tweetsTableView. Debido a que ya tenemos todos los Tweets en un array, es relativamente sencillo mostrarlos en el tableView, por eso vamos directamente a implementar los métodos convenientes:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
    return 1;
}

- (NSInteger)tableView:(UITableView *)tableView
                                  numberOfRowsInSection:(NSInteger)section
{
    return [self.tweets count];
}

- (UITableViewCell *)tableView:(UITableView *)tableView
            cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:
                                                      CellIdentifier];
    if (cell == nil)
    {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle
                                                    reuseIdentifier:CellIdentifier] autorelease];
    }

    NSDictionary *tweet = [self.tweets objectAtIndex:indexPath.row];

    cell.textLabel.text = [tweet objectForKey:@"text"];
    cell.detailTextLabel.text = [[tweet objectForKey:@"user"]
                           objectForKey:@"screen_name"];

    // cargamos las imágenes de los que envían el tweet de forma asíncrona
    dispatch_queue_t queue = dispatch_queue_create("com.thxou.totweet", NULL);
    dispatch_queue_t main = dispatch_get_main_queue();

    dispatch_async(queue, ^{
        NSURL *imageURL = [NSURL URLWithString:[[tweet objectForKey:@"user"]
                                            objectForKey:@"profile_image_url"]];
        NSData *imageData = [NSData dataWithContentsOfURL:imageURL];
        dispatch_async(main, ^{
            cell.imageView.image = [UIImage imageWithData:imageData];
        });
    });
    dispatch_release(queue);

    return cell;
}

Aquí hay algunas líneas que les sonarán a chino, no obstante explicaré un poco por encima que está sucediendo.

Al parsearse los datos estos son almacenados en el array tweets, pero los tweets dentro de el son almacenados en forma de diccionarios, fácilmente recuperables usando la clase NSDictionary. Entonces recuperamos cada campo de ese array en un diccionario que yo he llamado tweet para hacerlo más identificable (en realidad eso es lo que representa). Como ya saben, accedemos a los valores de un diccionario a través de keys, pero cuales son estas keys?, nos vamos a la documentación oficial y lo miramos allí. Lo que hacemos es simplemente mostrar el texto del tweet como título y el nombre “del que tweetea” como subtitulo en cada celda.

Para mostrar la imagen lo que hacemos es usar el GCD (Grand Central Dispatch) de Apple. A grandes rasgos explicarles que la descarga de datos de la red siempre debería de ser de forma asíncrona, esto es porque es un proceso que tarda un poco en llevarse a cabo y por lo tanto no puede hacerse en el mismo thread (hilo) ya que podemos bloquearlo, y esto dejaría inutilizable la interfaz de usuario hasta que se complete el proceso, cosa que por el bien de nuestros usuarios, no queremos. Pues este problema lo soluciona el GCD, haciendo que ciertos métodos se ejecuten de forma asíncrona (en otro hilo o thread), de esta forma evitamos bloquear la interfaz de usuario.

Enviando un tweet

Pues hacer esto es un poco más de lo mismo. Yo he creado un nuevo controlador para hacer esto llamado EnviarTweetViewController, el cual se muestra en una ventana modal y tiene un TextView y dos botones: uno para enviar el tweet y otro para cancelar la operación.

El de enviar el tweet ejecuta el método enviarTweet::

- (IBAction)enviarTweet:(id)sender
{
    // comprobamos si el campo para escrbir el tweet no está vacío
    if (![self.tweet.text isEqualToString:@""])
    {
        NSURL *url = [NSURL URLWithString:
                           @"https://api.twitter.com/1.1/statuses/update.json"];

        NSDictionary *parametros = [NSDictionary dictionaryWithObjectsAndKeys:
                                    self.tweet.text, @"status", nil];

        SLRequest *request = [SLRequest requestForServiceType:SLServiceTypeTwitter
                                                requestMethod:SLRequestMethodPOST
                                                          URL:url
                                                   parameters:parametros];

        // Set the account used to post the tweet.
        [request setAccount:self.cuenta];

        // Perform the request created above and create a handler block
        //to handle the response.
        [request performRequestWithHandler:
        ^(NSData *responseData, NSHTTPURLResponse *urlResponse, NSError *error)
         {
             NSDictionary *resultado = [NSJSONSerialization
                                       JSONObjectWithData:responseData
                                                           options:kNilOptions
                                                             error:&error];
         }];

        [self cancelar:nil];
    }
}

Como podéis observar se hace exactamente lo mismo. Tan solo cambian los parámetros, la URL y el método de la petición, y todo esto lo podemos encontrar en la documentación oficial.

A diferencia del anterior, aquí no accedemos a todas las cuentas del dispositivo, sino que simplemente pasamos a este controlador la cuenta que hemos obtenido antes, así nos aseguramos de que la cuenta que está seleccionada es desde la que se envía el tweet y sobre la que se hacen las operaciones solicitadas. No hay misterio.

Conclusión

El procedimiento para llevar a cabo todas estas acciones en Twitter llevan la misma estructura. Tan solo varían los parámetros, la URL y el método de la petición. Por lo que, si queremos hacer cualquier cosa, tenemos que ir a la documentación y mirar lo que necesitamos. Luego reemplazar los datos que hemos visto antes con los nuevos, enviar la petición y mostrar al usuario los datos obtenidos. Así de fácil es trabajar con el Social Framework.

Ahora puedes pasarte por la documentación de Apple sobre este tema y también visitar este tutorial sobre como parsear y manipular ficheros JSON de forma nativa y así extender un poco más tus conocimientos.

Descarga los archivos del tutorial haciendo click aquí.

Fuente | ThXou.com

Así que vamos a entrar en materia y veremos como poder implantarlo en nuestro propio proyecto (Talk is cheap, SHOW ME THE CODE!).

Empezamos

- Vamos a crear un nuevo proyecto en Xcode, para este ejemplo he utilizado “Single View Application” (DetectorCaras)

- Importamos los frameworks Core Image y QuartzCore al fichero de implementación de ViewController (ViewController.m)

#import <CoreImage/CoreImage.h>
#import <QuartzCore/QuartzCore.h>

- Añadimos al proyecto una imagen en la cual deberá aparecer mínimo una cara.

- Incluimos el método faceDetector (lo podéis llamar como queráis) para añadir la imagen,seleccionada anteriormente, a la pantalla.

-(void)faceDetector
{
    // Carga la imagen de la cara
    UIImageView *imagen = [[UIImageView alloc]
initWithImage:[UIImage imageNamed:@"megan.jpg"]];

    // La añadimos a nuestra vista
    [self.view addSubview:imagen];

    // Llamamos al método markFaces para poder detectar los rostros y
    // sí los detecta pintarlos en pantalla
    [self markFaces:imagen];
}

- Ahora vamos a añadir el método markFaces: con el que detectaremos si existen caras en la imagen.

-(void)markFaces:(UIImageView *)imagenCara
{
    CIImage *imagen = [CIImage imageWithCGImage:imagenCara.image.CGImage];
    // Para el detector, utilizamos la constante "CIDetectorAccuracyHigh" la cual
    // nos proporciona una precisión mejor pero requiere más tiempo de procesado
    // Más info en http://goo.gl/ahfoU
    CIDetector *detector = [CIDetector detectorOfType:CIDetectorTypeFace
    context:nil options:[NSDictionary dictionaryWithObject:CIDetectorAccuracyHigh
    forKey:CIDetectorAccuracy]];

    // Creamos un array con todas las caras detectadas en la imagen
    NSArray *features = [detector featuresInImage:imagen];

    // Hacemos un bucle por si detecta más de un rostro en la imagen
    for (CIFaceFeature *faceFeature in features) {
        // Obtener el ancho de la cara
        CGFloat faceWidth = faceFeature.bounds.size.width;

        // UIView usando las dimensiones de la cara detectada
        UIView *faceView = [[UIView alloc] initWithFrame:faceFeature.bounds];

        // Añadimos un borde alrededor del UIView
        faceView.layer.borderWidth = 1;
        faceView.layer.borderColor = [[UIColor blueColor] CGColor];

        [self.view addSubview:faceView];

        // Ojo derecho
        if (faceFeature.hasRightEyePosition) {
            // Creamos una UIView con el tamaño del ojo derecho
            UIView *rightEye = [[UIView alloc] initWithFrame:CGRectMake
            (faceFeature.rightEyePosition.x - faceWidth * 0.15,
            faceFeature.rightEyePosition.y -
            faceWidth * 0.15, faceWidth * 0.3, faceWidth * 0.3)];

            rightEye.backgroundColor = [[UIColor redColor]
            colorWithAlphaComponent:0.4];
            rightEye.center = faceFeature.rightEyePosition;

            rightEye.layer.cornerRadius = faceWidth * 0.15;
            [self.view addSubview:rightEye];
        }

        // Ojo izquierdo
        if (faceFeature.hasLeftEyePosition) {
            // Creamos una UIView con el tamaño del ojo izquierdo
            UIView *leftEye = [[UIView alloc] initWithFrame:CGRectMake
            (faceFeature.leftEyePosition.x - faceWidth * 0.15,
            faceFeature.leftEyePosition.y -
            faceWidth * 0.15, faceWidth * 0.3, faceWidth * 0.3)];

            leftEye.backgroundColor = [[UIColor redColor] colorWithAlphaComponent:0.4];
            leftEye.center = faceFeature.leftEyePosition;

            leftEye.layer.cornerRadius = faceWidth * 0.15;
            [self.view addSubview:leftEye];
        }

        // Boca
        if (faceFeature.hasMouthPosition) {
            // Creamos una UIView con el tamaño de la boca
            UIView *mouth = [[UIView alloc] initWithFrame:CGRectMake
            (faceFeature.mouthPosition.x - faceWidth * 0.20,
            faceFeature.mouthPosition.y -
            faceWidth * 0.20, faceWidth * 0.40, faceWidth * 0.40)];

            mouth.backgroundColor = [[UIColor greenColor]
            colorWithAlphaComponent:0.4];
            mouth.center = faceFeature.mouthPosition;

            mouth.layer.cornerRadius = faceWidth * 0.20;
            [self.view addSubview:mouth];
        }
    }
}

- El último paso sería llamar al método faceDetector desde viewDidLoad y ejecutar nuestro código para ver el resultado

- (void)viewDidLoad
{
    [super viewDidLoad];

    [self faceDetector];
}

ALGO VA MAL…

Como se puede apreciar parece que algo ha salido mal y el problema está en que las coordenadas que utiliza UIKit y CoreImage (OS X) son diferentes. El origen del sistema de coordenadas de CoreImage están en la esquina inferior izquierda y el de UIKit está en la esquina superior izquierda. Por eso necesitamos invertir las posiciones antes de pintarlas por pantalla. Como la mayoría de nuestro código tendrá las coordenadas de UIKit, será más fácil traducir CoreImage a UIKit. Para ello tendremos que realizar una serie de modificaciones en nuestros métodos:

- faceDetector

-(void)faceDetector
{
    // Carga la imagen de la cara
    UIImageView *imagen = [[UIImageView alloc] initWithImage:
    [UIImage imageNamed:@"megan.jpg"]];

    [self.view addSubview:imagen];

    // El origen del sistema de coordenadas de CoreImage están en la esquina
    // inferior izquierda
    // y el de UIKit está en la esquina superior izquierda. Por eso necesitamos
    // invertir las posiciones
    // antes de pintarlas por pantalla.
    CGAffineTransform transform = CGAffineTransformMakeScale(1, -1);
    transform = CGAffineTransformTranslate(transform,
                                           0,-imagen.bounds.size.height);

    [self markFaces:imagen withTransform:transform];
}

- markFaces: pasa a llamarse markfaces:withTransform: ya que vamos a pasarle un parámetro de tipo CGAffineTransform

-(void)markFaces:(UIImageView *)imagenCara withTransform:(CGAffineTransform) transform
{
    CIImage *imagen = [CIImage imageWithCGImage:imagenCara.image.CGImage];
    // Para el detector, utilizamos la constante "CIDetectorAccuracyHigh"
    // la cual nos proporciona una precisión mejor pero requiere más
    // tiempo de procesado
    // Más info en http://goo.gl/ahfoU
    CIDetector *detector = [CIDetector detectorOfType:CIDetectorTypeFace context:nil
    options:[NSDictionary dictionaryWithObject:CIDetectorAccuracyHigh
    forKey:CIDetectorAccuracy]];

    // Creamos un array con todas las caras detectadas en la imagen
    NSArray *features = [detector featuresInImage:imagen];

    // Hacemos un bucle por si detecta más de un rostro en la imagen
    for (CIFaceFeature *faceFeature in features) {

        // Convertir coordenadas CoreImage a UIKit
        CGRect faceRect = CGRectApplyAffineTransform(faceFeature.bounds, transform);
        // Obtener el ancho de la cara
        CGFloat faceWidth = faceFeature.bounds.size.width;

        // UIView usando las dimensiones de la cara detectada
        UIView *faceView = [[UIView alloc] initWithFrame:faceRect];

        // Añadimos un borde alrededor del UIView
        faceView.layer.borderWidth = 1;
        faceView.layer.borderColor = [[UIColor blueColor] CGColor];

        [self.view addSubview:faceView];

        // Ojo derecho
        if (faceFeature.hasRightEyePosition) {

            // Convertir coordenadas CoreImage a UIKit
            CGPoint rightEyePos = CGPointApplyAffineTransform
            (faceFeature.rightEyePosition, transform);

            // Creamos una UIView con el tamaño del ojo derecho
            UIView *rightEye = [[UIView alloc] initWithFrame:CGRectMake
            (rightEyePos.x - faceWidth * 0.15, rightEyePos.y - faceWidth * 0.15,
            faceWidth * 0.3, faceWidth * 0.3)];

            rightEye.backgroundColor = [[UIColor redColor]
            colorWithAlphaComponent:0.4];
            rightEye.center = rightEyePos;

            rightEye.layer.cornerRadius = faceWidth * 0.15;
            [self.view addSubview:rightEye];
        }

        // Ojo izquierdo
        if (faceFeature.hasLeftEyePosition) {

            // Convertir coordenadas CoreImage a UIKit
            CGPoint leftEyePos = CGPointApplyAffineTransform
            (faceFeature.leftEyePosition, transform);

            // Creamos una UIView con el tamaño del ojo izquierdo
            UIView *leftEye = [[UIView alloc] initWithFrame:CGRectMake
            (leftEyePos.x - faceWidth * 0.15, leftEyePos.y - faceWidth * 0.15,
            faceWidth * 0.3, faceWidth * 0.3)];

            leftEye.backgroundColor = [[UIColor redColor]
            colorWithAlphaComponent:0.4];
            leftEye.center = leftEyePos;

            leftEye.layer.cornerRadius = faceWidth * 0.15;
            [self.view addSubview:leftEye];
        }

        // Boca
        if (faceFeature.hasMouthPosition) {

            // Convertir coordenadas CoreImage a UIKit
            CGPoint mouthPos = CGPointApplyAffineTransform
            (faceFeature.mouthPosition, transform);

            // Creamos una UIView con el tamaño de la boca
            UIView *mouth = [[UIView alloc] initWithFrame:CGRectMake
            (mouthPos.x - faceWidth * 0.20, mouthPos.y - faceWidth * 0.20,
            faceWidth * 0.40, faceWidth * 0.40)];

            mouth.backgroundColor = [[UIColor greenColor] colorWithAlphaComponent:0.4];
            mouth.center = mouthPos;

            mouth.layer.cornerRadius = faceWidth * 0.20;
            [self.view addSubview:mouth];
        }
    }
}

RESULTADO

Podéis descargar el proyecto DetectorCaras1.zip (69,79 kb)

Fuente: Ingens Blog

Para empezar, RubyMotion es en sí un conjunto de herramientas, a saber:

• Unas herramientas de línea de comando, que generan proyectos (si alguna vez habéis utilizado RoR, es del mismo estilo), los ejecutan y los empaquetan
• Un compilador de MacRuby
• Una herramienta REPL que funciona sobre el simulador de iPhone

Con estas herramientas disponemos de la capacidad de desarrollar aplicaciones completas para iOS usando MacRuby. MacRuby es una implementación de Ruby que se caracteriza por funcionar sobre el runtime de Objective-C, en lugar de sobre C pelado. Cuando usamos MacRuby, los tipos nativos de Ruby se encuentran implementados por tipos de Objective-C/Cocoa. Por ejemplo, un string de ruby será en realidad un NSMutableString. Un hash será en realidad un NSMutableDictionary. Y así sucesivamente. No solo eso, si no que disponemos de unas extensiones a la sintaxis habitual de Ruby que nos permiten llamar a métodos en Objective-C que admitan múltiples parámetros respetando su idiosincrasia.

Si habéis seguido el panorama de MacRuby de cerca, sabréis que en principio solo está soportado en el Mac. Había una serie de importantes escollos técnicos que sortear antes de poder ponerse a desarrollar con MacRuby para iOS. Así que Laurent Sansonetti, el principal impulsor de MacRuby dentro de Apple, se despidió de la compañía para iniciar su propia empresa que resolviera esta demanda. Y así fue como RubyMotion vio la luz, en forma de producto comercial. Actualmente se está ofreciendo bajo un descuento por lanzamiento, el precio final será de unos €160.

Breve introducción a RubyMotion

Cómo se trabaja con RubyMotion? Para empezar, lo primero que hay que hacer es desplazarse a un directorio donde queramos tener los proyectos. Desde la terminal, y antes de empezar con nada más, podemos opcionalmente comprobar si hay alguna actualización:

sudo motion update

Aunque parezca una tontería mencionarlo, este paso puede ser interesante. En apenas unos días, RubyMotion ha alcanzado la versión 1.5. Y no es cuestión baladí actualizarse, ya que en cada versión se está ofreciendo funcionalidad nueva bastante interesante. Por ejemplo, al salir la release 1.0, RubyMotion no soportaba diseñar la interfaz gráfica desde Interface Builder. La idea era generar la interfaz programáticamente, tal vez con ayuda de un DSL especializado construido sobre ruby. Ahora ya se compilan los XIBs a NIBs automáticamente.

Una vez hecho esto, el siguiente paso sería crear un nuevo proyecto:

motion create nombre

Esto crea una estructura de directorios, y unos ficheros iniciales con los que empezar a trabajar. Como ya estamos acostumbrados, este proyecto vacío ya es ejecutable (aunque no haga nada):

cd nombre
rake

Eso inicia el proyecto, y nos abre una especie de shell (un REPL) desde donde podemos manipular los objetos de nuestra aplicación en vivo, utilizando un intérprete de Ruby! De hecho, cuando ya estamos mostrando elementos por pantalla en el simulador, con solo hacer ⌘-click obtenemos en la terminal la referencia al objeto.

Ahora ya solo se trata de empezar a trabajar poniendo las clases que faltan. Podéis ver los detalles en cualquiera de los tutoriales de RubyMotion que no paran de salir por todas partes, o los de MacRuby que ya existían. Si estáis interesados en aprender más, dejad vuestro feedback y trataremos de preparar algo más completo. De hecho, en la lista de correo no se ha mencionado para nada RubyMotion, así que asumo que soy el único que ha obtenido una licencia.

La mayoría de nosotros nunca te conocimos personalmente. Nunca estuvimos en una keynote tuya, te estrechamos la mano, ni recibimos un escueto correo tuyo. Pero a pesar de ello, nos sentimos apesadumbrados ahora que ya no estás, y nos falta algo. Porque afectaste a nuestras vidas  con tus ideas, y sin ti ni siquiera estaríamos reuniéndonos y compartiendo conocimientos.

Tú nos enseñaste que los detalles son importantes. Que no hay que tener miedo de lanzarnos a por lo que creemos. Que la informática es para todos. Y que hay que tratar de hacer del mundo un lugar mejor. Y por eso hoy es un día triste. Pero trataremos de seguir tu ejemplo como si estuvieras a nuestro lado, inspirándonos y criticando nuestros puntos débiles para que hagamos un mejor trabajo sin caer en la complacencia.

Seguiremos ávidos e ilusos. Y pensando diferente.

Los NSCoders.

Cuando comenzamos a desarrollar aplicaciones iOS llega un momento en que queremos utilizar funciones de persistencia para guardar ciertos datos entre distintas ejecuciones de la aplicación. De entre los distintos modos que tenemos disponibles para hacerlo, uno de los más recomendables es la utilización del framework Core Data.

Entre la documentación propia de Apple se encuentra el tutorial introductorio ‘Core Data Tutorial for iOS’. El documento adjunto es un simple resumen de dos páginas con los conceptos más importantes de dicho tutorial.

(by Albert Mata, @almata)

Gracias Albert!

Aquí os dejamos el primer podcast de la Asociación NSCoders España.

Para ser la primera edición, de muchas mas, creo que ya esta bien los poco mas de 36min de duración. 36min durante los cuales presentamos los orígenes de la asociación, el paso que parecía natural, de las “NSCoders Nights” a la “Asociación NSCoders España”. La diferencia entre los dos formatos. Lo que nos mueve a impulsarlo y apostar por este formato como un paso mas para los desarrolladores de Cocoa en toda España.
Una pequeña introducción al evento del próximo 29-30 de Octubre en Vilanova y la Geltru, Barcelona. El formato, los contenidos, algunos detalles mas y alguna primicia No demasiada información, si no más bien una pequeña pincelada del evento. En próximos podcast iremos sacando a la luz mas detalles, novedades y noticias. No os los perdáis!!

Y para terminar una de nuestras secciones estrellas de estos días: NSCollaborations. Esta semana:-Jonathan Chacón Barbero-Diego Freniche Brito

Os esperamos en la próxima edición del … NSPodcast!!

NSPodcast Edición num.001

PD: Próximamente en sus mejores iTunes :p

Llega el evento más relevante del año para desarrolladores y aficionados a los dispositivos móviles de Apple. Los próximos 29 y 30 de octubre tendrá lugar en Neàpolis Vilanova i la Geltrú la NSCoders Conference 2011.

De la mano de la Asociación NSCoders España llega un evento de dos días apto para todos los públicos, desde personas interesadas o apasionadas por los Iphone e Ipad que quieran iniciarse en este mundo, hasta profesionales del sector que quieran ampliar sus conocimientos o intercambiar experiencias y establecer contactos con empresas.

El formato elegido ofrecerá dos líneas de contenido simultáneas: una dirigida al público menos experimentado, con talleres de iniciación y contenidos elementales para dar los primeros pasos y otra con contenidos más especializados dirigida a aquellos que quieran explorar a fondo la arquitectura y posibilidades de estas tecnologías.

La calidad de las ponencias está asegurada por auténticos gurús del desarrollo como el consultor en accesibilidad Jonathan Chacón, que mostrará como estos dispositivos son grandes aliados de las personas con discapacidades o desarrolladores de referencia como Diego Freniche e Imanol Prados.

Asimismo se contará con la presencia de empresas, que nos mostrarán las claves de sus tecnologías y algún ponente sorpresa que dejará a los asistentes con la boca abierta de par en par…

Toda la información del evento está disponible en la web del evento: nsconf.nscoders.org

Sin embargo, pocas de estas herramientas se encuentran disponibles de serie en nuestros sistemas. Para poder utilizarlas, debemos instalarlas manualmente, lo cual es cuando menos engorroso, y cuando más, puede significar horas y horas perdidas tratando de resolver dependencias de las herramientas que utilizamos.

Para solucionar este problema, nacieron los gestores de paquetes. Del mismo modo que en linux disponemos de rpm y dpkg (o yum y apt), en MacOS X existen también varios sistemas de gestión de paquetes. En este artículo me centraré en el que considero más avanzado y más útil de ellos, Homebrew, ya que las alternativas, mayormente Macports (inspirado en el sistema de ports de FreeBSD) y fink (inspirado a su vez en apt), han ido poco a poco quedándose atrás en cuanto a frecuencia de actualización y catálogo de software disponible. Homebrew es obra del prolífico Max Howell, autor entre otras herramientas de las versiones Android e iOS de TweetDeck, y de los clientes de last.fm.

Homebrew es un sistema que goza de las simpatías de muchos desarrolladores y, por tanto, de un ímpetu, que lo ha convertido rápidamente en una elección muy popular entre los usuarios más técnicos. No en vano es el proyecto con mayor número de forks en GitHub (hecho que, al contrario de lo que pueda parecer, no es un indicativo de fragmentación, si no de participación popular, ya que cada persona que quiere añadir un paquete, o actualizarlo, simplemente crea un fork, añade su receta, y envía una solicitud de pull al mantenedor para que lo incorpore al proyecto principal).

Una de las principales características que tiene homebrew frente a otros gestores de proyectos, es que no necesitas ser root para instalar un paquete. Homebrew normalmente instala los ejecutables en /usr/local/, nada de /opt/, /sw/ ni tonterías similares. Y por tanto, espera que ese directorio sea escribible sin permisos de root. Al respecto ha habido cierta controversia, a mi al menos al principio no me parecía del todo correcto. Pero si nos ponemos a mirar, veremos que casi cualquier aplicación que bajamos de internet, y que se instale a pelo, es decir sin instalador, la copiamos tranquilamente a /Applications/ sin pensárnoslo dos veces. Y al contrario, cuando ejecutamos un script con sudo, estamos corriendo más riesgo del que pensamos.

Para instalar homebrew, simplemente vamos a https://github.com/mxcl/homebrew y vemos que hay que ejecutar un pequeño script en ruby:

/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

Si ejecutar un script obtenido a partir de una URL te pone los pelos de punta (debería), puedes echar un vistazo primero.

Una vez hecho esto, ya tenemos homebrew listo para instalar paquetes. Podemos probarlo de la siguiente manera:

brew install wget

Esto instruirá a brew a descargarse el código fuente de la utilidad wget, compilarlo, e instalarlo en /usr/local/. Homebrew en este sentido, es más parecido a los ports o al emerge de Gentoo. No lo he mencionado, dado que doy por sentado que todos tenemos Xcode, pero evidentemente necesitaremos las herramientas de desarrollo, no necesariamente Xcode al completo, pero si los paquetes de compiladores y demás.

Por cierto, por algún extraño motivo, en MacOS X, /usr/local/bin no está antes en el $PATH que /usr/local/, con lo cual, si instalamos alguna herramienta de las que vengan con el sistema o con Xcode, nos vamos a encontrar que la del sistema tiene prioridad sobre la versión que nosotros hemos instalado explícitamente (con lo cual, es como si no hubieramos hecho nada). En cualquier otro sistema UNIX (o linux), lo normal es que las customizaciones tomen prioridad, así que no acabo de entender muy bien esta política. Podemos solucionar esto de dos maneras, editando nuestro fichero ~/.bash_profile para modificar la variable de entorno $PATH, o bien cambiando el orden en /etc/paths (lo cual va a requerir permisos de root, al aplicarse a todo el sistema).

Las definiciones de los paquetes en homebrew siguen la metáfora de una cervecera. Cada paquete es una receta o fórmula para elaborar un… bueno, en castellano no tenemos una buena traducción para brew, en el sentido cervecero. Brebaje suena parecido pero es algo completamente distinto. Podríamos abusar del lenguaje y usar la palabra caldo, que los vinateros usan, pero lo dejaremos como brew. To brew en inglés es también un verbo, que es lo que representa el comando que usamos.

En fin, después de esta digresión, paso a enumerar los comandos más habituales de que disponemos para gestionar los paquetes. Lo mejor es que echemos un vistazo al manual de brew y los veamos cuando tengamos dudas:

brew search paquete

Este comando buscará un match en los nombres de los paquetes y nos listará los que coincidan (si el nombre de paquete está cerrado entre barras, se interpretará como una expresión regular). Una vez creemos haber encontrado el que nos puede interesar, lo podemos comprobar con

brew home paquete

Esto nos abrirá el navegador por defecto que tengamos en el sistema, en la página web del producto en cuestión. Estamos en el s. XXI y usamos Macs, así que no hay excusa para andarnos con cosas que recuerden a gnu info. Cualquier producto debería tener un website canónico.

brew install paquete

Este comando instalará el paquete, bajándose el código fuente si no está cacheado, y compilándolo. Del mismo modo,

brew remove paquete

lo eliminará del sistema. Si necesitamos saber qué fórmulas tenemos instaladas, pediremos un listado:

brew list

Si a este comando le añadimos además el nombre de una fórmula, lo que veremos son los ficheros instalados por esa fórmula.

Cuando queramos actualizar los paquetes, primero ejecutaremos

brew update

que actualizará brew y sus fórmulas, y luego podemos hacer algo como

brew install $(brew outdated)

para que nos instale las fórmulas nuevas de las que tengamos instaladas. Normalmente, al actualizar una fórmula nos instala la versión nueva pero no retira las antiguas, que siguen instaladas (aunque fuera del $PATH). Para limpiar estas versiones antiguas, el comando que necesitamos es

brew cleanup

Bueno, hasta aquí esta breve introducción. Hay unos cuantos comandos más, pero son menos frecuentemente utilizados, así que dad un vistazo a man brew para dar con ellos.

La conferencia se realiza el sábado 16 de Julio en el CINC Barcelona, manteniendo la linea argumental iniciado en la edición anterior. Mostraremos más temas de desarrollo de aplicaciones para iOS.

En esta segunda edición continuaremos desarrollando la App iniciado en la primera conferencia “Hello NSCoder I”. A parte del formato de ponencias de 90 y 45 minutos se expondrá un formato nuevo de micro sesiones de 15 minutos llamados “Recipes” en cuales se explica temas mas cortos y muy específicos.

Agenda:

9:00 – Geolocalización & MapKit (Alfonso @setfilesl / Guillem @gfernandezg / Andreas @aquarioverde)

10:30 – Pausa

10:45 – Introducción a Git & GitHub (Victor @jalencas)

11:30 – Debug y Analisis de Aplicaciones (Jose Juan @minyunmen)

12:15 – Pausa

12:30 – Solid (Pedro @pedromsantos)

12:45 – Mecadotecnia (Leo @Leo1098R)

13:00 – Lazy Loading (Ricardo @risalba)

13:15 – Pausa

13:30 – Bloack (Alfonso @setfilesl / Guillem @gfernandezg)

13:45 – Efecto Lupa (Ivan @ileider)

14:00 – Streaming Audio (Jose Juan @minyunmen)

Don’t miss it!!!!

Subscribe now:

http://hellonscoder2.eventbrite.com/

And see you soon!

Por cierto, para los que no sabeis porque nos llamamos NSCoders y los que dudáis de donde viene el NS:

NS == NEXT STEP == sistema operativo de los ordenadores NeXT, que tenia Objective-C como lenguaje de programación

Pues, solo querría aclararlo porque algunos me preguntaron hoy …