Кроссплатформенная разработка - использовать кроссплатформенный инструментарий пользовательского интерфейса или встроенный на нескольких платформах

Question

Я ищу некоторые аргументы, чтобы передать их боссу и коллегам-разработчикам.

В настоящее время мы заканчиваем предварительные макеты пользовательского интерфейса и готовимся перейти к следующим этапам разработки. Тем временем я копался в недрах API Carbon, Win32 и wxWidgets, пытаясь придать некоторым элементам управления более естественный вид на платформах Mac и Windows.

Чем больше я копаюсь в Win32 и Carbon API, чтобы реализовать то, что мы хотим в пользовательском интерфейсе нашего проекта, тем больше они устаревают, и тем больше я начинаю думать, что мы должны реализовывать проект, как описано в последний абзац здесь .

Мы используем wxWidgets для наших текущих проектов. wxWidgets появится на порте wxCocoa, но не похоже, что он будет готов к прайм-тайм, прежде чем мы начнем основные усилия по разработке нашего нового приложения. С точки зрения Windows, он оборачивает Win32 API, а не WinForms или WPF (вероятно, из-за нативного и управляемого кода).

Мы уже проектируем систему с учетом паттерна MVC, таким образом, помимо необходимости писать два собственных UI, это должно быть очень выполнимо и, IMHO, проще получить желаемые эффекты UI с помощью современных API, таких как Cocoa и WPF.

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

Заранее спасибо.

Answer 1

Создайте свой основной код в стандарте C ++ и используйте Objective-C ++ с Cocoa для создания вашего пользовательского опыта на Mac и C ++ / CLI плюс C # с WPF для создания вашего пользовательского опыта в Windows. Следуйте указаниям платформы для Mac в вашей версии Mac, для Windows в вашей версии Windows и даже не думайте о попытке поделиться кодом пользовательского интерфейса.

Один из хороших способов управления этим - вместо модели Model-View-Controller, следуя архитектуре Model-Model Controller-View Controller-View. Ваши модельные контроллеры независимы от платформы и управляют функциональностью вашего приложения на более высоком уровне. (Например, вся концепция документов, формат файла, очереди заданий и т. Д.) Ваши контроллеры представления зависят от платформы и являются посредниками между вашими модельными контроллерами и пользовательским интерфейсом.

Конечно, вы, вероятно, также захотите некоторый платформо-зависимый код на уровне модели; например, использовать NSOperation на Mac и пулы потоков в Windows для реализации очередей заданий. Просто создайте свои собственные легкие абстракции для такого рода вещей.

Answer 2

На самом деле, я думаю, что использование Qt стало очень интересным, поскольку теперь это LGPL

Answer 3

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

Если вы напишите специфические для платформы внешние интерфейсы, каждый из которых использует самые современные инструменты для этой конкретной платформы, вы получите гораздо лучший пользовательский опыт, но затраты на их разработку и обслуживание будут на одном уровне как разработка всего приложения с нуля для каждой платформы (да, даже с MVC).

Answer 4

Каждый раз, когда вы добавляете слой абстракции, вы торгуете контролем над деталями для более быстрой разработки. Вы сможете сделать многое заранее, используя некоторые кроссплатформенные фреймворки. С другой стороны, когда вы хотите сделать что-то, что фреймворк не поддерживает - и давайте посмотрим правде в глаза: он не будет реализовывать все возможные вещи, которые могут делать эти нативные API - вы должны либо реализовать это (для всех платформ ) с использованием нативного API или других странных хакерских атак, чтобы получить «достаточно хорошее» решение. И, конечно, когда дела идут ужасно неправильно, наличие лишнего слоя кода, которым вы не владеете, усложняет отладку. На самом деле есть что сказать, чтобы вы как можно больше владели всем вашим стеком.

Answer 5

Также см. в этой теме в списке рассылки Google Chrome, где обсуждается один и тот же выбор интерфейса для Chrome на разных платформах.

Answer 6

Лично я предпочел бы придерживаться мультиплатформенности и не беспокоиться об этом, но если бы я хотел использовать эти нативные API, я бы решил (видимые для конечного пользователя) различия между как все делается в разных графических интерфейсах. Если вы можете убедить их в том, что для того, чтобы чувствовать себя «родным», пользовательский интерфейс программы должен выглядеть и чувствовать себя очень по-разному в Windows и OSX (из-за разных руководств / принципов разработки), они должны понимать, что даже с wx все равно придется реализовать его дважды, чтобы учесть эти различные требования, так что вы также можете использовать реальную вещь, то есть нативный API.

Answer 7

Есть ли у кого-нибудь какие-либо предложения о том, как использовать собственные наборы инструментов пользовательского интерфейса в нашем следующем приложении по сравнению с использованием wxWidgets?

Никто не любит мудрый коридор .

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

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

Answer 8

Win32 определенно не подходит для старых, но вы можете захотеть взглянуть на что-то вроде Microsoft Foundation Classes, которое предназначено для нативной разработки на C ++. Я предполагаю, что похожая вещь существует для MAC.

Лично, если бы я был в вашей ситуации, я бы тоже правильно пошел на QT или WX.