1. Spotlight: un punto de luz en
tu aplicación
Javier Rodríguez (javierrodriguez@me.com)
lunes 27 de abril de 2009
2. 1. Breve historia
2. Los fundamentos
3. Las herramientas
4. Crea tu plug-in
5. Demo
lunes 27 de abril de 2009
3. 1. Breve historia
• Mac OS X 10.4: Un servidor central de Metadatos
• Importadores de serie (plug-in)
• Arquitectura modular
lunes 27 de abril de 2009
Con anterioridad al Mac OS X las búsquedas eran textuales cuando se refería al contenido de los documentos. El
resto de búsquedas eran sobre los metadatos básicos, comunes a todo tipo de archivos como la fecha de creación,
modificación, última apertura, etc.
4. 2. Los fundamentos
• Un tipo de archivo sólo puede ser indexado por
un plug-in.
lunes 27 de abril de 2009
(*) el sistema decidirá cuál es el tipo de plug-in más apropiado en el caso de que no se proporcione uno exclusivo.
Esto es lo que pasaría por ejemplo con un archivo de texto o XML.
5. 2. Los fundamentos
• Un plug-in puede analizar los documentos
correspondientes a diversos UTI (no, no es
contradictorio).
lunes 27 de abril de 2009
Si un importador tiene registrados varios UTI, entonces este será llamado cada vez que se modifique cada uno de
dichos documentos. La única función recibirá el UTI de modo que pueda modificar su comportamiento en
consecuencia.
6. 2. Los fundamentos
• Los metadatos se actualizan cuando se modifica
el archivo.
lunes 27 de abril de 2009
Spotlight guardará los metadatos recibidos por el plug-in encargado de procesar dicho archivo. Es decir: el
desarrollador decide cuáles son los metadatos importantes para un tipo de archivo concreto.
El plug-in ha de hacer el trabajo lo más rápido posible, ya que dicha indexación se produce durante los ciclos
muertos del procesador.
7. 2. Los fundamentos
• El plug-in debe estar localizado en cualquiera de las dos ubicaciones
posibles:
/System/Library/Spotlight (los incluidos por omisión)
/Library/Spotlight
~/Library/Spotlight
(aplicación)/Contents/Library/Spotlight
lunes 27 de abril de 2009
Si un importador tiene registrados varios UTI, entonces este será llamado cada vez que se modifique cada uno de
dichos documentos. La única función recibirá el UTI de modo que pueda modificar su comportamiento en
consecuencia.
Si existe un plug-in para un tipo de archivo determinado en la ruta “(aplicación)/Contents/Library/Spotlight” y otro
en cualquiera de las rutas anteriores, entonces tendrá precedencia para el parseo de los metadatos el disponible
dentro del bundle de la aplicación.
Si desarrollas un importador para parsear los documentos generados por una aplicación que no has creado tú,
entonces deberás añadir un “postinstall” en el script de instalación para informar manualmente a Spotlight de la
disponibilidad de tu plug-in (import manual)
8. 2. Los fundamentos
• El plug-in se asocia con el documento mediante
un UTI (Uniform Type Identifier; Identificador de
Tipo Uniforme).
lunes 27 de abril de 2009
Los UTI tienen forma de DNS inverso.
keys kMDItemContentType y kMDItemContentTypeTree (mdls)
9. 3. Las Herramientas
• Disponemos de varias herramientas del sistema:
> mdls
> mdutil
> mdfind
> mdimport
lunes 27 de abril de 2009
mdls: lista los atributos correspondientes a los metadatos para el archivo especificado.
mdutil: gestiona las bases de metadatos empleadas por Spotlight
mdfind: halla los archivos coincidentes con el criterio de búsqueda indicado.
mdimport: importa los metadatos correspondientes a los archivos indicados o bien jerarquías del sistema. Es útil
durante la depuración de nuestros plug-in
10. 4. Crea tu plug-in
• Identifica tu documento:
lunes 27 de abril de 2009
Asigna uno (o varios) UTI que identifiquen tu tipo de documento.
Esta operación se realiza en info.plist (en Target, preferiblemente).
Si el importador va a ser independiente de la aplicación, entonces se declarará en el archivo info.plist del proyecto del
plug-in.
11. 4. Crea tu plug-in
• Identifica tu documento:
lunes 27 de abril de 2009
Otra forma de llegar al mismo sitio: haz doble clic sobre el icono de la aplicación en Target.
En la ventana que se abre, selecciona la pestaña Properties y añade todos los atributos de la aplicación, entre ellos
los diferentes UTI en el listado inferior.
Ambas operaciones asocian el UTI con el tipo de documento, pero no lo declara por completo ante el sistema
operativo.
12. 4. Crea tu plug-in
lunes 27 de abril de 2009
Para exportar el UTI al sistema, pulse el botón Open info.plist as file y añade un array con la clave
UTEportedTypeDeclarations.
Dicho array debe contener un Diccionario para cada uno de los UTI declarados.
Utiliza MDimport -d1 sobre un documento de aplicación. Verás que se identifica correctamente el tipo.
Si en vez del tipo (UTI, DNS inverso) muestra un UTI del estilo dyn.... significará que algo va mal.... no ha hallado
ningún UTI asociado y por tanto ha asociado uno dinámico.
En ese caso, revisa el archivo PLIST, ya sea en Xcode o bien empleando la herramienta plutil para comprobar que se
parsea correctamente.
13. 4. Crea tu plug-in
• El molde de los bizcochos:
lunes 27 de abril de 2009
Problema: se crea como un nuevo proyecto (idealmente estaría bien que formase parte del proyecto de nuestra
aplicación)... pero a cambio Apple nos lo da todo prácticamente hecho.
Solución: en tu proyecto de aplicación puedes añadir el plug-in como un nuevo recurso de compilación del tipo
“Copiar archivo”.
14. 4. Crea tu plug-in
lunes 27 de abril de 2009
info.plist e infoPlist.string: viejos conocidos del proyecto de nuestra aplicación.
Aquí es donde deberías de definir los UTI en el caso de que estés diseñando un importador independiente de la
aplicación.
Schema.xml: Este es el archivo en el que debes definir los atributos (metadatos) que sean propios (exclusivos) del
documento que se va a parsear. Dichos metadatos deben de ser distintos a los que contempla por omisión el propio
sistema operativo.
15. 4. Crea tu plug-in
lunes 27 de abril de 2009
Tipos de valores soportados: CFString, CFNumber, CFBoolean, CFDate y CFArray.
Schema.strings incluye la representación en texto común para cada una de las claves de metadatos personalizados
que hayamos creado.
Dicha información es la que se presenta al usuario por el Finder, de modo que resulta más comprensible.
Una vez guardado el archivo: puedes comprobar la validez del mismo utilizando, desde el Terminal:
mdcheckschema schema.xml
16. 4. Crea tu plug-in
¿Qué metadatos puedo declarar?
Ninguno de estos: “Spotlight Metadata Attributes Reference”
lunes 27 de abril de 2009
Declara sólo los metadatos que sean realmente intrínsecos de tu aplicación. Antes de hacerlo, echa un vistazo
a la documentación de Apple. Si un metadato ya está declarado... usa la constante, no vuelvas a declararlo.
17. 4. Crea tu plug-in
Información para humanos: schema.strings
lunes 27 de abril de 2009
Schema.strings incluye la representación en texto común para cada una de las claves de metadatos personalizados
que hayamos creado.
Dicha información es la que se presenta al usuario por el Finder, de modo que resulta más comprensible.
18. lunes 27 de abril de 2009
Todo el código que necesitas para parsear el documento: en una captura de pantalla.
Además, no necesitas parchear todo el archivo sólo la parte sobre la que deseas actuar extrayendo los
metadatos.
Dicho código es reutilizado: ¡ya lo has escrito en tu proyecto para generar el documento personalizado!
Si la función parchea correctamente los metadatos: devuelve el booleano ‘true’... de lo contrario, ‘false’
19. 5. Demo www.colorate.eu
lunes 27 de abril de 2009
20. ¿Sigue alguien despierto?
Referencias:
http://www.apple.com/downloads/macosx/spotlight/
http://developer.apple.com/DOCUMENTATION/Carbon/Conceptual/MDImporters/Concepts/Troubleshooting.html
http://developer.apple.com/DOCUMENTATION/Carbon/Conceptual/MDImporters/Concepts/WritingAnImp.html
lunes 27 de abril de 2009