По ряду причин, мне понадобилось подобрать наиболее простой способ написать максимально переносимое приложение для "конечного пользователя". В процессе поиска и оценки решения накопился довольно большой объем информации, которая возможно будет кому-то полезной. Как ни крути у нас тут часто возникают вопросы про платформы, фрэймворки, на чем писать и т.д.
Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются
P.S. даю заметку в виде линке т.к. лень переформатировать заметку, да и таблицы форум не поддерживает.
Платформа/SDK C++ Java Objective-C C#
Windows + + — +
Linux + + — +
Mac OS X +/- +/- + —
iOS — — + +/-
Android — + — —
Symbian + + — —
Windows Phone 7 — — — +
Возможность написания бизнес-логики
Платформа/SDK C++ Java Objective-C C#
Windows + + + +
Linux + + + +
Mac OS X + + + +
iOS + — + +
Android + + — —
Symbian + + — —
Windows Phone 7 — — — +
Глядя в эти таблички видно, что максимальное покрытие функционала предоставляет Java, а вы в своих выводах пишете:
Выводы получаются довольно неожиданные. Java не является лучшим решением ни для написания кроссплатформенной логики, ни для написания кроссплатформенного GUI
Т.е. выводы никак не соотносятся с приведенными таблицами ( видно, что ява охватывает все, кроме iOS )... Это наталкивает на мысль об использовании автором взаимоисключающих параграфов. Или недостаточно детальной проработки вопроса.
Поклонников C# обрадует тот факт, что Mono работает на Mac OS X, но вот то как Mono приложение будет выглядеть на Маке заставит вздрогнуть даже не притязательного пользователя. Дело в том, что Mono использует библиотеку GTK, которая работает на Mac OS X только через X-сервер и отличается на редкость уродливым внешним видом (лично я это могу простит только Wireshark).
После просмотра скриншота кэп намекнет нам, что эмоциональная составляющая авторского message высосана из пальца. не нэтивный интерфейс != ужасный, хотите нэтива берите cocoa, не надо мозг людям пудрить, лучше вместо этого поизучайте биндинги к cocoa для mono и все будет выглядеть очень даже по маковски, хотя и все равно думаю найдутся ньюансы.
А вот это вообще писк, особенно выделенное.
А вот поддержку для Windows Phone 7 я бы стал делать только в крайнем случае. Создание приложения для этой платформы потребует отдельной реализации как логики, так и GUI которая нигде больше не пригодится.
т.е. плюсики в графе c# означают не то, что подсказывает капитан, а что-то другое?
в целом вы, я уверен людям интересующимся, америку не открыли. Все как было пару лет назад так и сейчас. Если хотите, чтобы приложение выглядело и работало на платформе как родное, то берите родную среду и инструменты для платформы и с их помощью разрабатывайте, серебряной пули как не было так и нет.
Здравствуйте, Visor2004, Вы писали:
V>Т.е. выводы никак не соотносятся с приведенными таблицами ( видно, что ява охватывает все, кроме iOS )... Это наталкивает на мысль об использовании автором взаимоисключающих параграфов. Или недостаточно детальной проработки вопроса.
Java не допустима на iOS и Windows Phone 7 и не желательна на Mac OS X.
V>После просмотра скриншота кэп намекнет нам, что эмоциональная составляющая авторского message высосана из пальца.
А начале заметки я писал о приложении для "конечного пользователя". Такого класса приложение не должно и не может смотреться на столько страшно, как то, что отображается на приведенном скриншоте
V> не нэтивный интерфейс != ужасный
В случае с Mac OS X, не нэтивный интерфейс == ужасный.
V>, хотите нэтива берите cocoa, не надо мозг людям пудрить, лучше вместо этого поизучайте биндинги к cocoa для mono и все будет выглядеть очень даже по маковски, хотя и все равно думаю найдутся ньюансы.
Будут. И примеров таких приложений, насколько я знаю, нет.
V>А вот это вообще писк, особенно выделенное.
Угу, поправлю. Тут скорее речь о том, что либо трудности с поддержкой одной платформы (в данном случае это Windows Phone 7), либо нескольких. Если идти по пути наименьшего сопротивления, то логичнее отказаться от поддержки одной платформы (которая еще не факт что выстрелит вообще). А при отказе от ее поддержки реализация действительно будет нигде не нужна.
V>в целом вы, я уверен людям интересующимся, америку не открыли.
В каких сценариях есть востребованность кроссплатформенности между ПК и мобильными устройствами? Если такие сценарии и есть, то приложение настолько просты, что переписывание его для каждой специфичной платформы наверно не покажется трудоемким.
По поводу "некрасивой" Java: про SWT (Eclipse) слышали?
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, kaa.python, Вы писали:
R>В каких сценариях есть востребованность кроссплатформенности между ПК и мобильными устройствами? Если такие сценарии и есть, то приложение настолько просты, что переписывание его для каждой специфичной платформы наверно не покажется трудоемким.
Довольно во многих. Пара примеров: OmniFocus, GoogleTalk (и любая другая болталка), Twitter клииент.
R>По поводу "некрасивой" Java: про SWT (Eclipse) слышали?
Слышал конечно. Но вроде как я написал про то, где и почему Java смотрится не красиво.
Здравствуйте, kaa.python, Вы писали:
R>>По поводу "некрасивой" Java: про SWT (Eclipse) слышали? KP>Слышал конечно. Но вроде как я написал про то, где и почему Java смотрится не красиво.
На SWT прорисовка выполняется стандартными средствами OS, это некрасиво?
Здравствуйте, kaa.python, Вы писали:
KP>Тем не менее, SWT приложение не выглядит "родным" (в качестве примера можно взять тот же Eclipse). В определенных случаях это равносильно "некрасиво".
Конкретнее можно, что не выглядит "родным"?
Здравствуйте, kaa.python, Вы писали:
R>>Конкретнее можно, что не выглядит "родным"? KP>Тулбары, табы, диалоги настройки, строка состояния.
По ссылке данной выше все это выглядит настолько нативно, насколько позволяет OS. Вы же говорите про надстройки над SWT сделанные в Eclipse RCP, в частности, JFace. Но их никто не заставляет использовать.
Здравствуйте, kaa.python, Вы писали:
KP>Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются
Для С++ (питона, руби, эрланга) есть еще wxWidgets как GUI библиотека лучше чем QT тем что для windows и linux(гномьего) рисует
нативными контролами, с маком те же проблемы что и у QT.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, kaa.python, Вы писали:
KP>>Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются
FR>Для С++ (питона, руби, эрланга) есть еще wxWidgets как GUI библиотека лучше чем QT тем что для windows и linux(гномьего) рисует FR>нативными контролами, с маком те же проблемы что и у QT.
Да, я про него в курсе. Дело в том, что Qt приложение довольно легко затягивается на Symbian и, в перспективе, MeeGo. Поэтому и не стал его рассматривать вообще.
Здравствуйте, kaa.python, Вы писали:
KP>По ряду причин, мне понадобилось подобрать наиболее простой способ написать максимально переносимое приложение для "конечного пользователя". В процессе поиска и оценки решения накопился довольно большой объем информации, которая возможно будет кому-то полезной. Как ни крути у нас тут часто возникают вопросы про платформы, фрэймворки, на чем писать и т.д. KP>Собственно вот мысли на эту тему. Дополнения и комментарии с радостью рассматриваются
KP>P.S. даю заметку в виде линке т.к. лень переформатировать заметку, да и таблицы форум не поддерживает.
А почему, кстати, не рассматривались динамические языки? Тот же питон есть на всех перечисленных платформах кроме ios и wp7. Причем в джейлбрейкнутой ios он уже давно есть (http://www.saurik.com/id/5), а если очень хочется, то можно и в нетронутой (http://www.philhassey.com/blog/2009/12/23/elephants-is-free-on-the-app-store/). Что касается wp7, то основным препятствием для использования этого языка там является отсуствие поддержки SR.Emit со стороны CLR, AFAIK (если говорить о дотнете и IronPython), либо пробовать подход для ios (трансляция в плюсовый код и сборка под конкретную платформу).
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А почему, кстати, не рассматривались динамические языки?
Потому-что интересовал способ затащить приложение на как можно большее количество платформ. Т.к. приложение для пользователя, а не системная утилита, то вариант с тем чтобы требовать дополнительно что-то доустановить (тем более что-то такое массивное как интерпретатор) я не рассматривал. Ну и не стоит забывать про внешний вид приложения и пожелание родного интерфейса.
Да и скорость работы интерпретируемых приложений не впечатляет, если честно
Здравствуйте, kaa.python, Вы писали:
KP>По ряду причин, мне понадобилось подобрать наиболее простой способ написать максимально переносимое приложение для "конечного пользователя".
Максимально переносимое приложение будет веб. Да и то из-за разных размеров экрана и органов управления может понадобиться делать разные интерфейсы для мобильных устройств и всех остальных.
Как только вы начинаете писать десктоп приложение, то сразу же надо думать о UI Guidelines, а они ооочень сильно отличаются для разных платформ.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>А почему, кстати, не рассматривались динамические языки?
KP>Потому-что интересовал способ затащить приложение на как можно большее количество платформ. Т.к. приложение для пользователя, а не системная утилита, то вариант с тем чтобы требовать дополнительно что-то доустановить (тем более что-то такое массивное как интерпретатор) я не рассматривал. Ну и не стоит забывать про внешний вид приложения и пожелание родного интерфейса.
Не холивара ради, но есть аж несколько путей поставки приложений на питоне без создания пользователю неудобств, связанных с необходимостью установки среды исполнения и библиотек. Есть масса упаковщиков py-приложений в автономно работающие пакеты, есть возможность компиляции в нативный код и т.п. По поводу же внешнего вида — у питона есть биндинги ко всем распространенным UI-фреймворкам, плюс к большинству GUI API непосредственно платформ (к той же ios, например).
KP>Да и скорость работы интерпретируемых приложений не впечатляет, если честно
Ну речь-то не о полностью интерпретируемом приложении. Канонический питон, по сути — клей на байт-коде, обеспечивающий работу вполне себе нативных и оптимизированных напрочь библиотек, написанных на нативных-же языках. Если этого не достаточно, то есть сразу несколько путей компиляции py-кода в нативный, что также дает прирост производительности (почти всегда не дотягивающей до труъ-натива, конечно, но тем не менее).
Я собственно не настаиваю, просто показалось, что тема динамики не прорабатывалась не столько из-за нежелания, сколько из-за отсутствия достаточной информации, чтобы говорить о такой проработке всерьез.
Если ставится цель сделать приложение, которое не будет выглядеть чужеродным, то даже между Windows и Linux, да что там, даже между GNOME и KDE нет возможности сделать это переносимо. Т.к. в каждой среде свои Guidelines о том, как должно выглядеть приложение. Кнопочки родные или похожие на них нарисовать несложно, но этого не достаточно.
Поэтому интерфейсная часть для серьёзного приложения должна писаться отдельно для каждой платформы.
Ну а ядро, конечно, будет общее.
Поэтому имеет смысл сравнивать разные языки и платформы в контексте поддержки соответствующих биндингов к WinAPI, Cocoa, GTK, Qt, и т.д., ну и, непосредственно, кроссплатформенности.
Здравствуйте, kaa.python, Вы писали:
KP>Да, я про него в курсе. Дело в том, что Qt приложение довольно легко затягивается на Symbian и, в перспективе, MeeGo. Поэтому и не стал его рассматривать вообще.
