Как Какао выдерживает сравнение с Microsoft, QT?

Я работал с Cocoa / Obj-C на протяжении многих лет. По состоянию на 2010 год я считаю это весьма ограничивающим по сравнению с WPF / NET Framework. Я перечислю некоторые из обнаруженных мною отличий, и вы можете судить сами.

Язык разметки

Когда я разрабатываю в WPF, я получаю разметку, которая представляет собой очень простой XML, который я могу легко редактировать вручную или редактировать с помощью инструментов, которые я пишу сам. В Какао я должен использовать файлы xib, которые не предназначены для простого ручного редактирования или манипуляций. Вот простой пример разметки WPF:

<DockPanel>
  <Label>Select your favorite food:</Label>
  <ComboBox
    SelectedText="{Binding FavoriteFood}"
    SelectedItemsSource="{Binding AllFoods}" />
</DockPanel>

Это вся разметка, эквивалентная примерно 50 строкам трудно редактируемого .xib.

Возможность видеть и редактировать простой XAML невероятно ценно для:

• Прямого редактирования вручную
• Связи с одноранговыми узлами (например, StackOverflow)
• Управления исходным кодом
• Поиска
• Автоматических преобразований

Макета возможности

В WPF я могу использовать панели для автоматического размещения элементов управления при изменении размера окна. Я могу использовать стили, чтобы определить расстояние между моими элементами управления, или я могу настроить поля, чтобы получить точный вид, который я хочу, или и то, и другое. В любом случае мой пользовательский интерфейс автоматически подстраивается под изменения размеров шрифта, размера окна и разрешения экрана. В Какао все элементы управления находятся в определенных местоположениях по осям x и y, как и в WinForms, и единственное, что я могу сделать, - это автоматически изменять размер. Это крайне ограничивает.Например:

• Элементы управления не могут переходить в новую строку или столбец, поскольку окно становится меньше (WrapPanel)
• Элементы управления не могут добавлять / удалять детали в зависимости от доступного пространства
• Элементы управления не могут перемещаться, чтобы освободить место для элемента управления в котором текста больше, чем ожидалось
• Элементы управления не могут выборочно сжиматься или увеличиваться для заполнения доступного пространства.
• Интерфейсный разработчик изначально устанавливает элементы управления в соответствии с руководящими принципами интерфейса, но применение нового стиля не может изменить макет.

Преимущество макета WPF заключается в том, что вы можете выразить свое намерение с помощью того, как вы добавляете элементы управления на панели, а затем настраиваете точный макет позже. Обратите внимание, что WPF также может работать по старинке, но как только вы используете панели для макета, вы никогда не вернетесь к макету X / Y.

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

Связь с данными

С Cocoa / Obj-C вы в значительной степени ограничены встроенной связью с данными, которая включает в себя базовый доступ к базе данных и сериализацию в файлы и из файлов.С помощью WPF / NET Framework вы можете напрямую привязать свой пользовательский интерфейс практически ко всему, что находится под солнцем, включая:

• Реляционные базы данных (SQL, Oracle и т. Д.)
• Объектные базы данных (Objectivity, Versant и т. Д.)
• Устаревшие базы данных ( Access, dBase, R: Base и т. Д.)
• Базы данных COBOL на мэйнфреймах
• Форматы собственных баз данных (сотни)
• Веб-страницы
• Веб-сервисы (SOAP, REST и т. Д.)
• XML-файлы
• Плоские файлы (с разделителями-запятыми, разделителями табуляции, фиксированной шириной)
• Документы Office (Word, Excel и т. Д.)
• Документы OpenOffice
• Поля формы PDF
• Данные GPS-приемника (текущее местоположение)
• Положения физических переключателей, кнопок, рычагов, ручек, ползунков и т. Д.
• Время (локальное или сетевое)
• Счетчики производительности (загрузка ЦП и т. Д.)
• Камеры (видеокамеры, веб-камеры, фотоаппараты и т. Д.) )
• Аналоговые электронные входы
• MIDI (клавиатуры музыкальных инструментов, звукосниматели и т. Д.)
• OBD-II (мониторинг транспортных средств)
• LDAP и Active Directory (информация об учетной записи пользователя)
• WBEM и SNMP (состояние и конфигурация сетевого устройства)

Фактически, вы можете выполнить привязку практически ко всему, для чего был написан драйвер на любом языке NET Framework - а существует более сотни языков NET Framework.

Повторяющийся код

В Какао ваша модель состоит из файлов .h и .m, ваш контроллер состоит из файлов .h и .m, а ваше представление состоит из файла .xib.Каждое поле в каждом объекте вашей модели должно иметь ссылку в каждом из этих мест!

В WPF / NET одно поле обычно появляется только в двух строках кода: один раз там, где определена модель, и один раз там, где она представлена ​​представлением. Например, в моем коде я обычно определяю простые поля модели в XML:

<Property Name="City" Type="string" />

затем, чтобы создать текстовое поле для редактирования города, я просто перетаскиваю свойство «Город» в свое представление и получаю этот XAML:

<TextBox Text="{Binding City}" />

Итак «Город» упоминается только в двух строках кода во всем моем приложении (если у меня нет другого текстового поля «Город» в другом месте). В Какао «Сити» будет упоминаться минимум пять раз.

Привязка непосредственно к модели

В Какао один контроллер действительно подходит только для одного представления: если вы создаете новое представление для той же модели, вам нужен новый контроллер. В WPF / NET есть лучший способ сделать это, хотя вы все равно можете создавать контроллеры, если вы действительно хотите.

В WPF / NET представление обычно привязывает большую часть своих элементов управления непосредственно к модели (см. Мой пример города выше). Другие элементы управления будут привязаны к «модели представления», моделирующей информацию о состоянии, связанную с текущим представлением. Например, если вы выполняете поиск, «Модель представления» будет содержать строку поиска, поэтому она может использоваться представлением как для фильтрации результатов, так и для выделения текста поиска.

В WPF / NET вы также можете привязать несколько свойств элемента управления к одной или разным частям вашей модели (или модели представления):

<TextBox Text="{Binding AmountToTransfer}"
         Background="{edf:Binding UserIsHappy ? Green : White}" />

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

Командная архитектура

В Какао кнопка сохраняет свою цель и действие в NSActionCell в представлении, что означает, что она будет вызывать определенный метод для определенного объекта (обычно контроллера). В WPF / NET кнопка имеет событие Click, которое работает таким же образом, но также имеет свойство Command, позволяющее вызывать команду.

Команды в WPF очень мощные, так как одна команда может использоваться во всем приложении. Например, сам WPF определяет команду «Удалить». Пока ваша модель реагирует на эту команду, добавить кнопку «Удалить» в ваше представление так же просто, как выбрать команду «Удалить» в окне свойств, которая создает этот XAML:

<Button Command="Delete" />

Это все, что вам нужно сделать, чтобы получить функциональная кнопка удаления, удаляющая объект из списка.Также обратите внимание на встроенную команду «Удалить»:

• Имеет привязку к клавише «Удалить» на клавиатуре.
• Предоставляет текст на соответствующем языке («Удалить» или «Элиминар», или «Löschen», или «Supprimer», или .. .)
• Включает описательную подсказку

Команда направляется к объектам-предкам и моделям, поэтому в типичном приложении вам почти никогда не нужно указывать, какой объект получает команду.

Таблицы стилей

В Какао нет механизма для применения таблиц стилей к панелям, чтобы они влияли на все элементы управления на панели, либо во время разработки, либо во время выполнения. Например, приложению может потребоваться:

• Сделать все текстовые поля в данной области доступными только для чтения
• Сделать все метки жирным шрифтом
• Придать всем комбинированным полям светло-зеленый фон
• Добавить равномерный интервал между набором кнопок
• Используйте большую зеленую галочку для набора флажков
• Добавить кнопку «Удалить» во все списки
• Сделать все кнопки «Удалить» в виде красного «заштрихованного» X вместо традиционной кнопки
• Сделать то же самое настройки нескольких отдельных элементов

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

<Button Style="{StaticResource DeleteButtonStyle}" />

Таблицы стилей могут быть определены где угодно: в управляющих библиотеках, на уровне приложения, специфичном для «темы», в окне, в определенном словарь ресурсов элемента управления или непосредственно в элементе управления.

Шаблоны элементов управления

В Какао вы не можете многое сделать для изменения визуального стиля элементов управления, кроме как создать их подклассы, поскольку каждый из них рисует свой собственный внешний вид.В WPF / NET внешний вид элемента управления задается его шаблоном, который можно свободно заменить практически всем, что вы можете придумать.

Например:

• Вы можете использовать ListBox в раскрывающихся меню и настроить его так, чтобы он выглядел как обычные пункты меню (с флажком рядом с текущим выбранным элементом)
• Вы можете изменить отображение TreeView как последовательность ListBoxes вместо дерева
• . Вы можете изменить "большой палец" ползунка, чтобы он отображался как деловой символ или персонаж мультфильма в зависимости от вашей целевой аудитории (двигайте лампочку или Микки Мауса вперед и назад)
• Вы можно изменить ползунок, чтобы он отображался как ручка или следовал нелинейным путем.
• Вы можете изменить флажок, чтобы он отображался как кнопка щелчка / выключения, значок замка, который открывается и закрывается, или дверь, которая открывается и shuts

Шаблоны управления и шаблоны данных могут также включать встроенную анимацию, так, например, ваша дверь может фактически анимировать распахивание и закрытие, когда вы нажимаете на нее. В Expression Blend это сделать тривиально просто: требуется около 20 щелчков мыши. Просто создайте две линейные анимации и прикрепите их к триггерам событий.

Пользовательские элементы управления

Какао, так и WPF позволяют создавать подклассы существующих элементов управления для создания новых. В Какао новые элементы управления сериализуются в файл .xib / .nib. В WPF они являются частью XAML, как и встроенные элементы управления:

<StackPanel>
  <TextBlock>
    Hello, <Run Text="{Binding FirstName}" />.
    <Bold>Good morning!</Bold>  How are you today?
  </TextBlock>
  <my:JoySelector Happiness="{Binding Happiness}" />
</StackPanel>

В этом примере JoySelector будет элементом управления, который я определил, а Happiness будет одним из его свойств.

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

Например, в Какао вы можете написать:

CGSize size = CGSizeMake(30, 20);
UIGraphicsBeginImageContext(size);
CGContextRef context = UIGraphicsGetCurrentContext();
CGContextSetRGBFillColor(context, 1.0, 1.0, 0.0, 0.0);
CGContextFillEllipseInRect(context, rect);
UIImage *image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();
return image;

тогда как в WPF с использованием XAML эквивалент будет:

<Ellipse Width="30" Height="20" Fill="Red" />

или в WPF в коде (C #):

return new Ellipse { Width=30, Height=30, Fill=Brushes.Red };

ControlTemplate, конечно, может иметь несколько элементов:

<ControlTemplate TargetType="my:JoySelector">
  <Grid Width="50" Height="50">
    <Ellipse Width="30" Height="20" Fill="Red" VerticalAlignment="Left" />
    <Path Data="M0,0 L3,5 L8,8 L5,3 L0,0" Fill="Blue" />
    <ComboBox
      SelectedItem="{TemplateBinding Happiness}"
      Style="{StaticResource JoySelectorBoxStyle}" />
  </Grid>
</ControlTemplate>

Этот XAML обычно создается в Expression Blend с помощью щелкнув правой кнопкой мыши JoySelector, выбрав «Правка»> «Шаблон»> «Создать новый», нарисовав эллипс, контур и ComboBox с помощью инструментов рисования и выбрав привязку и стиль ComboBox в окне «Свойства».

Шаблоны данных

В Какао, если вам нужен список или дерево элементов различных типов, таких как инвентарь оборудования в игре или список различных типов счетов (инвестиционный, денежный рынок, сбережения), вы можете многим придется все это кодировать самостоятельно. В WPF / NET вы можете использовать DataTemplates.

Например, если у каждого оружия есть «сила удара» и «сила защиты», вы можете включить такой шаблон данных:

<DataTemplate TargetType="game:Weapon">
  <DockPanel TextElement.FontWeight="Bold">
    <Image Source="{StaticResource WeaponDrawing}" />
    <TextBlock Text="{Binding WeaponName}" DockPanel.Dock="Top" />
    <TextBlock Text="{Binding HitStrength}" Foreground="Red" />
    <TextBlock Text="{Binidng DefenseStrength}" Foreground="Blue" />
  </DockPanel>
</DataTemplate>

Другие игровые объекты будут использовать другие шаблоны, тогда инвентарь может отображаться с помощью ListBox используя WrapPanel, чтобы расположить их в порядке чтения. (Обратите внимание, что в WPF ListBox не обязательно должен представлять свои элементы в виде вертикального списка: можно использовать любую панель.)

Этот же метод важен в LOB-приложениях: например, вы можете иметь представление по умолчанию для Invoice, который устанавливается в DataTemplate всего приложения, поэтому любая часть вашего приложения, которая представляет списки Invoice, будет автоматически отображать их в формате по умолчанию. Это может быть значок, номер счета, всплывающая подсказка с дополнительной информацией и контекстное меню, позволяющее открывать и / или редактировать счет.

Триггеры и анимация

В Какао вы можете делать анимацию, но должны писать код как для создания анимации, так и для ее применения. В WPF вы можете определить анимацию, используя временную шкалу в Expression Blend, и установить EventTriggers и PropertyTriggers в представлении для управления ее запуском. Чтобы создать анимацию, которая качает кнопку, просто щелкните правой кнопкой мыши, чтобы создать временную шкалу, установите положение кнопки, поворот или масштаб с помощью мыши в нескольких точках на временной шкале и измените автоматически созданный EventTrigger на нужное событие. чтобы активировать кнопку.

Какао не имеет хранилища свойств анимации или механизма принуждения, поэтому любые изменения, сделанные анимацией, являются постоянными: вы не можете удалить анимацию и вернуть значения свойств. Кроме того, вы не можете анимировать свойства общих ресурсов (например, цвета кисти), не копируя их вручную, и вы не можете анимировать до значений, выходящих за пределы допустимого диапазона, и чтобы сам элемент управления приводил к соответствующему значению. В WPF система анимации имеет возможность отдельно отслеживать значения анимации, связанные значения, значения по умолчанию и принудительные значения, чтобы вы не столкнулись с этими проблемами.

В WPF вы можете настроить анимацию для запуска при событиях пользовательского интерфейса, таких как нажатие кнопки, изменение состояния свойств (включая изменения данных в модели), события, генерируемые моделью, для непрерывного выполнения или с помощью кода.

В WPF вы можете создавать собственные классы анимации и использовать их с Expression Blend, как если бы они были частью WPF. Вы также можете рисовать объекты Geometry, используемые встроенной PathAnimation, а не кодировать их самостоятельно.

Обратите внимание, что WPF может создавать и запускать анимацию в коде, если вы действительно этого хотите. Также обратите внимание, что внедрение анимации из отдельного приложения, такого как Quartz Composer, - это не то же самое, что анимация свойств объектов пользовательского интерфейса. И Cocoa, и WPF могут встраивать анимацию, созданную с помощью других технологий, но с WPF вы можете использовать Expression Blend для создания временной шкалы, которая анимирует любую часть вашего пользовательского интерфейса.

Преобразования как часть привязки

Какао имеет возможность выполнять преобразования в и из одного значения с помощью NSFormatter. Все более сложное нужно делать в контроллере. В WPF вы можете использовать StringFormat для простых случаев. Обложка встроенных NSFormatters Какао, но вы также можете указать IValueConverter или IMultiValueConverter для реализации настраиваемого преобразования значений. Например, вы можете добавить настраиваемый преобразователь к ряду данных гистограммы, чтобы элементы данных в гистограмме быстро отображали целевые значения (известная как «желевая» анимация). Конвертеры WPF могут быть односторонними или двусторонними и могут преобразовывать одно значение или несколько значений.

Преобразования также позволяют вам выполнять привязку к нескольким свойствам или вычислениям и форматировать результат, например:

<TextBlock Text="{edf:Binding (Height + Width)/2, StringFormat=0.000}" />

Этот вид привязки с преобразованием невозможен в Какао.

Сторонние элементы управления

В Какао вы обычно можете включать в свое приложение только виджеты пользовательского интерфейса, разработанные для Какао. В WPF вы можете включать элементы управления WPF, но вы также можете включать разделы своего пользовательского интерфейса, разработанные с использованием WinForms, MFC, HTML, Java, Flash и других технологий.WPF предоставляет возможности для интеграции этих других технологий непосредственно в WPF, даже в той степени, в которой его система разметки используется для создания объектов и установки их свойств, например:

<StackPanel>
  <TextBlock>Here is a WinForms control:</TextBlock>
  <WindowsFormsHost>
    <tools:LegacyChartingControl
      Width="20" Height="30"
      Title="Graph of something"
      SeriesXMin="0"
      SeriesXMax="10" ... />
  </WindowsFormsHost>
</StackPanel>

Внешне-created media

Как Cocoa, так и WPF могут включать в себя такие мультимедиа, как видео, анимацию и растровые изображения, которые были созданы в сторонних инструментах. Каждая среда поддерживает все такие типы мультимедиа, поддерживаемые базовой операционной системой. WPF предоставляет немного больше, чем Cocoa, с точки зрения управления мультимедиа, например, если вы установите для команды кнопки значение «MediaCommands.NextTrack» или «MediaCommands.FastForward», мультимедиа автоматически ответит соответствующим образом. Кроме того, WPF обеспечивает некоторые улучшения асинхронной загрузки мультимедиа.

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

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

Сборка мусора

В 2007 году сборка мусора наконец-то поддерживается в Cocoa / Obj-C, но многие библиотеки по-прежнему не могут с ней справиться, поэтому большая часть кода Cocoa, который пишется сегодня, по-прежнему использует ручное выделение памяти с подсчетом ссылок. . Таким образом, даже сегодня вы по-прежнему разбросаны по всему коду Какао "[abc release]"! В WPF / NET с первого дня существует сборка мусора, поэтому этой проблемы нет.

Выполнение в веб-браузере

Какао-приложения в настоящее время ограничены выполнением как настольные приложения, тогда как WPF может работать в веб-браузере так же легко, как и на рабочем столе, с использованием технологии XBAP или Silverlight.

Кросс-платформенная совместимость

История здесь похожа:

• Какао-приложения изначально работают в Mac OS X, а также могут работать в Windows и Linux с помощью Cocotron или GNUstep и ограничивая себя подмножеством функций .

• Приложения WPF изначально запускаются в Windows, а также могут работать в Mac OS X и Linux, используя Silverlight и ограничивая себя подмножеством функций.

Единственное существенное отличие состоит в том, что Silverlight может работать в браузере и имеет гораздо лучшую поддержку и инструменты от поставщиков, чем Cocotron или GNUstep.

Другие расширенные возможности WPF

До сих пор я не нашел в Какао никаких возможностей, которых нет также в WPF / NET, но я нашел в WPF / NET многие, которых нет в Какао, например:

• Все элементы управления, такие как кнопки, текстовые поля, поля со списком и т. Д., Могут работать как в 3D-сценах, так и в 2D-макетах. Их также можно произвольно растягивать, вращать, наклонять и т. Д.
• Расширенные возможности рисования, такие как PolyBeziers, комбинированная геометрия, RenderTransform vs LayoutTransform, контроль альфа-прозрачности и т. Д.
• Расширенные кисти, такие как градиентные кисти, кисти мозаичного изображения и т. Д. «Визуальные кисти», которые позволяют создавать произвольно сложные кисти для рисования, например, вы можете нарисовать отражение вашего окна, включая все его элементы управления.
• Подсистема анимации позволяет анимировать практически все свойства, например, я анимировал свойство TextBox «Text», чтобы казалось, что текст набирается в

Сторонних алгоритмах и драйверах

Cocoa / Obj-C может вызывать предварительно скомпилированные библиотеки, использующие соглашения о вызовах C, и вызывать методы вызова для объектов, определенных в некоторых других языках. Это означает, что API в стиле C обычно требуется для стороннего кода, который необходимо интегрировать в ваше приложение. WPF / NET может включать код, написанный на более чем 100 языках, непосредственно в ваше приложение и позволяет вам напрямую получить доступ ко всем функциям. Кроме того, он также может вызывать предварительно скомпилированный код, написанный на других языках с использованием C, C ++, COM, DCOM, веб-служб и других соглашений о вызовах. Кроме того, существуют прокладки с открытым исходным кодом, позволяющие коду NET Framework напрямую обращаться к множеству других языков и систем. Это означает, что приложения WPF почти никогда не должны включать в себя больше, чем небольшое количество связующего кода для подключения к стороннему коду, включая драйверы устройств.

Сравнение языков

Сравнение Objective-C и C # - важная задача, и я не буду ее пытаться. Достаточно сказать, что начиная с версии 4.0 C # содержит все функции Objective-C и многие, многие, многие другие. Я изучил Objective-C в 1989 году - задолго до того, как был задуман C #, - и в то время это был удивительно мощный язык. Теперь, когда я использую его, я съеживаюсь, особенно из-за потери LINQ и Generics.

Попробуйте такое преобразование данных в Objective-C:

DataContext =
  from lesson in AllLessons
  where lesson.Active
  groupby lesson.Category into category
  select new
  {
    categoryName = category.Key.Name,
    lessonsInCategory =
      from lesson in category
      select new
      {
        lesson,
        fullName = lesson.ShortName + " " + lesson.Suffix,
        priority = rand.Next(10)
      }
  };

Если AllLessons предоставляется динамически, вы можете напрямую связать этот результат в WPF (с помощью ) и динамически обновлять его в режиме реального времени.

При использовании LINQ с C # вы также можете выполнять объединения, сортировку и т.д.закончить код, который нужно написать, а IntelliSense Visual Studio поможет вам заполнить имена свойств и т. д. при редактировании и даже подчеркнет ваши ошибки.

Я не знаю хороших сравнений между Objective-C и C #, но есть хорошее сравнение между C # и Java в wikipedia, в котором упоминаются многие функции C #, которые также отсутствуют в Objective-C.

Привязки языков

Какао не ограничивается Objective-C, а WPF не ограничивается C #. Оба доступны с ряда других языков. Разница в том, что Cocoa построен на Objective-C, поэтому использование его с другого языка может стать довольно неудобным. Например, действия становятся вызовом метода Objective-C, семантика которого сильно отличается от семантики Java или других языков. С другой стороны, WPF был намеренно разработан так, чтобы не требовать каких-либо специальных функций C #, поэтому его можно было легко использовать на других языках. Например, при использовании с Java (в котором отсутствуют истинные свойства) PropertyDescriptor вместо этого использует методы get и set.

Кроме того, поскольку оно построено на NET Framework, приложение WPF может одновременно работать с объектами и библиотеками, написанными на нескольких языках. Это означает, что если вы найдете отличную реализацию алгоритма на C ++, Haskell или Ruby, вы можете просто использовать код, не переписывая его на выбранный вами язык. С Cocoa вам обычно приходится переписывать код как Objective-C или создавать код прокладки для вызова другого языка.

Общие преимущества

Вот несколько преимуществ Cocoa по сравнению с конкурентами, которые он разделяет с WPF:

• Богатые функциональные возможности типографики
• Возможность включения трехмерной графики
• Встроенное редактирование форматированного текста, включая проверку орфографии
• Отменить / повторить
• Добавление функциональности к существующим классам (категории в Obj-C, присоединенные свойства и стили в WPF)
• Простое удаленное взаимодействие вызовов методов

Заключительные примечания

При сравнении Какао с WPF вы должны сравните Interface Builder с Expression Blend, а не с Visual Studio. Visual Studio подходит для написания кода, но, на мой взгляд, Expression Blend - единственный инструмент для разработки пользовательского интерфейса.

Для разработки практических приложений основное различие между WPF и Какао обычно не в более мощных графических возможностях WPF, поскольку они могут быть включены в приложение Какао путем их ручного кодирования. Основное различие заключается в привязке данных и эволюции от модели-представления-контроллера к модели-представлению-представлению, что делает WPF намного более эффективным для реальной разработки приложений.

Возможно, я пропустил недавнее улучшение Какао в приведенном выше описании, так как в последнее время я не очень часто использовал Какао. Если я был несправедлив по отношению к Какао (или к WPF, если на то пошло), пожалуйста, добавьте комментарий и дайте мне знать, что я пропустил.