Войти
МасАрр был Apple Computer «s объектно - ориентированная среда разработки приложения для классической Mac OS. Выпущенный в 1985 году, он перешел с Object Pascal на C ++ в версии 3.0 1991 года, которая предлагала поддержку большей части новых функциональных возможностей System 7. MacApp использовался для множества основных приложений, включая Adobe Photoshop и SoftPress Freeway. Microsoft «s MFC и Borland » s OWL оба были основаны непосредственно на концепциях МасАрра.
В течение десяти лет у продукта были периоды, когда он мало развивался, после чего следовали всплески активности. За этот период, Symantec «s Подумайте Библиотека классов / Think Паскаль стал серьезным конкурентом МасАрр, предлагая более простую модель в гораздо более высокой производительности интегрированной среды разработки (IDE).
Symantec не спешила реагировать на переход на платформу PowerPC в начале 1990-х годов, и когда Metrowerks впервые представила свою систему CodeWarrior / PowerPlant в 1994 году, она быстро вытеснила MacApp и Think в качестве основных платформ разработки на Mac. Даже Apple использовала CodeWarrior в качестве основной платформы разработки в эпоху Copland в середине 1990-х годов.
МасАрр имел краткую отсрочку в период между 2000 и 2001 годами, в качестве системы для перехода к углероду системе в MacOS X. Однако после демонстрации версии на Всемирной конференции разработчиков (WWDC) в июне 2001 года вся разработка была прекращена в октябре того же года.
MacApp был прямым потомком Lisa Toolkit, первой попытки Apple по разработке инфраструктуры объектно-ориентированных приложений под руководством Ларри Теслера. В команду разработчиков Toolkit входили Ларри Розенштейн, Скотт Уоллес и Кен Дойл. Инструментарий был написан на специальном языке, известном как Clascal, который добавил объектно-ориентированные методы в язык Pascal.
Изначально разработка для Mac велась с использованием кросс-компилятора в Lisa Workshop. Когда продажи Mac фактически прекратили продажи Lisa, началась работа по созданию новой платформы разработки для Mac. Мастерская программиста Лизы стала в 1985 году Мастерской программиста Macintosh, или MPW. В рамках этого процесса Clascal был обновлен до Object Pascal, а Lisa Toolkit предложила примечания к дизайну того, что стало MacApp.
Написание программы для Mac без фреймворка приложения - непростая задача, но в то время область объектно-ориентированного программирования была еще относительно новой и многими разработчиками считалась несколько подозрительной. Ранние фреймворки, как правило, подтверждали это подозрение, будучи большими, медленными и, как правило, негибкими.
MacApp был, пожалуй, первым действительно пригодным для использования фреймворком во всех смыслах этого слова. Скомпилированные приложения были вполне разумными с точки зрения размера и объема памяти, а производительность была не настолько плохой, чтобы разработчики этого не делали. Хотя первые выпуски были «слишком простыми», в ряде последующих версий были быстро решены основные проблемы. К этому моменту, примерно в 1987 году, система превратилась в полезный инструмент, и ряд разработчиков начали использовать ее в крупных проектах.
MacApp 2.0 был выпущен в 1989 году. Среди улучшений было упрощение некоторых взаимодействий элементов пользовательского интерфейса и поддержка Multifinder. Поскольку Apple объявила об отказе от поддержки MPW Pascal в 1992 году, эта версия не была обновлена, даже с поддержкой System 7, и разработчики Pascal были лишены возможности самостоятельно переносить MacApp 2.0 на PowerPC.
К этому моменту, в конце 1980-х, рынок двигался в сторону C ++, и бета-версия компилятора Apple C ++ появилась в 1989 году, примерно в версии MacApp 2.0. В то же время Apple прилагала все усилия, чтобы выпустить Систему 7, в которой был ряд важных новых функций. Было принято решение перейти на совершенно новую версию MacApp 3.0, в которой вместо Object Pascal будет использоваться C ++. Этот шаг стал предметом долгих и жарких споров между сторонниками Object Pascal и C ++ в Usenet и других форумах. Тем не менее, 3.0 удалось собрать разумное количество поклонников после его выпуска в 1991 году, даже несмотря на то, что пакет разработчика, MPW, становился устаревшим. Затем Apple сократила всю группу инструментов для разработчиков, оставив MacApp и MPW недоукомплектованными.
Одной из причин этого сокращения была долгая сага Apple о попытках представить «следующую великую платформу» для разработки, почти всегда в форме какой-то кроссплатформенной системы. Их первой попыткой была Bedrock, библиотека классов, созданная в партнерстве с Symantec, которая работала на Mac и Windows, но умерла медленной смертью, поскольку обе стороны в конечном итоге отказались от работы друг с другом. Одной из причин их проблем было создание OpenDoc, который сам был разработан в кроссплатформенную систему, которая напрямую конкурировала с Bedrock. Были попытки позиционировать Bedrock как платформу OpenDoc, но из этого ничего не вышло.
Пока происходили эти разработки, MPW и MacApp по большей части игнорировались. Гораздо важнее было вложить ресурсы разработчиков в эти новые проекты, чтобы помочь им быстрее выйти на рынок. Но когда Bedrock потерпел неудачу и OpenDoc встретил вялый прием, на Mac остались инструменты, которым уже почти десять лет, и которые не могут конкурировать с новыми продуктами сторонних производителей. В начале 1990-х конкурирующие фреймворки превратились в реальных конкурентов MacApp. Сначала у Symantec TCL появилось много поклонников, но затем PowerPlant Metrowerks захватил весь рынок.
Основные разработчики MacApp продолжали работать над системой на низком уровне активности в течение 1990-х годов. Когда все «официальные» кроссплатформенные проекты Apple рухнули, в конце 1996 года команда объявила, что они будут предоставлять кроссплатформенную версию MacApp.
Вскоре после этого Apple купила NeXT и объявила, что OpenStep будет основной платформой разработки Apple, которая будет двигаться вперед под названием Cocoa. Какао уже было кроссплатформенным, в то время его уже портировали примерно на шесть платформ, и он был намного более продвинутым, чем MacApp. Это привело к решительным протестам со стороны существующих программистов Mac, протестовавших против того, что их программы были отправлены в « штрафную », а фактически от них отказались.
На WWDC'98 Стив Джобс объявил, что негативные отзывы о переходе на Cocoa устраняются путем введения системы Carbon. Carbon позволит существующим программам Mac работать в новой операционной системе изначально после некоторого преобразования. Компания Metrowerks объявила, что будет переносить свой фреймворк PowerPlant на Carbon, но Apple не сделала аналогичных заявлений относительно MacApp.
В течение этого периода оставалось ядро лояльных пользователей MacApp, которые все больше разочаровывались в поведении Apple. К концу 1990-х, во время появления какао, это привело к прямому отказу от продукта. Дела были настолько плохи, что группа пользователей MacApp зашла так далеко, что организовала собственную встречу на WWDC '98 под вымышленным именем, чтобы сотрудники Apple не отказывали им в комнате для встречи.
Эта постоянная поддержка была замечена внутри Apple, и в конце 1999 года «новой» команде MacApp, состоящей из членов, которые работали над этим все время, была поставлена задача выпустить новую версию. Включены новые Apple Class Suites (ACS), более тонкий слой оболочек C ++ для многих новых функций Mac OS, представленных из OpenStep, и поддержка сборки в Project Builder. MacApp 3.0 Release XV был выпущен 28 августа 2001 года, и многие обрадовались. Однако в октябре продукт снова был убит, на этот раз навсегда, а поддержка существующих версий MacApp официально прекратилась.
Углеродно-совместимый PowerPlant X не поставлялся до 2004 года, и сегодня Cocoa почти универсален для программирования как для MacOS, так и для iOS.
MacApp поддерживается специальной группой разработчиков, которые поддерживали и улучшали структуру с тех пор, как Apple прекратила ее поддержку в 2001 году. MacApp был обновлен для полной поддержки событий углерода, универсальных двоичных файлов, текста Unicode, элемента управления MLTE, элемента управления DataBrowser, FSRefs, Анализ XML, настраиваемые элементы управления, составное окно, окно ящика, окно просмотра и настраиваемые окна. MacApp также имеет классы-оболочки C ++ для HIObject и HIView. Также версия Pascal, основанная в основном на MacApp-2, была перенесена на Mac OS X и Xcode. Он имеет длинные имена файлов Unicode и потоковые документы с автоматической заменой байтов.
MacApp поддерживает Xcode IDE. Фактически, на WWDC 2005, после того как Apple объявила о переходе на процессоры Intel, одному разработчику потребовалось 48 часов, чтобы обновить MacApp и примеры приложений MacApp для поддержки универсальных двоичных файлов.
Сама Mac OS имеет очень простую систему обработки событий. Структура события, передаваемая из операционной системы в приложение, содержит только тип события, такой как «нажатие клавиши» или «щелчок мышью», а также сведения о его местонахождении и удерживаемых клавишах-модификаторах. Приложение должно декодировать эту простую информацию в действие, которое пользователь выполнил, например, щелкнув команду меню. Расшифровать это может быть сложно, просматривая списки экранных объектов и проверяя, произошло ли событие в пределах их границ.
MacApp предоставил решение этой проблемы с использованием шаблона команд, в котором действия пользователя инкапсулируются в объекты, содержащие сведения о событиях, а затем отправляются соответствующему объекту для их выполнения. Логика сопоставления события с «правильным объектом» полностью обрабатывалась в рамках фреймворка и его времени выполнения, что значительно снизило сложность этой задачи. Роль внутреннего механизма MacApp состоит в том, чтобы принимать основные события ОС, преобразовывать их в семантически более высокоуровневые команды, а затем направлять команду соответствующему объекту.
MacApp не только избавил автора от необходимости писать этот код, который требуется для каждой программы, но и в качестве побочного эффекта этот дизайн четко разделил код на команды, действия, ориентированные на пользователя, и их обработчики, внутренний код, который выполнял работу.. Например, один может иметь команды для «зеленеть» и «краснеют», оба из которых обрабатываются с помощью одной функции, ChangeColor(). Программа, которая четко разделяла команды и обработчики, была известна, говоря языком Apple, с факторизацией.
Факторинг программы был особенно важен в более поздних версиях Mac OS, начиная с System 7. Система 7 представила систему Apple Events, которая расширила исходную систему событий Mac OS гораздо более богатой, которая могла быть отправлена между приложениями, а не только из ОС в конкретное приложение. Это было объединено с системой AppleScript, которая позволяла генерировать эти события из кода сценария. В MacApp 3.0 события Apple Events были декодированы в те же команды, как если бы они были инициированы прямыми действиями пользователя, а это означает, что разработчику не нужно было писать много кода, если таковой имеется, для непосредственной обработки событий Apple. Это было серьезной проблемой для разработчиков, использующих более ранние системы, включая MacApp 2.0, в которых не было такого разделения и часто приводило к тому, что поддержка Apple Event не учитывалась.
В соответствии со своей ролью каркаса приложений, MacApp также включал в себя ряд предварительно свернутых объектов, охватывающих большую часть основного графического интерфейса Mac - окна, меню, диалоговые окна и аналогичные виджеты были представлены в системе. К сожалению, Apple обычно поставляла легкие оболочки поверх существующего внутреннего кода Mac OS вместо того, чтобы предоставлять системы, которые можно было использовать в «реальном мире». Например, TTEViewкласс предлагался как стандартный виджет текстового редактора, но основная реализация TextEdit была сильно ограничена, и сама Apple часто заявляла, что его не следует использовать для профессиональных приложений. В результате разработчикам часто приходилось покупать дополнительные объекты для решения подобных задач или создавать собственные. Отсутствие набора графических объектов профессионального качества можно считать одной из самых больших проблем MacApp.
Эти проблемы были устранены в выпуске MacApp R16. MacApp R16 использует стандартные элементы управления Carbon для всех объектов графического интерфейса MacApp. Например, Carbon представила многоязычный текстовый движок (MLTE) для поддержки полного текста Unicode и длинных документов. В R16 исходный TTEViewкласс был заменен классом TMLTEView, который использует элемент управления MLTE.
Adobe Photoshop изначально был написан с MacApp 1.1.1 на Object Pascal, а затем перенесен на C ++ и MacApp 3.0 для Photoshop 2.5. После отмены MacApp Apple, обслуживание было взято на себя внутри команды разработчиков Photoshop, перенесено на PowerPC и преобразовано для совместного использования с портом платформы Windows.
