Copiar la ruta del fichero seleccionado en Finder usando Ruby

septiembre 11, 2011

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.


Mensajes entre clases usando NSNotificationCenter

abril 3, 2011

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 :D, y para dos futuros posts hablaremos de las notificaciones asíncronas usando colas de notificaciones y como enviar notificaciones entre procesos usando el NSDistributedNotificationCenter.


Desmitificando Core Data para iOS

marzo 6, 2011

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 🙂


Probando clases ObjetiveC usando MacRuby

febrero 12, 2011

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.


Construyendo un Servicio en OSX

enero 16, 2011

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.


Manejando Safari desde Objetive-C

enero 2, 2011

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 :D.

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.


Categoría para traducir entidades html en NSString

septiembre 20, 2010

Recientemente desarrollando para el iOS, me encontré con la necesidad de eliminar las entidades html de una cadena de texto.

Para el que no lo sepa, las entidades dentro de HTML, o en cualquier lenguage de marcas, son lo mas parecido a una secuencia de escape, es decir, una cadena que representa a un caracter que originalmente no esta permitido. Por ejemplo, y como parece obvio, si queremos poner el caracter ‘<‘ en HTML, no podemos ponerlo directamente, pues forma parte del propio lenguage. Por ello, si queremos escribir dicho carácter tendremos que poner <.

La principal característica de las entidades de un lenguage de marcas, es que comienzan con ‘&’ y acaban con ‘;’.

Dentro de la API de manejo de cadenas de UIKit, existe un método para codificar URLs, que aunque pueda parecer similar, no lo es. Pues las URLs no tienen nada que ver con el lenguage HTML, solo nos indican la forma de acceder a los documentos que estan hechos con HTML 😉

Dichos métodos son, stringByAddingPercentEscapesUsingEncoding: y stringByReplacingPercentEscapesUsingEncoding:, y sustituyen los caracteres especiales de las URLs por sus equivalentes “escapados” usando porcentajes, como por ejemplo el símbolo del $ la convertirá en %24.

Pero sin embargo no hay ninguna función para transformar las entidades en sus caracteres equivalentes.

La primera solución que se nos puede ocurrir es usar el mensaje stringByReplacingOccurrencesOfString:withString: por cada entidad. Y aunque funciona, es bastante penalizador desde el punto de vista del rendimiento, ya que si tenemos el siguiente código.

NSString* cad = [NSString stringWithString:@"&lt;&apos;&amp;&apos;&gt;"];
	NSLog(@"%@", [[[[cad stringByReplacingOccurrencesOfString:@"&lt;" withString:@"<"]
				  stringByReplacingOccurrencesOfString:@"&gt;" withString:@">"]
				  stringByReplacingOccurrencesOfString:@"&amp;" withString:@"&"]
				  stringByReplacingOccurrencesOfString:@"&apos;" withString:@"'"]);

Recorrerá la cadena entera tantas veces como entidades queramos sustituir, lo que para cadenas largas puede ser un gasto bastante grande e innecesario.

Después de buscar por internet, no encontré nada que me convenciera, asi que tome el camino del medio, y hice una categoria de NSString, que recorre la cadena y sustituye las ocurrencias, de las entidades por sus caracteres.

Al ser una categoria, no hace falta mas que incluir el fichero .h y llamarlo sobre cualquier objeto NSString.

@interface NSString (RemoveHtmlEntities)

- (NSString*) stringByRemovingHtmlEntities;

@end

@implementation NSString (RemoveHtmlEntities)

- (NSString*) stringByRemovingHtmlEntities {
	NSMutableString* newStr = [[NSMutableString alloc] init];
	NSUInteger i = 0;
	unichar c = 0;
	NSUInteger strLen = [self length];
	while (i < strLen) {
		c = [self characterAtIndex:i];
		if ( c == '&' ) {
			if ( [self rangeOfString:@"amp;" options:NSCaseInsensitiveSearch range:NSMakeRange(i, (5>(strLen-i))?strLen-i:5)].location != NSNotFound ) {
				[newStr appendFormat:@"&"];
				i += 5;
			} else if ([self rangeOfString:@"lt;" options:NSCaseInsensitiveSearch range:NSMakeRange(i, (4>(strLen-i))?strLen-i:4)].location != NSNotFound) {
				[newStr appendFormat:@"<"];
				i += 4;
			} else if ([self rangeOfString:@"gt;" options:NSCaseInsensitiveSearch range:NSMakeRange(i, (4>(strLen-i))?strLen-i:4)].location != NSNotFound) {
				[newStr appendFormat:@">"];
				i += 4;
			} else if ([self rangeOfString:@"quot;" options:NSCaseInsensitiveSearch range:NSMakeRange(i, (6>(strLen-i))?strLen-i:6)].location != NSNotFound) {
				[newStr appendFormat:@"\""];
				i += 6;
			} else if ([self rangeOfString:@"apos;" options:NSCaseInsensitiveSearch range:NSMakeRange(i, (6>(strLen-i))?strLen-i:6)].location != NSNotFound) {
				[newStr appendFormat:@"'"];
				i += 6;
			} else {
				[newStr appendFormat:@"&"];
				i++;
			}
		} else {
			[newStr appendFormat:@"%c", c];
			i++;
		}
	}
	return [newStr autorelease];
}

@end

Como veis, solo transforma las entidades que necesitaba en el momento de desarrollo, pero es trivial añadir mas clausulas “else if” al código 😉

Un posible uso del código sería

	NSString* cad = [NSString stringWithString:@"&lt;&apos;&amp;&apos;&gt;"];
        NSLog(@"%@", [cad stringByRemovingHtmlEntities]); 
       // Imprime <'&'>