Tras hablar sobre varios temas, en la última @nscoder_mad acabamos hablando del famoso lenguaje AppleScript. Personalmente es un lenguaje que he intentado varias veces aprender, pero nunca acaba de gustarme. Una de las conclusiones a las que llegamos es que es un lenguaje para no programadores. Quizás uno de los aspectos que no me gusta del lenguaje es que no veo a primera vista los diferentes elementos que conforman el código escrito con otros lenguajes como por ejemplo las palabras reservadas o incluso las propias sentencias en si mismo.

Un ejemplo de Applescript podría ser algo así:

tell application "Finder"
	set theFolder to make new folder at desktop
end tell

Sin duda algo que no se puede negar es su “verbosidad”, cualquiera que lo lea, mas o menos sabe lo que hace este mini-script. Pero, desde mi punto de vista, aunque muy literario, no me resulta cómodo leer código escrito de esta manera.

Pese a que a priori, puede parecer una opción muy asequible para gente que no ha programado en otros lenguajes, lo cierto es que incluso para ellos, crear algo nuevo en Applescript no es tan sencillo, en el fondo es un lenguaje de programación, y no entiende cualquier frase inglesa que podamos escribir.

Sin duda uno de los grandes beneficios de Applescript es su integración dentro de OSX, y como es capaz de interactuar con el sistema y el resto de aplicaciones de una forma muy sencilla.

De hecho, @j4n0 me comentaba que el tenía un script para copiar al portapapeles la ruta del fichero seleccionado en la ventana del Finder, cosa que es bastante útil.

Según lo expuesto hasta ahora, nuestra situación es que pese a que Applescript no parece un lenguaje muy atractivo pero es una “joya” a la hora de interactuar con el sistema operativo.

Por suerte hay una alternativa, gracias al ScriptingBridge, y como hablamos aquí y aquí, podemos usar otros lenguajes de programación como Ruby o Python para acceder a los mismos recursos que Applescript.

Actualmente mi situación es, me gustaría aprender Applescript por curiosidad, pero ¿para qué?. Lo mismo se puede hacer con Ruby, y es un lenguaje que ya conozco

Continuando con el caso anterior, el código en Ruby para copiar al portapapeles el fichero seleccionado en el Finder sería algo como:

require 'osx/cocoa'
include OSX
OSX.require_framework 'ScriptingBridge'

finder = SBApplication.applicationWithBundleIdentifier_ "com.apple.finder"
fileURL = NSURL.URLWithString_ finder.selection.get[0].URL
system "echo #{fileURL.path} | pbcopy"

Seguramente el código en Applescript ocupa menos lineas, pero al menos para mi, la versión en Ruby es mucho mas clara.

Como breve resumen al código, con la función applicationWithBundleIdentifier_ obtenemos la referencia al objeto “Finder” y usando el comando de consola pbcopy introducimos los datos al clipboard.

Pese a que funciona sin problemas desde la linea de comandos, este script es sobre todo útil cuando lo tenemos en la propia ventana del finder, para ello necesitamos encapsular el script en un bundle de Aplicación que OSX sepa como ejecutar.

Para ello, y aunque podamos hacerlo a mano, existe una utilidad llamada Platypus que nos automatizará el proceso. Una vez que tengamos el bundle solo nos queda arrastrarlo a la barra superior del finder y usarlo siempre que queramos.

Seguramente en muchas ocasiones se nos habrá presentado la necesidad de mandar información desde nuestra aplicación al “exterior”. Para mandar esa información tenemos varias alternativas, sin duda una de las mas sencillas es utilizar los propios mecanismos del móvil para hacerlo. Estos mecanismos son básicamente dos, mandar un correo electrónico o mandar un mensaje corto.

iOS nos proporciona un framework para realizar esta tareas, el nombre es Message UI. Este framework, nos va a proporcionar ViewControllers que podremos invocar desde nuestra aplicación y de esta manera, enviar el mensaje de correo o SMS sin tener que abandonarla.

Junto con los ViewControllers, el framework proporciona dos protocolos que representan los delegados de dichos controladores, de tal manera que podemos recibir información de como ha sido el proceso de envío.

Las clases de los controladores son MFMailComposeViewController y MFMessageComposeViewController.

Antes de empezar a experimentar con las clases, es importante que añadamos el framework a nuestro proyecto, ya que por defecto no lo tendremos. Para ello lo hacemos desde la siguiente ventana de XCode.

Empezando por la del correo electrónico, la clase nos proporciona diversos métodos para prefijar los contenidos, como “setSubject:” “setToRecipients:” o “setMessageBody:isHTML:”. Pese a que al ser un viewcontroller cualquiera, podemos usar cualquier técnica para mostrarlo, se recomienda usar el mensaje “presentModalViewController:animated:” de UIViewController.

Es importante notar que una vez que el controlador esta en primer plano, nuestra aplicación no puede cambiar el contenido del correo. Esto es así para prevenir aplicaciones “maliciosas” que podrían mostrar una cosa y luego enviar otra.

De esta manera el código para mostrar la pantalla de envío de correo seria:

MFMailComposeViewController *mailcontroller = [[MFMailComposeViewController alloc] init];
[mailcontroller setSubject:subjectText.text];
[mailcontroller setMessageBody:bodyText.text isHTML:NO];
mailcontroller.mailComposeDelegate = self;
[self presentModalViewController:mailcontroller animated:YES];

Como vemos en el código, previamente tenemos que establecer una instancia como delegado del controlador, cuando el usuario interactue con el controlador, se nos enviara un mensaje del tipo: “mailComposeController:didFinishWithResult:error:”. Este paso es importante pues nosotros somos los encargados de ocultar el viewcontroller cuando el usuario haya acabado, y esto lo hacemos llamando a “dismissModalViewControllerAnimated:” en el código del delegado.

- (void)mailComposeController:(MFMailComposeViewController *)controller
          didFinishWithResult:(MFMailComposeResult)result
                        error:(NSError *)error
{
    [controller dismissModalViewControllerAnimated:YES];
}

El caso del controlador de mensajes cortos es muy similar al del correo. La clase es MFMessageComposeViewController, y las propiedades que controlan el contenido son “recipients” y “body”, de la misma manera el controlador se muestra con el mensaje “presetModalViewController:animated” y el delegado, en este caso una clase que implemente el protocolo “MFMessageComposeViewControllerDelegate” y el método “messageComposeViewController:didFinishWithResult:” deberá ocultar el controlador una vez que el mensaje haya sido enviado.

MFMessageComposeViewController *smscontroller = [[MFMessageComposeViewController alloc] init];
smscontroller.body = bodyText.text;
smscontroller.messageComposeDelegate = self;
[self presentModalViewController:smscontroller animated:YES];

...

- (void)messageComposeViewController:(MFMessageComposeViewController *)controller
                 didFinishWithResult:(MessageComposeResult)result
{
    [controller dismissModalViewControllerAnimated:YES];
}

Ambos controladores poseen un mensaje estático que nos permite comprobar la disponibilidad de estos métodos. Dichos mensajes son “canSendText” y “canSendMail”. Así si estamos en un iPod Touch sin posibilidad de enviar SMS, podemos comprobarlo antes de intentar utilizar esta funcionalidad.

Como veis, el mecanismo para realizar este tipo de tareas es bastante sencillo a la vez que útil.

Seguramente en muchas de nuestras aplicaciones de iOS hemos tenido que mostrar una tabla de datos con un montón de entradas. Desde el punto de vista del usuario, es bastante molesto tener que buscar el elemento que quiere entre todos los elementos.

Para mejorar la usabilidad, se plantean varias alternativas. Podemos separar los datos en varios niveles, de tal manera que dividamos los datos en varios bloques, sin embargo, esta solución tiene como inconveniente que obligamos a navegar por varias pantallas.

Concretamente en iOS tenemos varias alternativas para “ordenar” nuestros datos a nivel visual. Podemos crear listas por secciones e incluso incluir un indice para saltar entre los diferentes datos al mas puro estilo iTunes o la aplicación que muestra los Contactos.

Sin embargo, aunque ayuda, no acaba de solucionar el problema de tener que buscar la entrada que queremos en nuestra tabla.

Aquí es donde entra el campo de búsqueda que seguro habéis visto en numerosas aplicaciones de iOS como Facebook, Twitter o iTunes. En esta entrada vamos a ver como añadir una barra de búsqueda a nuestra aplicación.

Dentro del conjunto de controles estándar de iOS, tenemos la clase UISearchBar, que representa el cuadro de texto con esquinas redondeadas y la lupa a la que estamos acostumbrados. Sin embargo, este elemento es solo la parte gráfica del sistema de búsqueda. Además de esta clase, vamos a necesitar tratar con la clase UISearchDisplayController, que será la que enlazada a los ViewControllers habituales, nos van a proporcionar todo el sistema de búsqueda que hemos visto en las aplicaciones antes comentadas.

Esta instancia de UISearchDisplayController no vive sola, la mayoría de nuestras vistas, están gestionadas por una clase “Controller” que hereda de UIViewController, en esta clase esta definida una propiedad llamada searchDisplayController, a la que podemos asignar nuestra clase controladora del campo de búsqueda. Haciendo esto ganamos bastante funcionalidad.

Si hemos visto el funcionamiento de la barra de búsqueda, hemos visto como al tocar para introducir texto, esta barra se coloca en la parte superior de forma animada, sombreando además la vista entera, además, en algunos casos salen unos botones debajo de la barra de búsqueda, que indican donde se esta realizando la búsqueda. Pues bien, todo este comportamiento esta “de propina” si asignamos la propiedad del ViewController a nuestro SearchController.

Para llevar esto a la práctica, suponiendo que tenemos un proyecto con un NavigationController, tenemos que ir a la vista que se carga como contenido del navigation controller y añadir el SearchViewController.

Automáticamente XCode asigna los outlets, pero para saber como funciona, no es mala idea cotillearlos un poco. XCode establece el outlet del UINavigationController llamado searchDisplayController al SearchDisplayController que acabamos de añadir a la vista. Normalmente el NavigationController será el File’s Owner del fichero, y así lo vemos en la captura de un poco más arriba.

Hasta ahora, solo hemos hablado de la parte visual, pero después de crear el SearchDisplayController y asignarlo a la propiedad en el ViewController, si introducimos texto, vemos como no pasa nada. El siguiente paso consiste en decir como vamos a mostrar los datos de la búsqueda.

Para mostrar los datos, una de nuestras clases tiene que implementar varios protocolos habituales de una UITableView, como son UITableViewDataSource y UITableViewDelegate. Como veis, al fin y al cabo el proceso se reduce a mostrar una vista reducida de nuestros datos, filtrada por la condición de búsqueda.

Como vemos en la captura anterior, los outlets del SearchDisplay controller respecto al origen de los datos, esta establecidos al File’s Owner.

En cuanto a la estrategia de implementación, se pueden seguir varias aproximaciones. Por un lado se puede hacer que la misma clase sea DataSource de ambas tablas, es decir, la tabla con todos los datos y la tabla con los datos de la búsqueda, sin embargo esta solución tiene el problema que los mismos métodos tienen que devolver cosas diferentes. Personalmente no me gusta nada esta solución.

Por otro lado, se pueden tener dos clases diferentes, sin embargo hay que tener en cuenta que el modelo de datos a la que acceden ambas clases, es compartido, ya que la búsqueda se realiza sobre los datos que esta mostrando el ViewController de turno.

Estas dos alternativas están pensadas a cuando la búsqueda se realiza sobre una tabla de datos, sin embargo, no tiene por que ser siempre así, la búsqueda podemos hacerla sobre cualquier vista que queramos. En tal caso no habrá mucho problema en unir en la misma clase que gestiona la vista, los métodos de gestión de la tabla de los resultados de la búsqueda.

A continuación os pongo el código de una implementación, el código no pretende ser eficiente, si no mostrar el funcionamiento

- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText
{
    [filteredData release];
    filteredData = [[NSMutableArray alloc] init];
    for ( NSString* name in tableData )
    {
        if ([[name lowercaseString] rangeOfString:[searchText lowercaseString]].location != NSNotFound )
            [filteredData addObject:name];
    }
}

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

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Cell"];
    if ( cell == nil )
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell"];
    
    cell.textLabel.text = [filteredData objectAtIndex:indexPath.row];
    return cell;
}

Ya que mucha parte del funcionamiento, esta embebido en los ficheros de Interface Builder, he subido el proyecto de prueba a github, por si alguien quiere echarle un ojo.

Seguro que en múltiples ocasiones al entrar en la configuración de nuestro teléfono hemos visto listadas un montón de aplicaciones en la parte inferior de la pantalla. Esto es así porque a la hora de proporcionar un punto para configurar nuestra aplicación tenemos dos opciones, una es meterla dentro de la propia aplicación y la otra es integrarla en el menú de configuración del sistema.

Sin duda la opción de hacerlo nosotros en la aplicación puede parecer a priori la mas fácil, pues no tenemos que aprender una nueva forma de hacer las cosas, pero como veremos en esta entrada, integrarse en el menú global de configuración es sencillo y de esta manera nos quitaremos el gestionar una pantalla mas dentro de nuestro programa.

La única limitación que se nos impone es que las opciones que queramos configurar se adapten a los controles que el sistema nos ofrece. Aunque sinceramente, la mayoría de las opciones suelen ser cajas de texto, sliders o booleanos de ON/OFF.

El primer paso para añadir nuestro programa al menú de configuración, es incorporar a nuestro proyecto un bundle de tipo “settings”, dicho bundle va a tener uno o varios ficheros de tipo plist donde vamos a especificar los elementos de configuración de nuestra aplicación.

Normalmente la opción mas sencilla será usar el editor de ficheros plist integrado que viene en el xcode, pues en el caso de los settings, automáticamente nos detectará el tipo de elemento y nos mostrará las opciones disponibles.

Aún así, si nos gusta mirar el código de las cosas como seguro que es el caso, podemos ver el XML que se genera y tocar ahí mismo los valores de configuración de cada componente. Como podemos ver en la siguiente captura.

Para mas información sobre las propiedades de cada elemento, podemos visitar la documentación oficial de Apple, donde se describen todas posibilidades a la hora de describir la interfaz de configuración.

Una de las cosas mas interesantes es que no estamos limitados a una sola pantalla de configuración, podemos añadir una estructura jerárquica de pantallas de configuración.

Para ello, uno de los elementos del fichero plist, es “PSGroupSpecifier”, que nos permite especificar otro fichero plist que será el que contenga la pantalla en el siguiente nivel de jerarquía, así podemos crear la configuración tan compleja como la necesitemos

Una vez que tenemos nuestro bundle listo, el siguiente paso es recuperar esos valores en nuestro código. Una vez mas, este proceso es bastante sencillo gracias a la clase NSUserDefaults. Este método tiene los típicos getters y setters para obtener y configurar los valores de la configuración, así por ejemplo el código para recuperar el valor del campo de configuración que describimos en el plist seria:

NSUserDefaults *settings = [NSUserDefaults standardUserDefaults];
NSLog(@"Players: %@",[settings integerForKey:@"players"]];
NSLog(@"Active Push Notifications: %@", [settings boolForKey:@"enable_push"]

Como hemos visto, integrar nuestra aplicación en el menú global de configuración es tremendamente sencillo, y gracias a su potencia a la hora de describir nuestros parámetros de configuración, nos va a ahorrar el hacer dichas pantallas dentro de nuestra aplicación.

La orientación a objetos de los lenguajes actuales hace que nuestros programas estén hechos de clases, clases que se comunican entre ellas mediante mensajes. Estos mensajes según el lenguaje se manifiestan en llamadas a métodos y en otros casos, como es el de ObjetiveC, como realmente mensajes.

Seguramente en muchas ocasiones, nos hemos encontrado con el caso de que queremos recibir un mensaje, pero el objeto que lo envía, no necesariamente tiene que tener una referencia nuestra, o visto desde el otro lado, queremos enviar un mensaje y no sabemos quien estaría interesado en recibirlo, e incluso, ese alguien no guarda ninguna relación con nuestra clase, por lo que no seria correcto que tuviera una instancia nuestra.

Pongamos un ejemplo, tenemos una clase que se encarga de gestionar una comunicación, y por otro lado, en la parte de la vista que muestra la información que viene de esa comunicación, tenemos una tabla que muestra datos. Cada vez que se recibe un mensaje nuevo, la tabla tiene que repintar los datos.

Podríamos tener una instancia de la clase de comunicación en nuestra vista, pero estaría ligando dos clases que excepto por ese detalle, no tienen nada mas en común.

Una solución seria utilizar una capa intermedia, que podría ser el Modelo que propagara las notificaciones de inserción de datos a todos los niveles. Esta solución sería la que actualmente implementaríamos en muchos sistemas, pero requiere meter eventos y orientar nuestro diseño hacia este tipo de dependencias entre las clases.

La solución a la que se puede llegar con las notificaciones es desacoplar totalmente todas las clases del ejemplo. Usando este modelo, la clase de la vista se registraría en la cola de notificaciones diciendo que le interesa escuchar cuando llega un nuevo mensaje. Por su parte la clase que se encarga de controlar la comunicación, “posteará” un mensaje cuando reciba un mensaje.

De esta forma, todos los elementos están completamente desacoplados, y en el fondo, nadie necesita tener una instancia de otras clases. Incluso, si en algún momento una de ellas dejaría de existir, las otras clases podrían seguir funcionando sin problemas.

Después de todo este rollo , vamos a ver como es de fácil hacerlo en Cocoa y la cantidad de ventajas que aporta este enfoque en el diseño de nuestras clases.

En Cocoa y Cocoa Touch, existe una clase llamada NSNotificationCenter, dicha clase se va a encargar de gestionar un “centro” de notificaciones que es accesible desde todas las clases de nuestro programa, e incluso desde clases de diferentes programas.

El runtime creará el centro de notificaciones por nosotros, y por lo tanto accederemos a la clase usando un método estático.

Básicamente hay dos formas de interacción con el centro de notificaciones, por un lado, los “observers” se añaden como receptores de la notificación usando un nombre determinado. Por otro lado, los notificadores, notifican a los observadores usando ese nombre como clave.

Hay varios métodos para registrarse como observador, por ejemplo el método, addObserver:selector:name:object:, especifica la instancia, el selector de la clase que se ejecutará, el nombre de la notificación y opcionalmente la instancia que será capaz de enviar la notificación, si este parametro lo dejamos en “nil” no filtraremos por el objeto que envia la notificación. El otro método para añadirse como observador es: addObserverForName:object:queue:usingBlock:, donde en lugar de indicar un selector, se pasa un bloque de código que se ejecutará cuando se reciba una notificación. En este último método vemos el parámetro “queue”, que trataremos mas adelante.

Por otro lado, para “postear” una notificación, podemos usar dos métodos, postNotificationName:object:, donde indicamos el nombre de la notificación que estamos “levantando”, o bien, podemos usar el método, postNotification:, donde agrupamos la misma información en un objeto de tipo NSNotification.

Finalmente, los observers deben quitarse del centro de notificaciones cuando ya no quieren recibir más. Para ello se puede usar el método removeObserver: o removeObserver:name:object:.

Vamos a ver un ejemplo completo en acción.

/* Código de un UIViewController que ademas es un UITableViewDataSource */

- (id) viewDidLoad
{
  // ...
  NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
  [center addObserver:self selector:@selector(logOn:) name:@"logged on" object:nil];

  // ...
}

- (void) logOn: (NSNotification*) theNotification
{
    // La clase encargada de la comunicación nos ha notificado de que
    // se ha producido la entrada al sistema
}

- (void)viewDidUnload
{
  NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
  [center removeObserver:self];
}

/* Codigo de la clase que se encarga de gestionar la comunicación */

// ...
  NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
  [center postNotificationName:@"loggedon" object:nil];
  // En este momento ya se habra ejecutado el codigo del ViewController que estaba
  // apuntado para recibir notificaciones.
// ...

Una duda que nos puede surgir es, como se ejecuta el código asociado a la notificación cuando el notificador postea un mensaje.

Realmente el código se ejecuta de forma síncrona y en el contexto de la instancia que se pasa cuando un observador se registra en el NotificationCenter, de esta manera, cuando el notificador postea el mensaje usando una de las variaciones del postNotification, se bloquea hasta que todos los métodos de los obsevers se ejecutan. Sin embargo, por si queda alguna duda, el método addObserver no bloque a la clase que se llama, el único momento de sincronismo se produce por parte de la clase que envía la notificacion.

Para que esta ejecución sea asíncrona, debemos usar colas de notificación, y si volvemos atrás, el parámetro queue del método postNotification es el que gestiona este detalle.

Así que os dejo con la intriga , y para dos futuros posts hablaremos de las notificaciones asíncronas usando colas de notificaciones y como enviar notificaciones entre procesos usando el NSDistributedNotificationCenter.

Seguro que en muchas ocasiones hemos leido el nombre de Core Data, y puede que en esas ocasiones nos haya parecido que seria una librería compleja de utilizar.

Si hay algo constante en la gran mayoría de las aplicaciones es, su necesidad de guardar datos en el medio de almacenamiento que el dispositivo ofrezca. Esta necesidad es la que vamos a poder salvar con Core Data, y de una manera bastante sencilla.

Concretamente, en esta entrada vamos a hablar de la versión para iPhone de Core Data, que en sus funcionalidades básicas, poco tiene que envidiar a su hermana mayor de OS X.

A diferencia de algunos tutoriales que andan por ahí, que empiezan desde una aplicación vacía, aquí vamos a ver como incorporar Core Data a nuestra aplicación ya empezada.

Personalmente, Core Data me ha sorprendido, pensaba que sería mucho mas compleja y complicada de incorporar a una aplicación, pero siguiendo la linea de muchas cosas de Apple, la librería es muy sencilla de utilizar. Pero, no adelantemos acontecimientos

El primer paso es entender como funciona Core Data. Para ello, nos vamos a ayudar del siguiente gráfico:

Como vemos, hay tres niveles, arriba del todo están nuestros objetos, que o bien son instancias de NSManagedObject, o bien heredan de él. Como en la vida real , nuestros objetos viven en un contexto, aquí esta representado por el NSManagedObjectContext. Este contexto va a ser el que alojara nuestros objetos dotándoles de los mecanismos de persistencia que Core Data proporciona. Por ejemplo, si queremos crear un objeto, en lugar de construirlo por nuestra cuenta, le pediremos al contexto que nos genere uno. Y de la misma manera cuando queramos guardar el objeto a disco, le diremos al contexto que lo guarde.

En la parte mas baja, se encuentra el Persistent Store Coordinator, que, como su nombre indica, es el encargado de coordinar la escritura en el almacenamiento. Realmente nosotros, salvo para indicarle donde esta el almacenamiento, no vamos a trabajar mucho mas con él.

Finalmente, el ultimo elemento del gráfico es el modelo que describe como son nuestros objetos. Eso es lo que se conoce como el Managed Object Model, y que esta representado por el fichero xcdatamodeld y que podremos editar de una forma bastante cómoda usando xcode.

Una vez visto (de forma breve y resumida) la arquitectura de Core Data, vamos a ponernos manos a la obra y vamos a dotar de persistencia a nuestra aplicación.

Para ello, el primer paso es incluir dentro de nuestros frameworks, el de Core Data.

El siguiente paso es crear el modelo de los objetos que vamos a utilizar, para ello, añadimos un nuevo fichero de tipo Core Data Model a nuestro proyecto, lo que creara un fichero de tipo xcdatamodeld.

Si abrimos dicho fichero, xcode nos mostrará un cómodo editor para crear nuestras entidades, por ejemplo vamos a crear una clase que represente a un coche.

Ahora vamos al código de verdad. Para guardar objetos en el contexto, necesitamos acceder al propio contexto, y lo vamos a necesitar desde múltiples sitios, por ello, lo mejor es crearnos una clase que sea accesible desde todos los sitios y que “guarde” la instancia del contexto. Cogiendo el código que Apple pone de ejemplo cuando creamos una aplicación que use code data, dicha clase sería algo como:

@interface CoreDataManager : NSObject {
    
}

@property (nonatomic, retain, readonly) NSManagedObjectContext *managedObjectContext;
@property (nonatomic, retain, readonly) NSManagedObjectModel *managedObjectModel;
@property (nonatomic, retain, readonly) NSPersistentStoreCoordinator *persistentStoreCoordinator;

- (void)saveContext;
- (NSURL *)applicationDocumentsDirectory;

+ (CoreDataManager*) sharedInstance;

@end

@implementation CoreDataManager

@synthesize managedObjectContext=__managedObjectContext;
@synthesize managedObjectModel=__managedObjectModel;
@synthesize persistentStoreCoordinator=__persistentStoreCoordinator;

static CoreDataManager* _sharedInstance;

+ (CoreDataManager*) sharedInstance
{
    if ( ! _sharedInstance )
        _sharedInstance = [[CoreDataManager alloc] init];
    
    return _sharedInstance;
}

- (id)init 
{
    self = [super init];
    if (self) {
        _sharedInstance = self;
    }
    return self;
}

- (void) dealloc 
{
    [__managedObjectContext release];
    [__managedObjectModel release];
    [__persistentStoreCoordinator release];
    [super dealloc];
}
- (void)saveContext
{
    NSError *error = nil;
    NSManagedObjectContext *managedObjectContext = self.managedObjectContext;
    if (managedObjectContext != nil)
    {
        if ([managedObjectContext hasChanges] && ![managedObjectContext save:&error])
        {
            NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
            abort();
        } 
    }
}

#pragma mark - Core Data stack

- (NSManagedObjectContext *)managedObjectContext
{
    if (__managedObjectContext != nil)
    {
        return __managedObjectContext;
    }
    
    NSPersistentStoreCoordinator *coordinator = [self persistentStoreCoordinator];
    if (coordinator != nil)
    {
        __managedObjectContext = [[NSManagedObjectContext alloc] init];
        [__managedObjectContext setPersistentStoreCoordinator:coordinator];
    }
    return __managedObjectContext;
}

- (NSManagedObjectModel *)managedObjectModel
{
    if (__managedObjectModel != nil)
    {
        return __managedObjectModel;
    }
    NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@"PruebaCoreData" withExtension:@"momd"];
    __managedObjectModel = [[NSManagedObjectModel alloc] initWithContentsOfURL:modelURL];    
    return __managedObjectModel;
}

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator
{
    if (__persistentStoreCoordinator != nil)
    {
        return __persistentStoreCoordinator;
    }
    
    NSURL *storeURL = [[self applicationDocumentsDirectory] URLByAppendingPathComponent:@"PruebaCoreData.sqlite"];
    
    NSError *error = nil;
    __persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[self managedObjectModel]];
    if (![__persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeURL options:nil error:&error])
    {
        NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
        abort();
    }    
    
    return __persistentStoreCoordinator;
}

#pragma mark - Application's Documents directory
- (NSURL *)applicationDocumentsDirectory
{
    return [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];
}
@end

Una vez que el contexto es accesible desde otros puntos del nuestro programa, el siguiente paso es guardar un objeto en el almacenamiento, para ello le pedimos al contexto que nos de una nueva instancia de la clase, la rellenamos con los datos y le decimos al contexto que la guarde. El código que lo hace sería así:

NSManagedObject* myCoche = [NSEntityDescription insertNewObjectForEntityForName:@"Coche" inManagedObjectContext:[CoreDataManager sharedInstance].managedObjectContext];
[myCoche setValue:@"Ford" forKey:@"Fabricante"];
[myCoche setValue:@"Crown Victoria" forKey:@"Modelo"];
[myCoche setValue:[NSNumber numberWithInt:12000] forKey:@"Precio"];
[[CoreDataManager sharedInstance] saveContext];

Como veis, el funcionamiento no podía ser mas fácil. Con muy poco código, tenemos persistido nuestro objeto en un almacén de datos.

Finalmente, el último paso seria recuperar los objetos que hay en el almacén, para ello necesitamos una nueva clase, llamada NSFetchRequest. En esta entrada nos vamos a quedar en un nivel básico, ya que el propósito es ver que componentes entran en juego cuando usamos Core Data, por lo que vamos únicamente a recuperar todos nuestros objetos, sin poner ningún tipo de filtro.

Es evidente que vamos a necesitar un mejor control de como recuperamos nuestros objetos, para ello lo mejor es acudir directamente a la documentación sobre esta clase y quizás a una futura entrada que explique en detalle como se recuperan objetos usando esta clase

Volviendo a la recuperación de datos, el proceso consta de crear el FetchRequest, especificar el tipo de entidad que vamos a recuperar, en nuestro caso, un Coche, y ejecutar el request, obteniendo así un array con los objetos que estaban en el almacén.

NSFetchRequest *req = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Coche" inManagedObjectContext:[CoreDataManager sharedInstance].managedObjectContext];
    [req setEntity:entity];
    NSError *error;
    NSArray *objects = [[CoreDataManager sharedInstance].managedObjectContext executeFetchRequest:req error:&error];

Como se suele decir, lo difícil es empezar, y espero que con esta entrada ese paso este dado. Queda mucho Core Data por explorar, cosas como las relaciones entre entidades, o los filtros en los request son cosas muy comunes y que vamos a necesitar usar. Sin duda, son materia para futuras entradas

Sin duda una de las cosas que siempre me ha gustado tener a mano es una manera de probar código sin tener que crear todo un proyecto para ello. Hace mucho tiempo, cuando usaba Java como mi principal lenguaje de programación, usaba Beanshell, que ademas de ser un lenguaje de scripting ofrece una consola que interpreta código en java en tiempo real.

Por aquel tiempo, si quería probar, por ejemplo, como sacar una subcadena a partir de un carácter dado, podía ir probando con las diferentes combinaciones en la consola de Beanshell. La alternativa era construirse todo un proyecto solo para probar como deberías hacer el substring correcto, proyecto que había que compilar y ejecutar para ver los resultados. Sin duda el hecho de usar una consola que te daba los resultados inmediatos era una gran ventaja.

Mas adelante, y con algunas aventuras en python o ruby, la existencia de la consola para probar código venia de serie con la plataforma. Así si queremos probar un pequeño fragmento de código Ruby, podemos arrancar el irb y escribirlo tal cual.

Hoy en día, en mis aventuras por Objetive-C, echaba de menos esta funcionalidad. Esta claro que al ser Objective-C un lenguaje compilado, a priori es complicado tener un programa que haga esto, pero es aquí donde encaja esa maravilla llamada MacRuby

Dado a que, usando MacRuby, podemos acceder a todas las clases definidas en los frameworks de OSX sin importar en que lenguaje estén definidas, vamos a poder usar el irb para poder probar esas clases de Cocoa que usamos habitualmente.

Vamos a ver un ejemplo:

Supongamos que tenemos una cadena de la forma “clave=valor;clave2=valor2″” y queremos transformarla en un diccionario que almacene esta información.

Para ello, necesitamos manipular la clase NSString, sin duda una alternativa sería escribir el código (siempre después de los test, claro ), e ir probando. Pero siempre surgen algunas dudas, como por ejemplo, el IndexOf de NSString, ¿esta basado en 0?, si hago un substring con inicio en la posición 3, ¿incluye el tercer carácter?

Estas dudas, harán posiblemente que el código que escribamos la primera vez, falle.

La alternativa es arrancar macirb, y jugar directamente con la clase NSString. Por ejemplo si ejecutamos lo siguiente:

irb(main):010:0> "clave=valor;clave2=valor2".componentsSeparatedByString(";")
=> ["clave=valor", "clave2=valor2"]

Veremos que el mensaje “componentsSeparatedByString”, funciona como esperábamos. Pero no solo eso, vemos que también podíamos aplicar lo mismo a cada elemento para obtener cada clave y cada valor:

irb(main):012:0> "clave=valor;clave2=valor2".componentsSeparatedByString(";").each { |x| p x.componentsSeparatedByString("=") }
["clave", "valor"]
["clave2", "valor2"]
=> ["clave=valor", "clave2=valor2"]

Como vemos, la comodidad que ofrece el probar código solo con teclearlo directamente en la consola es tremendamente util para reducir muchos ciclos de compilar (o ejecutar test) y ver como vuelve a fallar.

La “magia” de MacRuby no acaba aquí, como hemos dicho antes, podemos llamar a cualquier clase de Cocoa, por lo que si probamos el siguiente código:

irb(main):006:0> framework 'Cocoa'
irb(main):007:0> sp = NSSpeechSynthesizer.alloc.initWithVoice nil
=> #<NSSpeechSynthesizer:0x2005293e0>
irb(main):008:0> sp.startSpeakingString "hello from macruby. This is so cool!"
=> true

Nuestro mac empezará a hablar.

Como veis, la única regla a seguir es en vez de utilizar la sintaxis típica de objetive c para enviar mensajes, debemos utilizar la notación habitual con el “.”. Aunque si esto nos incomoda, siempre podemos seguir usando mensajes gracias al método “send” de Ruby, y de esta manera ejecutar el anterior código como:

irb(main):010:0> sp.send :startSpeakingString, "hello from macruby. This is so cool!"

La interoperabilidad Ruby Cocoa abre todo un mundo de posibilidades, ¿Alguien ha dicho algo sobre RSpec para probar clases hechas en ObjectiveC?. En cualquier caso, son unos interesantes temas para otras entradas del blog.

Uno de los aspectos que pasan mas desapercibidos en OSX son los “Servicios”. Seguramente por el nombre pensareis que es un programa que se ejecuta de fondo en nuestro ordenador.

Si bien ese pensamiento no es del todo incorrecto, los servicios en OSX es algo mas. Con servicios me refiero a los elementos del menú que sale cuando pinchamos sobre el nombre del programa activo en la barra de menús.

La localización de dicho menú ha ido cambiando con el tiempo, en versiones anteriores ocupaban una posición mas destacada, pero poco a poco han ido pasando a un plano mas “oculto”.

Sin embargo, la posición de esta funcionalidad no nos tiene que despistar, ya que la utilidad que prestan es bastante buena.

Para comprobar su funcionamiento, solo tenemos que seleccionar algo de texto, e ir al menú Servicios. Desde dicho menú se nos dará la opción de hacer diversas cosas, como por ejemplo, crear una nota. Además no solo los servicios están accesibles desde este menú, si no que podremos acceder usando atajos de teclado. Por ejemplo, si pulsamos SHIFT+ ⌘+Y, crearemos la nota al instante.

Una de las grandes ventajas de los servicios es que están disponibles para todo el sistema, esto es, independientemente de la aplicación donde seleccionemos el texto, si pulsamos el atajo de teclado, crearemos una nota con el texto seleccionado.

Como podemos leer en la propia documentación de Apple, posibles servicios serian, reconocedores de texto en una imagen, cifrado de texto o incluso, aunque no venga en la guía de Apple, sería útil un servicio para insertar una cita de Chuck Norris en el documento actual

Desde el punto de vista de la programación, se pueden distinguir dos elementos, por un lado el propio servicio, y por otro la aplicación que interactua con él. La pieza que intercomunica ambas partes es el clipboard. Cuando pinchamos en un servicio, la aplicación pone los datos necesarios en el clipboard, e invoca al servicio. El servicio por su parte, recoge dichos datos, los procesa y los vuelve a poner en el clipboard. Finalmente, la aplicación recoge lo que haya en el clipboard y hace lo que considere oportuno con dichos datos.

En la entrada vamos a crear un servicio, que seleccionado texto, lo consulte en la wikipedia usando Safari.

El código que atiende al servicio, es sencillo, a grandes rasgos, los pasos que hay que dar son por un lado, crear el método al que se llamará, y por otro, registrar el servicio en el sistema.

Desafortunadamente, xcode no tiene plantillas para crear los servicios, por lo que tendremos que empezar desde un proyecto vacío que cree un ejecutable.

Una vez que tenemos el proyecto creado en el XCode, debemos añadir (si no lo estaba antes), el framework de Cocoa y Foundation, y añadir la clase que implementará el método que atiende el servicio.

En nuestro caso, dicha clase es WikipediaService

==== WikipediaService.h

#import <Cocoa/Cocoa.h>


@interface WikipediaService : NSObject {

}

- (void) wikipediaSearch: (NSPasteboard*) pboard 
				userData:(NSString*) theUserData 
				   error:(NSString**) theError;

@end

==== WikipediaService.m

@implementation WikipediaService

- (void) wikipediaSearch: (NSPasteboard*) pboard userData:(NSString*) theUserData error:(NSString**) theError
{
	// Test for strings on the pasteboard.
	NSArray *classes = [NSArray arrayWithObject:[NSString class]];
	NSDictionary *options = [NSDictionary dictionary];
	
	if (![pboard canReadObjectForClasses:classes options:options]) {
		*theError = NSLocalizedString(@"Error recuperando datos del pboard", 
									  @"pboard couldn't give string.");
		return;
	}
	
	// Get and encrypt the string.
	NSString *pboardString = [pboard stringForType:NSPasteboardTypeString];
	NSString *wikipediaString = [NSString stringWithFormat:@"http://en.wikipedia.org/wiki/%@", pboardString];
	NSURL *url = [[NSURL alloc] initWithString: wikipediaString];
	[[NSWorkspace sharedWorkspace] openURL:url];
	
	[pboard clearContents];
}

@end

Como vemos, el clipboard es la parte que comunica ambos procesos. Con el mensaje canReadObjectForClasses primero comprobamos si el clipboard contiene datos de tipo cadena, y luego con el mensaje stringForType del “pasteboard” obtenemos dicha cadena.

Por otro lado, en nuestro punto de entrada de la aplicación, debemos situar el código que registra el servicio en el sistema.

int main(int argc, char *argv[])
{

	NSRegisterServicesProvider([WikipediaService new], @"WikipediaService");
	NSUpdateDynamicServices();
	[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
	return 0;
}

Antes de ejecutar y probar nuestro servicio, nos queda una parte muy importante. En el fichero plist de la aplicación, debemos indicar los datos referentes al servicio. Que indicará al sistema como llamar y como mostrar la información asociada.

	<key>NSServices</key>
	<array>
		<dict>
			<key>NSMenuItem</key>
			<dict>
				<key>default</key>
				<string>Wikipedia Search</string>
			</dict>
			
			<key>NSKeyEquivalent</key>
            <dict>
                <key>default</key>
                <string>R</string>
            </dict>
			
			<key>NSMessage</key>
			<string>wikipediaSearch</string>
			
			<key>NSPortName</key>
			<string>WikipediaService</string>
			
			<key>NSSendTypes</key>
			<array>
				<string>NSStringPboardType</string>
				<string>NSPasteboardTypeString</string>
			</array>			
		</dict>
	</array>

Si os fijáis, en el campo, NSKeyEquivalent, podemos asignar una tecla, que sumada a Command, sera el shortcut para llamar a nuestro servicio. Si dicha letra esta en mayúsculas, ademas necesitaremos pulsar Shift.

Con todo ya terminado, solo nos queda instalarlo, para ello debemos copiar el “Bundle” que ha generado nuestro proyecto en XCode a ~/Library/Services. Para que el servicio sea reconocido, debemos cerrar sesion y volverla a inciar, pero existe una forma manual para forzar al sistema para que reconstruya el indice de servicios.

Esto es ejecutando el siguiente comando: /System/Library/CoreServices/pbs

Una vez que tenemos nuestro servicio instalado, solo tenemos que seleccionar cualquier texto para buscarlo en la wikipedia.

Recientemente me surgió la necesidad de controlar remotamente un explorador web en Windows. En el sistema operativo de Microsoft, gracias a los objetos COM, es posible “instanciar” un objeto InternetExplorer y controlarlo desde código fuente. Gracias a .NET y la Interoperabilidad con los objetos COM, la tarea inicialmente no parece ser para nada complicada, aunque como la compañía de Redmond nos tiene acostumbrados, lidiar con los detalles será una tarea que nos llevará bastante tiempo.

En OSX por su parte este objetivo también esta cubierto, y como pasa habitualmente, de una forma bastante más elegante .

La idea es poder controlar, y crear instancias de una aplicación que esta ejecutandose, o que vamos a iniciar. Para ello, como requisito imprescindible, la aplicación debe estar preparada para ser manejada.

El componente clave para que todo esto se pueda realizar son los denominados “Apple Event”, que son paquetes de información que se envían en forma de mensaje entre las diferente aplicaciones que se están ejecutando en el Sistema Operativo.

Por ejemplo, si queremos que el Safari en ejecución navegue a una URL, y eso lo queremos hacer desde nuestra aplicación, deberemos enviar un Apple Event que contenga los datos necesarios para llevar a cabo esa acción.

Originalmente, solo era posible enviar eventos usando AppleScript, de hecho, el lenguaje se creo alrededor de dichos eventos. Pero hoy en día se puede utilizar multitud de lenguajes para enviar “Apple Events” como Python, C#, Ruby o Javascript.

Lo que hace posible esta interoperabilidad de lenguajes es lo que se conoce como el Scripting Bridge, como ya hablamos en el blog cuando queríamos usar Python para controlar el iTunes.

A diferencia de la entrada anterior, en esta entrada, vamos a usar Objecitve-C para controlar el Navegador Web, dado que ObjC es un lenguaje compilado, necesitamos tener una referencia de lo que podemos hacer con el “objeto” Safari, de tal manera que podamos compilar nuestro código.

Para ello usamos el comando sdp, que generará un fichero .h y que usaremos para compilar nuestro código. La entrada del comando sdp son los ficheros .sdef, que contienen, en forma de XML, una descripción sobre lo que se puede hacer con el objeto en cuestión.

A nivel de controlar el Navegador, una de las cosas mas utiles es que podemos ejecutar código javascript, con lo que tenemos acceso a todo el documento web que estamos visualizando.

A continuación os dejo un fragmento de código que navega a google, realiza una busqueda usando javascript y muestra el numero de resultados encontrados.

SafariApplication* safari = [SBApplication 
  applicationWithBundleIdentifier:@"com.apple.Safari"];
	
SBElementArray* windows = [safari windows];
SafariTab* currentTab = [[windows objectAtIndex: 0] currentTab];
	
[currentTab setURL:@"http://www.google.com"];
[safari doJavaScript: 
 @"document.getElementsByName('q')[0].value = 'Safari'" 
				  in:currentTab];
[safari doJavaScript: @"document.forms[0].submit()" 
				  in: currentTab];
id result = [safari 
   doJavaScript:@"document.getElementById('resultStats').firstChild.data"
           in:currentTab];
NSLog(@"Results: %@", (NSString*)result);

Un uso en el que esta técnica es útil es cuando queremos hacer pruebas automatizadas de alguna web que estemos realizando. Aunque para estas tareas existe selenium, que si utilizamos firefox, seguramente cubra nuestras necesidades.

Desde hace algún tiempo, llevo investigando el mundo de la programación funcional. Después de probar varios lenguajes como F#, o Clojure, finalmente me decanté por Erlang.

La verdad es que estoy pasandomelo bien recordando los viejos tiempos de Lisp o Prolog , y sobre todo aprendiendo una forma diferente de afrontar los problemas.

Para el aprendizaje, mi libro de cabecera es Programming Erlang de la editorial Pragmatic Bookshelf. Libro que me esta gustando bastante, ya que asume que no tienes ni idea de programación funcional, como era mi caso.

Quizás para otro post os pueda contar algo de los beneficios que tiene la programación funcional, como por ejemplo, lo bien que escalan en entornos multiprocesador y lo robustos que son para entornos multihilo, gracias a la eliminación de los “side-effects”.

En dicho libro se plantea un ejercio en el que se pide que se cree un “anillo” de M procesos, de tal manera que enviando un mensaje a uno de esos procesos, dicho mensaje circule por el anillo N veces.

Una vez que se tiene la estructura, se pide que se mida el tiempo que tarda en circular los M*N mensajes, se compare con lo mismo hecho en otro lenguaje de programación (preferiblemente no funcional) y después que se publique en un blog.

Así que obediente de mi, aqui os dejo la primera parte, el ejercicio hecho en Erlang. Para otra entrada dejo la comparación con lo mismo hecho en otro lenguaje

-module(ring).
-export([ringtest/2, ringNode/1]).

ringNode(PPid) ->
	receive
		{exit} ->
			PPid!{exit},
			true;
		{0} ->
			PPid!{exit},
			true;
		{N} ->
			PPid!{(N-1)},
			ringNode(PPid)
	end.

ringtest(N, M) ->
	ringtest(N-2, self(), N*(M-1)).

ringtest(0, ThisPid, M) ->
	Pid = spawn(ring, ringNode, [ThisPid]),
	Pid!{M},
	ringNode(Pid);
ringtest(N, ThisPid, M) ->
	Pid = spawn(ring, ringNode, [ThisPid]),
	ringtest(N-1, Pid, M).

Analizando los tiempos (que están en microsegundos), lo cierto es que erlang es bastante rápido, tanto en crear procesos como en enviar mensajes entre ellos. El ordenador que ejecuto el programa era un ATOM D525 de 1.8Ghz y en crear 5000 procesos, y enviar el mensaje 100 veces alrededor del anillo, sólo tardó 1,2 segundos. Sin duda, una cifra bastante interesante.

Despueés de ver estos números, esta claro que no es casulidad que sea una de las plataformas preferidas a la hora de desarrollar aplicaciones que se muevan en estos tipos de entornos.

No soy ningun experto de Erlang, de hecho aun estoy aprendiendo, así que alguien lo lee y tiene algún comentario, serán bienvenidos!