| MetaCard y Revolution: Herramientas de autor multiplataforma para multimedia | ||
|---|---|---|
| Anterior | Capítulo 3. Programación en MetaTalk y Transcript | Siguiente |
Antes de continuar hemos de reseñar una serie de cuestiones que hacen posible que una aplicación tenga la difícl característica de poder ser utilizada en diferentes plataformas o sistemas operativos.
Desde luego debe haber soporte de la herramienta de construcción de aplicaciones para las diferentes plataformas o habrá poco que hacer. En el caso de los lenguajes de programación, disponer de un compilador o un intérprete para ellos suele ser suficiente: los ejecutables (los archivos binarios que puede crear con Pascal o C) se recrean desde cero a partir del código fuente y a correr; o bien se utiliza un intérprete para cada sistema operativo el código se puede "portar" sin mayores problemas (como es el caso Java).
Nota: MetaCard dispone de la orden secureMode para deshabilitar el acceso a los recursos locales, con lo que se puede ejecutar de manera similar al modo "protegido" (sand box) de Java.
Pero eso no es todo, en cada sistema operativo hay funciones que son soportadas en unos y no en otros (véase las funciones files, sysError o la orden kill), gestores de ventanas que soportan o no determinados servicios
En MetaCard ( y en Revolution) existen una serie de órdenes que pueden ayudarnos a realizar acciones de una forma u otra, relativas a la propia herramienta y al entorno de ejecución, como la versión de MetaCard, el sistema operativos sobre el que se ejecuta, ... En este momento, en mi sistema, puedo obtener esta información:
version : 2.4
buildNumber : 2
environment : player
lookAndFeel : Motif
platform : Linux
machine : i686
systemVersion : Linux 2.4.6
screenVendor : The XFree86 Project, Inc 3360
screenName : :0.0
address : mudet:mc
qtVersion : 2.0
Algunas cosas que son posibles en otros sistemas operativos y de cierto interés pueden ser:
En MacOS y Windows si se dipone de QuickTime es posible utilizarlo sustituyendo al objeto player y alguna cosa más. Véae: qtVersion (sieempre vale "2.0" en Unix) o dontUseQT. También es posible localizar ciertos directorios habituales en estos sistemas con specialFolderPath.
En Windows hideConsoleWindows, queryRegistry (véase ... aplicaciones externas).
En MacOs se puede encontrar un buen número de funciones sólo aplicables a esta plataforma: relativas a recursos (getResources, setResources), comunicación con las aplicaciones (appleEvent, request, reply). Esto no se lo puedo ensenyar ..., es que no dispongo de este sistema.
Al respecto de la creación de ejecutables existen una serie de cuestiones que abordaremos en la la sección de nombre Creación de ejecutables en Capítulo 5. Por ejemplo se puede generar el ejecutable para las tres plataformas desde cualquiera de ellas.
Importante: Aunque parezca una trivialidad, uno de los mayores problemas para hacer aplicaciones ampliables, portables y multiplataforma es la falta de apoyo de las herramientas y el desconocimiento de lo que implica por parte de quienes las emplean. Básicamente, los problemas más usuales son:
Asignar de forma estática ficheros. La carga de documentos en una aplicación cuyos contenidos están siendo desarrollados obliga a que el avance de la misma dependa del proceso de producción de los mismos. Es más, si esta es una labor con un tiempo de desarrollo largo o con un contenido no cerrado, no se puede detener el proceso de implementación por no disponer de todos los elementos finales.
Utilizar rutas absolutas. Esto hará que su aplicación sólo se pueda ejecutar exactamente en la misma disposición de su equipo de desarrollo.
Utilizar elementos específicos de una plataforma. Sólo hay un sistema operativo que utiliza las contrabarras "\" como separador en la especificación de las rutas de los recursos que se disponen en su sistema de archivo. Todos los demás emplean la barra "/", de hecho en la Web también se han adoptado estas como separadores.
En este sentido, cada uno de esos items necesitará la consideración del programador de una aplicación multimedia, preveyendo su inclusión en una etapa posterior de una forma lo más automática posible. Para ello:
Si fija recursos de gran tamaño como las imágenes (pero también es ampliable al uso de ficheros de audio y de vídeo) puede ser interesante precargarlos para que el usuario no vea alterado el lógico transcurrir de la aplicación que utiliza. Esto puede llevar a realizar por código esta asignación del nombre del fichero correspondiente al objeto en cuestión. Además facilita las pruebas necesarias durante el desarrollo de la misma, sin forzar a una dependencia estricta de la disponibilidad de los "actores" finales.
Aunque el entorno visual de desarrollo hace cómodo el incoporar elementos del sistema de ficheros especificando la ruta completa, hacer que esta sea dependiente de un punto sin especificar posiblitará que se pueda instalar y ejecutar desde cualquier otra que el usuario final especifique. Haga que siempre sea expuesta como relativa a un punto, por ejemplo donde reside su aplicación principal. A partir de ahí diseñe una estructuración lógica de los elementos que considere apropiada.
En herramientas con capacidad de trabajo multiplataforma, los detalles depenidientes de un sistema u otro deberían ser manejados de forma automática. Para ello MetaCard y Revolution le permiten hacer uso siempre de las "/" y, si es necesario, es la propia herramienta en tiempo de ejecución la que hace la traducción al carácter apropiado.