Как Cocoa сравнить с Microsoft, Qt?

Ответ 1

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

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

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

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

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

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

• Прямое редактирование вручную
• Связь со сверстниками (например, StackOverflow)
• Источник contrrol
• Поиск
• Автоматизированные преобразования

Возможности макета

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

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

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

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

Подключение к данным

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

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

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

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

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

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

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

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

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

Таким образом, "Город" упоминается только в двух строках кода во всем моем приложении (если у меня нет другого текстового поля "Город" в другом месте). В Cocoa "Город" будет указываться не менее пяти раз.

Связывание непосредственно с моделью

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

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

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

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

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

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

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

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

<Button Command="Delete" />

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

• Связывает ключ с клавишей Delete на клавиатуре
• Поставляет соответствующий языку текст ( "Удалить" или "Eliminar" или "Löschen" или "Supprimer" или...)
• Включает описательный подсказку

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

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

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

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

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

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

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

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

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

Например:

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

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

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

Cocoa и WPF позволяют вам подклассифицировать существующие элементы управления для создания новых. В Cocoa новые элементы управления сериализуются в файле .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 будет определяемым мной элементом управления, и Счастье будет одним из его свойств.

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

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

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 в коде (С#):

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, выбрав "Редактировать" > "Шаблон" > "Создать новый", построив Ellipse, Path и ComboBox с помощью инструментов рисования и выбрав привязку и стиль ComboBox из свойств окно.

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

В Cocoa, если вам нужен список или дерево элементов различного типа, например инвентарь инвентаря в игре или список различных типов счетов (инвестиции, денежный рынок, сбережения), вам в значительной степени приходится код все это самостоятельно. В 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: например, вы можете иметь представление по умолчанию для счета-фактуры, которое задано в общесистемной DataTemplate, поэтому любая часть вашего приложения, которая представляет списки счетов-фактур, автоматически отображает их в формат по умолчанию. Это может включать в себя значок, номер счета, всплывающее окно всплывающей подсказки с дополнительной информацией и контекстное меню, которое позволяет открывать и/или редактировать счет-фактуру.

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

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

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

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

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

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

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

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

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

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

Такая привязка с преобразованием невозможна в Cocoa.

Элементы управления третьей стороной

В Cocoa вы обычно можете включать только виджеты пользовательского интерфейса, предназначенные для Cocoa в вашем приложении. В 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>

Внешне созданный носитель

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

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

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

Сбор мусора

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

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

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

Возможности кросс-платформенной

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

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

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

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

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

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

• Все элементы управления, такие как кнопки, текстовые поля, выпадающие списки и т.д., могут работать как в трехмерных сценах, так и внутри 2D-макетов. Они также могут быть произвольно растянуты, повернуты, перекошены и т.д.
• Расширенные возможности рисования, такие как PolyBeziers, комбинированные геометрии, RenderTransform vs LayoutTransform, управление прозрачностью альфа и т.д.
• Расширенные кисти, такие как градиентные кисти, черепичные кисти изображений и "визуальные кисти", которые позволяют создавать произвольно сложную кисть для рисования, например, вы можете нарисовать отражение вашего окна, включая все его элементы управления.
• Анимационная подсистема позволяет анимировать практически каждое свойство, например, я анимировал свойство TextBox "Текст", чтобы оно показалось, что текст был введен в

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

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

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

Сравнение Objective-C с С# - основная задача, и я не буду пытаться. Достаточно сказать, что с версии 4.0 С# содержит все функции на Objective-C и многие, многие и многие другие. Я узнал Objective-C в 1989 году - задолго до того, как С# даже задумался - и в то время это был удивительно мощный язык. Теперь, когда я использую его, я съеживаюсь, особенно в случае потери 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 (с <ListBox ItemsSource="{Binding}" />) и динамически обновлять его в реальном времени.

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

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

Языковые привязки

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

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

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

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

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

Заключительные заметки

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

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

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

Ответ 2

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

Obj-C менее сложный, чем С++ и С#, но, как и все языки программирования, у него есть свои моменты. Это также Mac, поэтому, если вы ориентируетесь на Windows или Linux, это не вариант.

Между выводами/действиями и сигналами/слотами нет большой разницы, и, вероятно, причины, по которым у меня не было много проблем, когда я был представлен в Cocoa Outlets/Actions (из фона Qt). Поэтому, если вы работали над ними, вы, вероятно, делали что-то неправильно.

Что касается IDE, это во многом зависит от OS, на которую я нацеливаюсь, ни один из них больше, чем другие, все они выполняют свою работу, все они имеют свои сильные и слабые стороны (и проблемы), все они имеют Дизайнеров GUI, и все они работают по-разному, что никакое сравнение между ними не имеет большого смысла;). Так что я использую, зависит от целевой ОС программного обеспечения, которое я пишу:

Только для Mac OS X → Cocoa с Xcode Только Windows → Visual Studio (в основном .NET framework) Кроссплатформенность → QT с QtCreator (такая же платформа разработчиков на всех целевых ОС - явный выигрыш в этом случае)

Что касается документации, я нахожу Qt-документацию наиболее удобочитаемой и простой в навигации... хотя большую часть времени я использую Google как свою документацию;)

Ответ 3

Это один из способов взглянуть на него. Чтобы услышать другую сторону, я бы сказал, что это неплохо читается: http://arstechnica.com/apple/news/2008/04/what-microsoft-could-learn-from-apple.ars

Лично я считаю, что нужно также учитывать производительность. Objective-C, а первые библиотеки Nextstep кажутся намного более компактными, в то время как WPF немного перегружен.