» Вопросы по Embarcadero RAD Studio XE4

deks
Ну, на телефоне и декстопном компе вообще в принципе разные задачи решаются. И разными средствами в том числе. Лично я даже представить себе не могу программу, котрая должна одинаково выглядеть на телефоне, планшете и десктопе; рисование формы тут - дело десятое. А вот общая среда разработки и общие библиотеки кода для разных вариантов приложения (а фактически - разных приложений) - уже интересснее.

deks

Цитата:

По мне - так FCL/RTL от FPC довольно скромные в сравнении с .NET/Cocoa

В зачет FPC идет огромное количество сторонних компонентов и библиотек, в том числе портированых из мира дельфей. Плюс ко всему это реальная кросс-платформа, чего нет ни у дотнета (mono на каждой из поддерживаемых платформ выглядит чужеродным элементом) ни тем более у какавы. А без единой RTL разработчикам библиотек для оксиджена придется кропать свой переносимый аналог. Чего-то геморойно слишком...


Цитата:

Вопрос в построении приложений - не верю, что можно переносить код без переписывания программы чуть меньше чем полностью!

Это не вопрос веры Лазарус собирается и работает под несколькими ОС. Ну и довольно известные PeaZip и Transmission Remote GUI.


Цитата:

Хотел бы посмотреть на пример таких приложений, которые и на телефоне, и на десктопном компе работают

Игрушки более чем возможны. С приложениями других категорий это вряд ли вообще получится т.к. слишком уж разные в плане организации UX платформы.

valgreesh

Цитата:

Игрушки более чем возможны.

Хм. На 19-24" мониторе с управлением с мыши/клавы/джойстика и на 4-5" дисплее телефона одинаковая игрушка? Неужели шахматы?

valgreesh

Я не говорю про то, что у FPC маленькая поддержка! Я указал на то, что она довольно блеклая в сравнении. И вы недооцениваете количество сторонних библиотек для Cocoa/.NEt - FPC, к сожалению, близко не валялся)) Например, найдите мне хоть один парсер для Markdown. Ну или скажите - что для FPC есть, чего нету для Cocoa/Java/.NET.

А еще я говорю о том, что кросс-платформенные приложения (multi-device) это такой сферический конь в вакууме! То есть как бы теориетически они есть, а практически сложно придумать для них нишу. Я еще верю в кросс-платформенные приложения между Win/OSX/Linux, хотя формочки переделывать придется, и Дельфи не поддерживает Win8/RT. Но при переходе от десктопа к мобильной платформе вообще многое придется переписать: начиная от схемы доступа к данным, кончая общей архитектурой классов (для экономии памяти, например). Также пока не видно возможности легко делать переход между мобильными ОС. Например, схема организации фоновых задач в iOS и Android оч разная. Также разный подход к передаче документов между приложениями - если на Андроиде традиционная файловая система, то в iOS файлами обмениваемся между приложениями (что нужно зарегистрировать в манифестах и сделать соответствующие обработчики). Я все это говорю, чтобы показать: разный дизайн приложения, мало места для разделяемого между платформами кода.

А какой код вы видите как разделяемый между платформами? На примере?


Добавлено:
miwa

Ну - игры хотя бы будут иметь почти одинаковый GUI, просто разное управление. Также обычно переделывается графика, потому как на 27" и на 4" разное разрешение фигурок должно быть. И я бы сказал, что игры МОЖНО портировать, но все таки это - не КРОСС-ПЛАТФОРМЕННЫЙ код. Именно ПОРТИРОВАННЫЙ.

К тому же для игр есть небольшая обвязка с платформой - например, GameCenter для iOS/OSX и iCloud сохранение игр. Для Android такого нету (пока, хотя на IO-2013 чего то показали аналогичное GameCenter).

Мое ИМХО - игры проще портировать, чем многие другие типы приложений. Но портировать все равно придется. Не слышал про write once - compile everywhere!

с небольшим шаманством смог поставать JEDI JVCL, по этому принципу http://kutsoff.ru/2013/05/24/how-to-install-jcljvcl-on-delphi-xe4/

miwa

Цитата:

Неужели шахматы?

Да ладно... Есть примеры. И это растровая графика, с 3D должно быть проще.

deks

Цитата:

Например, найдите мне хоть один парсер для Markdown.

В эту игру можно играть долго, но всегда с предсказуемым результатом. Не будем этого делать.


Цитата:

(multi-device) это такой сферический конь в вакууме!

А кто спорит? Речь о переносимости кода между близкими в функциональном смысле платформами Win/Lin/MacOS, ну и между мобильными, хотя там все сложнее.


Цитата:

кончая общей архитектурой классов (для экономии памяти, например).

Это вообще странно... Лично я не занимаюсь проектированием в расчете на 16GB ОЗУ - не больше того, что требуется. Исходя из этого переделывать архитектуру не придется, однозначно. А исходя из того, что сегодняшние мобилы и планшеты по объему памяти не уступают вчерашним нетбукам говорить об экономии на спичках (а архитектура классов это спички, по сравнению с той же ретиной или FullHD) вообще смешно.


Цитата:

А какой код вы видите как разделяемый между платформами? На примере?

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

valgreesh


Цитата:

с предсказуемым результатом

К сожалению, Дельфи объективно на порядки менее популярный язык чем ObjC/Java/.NET. Как следствие - размер имеющейся кодовой базы. К сожалению, не в пользу паскаля!


Цитата:

говорить об экономии на спичках

Я лично мерил производительность FMX и iCL в приложениях с прокруткой обычного UITableView. Доложу вам что когда FMX потребляет 70-90% cpu на статическом списоке с 10 элементами, то лагает даже на iPhone5! А, на секунду, там стоит самый быстрый для iOS устройств процессор. А если на iOS лагает, то на Андроиде будет еще сильнее лагать (там все таки графика с приоритетом пользовательского уровня рисуется, а не привелигированная как на iOS).

Почему iCL не лагает? Потому как нативный TableView в iOS кэширует вообще все - он даже одинаковые элементы не создает (alloc/init), он их в пуле держит и инициализирует нужными данными по требованию. Каждый отрисованный участок экрана не перерисовывается самим iOS (CoreGraphics), а кэшируется в битмэп, который в OpenGL довольно шустро анимируется. Зачем? Потому как иначе не вытягивает мобильный процессор/GPU. К чему я это говорю? Что соврменнные мобильные устройства текущего поколения ПОКА ЕЩЕ не прощают слабо оптимизированный код. А вот без переделки классов и алгоритмов FMX не получится оптимизировать, .. По поводу retina - только усугубляет проблемы неоптимизированных программ! Это i5/i7 и desktop-GPU FMX переваривают (и то слабо), а на мобильных даже от html5 народ отказывается - лагает..


Цитата:

не занимаюсь проектированием в расчете на 16GB ОЗУ

На мобильных платформах есть куча других нюансов. Например, на iOS есть бэкап в iCloud. Важно кэшировать данные в специальную папку, которая не будет бэкапится (иначе у пользователя на ненужные данные будет уходить квота в iCloud, а там всего 5Gb бесплатно). А на десктопе в принципе пофиг куда кэш класть - не сложилось строгого разделения. Хорошо что не в program files щас .ini пишутся..


Цитата:

Любой библиотечный не имеющий привязок к платформе

Скажите мне какая именно библиотека не имеет привязок к платформе? Ну из реально использующихся? Я вот только математику могу подумать - и то я их никогда не использовал. Ну пару примеров приведите? Мне лично в голову ничего не приходит!


Добавлено:

Цитата:

А кто спорит?

ЭМРО спорит. К сожалению, они как удила закусили: весь их твиттер в предложениях посмотреть на multi-device development! Marketing bullshit в полный рост, я почти привык. Беда, что мозги народу засирают. Интересно, кто то ж верит?!

Вот недавно ЭМРО написали что Дельфи - это true native! Не в пример всяким Xamarin и PhoneGap. Типа, Xamarin.iOS не нативный, типа он через VM исполняется, поэтому медленный! Miguel De Icaza (который Xamarin) оч удивился, даже поправил их - впрочем, на него никто внимания не обратил)) На самом деле, Xamarin.iOS как раз и является статическим компилятором. Поэтому не доступны всякие динамические возможности .NEt типа Reflection.Emit. Ну и на iOS запрещена динамическая компиляция чего-либо. Поэтому ЭМРО так слегка ввели людей в заблуждение и даже не порпавились! Не в первый раз, ага

Upd: нашел блогопост - _http://blogs.embarcadero.com/jtembarcadero/2013/04/18/true-native/ Картинку зацените, не поленились, нарисовали! Фантазеры))

deks

Цитата:

К сожалению, Дельфи объективно на порядки менее популярный язык чем ObjC/Java/.NET

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


Цитата:

Я лично мерил производительность FMX и iCL

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


Цитата:

На мобильных платформах есть куча других нюансов. Например, на iOS есть бэкап в iCloud. Важно кэшировать данные в специальную папку, которая не будет бэкапится

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


Цитата:

Скажите мне какая именно библиотека не имеет привязок к платформе? Ну из реально использующихся?

Примеров масса: SynEdit, DWScript, GLScene, THtmlViewer, Synapse, Indy, библиотеки доступа к БД, криптография... Тысячи их, перечислять можно долго. Привязка осуществляется к RTL и CL, при обеспечении портабельности которых обеспечивается и портабельность библиотек. Там где не хватает RTL и CL делается небольшой абстрагирующий слой с внутренностями из дефайнов.


Цитата:

ЭМРО спорит. К сожалению, они как удила закусили: весь их твиттер в предложениях посмотреть на multi-device development! Marketing bullshit в полный рост, я почти привык. Беда, что мозги народу засирают.

Эмбаркадеро таким образом, похоже, пытается просто выжить

Цитата:

Важно кэшировать данные в специальную папку, которая не будет бэкапится

Интересно, iOS понимает, когда в папке лежит кэш, а не данные ?

http://www.brynosaurus.com/cachedir/spec.html

deks

Цитата:

К сожалению, Дельфи объективно на порядки менее популярный язык чем ObjC/Java/.NET. Как следствие - размер имеющейся кодовой базы. К сожалению, не в пользу паскаля!

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

miwa


Цитата:

статистика

Рейтинг языков : http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html - Рейтинг именно Дельфи более чем в 20 раз ниже, например, Java.

Еще очень показательный - просмотр статистики по языкам репозиториев на GitHub, sf.net, Google.Code. С ходу не могу привести ссылок, но на каждом сайте где то есть. Ну например, гляньте что GitHub считает popular language в advanced search.

Arioch1


Цитата:

iOS понимает, когда в папке лежит кэш, а не данные

Фактически, для приложения это выглядит просто как разные папки - типа, как User Documents и AppRoaming. Просто в iOS есть несколько типов папок: для iCloud данных (такой дропбокс от Эппла, только для приложений), для локальных данных (песочница) и для временных файлов. Папки доступны только приложению и не видны из другого приложения (sandboxing), кстати, это щас и в OSX внедряют. Ну и еще - например, когда дивайс видит, что место заканчивается, то iOS может самостоятельно потереть данные во временных папках приложений - поэтому там хранят только кэш, то есть те данные, которые можно откуда-то восстановить. Может iOS еще и iCloud трет, не в курсе.

valgreesh


Цитата:

на серверной стороне темных энтерпрайзовых углов

RLY? Весь буржуйский ынтерпрайз - это Java в вариациях j2EE, EJB, TomCat, WebSphere, ... Почти все банки на java работают. На .NET тоже куча всего ынтерпрайзного, не даром девки активно в той степи работают - для них нынче VCL это legacy, а .NET это мейнстрим и продуктов для .NET у них больше гораздо.


Цитата:

не обязательно использовать платформенные тулы

Для поддержки iCloud - обязательно. А хочешь Documents in iCloud, то еще и по специфическому протоколу, через UIDocument. У Андроида/Linux такго вообще нету. Похож только Dropbox Sync из SDK.


Цитата:

SynEdit, DWScript, GLScene, THtmlViewer, Synapse, Indy, библиотеки доступа к БД, криптография

SynEdit, GLScene, THtmlViewer - это таки компоненты UI - не представляю их без привязки к платформе. К тому же кроме SynEdit на iOS они не нужны: GLScene не имеет смысла под iOS так как есть CoreGraphics (тот же OpenGL ES, но ускоренный аппаратно) + GLKit / SceneKit. Как только сделают SceneKit под iOS, вообще смысла в 3D фреймвоке даже среднего уровня пропадет - останутся только полноценные игровые (не столько графические) движки высокого уровня (типа Cocos, Unity, etc) - с физикой, управлением, рисованным кастомным GUI, игровой механикой etc.

THtmlViewer на iOS смысла не имеет, есть свой крутой TWebView - это контрол с WebKit без JS-JIT-движка.

DWScript вообще нельзя по лицензии на iOS использовать внутри софта, так как это интерпретатор.

Сетевые тулзы типа Synapse/Indy плотно завязаны на сетевой стэк платформы, и я имхо не вижу смысла в них без поддержки блоков/GCD на Cocoa: получается, что использовать нативные платформенные возможности удобнее. А для задач более высокого уровня есть куча всяких REST Kit, etc). Библиотеки доступа к БД - завязаны на сетевой стэк минимум. Ну и не принято к БД ходить с мобильных дивайсов. Есть локальная ORM CoreData (SQLite3 + отображение данных на классы) и куча фреймфорков для работы с сетевыми сервисами.

Из по-настоящему кросс-платформенного софта без привязки согласился бы с криптографией, хотя SHA1/MD5 должен быть в сетевых библиотеках платформы, также как и SSL/TLS (а значит и инфраструктура сертификатов-ключей). Шифрование прикладного уровня - да, всякие там BlueFish, BCCrypt или чего там еще есть. Upd: OpenSSL официально входит в состав OSX.




Добавлено:
upd

Я так подробно пишу для того, чтобы показать - мобильные платформы имеют свою сильную специфику, и свою хорошую объектно-ориентированную плафторму. Не имеет смысла прикрывать эту платформу слоем "абстракции" сверху. Лишняя абстракция не добавляет удобства, а только мешает: все равно работать будет платформа, а значит в ней придется разбираться. Но для родных возможностей платформы есть куча документации, статей на stack overflow, примеров, библиотек и компонентов. А вот для "абстракции" ничего такого нет. А вот удобство, которое добавляет "абстракция" - спорное, потому как "абстрагированные" фичи платформы зачастую более убогие чем нативные.

Ну и при правильной архитектуре программы проще заменить "кросс-платформенный" код на имеющиеся на платформе нативные компоненты. Типа, нативный парсер JSON, нативный WebView и тп. Выигрышь будет по сопровождаемости (быстрый фикс багов) и быстрая адаптация новых версий.

Ну и финальный аргумент: вспомните историю "стокового андроида" (который на nexus идет) и кастомных "оберток" от вендоров - все вендоры лагали с выпуском апдейтов, у всех вендоров были дыры с безопасностью. Аналогия более чем прозрачна.

За сим я иссяк на предмет аргументов: свою позицию я донес, кто хотел - ее услышал)) Разделять ее я не призываю, все - имхо, Just мой взгляд на вопрос.

deks

Цитата:

Рейтинг языков

Пардон муа, но ценность этого рейтинга, как бы сказать помягше...


Цитата:

Весь буржуйский ынтерпрайз - это Java в вариациях j2EE, EJB, TomCat, WebSphere

Ну а я о чем говорю? В энтерпрайзах они и живут, популярного массового софта на них нет.


Цитата:

не даром девки активно в той степи работают - для них нынче VCL это legacy

А точнее VCL для них уже освоенная территория, а те края нет, поэтому денег там больше и работы много.


Цитата:

Для поддержки iCloud - обязательно.

Для поддержки специфической фичи платформы и только.


Цитата:

SynEdit, GLScene, THtmlViewer - это таки компоненты UI - не представляю их без привязки к платформе

И тем не менее они чудесно работают под виндами и линуксом. Ни синэдиту, ни хтмлВьюэру ничего кроме холста не требуется (мелочи вроде GDI+ несущественны т.к. из них используется лишь поддержка PNG, которая давно уже есть в pure pascal варианте). GLScene аналогично, от платформы требуется только обеспечить доступ к OpenGL API. Весь прочий их функционал, в котором и заключается основная ценность, к платформе не привязан совершенно.


Цитата:

GLScene не имеет смысла под iOS так как есть CoreGraphics

Скорее CoreGraphics не имеет смысла в контексте разговора о портируемом коде. Ну в самом деле, если у нас на руках проект основанный на GLScene, нам проще осуществить его перенос на новую платформу чем менять инструменты: язык, фреймвок и получать новый опыт разработки. Мне кажется это довольно очевидные вещи.


Цитата:

THtmlViewer на iOS смысла не имеет, есть свой крутой TWebView - это контрол с WebKit без JS-JIT-движка

Вообще говоря еще как имеет т.к. предоставляет возможности выходящие за рамки HTML - такие как внедрение сколь угодно сложных контролов (dbgrid например или тот же sceneViewer от GLScene) в HTML-документ благодаря поддержке кастомных тэгов. Кроме того, отображение html всегда и везде будет выглядеть одинаково и не будет зависеть от версии плтформенного движка.


Цитата:

DWScript вообще нельзя по лицензии на iOS использовать внутри софта, так как это интерпретатор.

Да вроде как можно. Достаточно условия соблюсти. Ну и потом, iOS не единственный вариант.


Цитата:

Сетевые тулзы типа Synapse/Indy плотно завязаны на сетевой стэк платформы

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


Цитата:

получается, что использовать нативные платформенные возможности удобнее

Не получается. Получается прибить себя гвоздями к единственной платформе. Чего-то мне эта идея не очень симпатична.


Цитата:

Библиотеки доступа к БД - завязаны на сетевой стэк минимум

Да ладно, обертка над библиотекой клиентского доступа знать ничего не знает ни про какой сетевой стек.


Цитата:

Ну и не принято к БД ходить с мобильных дивайсов

БД может быть использована в качестве локального хранилища. И не нужно про SQLite. Я предпочитаю FB/IB и не вижу причин отказываться от них (кроме случаев когда они на платформе не представлены).


Цитата:

Есть локальная ORM CoreData (SQLite3 + отображение данных на классы)

Твои ответы прямо пропаганда vendor lock-in


Цитата:

хотя SHA1/MD5 должен быть в сетевых библиотеках платформы

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

Что за Update 1 xe4 вышел недавно? кто ставил?

alexgala
Пока только Help Update вышел, вроде.

valgreesh


Цитата:

ценность этого рейтинга

Ну - просвятите про "правильный" и "ценный" рейтинг))


Цитата:

популярного массового софта на них нет

Если "них" - это Java/.NET, то чем вам Андроид кажется малопопулярным?


Цитата:

абстрагирующий слой

Ну вот и суть дискуссии - вам нравится использовать абстрагирующий слой, а я в них разочаровался. Нынче я верю только в такие слои, которые дают повышение абстракции (как давала VCL по сравнению с Win32API). А вам нравятся некие "транслирующие" слои, которые абстракцию не повышают, а просто платформенную абстракцию "транслируют" к некому кросс-платформенному API. Лично я такое не люблю, и предпочитаю сразу заюзать платформенное API. Вам это кажется полезным, что тоже ок - у кажого свой опыт и свои представления!))

Oxygene Sugar - не пример такого "транслирующего слоя" ?

deks

Цитата:

Ну - просвятите про "правильный" и "ценный" рейтинг))

Беда в том, что таковых нет.


Цитата:

Если "них" - это Java/.NET, то чем вам Андроид кажется малопопулярным?

С Андроидом ситуация совершенно не показательна. Платформа фактически ставит вас перед выбором - либо жаба, либо NDK.


Цитата:

Нынче я верю только в такие слои, которые дают повышение абстракции (как давала VCL по сравнению с Win32API). А вам нравятся некие "транслирующие" слои, которые абстракцию не повышают, а просто платформенную абстракцию "транслируют" к некому кросс-платформенному API. Лично я такое не люблю, и предпочитаю сразу заюзать платформенное API.

То есть на виндах ты будешь дергать WideCharToMultiByte(), а на линуксах iconv()? Зачем? Не проще ли организовать абстракцию TEncoding и забыть о привязке к платформе, как о страшном сне? Я даже больше скажу, у меня в разработке большая библиотека, так вот для того чтоб она работала в разных версиях дельфей мне пришлось вводить небольшой абстрактный слой над RTL, иначе бы мой код утонул в дефайнах и ифдефах.

Arioch1


Цитата:

Oxygene Sugar

Именно. Как слой абстракции - мне он нравится. С технической точки зрения, - это один из самых "легких" слоев, за счет использования mapped-типов. У mapped типов нет собственных данных, методы-только inline, есть совместимость "по типу" с исходным mapped type (то есть NSString = Sugar.String, можно Sugar.String пихать в Cocoa).

Но надобности в нем немного. Именно поэтому Sugar - это не RTL для Oxygene. Это просто опция для тех, кто любит "абстрактные" обертки))

valgreesh


Цитата:

Не проще ли организовать абстракцию

Вот именно Win32/64 и Linux не имеют нормальных платформенных абстракций, у них не объектно-ориентированный API. Как вы помните, я ранее уже говорил, что VCL стала хорошим дополнением для Win, именно потому что VCL подняла уровень абстракции для Win32 API.

Но для других ОС ситуация качественно другая.

Для Win8 вроде как .NET (в части WinRT) теперь как родной. Для Java/Android и iOS/OSX есть вполне "взрослые" родные абстракции платформы.

А вот уже нормальную абстракцию я не вижу смысла "перепаковывать" в другую абстракцию. Поясню. ИМХО, почти во всех реальных случаях требуется особенности платформы минимум учесть, максимум - задействовать. ИМХО, "скрыться" от деталей реализации платформы получается только в тривиальных случаях: когда API на разных платформах делает одно и то же, просто называется по-разному. Именно об этом ваш пример с конвертацией.

Ну и что делать, когда схожее API на разных платформах делает немного разные вещи и немного по-разному работает? Типа, организации интерфейсных анимаций в WPF и Cocoa? Мы уже знаем, как делает в этом случае FMX - оно делает такие анимации само, делает это с глюками и медленно. Глюки поправимы, а вот "медленно" - может и не получится поправить. Потому как на Cocoa быстро - это когда все делает "системный" уровень, графическое ядро. А логика анимации FMX "не совместима" с логикой анимации Cocoa. Упс.

Добавлено:
Гляньте - TMS прописалось про iCL. Оказывается это iOS Component Library! _http://www.tmssoftware.com/site/blog.asp?post=266

deks

Цитата:

Но надобности в нем немного. Именно поэтому Sugar - это не RTL для Oxygene. Это просто опция для тех, кто любит "абстрактные" обертки))

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


Цитата:

Вот именно Win32/64 и Linux не имеют нормальных платформенных абстракций, у них не объектно-ориентированный API.

Это не совсем так. На виндах есть вполне себе объектные API - это COM, это реализация некоторых компонентов системы выполненная в виде COM-объектов но без поддержки инфраструктурой (Direct2D, XmlLite и другие). На линуксе также есть объектные API - это например GObject в GNOME. Мой пример с кодировкой можно было дополнить вполне себе объектной абстракцией IMultiLanguage присутствующей в виндах.


Цитата:

А вот уже нормальную абстракцию я не вижу смысла "перепаковывать" в другую абстракцию.

А я вижу смысл и смысл этот в написании переносимого кода. Это прекрасно демонстрирует LCL, работая над плоским win32 и объектными GTK2/Qt/Carbon/Cocoa.


Цитата:

ИМХО, "скрыться" от деталей реализации платформы получается только в тривиальных случаях: когда API на разных платформах делает одно и то же, просто называется по-разному.

А разве к гую это не относится? Кнопки они везде кнопки. Поля ввода они везде поля ввода. Минимальные отличия в поведении реализуются как раз на уровне абстракции. По моему Qt и LCL это хорошие примеры возможности писать переносимый софт с нативным гуем.


Цитата:

Ну и что делать, когда схожее API на разных платформах делает немного разные вещи и немного по-разному работает? Типа, организации интерфейсных анимаций в WPF и Cocoa?

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


Цитата:

Мы уже знаем, как делает в этом случае FMX - оно делает такие анимации само, делает это с глюками и медленно

Каково качество FMX мы так же знаем, поэтому сырую альфу вряд ли стоит рассматривать в качестве примера. Но у FMX (а точнее новой системной абстракции дельфей) есть кое что, о чем стоит упомянуть - поддержка сенсоров (в win32 присутствует в виде объектного API). Единообразная на всех платформах. Поддержка захвата и воспроизведения видео (это уже FMX) - единообразная на всех платформах, и более того - расширяемая. В этом и есть сила абстракций, мы можем писать прикладной код не беспокоясь что там творится под капотом.

Добавлено:

Цитата:

TMS прописалось про iCL

Мне не очень понятно, чего все так носятся с iOS и мобильными платформами вообще. Сколько на хабре было историй успеха на iOS - все сплошь игрушки/развлекашки (которым нативный гуй нужен как балерине кирзачи). На андроиде вообще не покупают нифига. Кто-то правда думает зарабатывать бизнес-приложениями на этих платформах?

valgreesh

Цитата:

оксиджен - не хватает языковых возможностей

Каких именно возможностей не хватило?


Цитата:

А я вижу смысл

Дело вкуса) Я ж говорю - у меня ничего путного не получилось, и не претендую на истину. Может, у вас получится!)


Цитата:

Кнопки они везде кнопки

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


Цитата:

сырую альфу

Если что, сырой альфой оно было когда у меня был KsDev Lifetime License, я тогда на нем под OSX пытался в Lazarus ваять)) А сейчас это уже ТЕРТИЙ мажорный релиз. просто он работает как альфа)) И как я уже приводит пример - не факт, что особенности работы всегда связаны с глюками. Иногда, как в примере с анимацией - это не будет вылечено НИКОГДА. Потому как либо анимацию быстро делает ядро ОС, либо медленно делает пользовательский уровень. Оптимизация FMX даст эффект в том, наксколько медленно будет происходить анимация. Пока - в FM3 слайд-анимация выглядит УЖАСНО с точки зрения визуальной, и жрет 90% cpu на самых топовых iOS дивайсах. Как выйдет iPhone5S (или как там его еще назовут) - проверю на нем))


Цитата:

чего все так носятся с iOS и мобильными платформами вообще

Потому что рынок или уже больше всех PC, или прямо в ближайшее время станет больше. И потенциал роста - колоссальный! Smart Watch, Smart Glasses - это все тоже будет под мобильными ОС. Думаю, все devices/embedded скоро переедет на Android c Linux (nas, router, media player, ...). Десктопные ОС переходят в роль "нишевого" продукта "для офиса".


Цитата:

историй успеха на iOS

Успех - это способ сделать что-то полезное широкому кругу посторонних людей. Не всегда это связано с именно продажей софта через магазин. Иногда достаточно возможности доступа через приложение с платформы! Я вообще зарабатываю недвижимостью и продажей пром оборудования для всякой Роснефти)) Но это не мешает мне заниматься разработкой ИТ-технологий/решений для своего бизнеса - я так развлекаюсь)) Но и конкурентное преимущество своего чбизнеса создаю!))

deks

Цитата:

Каких именно возможностей не хватило?

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


Цитата:

.. но HIG разный, стилями поправить не всегда получается, почти всегда нужно перепроектирование GUI для каждой платформы.

Основные отличия - размер элементов и порядок их размещения. LCL, например, решает проблему очень просто - для соответствия размеров используется свойство AutoSize у элементов + очень грамотно реализованные привязки элементов (VCL anchors нервно покуривают в стороне), для порядка размещения используется элемент ButtonPanel, позволяющий размещать кнопки в диалоге так, как это принято на целевой платформе. Ну и кнопки с иконками могут показывать их или скрывать в зависимости от правил принятых на платформе. По идее, возможностей у FMX еще больше т.к. стилизовать можно не отдельные элементы управления а целиком форму (впрочем, LCL-привязки и ей бы не помешали) - что позволит иметь кардинально разные формы - будь на то надобность - на разных платформах. Другое дело, что для использования FMX не пригодна, но мы же говорим о возможности как таковой.


Цитата:

Если что, сырой альфой оно было когда у меня был KsDev Lifetime License, я тогда на нем под OSX пытался в Lazarus ваять)) А сейчас это уже ТЕРТИЙ мажорный релиз. просто он работает как альфа))

Но мы же понимаем, что FMX это уже совсем не VG/DXScene. Как понимаем и то, что сейчас идет процесс переработки её внутренностей и параллельные попытки эту альфу продавать, называемые релизами Я вообще не понимаю, нафига абракадабре понадобилось связываться с KsDev, а не писать полностью своё с нуля. VGScene и до покупки производительностью не блистал, а некоторые решения принятые в нем и вовсе порочны. А теперь не известно будет ли это исправлено.


Цитата:

Иногда, как в примере с анимацией - это не будет вылечено НИКОГДА. Потому как либо анимацию быстро делает ядро ОС, либо медленно делает пользовательский уровень.

Для GPU разницы нет на кого работать - на ядро или пользовательский уровень. Анимации Qt прекрасно работают на мобильных девайсах, хотя, как ты понимаешь, к системе ни какого отношения не имеют. Беда FMX в её кривой реализации, а не в отчужденности от системны. В качестве небольшой иллюстрации приведу пример. Есть известная библиотека GR32, для работы с битмапами. Она хорошо оптимизирована и использует только возможности CPU. У нее есть демка показывающая работу со спрайтами и одновременно выступающая как бенч. Я повторил эту демку на FMX, только задействовал возможности GPU - использовалась Form3D с плоской проекцией. Результат меня удивил - демка из GR32 почти не уступала демке использующей GPU. Но это означает, что FMX совершенно не умеет пользоваться GPU. То есть, не в абстрагирующем подходе проблема - проблема в реализации.


Цитата:

Потому что рынок или уже больше всех PC, или прямо в ближайшее время станет больше. И потенциал роста - колоссальный! Smart Watch, Smart Glasses - это все тоже будет под мобильными ОС.

И что с того? Проникновение у мобильных девайсов всегда было лучше, чем у ПК. Ну да, сегодняшние мобильные дефайсы еще и софт позволяют использовать. Ок. Так какой же софт используют юзеры? Браузер + птички + ферма - примитивные игрушки, короче. Нужно понимать, что основное назначение мобильных устройств это развлечения и все что с ними связано, отсюда и основные тренды в софтостроительстве на этих платформах.


Цитата:

Десктопные ОС переходят в роль "нишевого" продукта "для офиса".

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


Цитата:

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

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


Цитата:

Я вообще зарабатываю недвижимостью и продажей пром оборудования для всякой Роснефти)) Но это не мешает мне заниматься разработкой ИТ-технологий/решений для своего бизнеса - я так развлекаюсь))

Вот теперь очень многое становится ясно

valgreesh


Цитата:

Основные отличия - размер элементов и порядок их размещения

Не всегда. Во-первых, я согласен что на десктопных платформах особых проблем нету - что OS X, что Win32/64, что Linux (в вариации типа Ubuntu) - все похожи. Не даром, все друг у друга чего то крали в плане UI))

На мобильных есть проблема в разном составе элементов и в разном их ожидаемом поведении. Ну типа - разные интерфейсные композиции. Например, как Google Play и AppStore: у AppStore есть вкладки, у Play-нету. Хотя многие не заморачиваются на адаптацию интерфейса к традициям платформы. Так на Android появляются приложения, которые явно были написаны для iOS в свое время.

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

Между жесктопными платформами перенос оч реален - даже на FMX на OSX интерфейс вполне работает. Ну, глюки - да, но не то, чтобы очень неработоспособно.

Между мобильными платформами - не уверен.


Цитата:

Но это означает, что FMX совершенно не умеет пользоваться GPU

Не совсем - оно не умеет согласовать работу GPU на платформе с тем, что нужно именно FMX. И не факт, что можно научить. Может, нужен немного другой подход к построению фреймвока. Вон - iCL хвастаются что анимация выполняется ядром ОС, поэтому плавно. И нажатия на контролья распознаются ядром ОС. Они считают это принципиальным и могу подвержить, что работает это хозяйство в разы шустрее, собственно - аналогично нативным ObjC. Можно ли эмуляцию UI заставить двигаться сопоставимо шустро - не знаю..

По поводу Qt - на iOS живьем, на железе не видел, чтобы обычный интерфейс прям нормально работал. Посмотрим, когда наваяют - вроде бы сейчас только первые альфы выходят! БЫло бы любопытно если они утрут нос FMX. Фактически, единственный оставшийся нативный кросс-платформенный тулкит и единственный конкурент.


Цитата:

под успехом понимаются вполне конкретные деньги

Ну польза=деньги в общеэкономическом смысле. Я имел ввиду то, что деньги можно заработать не продажей софта, а, например, предоставлением сервиса. А уже для оказания сервиса может быть нужно приложение)


Цитата:

основное назначение мобильных устройств это развлечения

Все зависит от желания задействовать дивайс: у нас народ ходит в нашу CRM со смартфонов (урезанный функционал), и в базу знаний) В промежутках между птичками) Ну и апдейты в твиттер/FB/VK сыпятся по статусу заказов - это для клиентов в осн) Для сотрудников пушами удобнее.


Цитата:

многое становится ясно

Да, у меня есть ресурсы для экспериментов)))



Добавлено:
Nested Types

http://wiki.oxygenelanguage.com/en/Nested_Types (с 2005 года)

deks

Цитата:

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

Как раз об этом я и говорил, когда упоминал, что FMX позволяет целиком стилизовать форму, как это делается в контролами. То есть для iOS будет стиль iosformstyle, а для Android androidformstyle. Правда дизайнер не позволяет это автоматизировать, но у FMX с поддержкой дизайнеров вообще беда.


Цитата:

Поэтому по поводу кросс-платформенной разработки - сказал бы так: с десктопа перенести на мобильное устройство прикладное приложение (не игру) - сложно

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


Цитата:

Можно ли эмуляцию UI заставить двигаться сопоставимо шустро - не знаю..

Какие ты видишь технические сложности? Я не вижу ни каких.


Цитата:

По поводу Qt - на iOS живьем, на железе не видел, чтобы обычный интерфейс прям нормально работал.

Демки Qt5 вроде доступны... Андроидные демки на видео выглядели более чем пристойно.


Цитата:

БЫло бы любопытно если они утрут нос FMX. Фактически, единственный оставшийся нативный кросс-платформенный тулкит и единственный конкурент

Эмбаркадеро заявляла о том, что Qt рассматривался, как основа будущего кроссплатформенного фреймвока, но якобы не удовлетворил какими-то возможностями. Хотя скорее всего побоялись привязки к вендору положение которого вызывало опасения.


Цитата:

Да, у меня есть ресурсы для экспериментов)))

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


Цитата:

Nested Types http://wiki.oxygenelanguage.com/en/Nested_Types (с 2005 года)

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

Цитата:

для iOS будет стиль iosformstyle

Мне кажется, это как IFDEF только для GUI.

Не проще ли сделать просто папки в основном проекте - UI/IOS, UI/DROID?

Чем кросс-платформенные формочки, мне больше нравится кросс-платформенная библиотека для тестирования! Вот это реально нужная вещь для кросс-платформы. При правильно разработанной системе тестов сопровождать пару форков проекта - оч просто.


Цитата:

По поводу Qt - на iOS живьем, на железе не видел

Я хотел сказать, что сам не щупал, на своем дивайсе не крутил! Презентации с выставок я к сведению принимаю, не более. Без личного эксперимента нельзя никому щас верить - все стараются альфу и бэту выпустить: приходится все проверять на предмет реального качества каждого решения. Без особых проверок пользую только mature проекты (типа nginx), и то - там свои заморочки))


Цитата:

Nested Types

Э.. Вроде бы все ок с приватными типами. На всякий случай вот тут написано, что это просто member такой, на него все 6 уровней visibility распространяются!
http://wiki.oxygenelanguage.com/en/Class_Member_Visibility_Levels

Не совсем понимаю, если декларировать встроенный тип как private, то зачем его использовать в свойстве? Логично же что он должен быть по уровню видимости = уровню видимости свойства?

Я почему расспрашиваю - потому как оксиген имхо как язык ну всяко помощнее дельфи будет! Оч много хороших и приятных вещей реализовано! Раньше я относился к нему как к "обертке" над фичами .NET, но после появления Java/Cocoa и сохранением фич - мнение сменил. Один colon operator чего стоит ( рекламка фич языка тут http://www.remobjects.com/oxygene/language/ ). Не даром DWS у Oxygene заимствует (просто сделайте поиск "oxygene" по delphitools.info). Много удобных вещей не мешало бы и в Дельфи сделать.

Код:
{$ALIGN ON}

deks

Цитата:

Не проще ли сделать просто папки в основном проекте - UI/IOS, UI/DROID?

Как раз с подходом FMX этого не потребуется - логика гуя будет описана в одном экземпляре, а look будет задан в виде стиля (стили, понятное дело, будут в разных файлах). Решение получается более красивым.


Цитата:

Чем кросс-платформенные формочки, мне больше нравится кросс-платформенная библиотека для тестирования! Вот это реально нужная вещь для кросс-платформы. При правильно разработанной системе тестов сопровождать пару форков проекта - оч просто.

Тесты не священная корова, 100% покрытие обеспечить очень и очень не просто. У меня есть места, где для метода в пару-тройку десятков строк пришлось писать чудовищное количество тестирующего кода. То есть иногда оно того просто не стоит. Хотя, вне всякого сомнения, тесты вещь нужная.


Цитата:

Без личного эксперимента нельзя никому щас верить - все стараются альфу и бэту выпустить: приходится все проверять на предмет реального качества каждого решения

+1. Трудно не согласиться. Похоже, что качество нынче сдает последние рубежи Хотя, качеству последних версий лазаруса я лично очень порадовался - это же офигеть можно, когда в бесплатном продукте редактор кода по возможностям уделывает редактор дельфей.


Цитата:

Э.. Вроде бы все ок с приватными типами

Этот код не скомпилируется:

Код:
TElement nested in value = private class
end;

value = Class
public
function getelement : TElement;
end;

Цитата:

Эмбаркадеро заявляла о том, что Qt рассматривался, как основа будущего кроссплатформенного фреймвока, но якобы не удовлетворил какими-то возможностями. Хотя скорее всего побоялись привязки к вендору положение которого вызывало опасения.

Видно учли опыт Kylix который как раз был завязан на Qt.

LadyOfWood
Qt времен кайликса и сегодняшний Qt это две разные вселенные Тогда он ужасно выглядел и на линуксе и на виндах. Сейчас это хороший фреймвок позволяющий писать приложения которые выглядят родными на целевой платформе. Но я понимаю решение эмбаркадеро гнуть свою линию, особенно учитывая пертурбации творившиеся с Qt в последнее время.

LadyOfWood

Цитата:

Видно учли опыт Kylix который как раз был завязан на Qt.

А разве там не использовалась какая-то кастрированная вариация wine?

valgreesh

Цитата:

Но я понимаю решение эмбаркадеро гнуть свою линию, особенно учитывая пертурбации творившиеся с Qt в последнее время.

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

Цитата:

какая-то кастрированная вариация wine

для GUI - нет.

Иначе бы в delphi 7 не нужно было бы вводить тотже самый CLX точно так же основанный на Qt
Да и в кайликсе бы не надо, если бы кайликс делали на winelib, то в нем бы использовался обычный VCL

Добавлено:

Цитата:

особенно учитывая пертурбации творившиеся с Qt в последнее время

...а я помню, когда-то для C-X-Builder обещали сделать VCL поверх wxWidgets

ведь не qt-ом единым. Есть очень много разных тулкитов.