MacApp es el marco de trabajo de aplicaciones orientadas a objetos para el sistema operativo Mac OS de Apple Computer , que ya no se fabrica . Lanzado en 1985, pasó de Object Pascal a C++ en la versión 3.0 de 1991, que ofrecía soporte para gran parte de la nueva funcionalidad de System 7. MacApp se utilizó para una variedad de aplicaciones importantes, incluidas Adobe Photoshop [1] y SoftPress Freeway . [ cita requerida ] MFC de Microsoft y OWL de Borland se basaron directamente en los conceptos de MacApp.
A lo largo de un período de diez años, el producto tuvo períodos de poco desarrollo seguidos de rachas de actividad. Durante este período, Think Class Library /Think Pascal de Symantec se había convertido en un serio competidor de MacApp, ofreciendo un modelo más simple en un entorno de desarrollo integrado (IDE) de mucho mayor rendimiento .
Symantec tardó en responder al cambio hacia la plataforma PowerPC a principios de los años 1990, y cuando Metrowerks presentó por primera vez su sistema CodeWarrior / PowerPlant en 1994, desplazó rápidamente tanto a MacApp como a Think como plataformas de desarrollo principales en Mac. Incluso Apple utilizó CodeWarrior como su plataforma de desarrollo principal durante la era Copland a mediados de los años 1990.
MacApp tuvo un breve respiro entre 2000 y 2001, como sistema para la transición al sistema Carbon en MacOS X. [ 2] Sin embargo, después de demostrar una versión en la Conferencia Mundial de Desarrolladores (WWDC) en junio de 2001, todo el desarrollo se canceló ese octubre.
MacApp fue un descendiente directo de Lisa Toolkit, el primer esfuerzo de Apple en el diseño de un marco de aplicación orientado a objetos, dirigido por Larry Tesler . El equipo de ingeniería de Toolkit incluía a Larry Rosenstein, Scott Wallace y Ken Doyle. Toolkit se escribió en un lenguaje personalizado conocido como Clascal , que agregó técnicas orientadas a objetos al lenguaje Pascal . [3] [4]
Inicialmente, el desarrollo para Mac se llevó a cabo utilizando un compilador cruzado en Lisa Workshop. Cuando las ventas de Mac terminaron con las de Lisa, se inició un esfuerzo para construir una nueva plataforma de desarrollo para Mac. Lisa Programmer's Workshop se convirtió en 1985 en Macintosh Programmer's Workshop o MPW. Como parte de este proceso, Clascal se actualizó para convertirse en Object Pascal y Lisa Toolkit ofreció notas de diseño para lo que se convirtió en MacApp. [4]
Escribir un programa para Mac sin un marco de aplicación no es una tarea fácil, pero en ese momento el campo de la programación orientada a objetos era relativamente nuevo y muchos desarrolladores lo consideraban sospechoso. Los primeros marcos tendían a confirmar esta sospecha, ya que eran grandes, lentos y, por lo general, inflexibles.
MacApp fue quizás el primer framework verdaderamente utilizable en todos los sentidos del término. Las aplicaciones compiladas eran bastante razonables en términos de tamaño y consumo de memoria , y el rendimiento no era lo suficientemente malo como para que los desarrolladores lo rechazaran. Aunque era "demasiado simple" en sus primeras versiones, varias versiones posteriores abordaron rápidamente los principales problemas. En ese momento, alrededor de 1987, el sistema había madurado hasta convertirse en una herramienta útil, y varios desarrolladores comenzaron a usarlo en proyectos importantes.
MacApp 2.0 se lanzó en 1989. Entre las mejoras se encontraba una simplificación de algunas de las interacciones de los elementos de la interfaz de usuario y soporte para Multifinder. [5] Cuando Apple anunció que dejaría de dar soporte a MPW Pascal en 1992, [6] esta versión no se actualizó, ni siquiera con soporte para System 7, y los desarrolladores de Pascal se quedaron solos para portar MacApp 2.0 al PowerPC. [6] [7]
En ese momento, a finales de los años 1980, el mercado se estaba orientando hacia C++ , y la versión beta del compilador Apple C++ apareció en 1989, cerca del lanzamiento de MacApp 2.0. [5] Al mismo tiempo, Apple estaba inmersa en el esfuerzo de lanzar System 7 , que tenía varias características nuevas importantes. Se tomó la decisión de realizar la transición a una versión completamente nueva de MacApp, 3.0, que usaría C++ en lugar de Object Pascal. [8] Este movimiento fue objeto de un largo y acalorado debate entre los defensores de Object Pascal y C++ en Usenet y otros foros. Sin embargo, 3.0 logró reunir un número razonable de seguidores después de su lanzamiento en 1991, a pesar de que la suite para desarrolladores, MPW, se estaba quedando obsoleta. Apple luego redujo el tamaño de todo el grupo de herramientas para desarrolladores, dejando tanto a MacApp como a MPW con poco personal.
Una de las razones de esta reducción de personal fue la larga saga de Apple de intentar introducir la "próxima gran plataforma" para el desarrollo, casi siempre en forma de un sistema multiplataforma de algún tipo. Su primer intento fue Bedrock , una biblioteca de clases creada en asociación con Symantec que se ejecutaba en Mac y Windows, que murió de forma lenta ya que ambas partes finalmente renunciaron a trabajar con la otra. Una de las razones de sus problemas fue la creación de OpenDoc , que se desarrolló en sí mismo como un sistema multiplataforma que competía directamente con Bedrock. Hubo algunos intentos de posicionar Bedrock como una plataforma OpenDoc, [9] [10] pero nada salió de esto.
Mientras se producían estos desarrollos, MPW y MacApp fueron ignorados en gran medida. Era más importante destinar esos recursos de los desarrolladores a estos nuevos proyectos para ayudarlos a llegar al mercado antes. Pero cuando Bedrock fracasó y OpenDoc tuvo una recepción tibia, Mac se quedó con herramientas que ya tenían casi una década de antigüedad y no podían competir con los productos más nuevos de terceros. A principios de la década de 1990, los marcos de trabajo de la competencia se convirtieron en verdaderos competidores de MacApp. Primero, TCL de Symantec cosechó seguidores, pero luego PowerPlant de Metrowerks se apoderó de todo el mercado.
Los desarrolladores principales de MacApp continuaron trabajando en el sistema con un nivel de actividad bajo durante la década de 1990. Cuando todos los proyectos multiplataforma "oficiales" de Apple fracasaron, a fines de 1996 el equipo anunció que proporcionaría una versión multiplataforma de MacApp.
Poco después, Apple compró NeXT y anunció que OpenStep sería la plataforma de desarrollo principal de Apple en el futuro, bajo el nombre de Cocoa . Cocoa ya era multiplataforma, en ese momento ya había sido portado a alrededor de seis plataformas, y era mucho más avanzado que MacApp. Esto provocó enérgicas protestas de los programadores de Mac existentes que protestaban porque sus programas estaban siendo enviados al " baúl de penalizaciones ", siendo efectivamente abandonados.
En la WWDC'98, Steve Jobs anunció que las reacciones negativas sobre el cambio a Cocoa se estaban abordando mediante la introducción del sistema Carbon . Carbon permitiría que los programas existentes de Mac se ejecutaran de forma nativa en el nuevo sistema operativo, después de algunas modificaciones. Metrowerks anunció que trasladaría su marco PowerPlant a Carbon, pero Apple no hizo ningún anuncio similar con respecto a MacApp.
Durante este período, quedó un núcleo de usuarios fieles de MacApp que se sentían cada vez más frustrados por el comportamiento de Apple. A finales de los años 90, durante la introducción de Cocoa, esta tendencia había llegado a un rechazo total del producto. La situación era tan mala que un grupo de usuarios de MacApp llegó al extremo de organizar su propia reunión en la WWDC '98 bajo un nombre falso, para evitar que los empleados de Apple les negaran una sala para reunirse.
Este apoyo continuo se hizo notar dentro de Apple y, a finales de 1999, un "nuevo" equipo de MacApp, formado por miembros que habían trabajado en él desde el principio, recibió la tarea de lanzar una nueva versión. Incluía las nuevas Apple Class Suites (ACS), una capa más delgada de envoltorios de C++ para muchas de las nuevas características de Mac OS que se estaban introduciendo desde OpenStep y soporte para la compilación en Project Builder. MacApp 3.0 Release XV se lanzó [11] el 28 de agosto de 2001 para el deleite de muchos. Sin embargo, en octubre el producto fue eliminado una vez más, esta vez para siempre, y el soporte para las versiones existentes de MacApp finalizó oficialmente.
El PowerPlant X compatible con Carbon no se lanzó hasta 2004, y hoy Cocoa es casi universal para la programación tanto de MacOS como de iOS.
MacApp se mantiene viva gracias a un grupo dedicado de desarrolladores que han mantenido y mejorado el framework desde que Apple dejó de darle soporte en 2001. MacApp se ha actualizado para que sea totalmente compatible con Carbon Events, Universal Binaries, Unicode Text, control MLTE, control DataBrowser, FSRefs, análisis de XML, controles personalizados, ventana compuesta, ventana de cajón, ventana HIView y ventanas personalizadas. MacApp también tiene clases contenedoras de C++ para HIObject y HIView. Además, la versión Pascal, basada principalmente en MacApp-2, se ha adaptado a Mac OS X y Xcode. Incluye nombres de archivo Unicode largos y documentos transmitidos con intercambio automático de bytes.
MacApp es compatible con el IDE Xcode . De hecho, en la WWDC 2005 , después de que Apple anunciara la transición a las CPU Intel, un único desarrollador tardó 48 horas en actualizar MacApp y las aplicaciones de ejemplo de MacApp para que fueran compatibles con los binarios universales.
El sistema operativo Mac OS tiene un sistema de gestión de eventos muy simple. La estructura de eventos que se pasa del sistema operativo a la aplicación solo tiene un tipo de evento como "pulsación de tecla" o "clic del ratón", y detalles de su ubicación y las teclas modificadoras que se mantienen presionadas. Depende de la aplicación decodificar esta información simple en la acción que el usuario llevó a cabo, por ejemplo, hacer clic en un comando de menú. Decodificar esto puede ser difícil, ya que hay que recorrer listas de objetos en pantalla y verificar si el evento tuvo lugar dentro de sus límites.
MacApp proporcionó una solución a este problema utilizando el patrón de comando , en el que las acciones del usuario se encapsulan en objetos que contienen detalles del evento y luego se envían al objeto adecuado para llevarlas a cabo. La lógica de asignar el evento al "objeto adecuado" se manejó completamente dentro del marco y su entorno de ejecución, lo que redujo en gran medida la complejidad de esta tarea. El papel de la maquinaria interna de MacApp es tomar los eventos básicos del sistema operativo, traducirlos en comandos semánticamente de nivel superior y luego enviar el comando al objeto adecuado.
No sólo MacApp liberó al autor de tener que escribir este código, que todo programa requiere, sino que también, como efecto secundario, este diseño separó claramente el código en comandos , acciones orientadas al usuario, y sus controladores , el código interno que hacía el trabajo. Por ejemplo, uno podría tener comandos para "Ponerse verde" y "Ponerse rojo", ambos manejados por una sola función, ChangeColor(). Un programa que separaba claramente los comandos y los controladores se conocía, en el lenguaje de Apple, como factorizado .
La factorización de un programa fue particularmente importante en versiones posteriores del sistema operativo Mac, comenzando con System 7. System 7 introdujo el sistema Apple Events , que amplió el sistema de eventos del sistema operativo Mac original con uno mucho más completo que podía enviarse entre aplicaciones, no solo desde el sistema operativo a una aplicación en particular. Esto se combinó con el sistema AppleScript que permitió que estos eventos se generaran a partir de código de script. En MacApp 3.0, los eventos de Apple se decodificaban en los mismos comandos como si hubieran sido iniciados por acciones directas del usuario, lo que significa que el desarrollador no tenía que escribir mucho código, si es que tenía que escribir alguno, para manejar directamente los eventos de Apple. Este fue un problema importante para los desarrolladores que usaban sistemas anteriores, incluido MacApp 2.0, que no tenía tal separación y a menudo conducía a que se dejara de lado la compatibilidad con eventos de Apple.
En consonancia con su papel como marco de aplicación, MacApp también incluía una serie de objetos predefinidos que cubrían la mayor parte de la interfaz gráfica de usuario básica de Mac : ventanas, menús, cuadros de diálogo y widgets similares estaban todos representados dentro del sistema. Desafortunadamente, Apple normalmente proporcionaba envoltorios ligeros sobre el código interno existente de Mac OS en lugar de proporcionar sistemas que fueran utilizables en el "mundo real". Por ejemplo, la TTEViewclase se ofrecía como el widget de editor de texto estándar, pero la implementación subyacente de TextEdit estaba severamente limitada y la propia Apple a menudo afirmaba que no debería usarse para aplicaciones profesionales. Como resultado, los desarrolladores a menudo se veían obligados a comprar objetos complementarios para abordar este tipo de necesidades, o a desarrollar los suyos propios. La falta de un conjunto de objetos de interfaz gráfica de usuario de calidad profesional puede considerarse uno de los mayores problemas de MacApp.
Este problema se ha solucionado con el lanzamiento de MacApp R16. MacApp R16 utiliza controles Carbon estándar para todos los objetos de la interfaz gráfica de usuario de MacApp. Por ejemplo, Carbon introdujo el motor de texto multilingüe (MLTE) para compatibilidad total con texto Unicode y documentos largos. En R16, la TTEViewclase original ha sido reemplazada por TMLTEView, que utiliza el control MLTE.
Adobe Photoshop se escribió originalmente con MacApp 1.1.1, en Object Pascal , y luego se adaptó a C++ y MacApp 3.0 para Photoshop 2.5. Después de la cancelación de MacApp por parte de Apple, el equipo de desarrollo de Photoshop se hizo cargo del mantenimiento de forma interna, se adaptó a PowerPC y se transformó para que se compartiera con la plataforma Windows. [1]