Как стать автором
Обновить

Комментарии 41

Не пробовали. И я первый раз вижу этот враппер.
Когда мы начинали разработку, мы планировали в скором времени выпустить и мобильную версию. И поэтому интерфейс на html+js+css нам кажется более подходящим.
Для кроссплатформенной разработки десктопных приложений на C# можно использовать следующие GUI фреймворки:
XWT github.com/mono/xwt
Eto github.com/picoe/Eto/
Я видел эти проекты, но у нас очень высокие требования к гибкости интерфейса, к возможности добавления своих компонентов. Есть опасение, что придется писать в итоге все равно под каждую платформу по отдельности, как и предлагается в Eto:
«For advanced scenarios, you can take advantage of each platform's capabilities by wrapping your common UI in a larger application, or even create your own high-level controls with a custom implementations per platform.»
А почему вебкит, почему не CEF? С CEFGlue можно использвать одну единственную dll-ку биндингов на всех платформах, например.
Когда писали Windows версию, CEF не попался на глаза, хотя судя по истории он появился на пару месяцев раньше. Когда делали обертку под Mac, мне он показался по каким-то причинам не рабочим под этой платформой. А сейчас у нас все работает с имеющейся реализацией и предпосылок для переписывания нету, да и других задач хватает.

Но в целом, мне идея с CEF очень нравится.
НЛО прилетело и опубликовало эту надпись здесь
Мы пишем обертку над браузерами чтобы унифицировать взаимодействие. Дальше логика приложения работает с оберткой.
Получается что под разными платформами отличается только обертка(строк по 100 кода), а вся логика и весь интерфейс абсолютно одинаковый.

Видео с GUI
Можно поступить проще. Использовать CefSharp в качестве браузера github.com/cefsharp/CefSharp — это chromium.
пользователь сам должен будет поставить Mono и, следовательно, приложение не может попасть в AppStore
Вообще говоря при наличии прямых рук, навыков использования otool и скрипта, прописывающего DYLD_LIBRARY_PATH, можно сделать упаковку в бандл самостоятельно.
Я с этим согласен, но разве мы в этом случае не нарушаем лицензионное соглашение?
MIT и LGPL-то?
Извиняюсь, что долго не отвечал. Вспоминал(гуглил).

«GNU LGPL позволяет линковать с данной библиотекой или программой программы под любой лицензией, несовместимой с GNU GPL, при условии, что такая программа не является производной от объекта, распространяемого под (L)GPL, кроме как путём линкования.»

Встроить в бандл — это явно ведь не линкование.

«The Mono runtime license is a commercial license that allows developers to redistribute their Mono-based applications without being bound by the terms of the GNU LGPL v2. This allows you to publish both to the Apple App Store as well as distributing applications that embed the Mono runtime without having to provide source code or object files for end users to relink.» Взято здесь

И мы хотим распространять наш продукт под коммерческой лицензией
Встроена в бандл — это значит вы просто поставляете ее вместе с программой, но вы по-прежнему динамически линкуетесь с ней, так что нарушения лицензии не будет.
Интересный подход. Правда я, если есть потребность в написании кросс-платформенного приложения, использую Qt. Язык разметки интерфейса сильно HTML/CSS напоминает и WEB разработчикам будет довольно просто на него перейти. Единственное, на iOS это перенести не получится. А вот с Андроид ситуация улучшается
То есть вы в своем основном продукте принесли в жертву его самую важную часть (user experience) в угоду экономии на разработке? :(
НЛО прилетело и опубликовало эту надпись здесь
Веб-приложения — это отдельная история.
Вы не обращали внимания, что с появлением магазинов приложений на десктопах, появляются приложения популярных веб-сервисов (для одного ВК приложений понаделана уйма)? И надо сказать, что пользоваться ими зачастую удобнее, чем веб-версиями (встраивание в систему, отзывчивость, оффлайн, ярлык для запуска приложения в удобном месте и т.д.).

В конечном счете сейчас идет тенденция к стиранию границы между сайтом и традиционными десктоп-приложениями — теперь есть сервер/API и есть клиенты, одним из которых является сам сайт.
А разработать клиент-приложение для десктопа на нативных технологиях зачастую даже проще, чем веб-версию на html/css/js.
А собственно, почему разработка нативного приложения должна быть сложнее?
Это по-определению проще, чем разработать веб-приложение, работающее в зоопарке браузеров, на разных разрешениях, в разных ОС, с неустоявшимся набором практик и инструментов.
Вы столкнётесь с зоопарком версий Windows, с лгущим о размерах окна Windows.Forms/WPF, нехорошими людьми, вещающими глобальные перехваты WinAPI, параноидальными антивирусами и криворукостью админов организаций. На линуксе ещё и зоопарк дистрибутивов. В общем, много весёлого и занимательного, о котором веб-разработчики не подозревают.
А я не согласен, что у нас user experience пострадал.
Во-первых, пользователь, меняя платформу, видит абсолютно такую же программу. Ему не нужно искать привычный функционал. Это фича!
Во-вторых, разработка трех интерфейсов параллельно сказалась бы на количестве багов.
В-третьи, html-js-css очень хорошо кастомизируется под любую прихоть пользователя.
Во-первых, пользователь, меняя платформу, видит абсолютно такую же программу. Ему не нужно искать привычный функционал. Это фича!

Все-таки рядовой пользователь чаще переключается между приложениями, чем меняет платформу. Сложно назвать это фичей.
В наше время это уже не факт. На работе Windows, дома MacOS или Ubuntu, в дороге Android или iOS — совсем не редкость.
Согласен с VolCh. Мне очень удобно, что все программы, с которыми я работаю, имеют одинаковый интерфейс на всех платформах. Большинство программ из сферы разработки и повышения продуктивности, а так же браузеры, почтовые клиенты и т.д. только выигрывают от кроссплатформенного интерфейса.
> Во-вторых, разработка трех интерфейсов параллельно сказалась бы на количестве багов.

Это не про UX, а про качество. Под UX, как я понял, имелось в виду как раз интеграция приложения в среду устройства: быть может не все фичи платформы будут доступны для веб слоя.

> В-третьи, html-js-css очень хорошо кастомизируется под любую прихоть пользователя.
Веб-приложения на мобильных устройствах уступают в производительности нативным, и под эту прихоть пользователя («хочу, чтобы летало… фью… фью..») Вам HTML+CSS+JS, возможно, не удастся кастомизировать.
Идентичный интерфейс под всеми платформами можно рассматривать как «баг», а можно как фичу. Всё зависит от ЦА.
Ну например менюшки на яваскрипте вместо привычных пользователю системных контекстных меню сложно назвать фичей.
Да там даже заголовок окна несистемный — то есть абсолютно все контролы приложения ведут себя непредсказуемым образом.

Я не спорю, кроссплатформенная разработка — это здорово, но я для себя пока плохо представляю, как совместить единый код и различные интерфейсы (а в разных ОС не только внешнее оформление, но и некоторые базовые парадигмы различны).

К тому же, это приложение нельзя опубликовать в Mac App Store — а это потеря еще одного канала продвижения приложения.
>>Да там даже заголовок окна несистемный
Он только под виндой несистемный. Специально выпиливали потому что не понравилось как выглядит приложение в стандартном окне. В общем, это тоже фича :( Под Ubuntu и Mac системные окна.

>>К тому же, это приложение нельзя опубликовать в Mac App Store
Почему нельзя? Можно — документация
Каких системных контекстных? По оформлению или по содержанию? Насколько я помню разработку под десктоп, то содержанием управляет исключительно приложение.

А вообще решение писать кроссплатформенный клиент с единым интерфейсом может быть обусловлено множеством причин, от маркетинговых (ЦА нужна именно предсказуемость приложения независимо от платформы) до технико-экономических (в команде нет людей, способных за разумное время создать и поддерживать нативный код под десяток платформ) и идеологических (люди есть, но из принципа не хотят).
Спасибо за статью. Можно несколько вопросов?
1. А как у вас с потреблением ресурсов?
2. Сколько вышел размер итогового приложения? У вас с виду довольно компактное приложение. Не напрягает ли клиентов то, что вы толстый вебкит тащите?
3. Насколько отзывчив интерфейс? Видео просмотрел, но не очень чувствуется время отклика, когда сам не пробовал.
4. Как решили вопрос с кастомизацией диалогов и модальных окон?

Сейчас как раз делаю нечто подобное. Только использую Xilium.CEFglue Вы пробовали какие-то другие инструменты? Судя по видео, с вашей задачей неплохо бы справился Adobe Air. И довесок в виде среды исполнения был бы копеечный.
Небольшое уточнение к первому вопросу. Я видел в посте про потребление оперативной памяти. Хотелось узнать как это сказалось на ваших клиентах? Не было ли обращений в службу поддержки по этому поводу?
1. На потребление ресурсов жалоб не было. Может быть еще будут :))
2. Под Windows приложение 35 мегабайт. Плюс надо поставить 3 распространяемых пакета сумарно 15 мб. Под linux deb пакет 1.5 мегабайта, но он тянет зависимости. Не возьмусь оценить сколко это, а Ubuntu под рукой нету. Под мак приложение 50 мб вместе со встроенным Mono runtime. A installer для мака 10 мегабайт.
Я не думаю, что это много.
3. Отзывчивость интерфейса зависит от платформы. Нас пока устраивает, но иногда ощущаются тормоза. Тут стоит принять во внимание, что еще и интерфейс у нас «тяжелый», писали на Sencha Touch.
4. Никак не кастомизируем системные модальные окна. Практически их не используем. И в интерфейсе используем модальные окна от Sencha Touch.

Под виндой еще пробовали Awesomium. Под линукс и мак у нас сходу завелись указанные компоненты. Их и используем.
Про Adobe Air не думали.

P.S. Если хотите оценить отклик, Вы можете скачать клиента на нашем сайте. Но придется зарегистрироваться. Если не хотите лишних писем, то можно использовать 10 minute mail. И мы не выкладываем клиента под мак в общий доступ, потому что хотим распространять через app store. Поэтому если хотите, то я могу отправить.
Спасибо за ответы. Посмотрю приложение. А XULRunner + GeckoFX не смотрели? Там рантайм немного меньше будет по размеру.
Нет, не смотрели. Sencha Touch под Gecko не работает
Не совсем понятно для чего использовать разные решения под каждую ОС. Ведь можно просто взять например враппер для гейко и использовать его под каждой ОС, это конечно не решит вопрос с лицензиями под осикс но все же уменьшит танцы с бубном под различные ос.
Уточните, пожалуйста, что такое гейко.
Простите за неверную транскрипцию, но вы наверное уже догадались что я про GeckoFX, хотя есть подобные решения, обертки для webkit.
А QT нет под C#?
Есть. Но там тоже уходят от виджетам к QML. Мы вот новую версию кебрумовского клиента писали в смешанном режиме — системная логика — C++, весь гуй — HTML + JS через QtWebKit, получилось намного быстрее и красивее чем на виджетах.
На все вопросы, возникшие у меня во время прочтения статьи, ответы в комментариях я получил. Интересует лишь одно: Вас не смущает, что webkit.net последний релиз был года этак 3 назад?
Проект, видимо, перестал развиваться. Но имеющаяся версия справляется с отображением нашего GUI. И у нас реально ситуация «написал и забыл». Два года уже пашет webkit.net и практически о себе не напоминает, критичных багов в нем не замечено. В общем, проверенное временем решение.

Как появятся серьезные предпосылки, переедем на что-нибудь другое. Скорее всего на CEF.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий