Кристофер Ллойд (Christopher Lloyd) разрабатывает API для Mac OS X как open source. Проект носит название Cocotron и позволяет разработчикам кросс-компилировать Cocoa-программы (Mac OS X) для запуска в Windows или даже Linux.

Cocoa — объектно-ориентированная среда, созданная для разработки нативных программ для Mac OS X. Cocoa-фреймворк поддерживает высокую скорость и продуктивность разработки. Cocoa позволяет также переносить программы для других платформ на Mac OS X.

Вступление

Я думаю все слышали про Mac OS X как операционную систему для дизайнеров и домохозяек. Но хочется рассказать про средства разработки для OS X, а то хорошие программы пишут, а на чем — никто не знает.

Сразу скажу, что не буду рассказывать про кроссплатформенные фреймворки и тулкиты(такие как Qt) или про создание консольных приложений, я расскажу про то, что в плане создания приложений отличает Mac OS X от других операционных систем, а именно — фреймворк Cocoa. Оговорюсь сразу, что буду стараться избегать сравнений с другими фреймворками, я хочу просто рассказать про Cocoa.

В этой части я расскажу про еще одно интересное средство разработки приложений для Mac OS X — скриптового языка Apple Script.

Apple Script разрабатывался чтобы применяться конечными пользователями, а не программистами, и позволить им контролировать приложения и документы, с которыми они работают. Например, с помощью Apple Script можно открыть фотографию в редакторе изображений, обрезать до нужного размера, записать ссылку на фото в текстовый файл и т.п.

в этой статье я попытаюсь рассказать немного больше о Cocoa и его основных принципов. Скажу сразу, что материал не будет всеобъемлющим, поэтому матчасть учим здесь.

Откройте XCode и создайте новое Cocoa Application, назовите его DotView. Что будет делать наша программа? Она будет рисовать на компоненте NSView точку. Что такое NSView? Это базовый класс для графических виджетов Cocoa, поэтому если вы хотите создать свой собственный виджет, то скорее всего это будет наследник NSView.

Блогер Дрю Нельсон (Dru Nelson) пишет о стартапе 280 North и их вэб–приложении 280Slides.

Если бы это был просто вэб–аналог PowerPoint или Keynote, новость не подняла бы больших волн. Но все стало гораздо интереснее, когда Дрю заглянул «под капот» и увидел...

С одной стороны, перевод официальной документации не очень интересная вещь, с другой — этот перевод не встретишь нигде, сама документация написана достаточно живым языком, да и, собственно, — это мой личный блог. Но может быть, эта заметка будет интересна другим программистам, работающих на Маках.

Foundation представляет несколько парадигм и политик для программирования в Cocoa, чтобы обеспечить согласованное и ожидаемое поведение объектов программы в различных ситуациях.

Прошлым летом случилось страшное… Накрылся винт в моем МакБуке. Все важные данные были легко восстановлены. Слава Машине Времени! А вот музыкальной коллекции, которую я кропотливо взращивал годами, не повезло. Саму музыку восстановить не проблема, а вот рейтинги и количество прослушиваний, чья история уходит корнями в самое появление iTunes под Windows, ой как жалко. Пережила фонотека многое, в том числе перенос с Windows на Хакинтош, а затем и на МакБук.

Благо мадиатека была потеряна не вся — остались рожки да ножки, а точнее заветный файл "iTunes Library". На днях я решился его реанимировать.

Решение под Mac OS

Очевидное решение — использовать AppleScript. С помощью него практически любое приложение в Mac OS можно автоматизировать. Язык настолько близок к английскому и далек от других языков программирования, что ввел меня в ступор. Я не знал с какой стороны к нему подступиться.
Пришлось использовать XCode и немного знакомый Objective-C. Работа с XML не вызвала практически никаких проблем. NSXML… и MSXML оказались API очень похожими не только названием.

С общением с iTunes дела обстоят сложнее. Помимо собственно AppleScript, который можно использовать в проектах XCode, я нашел всего два способа. Оба по сути являются обертками для AppleScript.

На новых MacBook, MacBookPro и MacBookAir есть такие виды жестов (gestures):

двумя пальцами — скролл
двумя пальцами — увеличение (magnify)
двумя пальцами — поворот (rotate)

тремя пальцами — swipe вертикальный
тремя пальцами — swipe горизонтальный

четырьмя пальцами — swipe вертикальный
четырьмя пальцами — swipe горизонтальный

Как пользоваться этими жестами, подробно показано в System Preferences->TrackPad.

280 North, компания, стоящая за такими вещами как Cappuccino/Objective-J и 280 Slides, анонсировала на FOWA новый продукт — Atlas.
Для тех, кто не знает: если описать Cappuccino в двух словах, то это фреймворк, который помогает создавать вебдванольные приложения для веба, которые выглядят как десктопные.
Для этого нам предлагают использовать Objective-J — помесь Objective-C и JavaScript.
Подход, конечно, весьма спорный — далеко не все считают его правильным направлением развития.

Вернемся к Атласу. По сути — Interface Builder от Apple, только переделанный под Cappuccino и работающий в браузере. Многих веб-девелоперов/дизайнеров впечатлило. Достаточно и заявлений о том, что это очередной фэйл — мне более близка эта позиция.
На сайте на данный момент доступен только скринкаст, и предложение получать апдейты по е-мэйлу (адреса, кстати, собирают через гуглодокументы)
Релиз ожидается этим летом.

Все разработчики Cocoa знают про эту неприятную мелочь: при создании нового проекта Cocoa Application в Interface Builder’е нужно вручную править меню программы и менять NewApplication на название программы. По какой причине разработчики Xcode не автоматизировали этот процесс не понятно, т.к. это дело двух минут. Придется сделать это за них.

Cocotron — это реализация runtime для Objective-C, похожего на рантайм Apple — Cocoa. Он достаточно сильно отличается от другого популярного открытого рантайма — GNUstep, как в целях, так и в реализации.

Cocotron отлично подходит для портирования кода с платформы OSX на Win32. Конечно реализация API далека до идеала, но, как показывает практика, разработчики всегда быстро решают проблемы.

Изначально Cocotron использовался только при кросс-сборке на базе XCode и mingw-toolchain. При кросс-сборке доступно развертывание на Windows, Linux и Solaris.

Конечно такой подход оставлял в цепочке разработки самый сложный и дорогой этап — OSX (оптимально — на оригинальном железе). Возможность Cocotron, как платформы, не могла быть полностью раскрыта из-за этой зависимости.

Qt можно считать наиболее распространенной кроссплатформенной библиотекой для разработки пользовательских интерфейсов. Carbon (С++) и Cocoa (Objective-C), в свою очередь, являются основными фреймворками, используемыми Apple, что означает гармоничный внешний вид и наилучшую интеграцию с системой при их использовании. Несмотря на попытки создания свободных клонов, в полном объеме они реализованы только в MacOS.

Уверен, что вопросом связи Qt и Cocoa задавались многие, но в условиях отсутствия внятной информации в интернете вряд-ли достигли значимых успехов.

Сегодня мне наконец таки надоело запускать Firefox каждый раз, когда надо быстро выдернуть из сайта XPath для какого-то элемента (там для этого приятное расширение XPather), и я решил таки глянуть, как делать инъекции своего кода в Cocoa-приложения.

Во время работы потребовалось определять координаты объектов(широту и долготу). Поскольку Google Maps просто так не хотел их отдавать(или я не нашел как это просто сделать), то быстро написал небольшое Cocoa приложение, которое по введенному адресу получает от Google Maps координаты объекта и отображает его на карте.

Бытует расхожее мнение, что в Common Lisp нет или же плохая поддержка графики. Это еще один миф из серии, что Lisp — это язык только для подсчета факториалов. На самом деле, как и в большинстве других прикладных сфер общего назначения (например, веб, форматы передачи данных, взаимодействие с БД и т.д.) в Lisp-среде есть полный спектр библиотек и тулкитов для всех основных платформ с разными уровнями абстракции.

Linux/Unix

Базовой библиотекой для графики из Common Lisp под Unix является CLX. Это аналог xlib, т.е. низкоуровневый клиент, напрямую общающийся по X-протоколу.

Кроме того, есть обертки для основных графических фреймворков разной степени зрелости: LTK, CL-GTK2, CommonQt, CL-CAIRO2. Лично мне доводилось иметь дело с LTK, и работа с ним тривиальна. Хороший пример приложения, его использующего — простой и удобный Lisp-редактор/REPL ABLE.

Windows

Кроме возможности использовать кросс-платформенные фреймворки из прошлого раздела, есть еще LispWorks CAPI, о котором только положительные отзывы. Единственная особенность заключается в том, что, как и большинство профессиональных сред разработки на любых языках под Windows, LispWorks стоит довольно дорого (ок. 1200 $), а CAPI доступна только в профессиональной версии. (Впрочем, попробовать его можно и в trial версии).

Также есть CL-OPENGL, которая, разумеется, кросс-платформенная.

Многие наверняка сталкивались с необходимостью быстрого создания контролов в мобильном пользовательском интерфейсе. Рассмотрим стандартные кнопки UIButton. Базовый контрол мало устраивает взыскательного заказчика и зачастую стандартное решение, это натягивание на кнопки битмапов состояния. Растянутая ли это картинка или целиком вырезаная кнопка — решение требует дополнительных временных затрат на дизайн пользовательского интерфейса. Хорошо было бы иметь универсальный контрол, с более широкими визуальными возможностями, чем базовый UIButton.

Все более-менее сложные программные системы содержат ошибки (если и не собственные, то наведённые используемыми библиотеками или по причине неточного осознания поведенческих парадигм используемых фреймворков).
Часто, для тестирования системы на этапе разработки используются Unit-тесты.

Так программист может контролировать поведение системы на контрольных точках и пограничных значениях.
Часто именно неверная отработка пограничных значений приводит к проблемам. И опытные программисты это знают и учитывают при проектировании Unit-тестов.

Удобство Unit-тестов ещё и в том, что изменяя код вы ожидаете получить предсказуемые результаты и провести полностью автоматическое тестирование по имеющимся сценариям, чтобы быстро выявить наведённые изменениями неприятности.

Например, вы пишите код для работы на Intel и PPC, разрабатываете его на Intel, но учитываете порядок байтов. Потом прогоняете свои Unit-тесты, чтобы сравнить выходные данные с эталоном и обнаруживаете расхождения — понятно, где-то забыли байты перевернуть — исправляете — всё в порядке.

Однако, любой пользователь всегда несёт в себе элемент случайности.

Опытный программист сочетает в себе талант качественного тестировщика и может отловить много ошибок до выхода программы в свет.

Если программа делает больше чем печать «Hello World!», то скрытые ошибки в любом случае остаются.
Это могут быть ошибки и в логике в том числе.

Программа компилируется, все Warning'и устранены… но иногда что-то идёт не так… у пользователя (который живёт далеко в домике на островке в тихом океане — приехать к нему и пощупать нет возможности). Программист прокликал и протестировал со своей стороны всё что мог, но ошибки не нашёл. Что же делать?

Читая Mac OS X 10.6 Reference Library, я испытал смешанные эмоции: столько новых возможностей, но если их использовать, программы не смогут запуститься на PowerPC маках, и к тому же не все захотят ставить Снежного Барса, если их вполне устраивает Лео. Самым простым решением кажется не использовать эти возможности, но это значит ограничить себя. Не знаю как вы, но я не люблю, если меня ограничивают. Хочется чтобы программа использовала все преимущества Снежного Барса, но в то же время могла работать на прежней версии Mac OS X. Возможно ли это?

Многие об этом говорят, но какое на самом деле место занимает Cocoa environment в жизни IOS и MacOS, да и вообще что это за такая уличная магия?

Поприветствуйте Cocoa!

Cocoa — это основная среда приложений для Mac OS X (есть еще Carbon, но эта среда используется в основном только для поддержки кода написанного для Mac OS 9.) и единственная среда приложений для операционных систем IOS. Она состоит из набора объектно-ориентированных библиотек, исполняющей среды и среды разработки.
Большинство программ, которые используют пользователи Mac OS X (например, Mail или Safari), а тем более, пользователи IOS, это программы, написанные с помощью Cocoa.
Ну а для создания приложений под Cocoa используется знаменитый Xcode.

Как и с чем?

Как и во всех средах приложений, Cocoa имеет два мира: мир runtime'а и

Objective-C, в отличие от иных языков, тип указателя у объектов не имеет особого значения во время исполнения при посылке сообщений и используется лишь во время компиляции. Просто выполните и проверьте:

NSNumber *string = [[NSString alloc] initWithString: @"hello"]; 
NSLog(@"%@", string); 

Вы же не сомневались ;-) Мы бы могли использовать любой тип или вообще id.
Во время исполнения же всю нужную информацию получают у class object, через переменную isa. class object, c типом Class (или просто класс) – это синглтон, и поэтому классы у объектов можно сравнить простым сравнением указателей:

[object class] == [object2 class]; 

Если собрать всё информацию из class object, то несложно восстановить интерфейсы у объектов во время исполнения.