Leopard: nuevas tecnologías comunes para las aplicaciones
Publicado el 18 Diciembre 2006 por juandesant[Actualización: Al parecer, el Scripting Bridge no sólo soportará AppleScript, sino también Python y Ruby. Eso significa que será posible, en principio, crear una especie de Script Studio que vaya más allá de AppleScript, atrayendo aún a más desarrolladores. De paso, nos enteramos de que Ruby vendrá como un framework más de Mac OS X —como ya lo hace Python—, e incluirá mútiples gems, especialmente las que forman Rails.]
Hace ya casi un mes que Apple ha comenzado con una serie de artículos para desarrolladores, especialmente para aquellos que aún no están registrados para el Leopard Early Access Kit, y que explican algunas de las nuevas tecnologías de Leopard. El primer artículo de dicha serie estaba dedicado a hacer un repaso a todas las tecnologías disponibles en Leopard, mientras que el segundo estaba centrado en las nuevas herramientas de desarrollo disponibles.
El tercero, en cambio, se llama “Repaso de las tecnologías de aplicación para los desarrolladores”, y estos son los capítulos principales que cubre:
* Integración con _Time Machine_
* Integración con _iChat_
* Uso del _Repositorio de Calendarios_
* Uso del puente AppleScript > Cocoa
* Animación de interfaces de usuario con Core Animation
* Adaptación de las aplicaciones al futuro hardware
Veremos de qué se habla en cada uno de esos capítulos.
Integración con _Time Machine_
Recordemos que una de las novedades que más llamó la atención de Leopard fue Time Machine, un interfaz de copia de seguridad automática —todo cambio guardado es registrado—, que además permite una recuperación cronológica de forma visual, pero especialmente granular: no sólo era posible recuperar una carpeta o un archivo que antes existía y que hace tiempo que no, sino que también es posible recuperar diferentes versiones, de forma automática, desde dentro de aplicaciones como la Agenda o iPhoto.
En este artículo se muestra a los desarrolladores diferentes técnicas para su integración con Time Machine… comenzando por la de cómo hacer que ciertos archivos temporales no se copien. Al parecer, Time Machine no hará copia de seguridad de aquello que esté dentro de las carpetas /tmp, /Library/Caches/ y ~/Library/Caches/ —esta última es la carpeta que cuelga de cada uno de los usuarios—. También es posible indicar al sistema que, pese a su localización, ciertos archivos en concreto no han de ser copiados.
Lo segundo que se indica es que Time Machine —como Spotlight, por cierto— está basado en acceso a archivos, de modo que un pequeño cambio en un gran archivo implicará la copia de seguridad de todo el archivo —aunque se realiza primero un enlace que indica la diferencia con el archivo anterior, y el momento de la copia se deja para más tarde, no es inmediato—. Así que una aplicación que realice con frecuencia cambios en pequeñas partes de un archivo debería separar esas partes más cambiantes en un archivo diferente.
Y lo tercero es la creación de módulos de Visualización Rápida para tipos de datos no reconocidos por el sistema. Así será posible inspeccionar tanto desde el Finder, como a la hora de recuperar un archivo, basándonos en su contenido. Es interesante que una tecnología necesaria para Time Machine —para poder distinguir entre versiones de archivos— sirva para implementar una característica muy necesaria en el Finder.
h3. Integración con _iChat_
Otra función muy esperada de Leopard es su integración de aplicaciones con el iChat Theatre, o lo que es lo mismo: Leopard permitirá que cualquier aplicación pueda enviar o recibir datos de audio y vídeo a través de la conexión establecida por iChat entre varios usuarios, mejorando la colaboración.
Las aplicaciones que se quieran integrar con iChat —se demostró el uso de Keynote a través de iChat, por ejemplo— tienen que usar las bibliotecas de funciones Instant Message para recibir notificaciones de mensajes entre usuarios, y una vez abierta una conexión a la aplicación se le pide que proporcione vídeo y audio a través de llamadas de Core Audio.
Se me ocurre que algunas aplicaciones que pueden estar muy interesadas en este tipo de servicios —y pueden ser muy fáciles de escribir— son las de monitorización remota de procesos, que podrían abrir automáticamente sesiones de conferencia, y enviar imágenes sintéticas con los contenidos de determinados parámetros, alertando a los administradores de sistemas en caso de problemas. Sería genial si además existiera el especulado _teléfono iChat_ ;-)
h3. Uso del _Repositorio de Calendarios_
El Repositorio de Calendarios —_Calendar Store_ en inglés— es el lugar centralizado donde se va a almacenar toda la información que tiene que ver con todos los acontecimientos que suceden en determinadas fechas. Ya no existirá una aplicación _privilegiada_ como iCal, única capaz de trabajar con toda la información de calendarios, acontecimientos, fiestas, y tareas por hacer, sino que será el propio sistema operativo quien la gestionará, y proporcionará funciones tanto para iCal como para cualquier otra aplicación que quiera acceder al Calendar Store.
Y si pensamos en la conferencia WWDC 2006, recordaremso que Leopard contará con un repositorio e interfaz de tareas compartido entre todas las aplicaciones, que también estará disponible a través del _Calendar Store_.
Todo eso permitirá que cualquier aplicación pueda acceder a dicho repositorio, lo que proporciona mayor libertad a toda esa información (ya no es sólo la información de iCal), y mayores posibilidades de exportarla a otros sistemas. Y no sólo se tiene acceso a la información: los mecanismos de notificación de alarmas, sucesos, etcétera, también están codificados en el sistema, por lo que todas las aplicaciones tienen las mismas oportunidades de saber qué está ocurriendo con esa información.
Eso hace posible, por ejemplo, la mayor interacción entre aplicaciones de colaboración a través no sólo de Mac OS X, sino de aplicaciones web con servidores basados en Mac OS X.
h3. Uso del puente AppleScript > Cocoa
Una característica que no había visto documentada hasta la aparición de este artículo es la existencia de un nuevo puente entre AppleScript y Cocoa. Si bien con AppleScript Studio era posible escribir aplicaciones creando el interfaz —y por tanto, algunos objetos Cocoa— con Interface Builder, para después crear los programas que respondían a los botones y resto de elementos del Interfaz con AppleScript, o se podían crear algunos módulos adicionales en Objective-C —el lenguaje de Cocoa—, había que hacerlo en archivos aparte, y había dificultad para utilizar AppleScript desde Cocoa.
Con el puente AppleScript > Cocoa, es posible hacer que una aplicación controle a otra por medio de eventos AppleScript, pero escribiendo mucho menos código, y con una velocidad de ejecución muchísimo mayor. En concreto, el programador se ahorra tener que hacer cambios de tipos de datos entre AppleScript y Objective-C, y la interpretación de una cadena de texto que finalmente producirá una serie de mensajes Objective-C: esos mensajes se envían, reciben e interpretan directamente.
h3. Animación de interfaces de usuario con Core Animation
Core Animation proporciona varias cosas para el programador: una forma sencilla de definir muchas de las animaciones del interfaz, que se activarán automáticamente, prácticamente sin intervención del programador… que sólo tiene que incluir una línea de activación de la animación correspondiente, y eso en caso de que no se conforme con la animación por defecto.
No sólo eso, sino que Core Animation lanza las animaciones en hilos de tarea diferentes a los de la tarea principal, por lo que la animación se realizará en un hilo diferente, y si hay más de un núcleo disponible, seguramente en otro núcleo.
Una aplicación que use Core Animation para su interfaz, pues, no sólo será más vistosa, sino que en máquinas con más de un núcleo será, con toda seguridad, más rápida.
h3. Adaptación de las aplicaciones al futuro hardware
Este capítulo, en realidad, está especialmente dedicado al cambio de 32 a 64 bits, con la gran ventaja de que parte de ese camino ya está recorrido: aquellos programadores que hayan organizado sus Binarios Universales en torno a los tipos de datos del sistema NSInteger y/o NSUInteger no sólo no tienen que preocuparse de la ordenación interna del procesador —Mac OS X gestiona eso automáticamente—, sino que tampoco tienen problema para abstraer la diferencia entre máquinas de 32 y 64 bits.
Recordemos que, a diferencia del caso PowerPC, las aplicaciones x86_64 sí que son significativamente más rápidas que las aplicaciones x86_32, esencialmente debido a que los PowerPC mantienen su —alto— número de registros, mientras que el paso de x86_32 a x86_64 *duplica* el número de registros —zonas de memoria de acceso inmediato— disponibles para el procesador.
Tal y como está hecho Leopard, las aplicaciones y bibliotecas de funciones de 32 y 64 bits pueden convivir en el mismo archivo, y además pueden llamar a código de cualquiera de los modos, con el resultado más interesante de todos: Leopard permitirá el uso de _drivers_ de 32 o de 64 bits de forma indistinta, de modo que no existirá un _vacío de drivers_ para la versión de 64 bits, y será posible realizar dicha transición de forma más sencilla y rápida.
Comparemos esto con el estado de Windows de 64 bits, y su falta de _drivers_. Windows Vista está en una situación incluso peor: son necesarios nuevos drivers —por seguridad, no sirven los de XP—… y esos drivers hay que compilarlos, de forma separada, en versiones de 32 y de 64 bits. ¡Que tengáis suerte al escoger el correcto!
h3. Enlaces
* Apple Developer Connection: “Leopard Developer Application Technologies Overview”:http://developer.apple.com/leopard/overview/apptech.html
* Apple Developer Connection: “Leopard Technology Series for Developers”:http://developer.apple.com/leopard/overview/
* Faq-Mac: “Seguimiento Keynote WWDC 2006″:http://www.faq-mac.com/keynote_2006WWDC.html
Siempre me he preguntado si las aplicaciones de 64 bits usan el doble de memoria.
Podrías responderme?
Hola, Pancho, sí puedo responderme, y espero hacerme entender ;-)
Los números de 64 bits ocupan el doble de tamaño que los números de 32 bits, igual que un número de 10 cifras necesitaría el doble de casillas en un formulario que un número de 5 cifras. Pero las aplicaciones de 64 bits normalmente manejan los mismos tamaños de números que antes, sólo que ahora todo cabe en una sola operación. En ese sentido, no ocupan el doble, para nada.
Ahora bien, los programas utilizan una cosa que se llaman punteros para indicar en qué parte de memoria han dejado una información. Si un programa utiliza muchos punteros, y cuanto más complejo sea, más utilizará, cada uno de esos punteros ocupará el doble en una máquina de 64 bits respecto a una máquina de 32 bits. Ahora bien, la proporción entre punteros y trozos de memoria útiles suele ser muy superior a 10:1, de modo que el incremento *en memoria utilizada* por esa causa sería muy inferior al 20%.
Hay un posible incremento adicional: en los micros PowerPC, las instrucciones de 64 bits ocupan exactamente lo mismo que las de 32 bits —después de todo, los primeros PowerPC eran una versión 32 bits de una arquitectura de 64 bits—. En cambio, en los micros x86 las instrucciones x86_64 ocupan entre un 25% y un 35% más que las instrucciones de 32 bits, por lo que el tamaño del ejecutable también crece.
Si tienes en cuenta que Mac OS X Leopard va a incluir versiones de 32 y de 64 bits, para PowerPC e Intel, de la inmensa mayoría de los ejecutables, eso implica que el tamaño de un archivo binario determinado puede llegar a ser unas 4 veces el tamaño original, a cambio de no tener 4 programas diferentes en el disco.
Eso explica también por qué Adobe Photoshop CS3 ocupa casi el doble que la versión de Windows: se trata de un Binario Universal, con versiones tanto PowerPC como Intel en el mismo paquete.
[...] Cosas como: la revisión que hice a VirtueDesktops que sus desarrolladores van a abandonar a favor de Spaces (dijeron que no lo harían), las tecnologías comunes de Leopard, una demo de Mac OS X Tiger, las declaraciones de Thomas Hawk sobre la mac que se compró (junto con Kristopher Tate han desarrollado Zooomr, una buena competencia de Flickr), el Low Level Virtual Machine (LLVM) ya me habia olvidado de él y tal vez lo veamos en Leopard, otros comentarios sobre Mac OS X, QTFairUse6 ahora que el DRM está en boca de tantos, la revisión a la MacBook (todavía no tengo una, buuaaa), etc, etc. [...]
Pues nos deja un poco secos a los que tenemos macs que no tienen procesador con 64 bits como puede ser los mac mini o powerbooks un poco mas viejos
¿podremos utilizar leopard sin problemas?
Desde luego es un gran avance y aun teniendo máquinas de la mas baja gama apple tenemos maquinas mas potentes que las ultimas con vista
Saludos
Burtelon, Leopard es PowerPC/Intel 32-64 bits, todo a la vez. Los drivers de 32 bits funcionan con las aplicaciones de 64 bits sin problema, así que no existen los problemas que tienen las versiones de 64 bits de Windows y Linux para tener drivers.
