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

sergionn

Да, весело))

Интересно, что TMS напишет про целесообразность создания такого вот пака?))

кстати у Саймона во всю кипит работа: xe4 ios 6.1 framework
_http://blog.naver.com/PostView.nhn?blogId=simonsayz&logNo=120190897311&redirect=Dlog

Цитата:

почему КЛОУНЫ из абракадабры не СДЕЛАЛИ ЭТО?

потому что это не будет работать на винде и андроиде

приехали,

Цитата:

потому что это не будет работать на винде и андроиде

1) а ЭТО и на ios НЕ работает - только греет процессор и кушает память, служа только для ДЕМОШОУ!
2) Эти tms контролы сделаны в виде оберток над нативными, так же как и ВСЕ общение с cocoa api в виде оберток над классами, например вот так напрямую: _http://blog.naver.com/simonsayz/ или через сервисы, которые в свою очередь обертки: _http://docwiki.embarcadero.com/RADStudio/XE4/en/Using_Pickers_to_Provide_Platform-Specific_Behavior_and_View_of_Selection_Controls......
3) Для создания ios приложения - ты СОЗДАЕШЬ НОВЫЙ ДИЗАЙН приложения, с новым расположением контролов, и даже с НОВОЙ нумерацией строк, А НЕ ПЕРЕНОСИШЬ его с windows или андроид, переносится только логика, которая НЕ имеет отношения к gui!

Цитата:

1) а ЭТО и на ios НЕ работает - только греет процессор и кушает память, служа только для ДЕМОШОУ!

Текущий уровень реализации — это отдельная тема. Но контролы от TMS нигде кроме ios работать не будут принципиально, даже в дизайнере вместо них отображаются простенькие заменители. Короче говоря, Эмба развивает кросс-платформенную часть FMX, а поставщики компонент видимо решили взять на себя остальное. Короче говоря, всё тоже самое, что и при разработке под Винду с Девками и ТМСками.

Цитата:

3) Для создания ios приложения - ты СОЗДАЕШЬ НОВЫЙ ДИЗАЙН приложения, с новым расположением контролов, и даже с НОВОЙ нумерацией строк, А НЕ ПЕРЕНОСИШЬ его с windows или андроид, переносится только логика, которая НЕ имеет отношения к gui!

Это смотря какие требования у заказчика и что нужно сделать. Если бы всем нужны были чисто нативные рожи везде и всюду не было бы никаких PhoneGap, jQuery Mobile и прочего добра. А уж если решил задизайнить гуй в своем стиле, то сдались тебе эти нативные контролы.

P.S. Помнится ЭМБ как-то упоминала о сотрудничестве с ТМС и что те готовят что-то интересное. Видимо, оно и есть.
P.S.S. А направление кросс-платформенный фреймворк со своим движком рендеринга GUI и возможностью внедрять нативные контролы мне нравится.

Цитата:

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

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

Цитата:

А направление кросс-платформенный фреймворк со своим движком рендеринга GUI и возможностью внедрять нативные контролы мне нравится.

что то мой кредит доверия к способности разработчиков довести до ума это чудо-фреймворк подходит к концу.......

sergionn

Цитата:

что то мой кредит доверия к способности разработчиков довести до ума это чудо-фреймворк подходит к концу

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

Цитата:

и в теории, если бы fmx был сделан по уму, то разговоров о нативных компонентов почти не возникало...........

Если бы, вот только в реальности все немного по другому.

sergionn

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

Про FMX: я активно экспериментировал с FMX и TMS FMX Pack на XE2, и в результате опытов пришел к полной непригодности FMX для iOS и к вопросам под OSX (общая глюкавость и 32х битый компилятор под 64х битную ось). Поэтому все iOS я сделал на Xcode/objC и немного на Oxygene.

Сейчас мне лень выкидывать еще $1,5-2K на новые эксперименты, поэтому я тестю готовый софт. Результаты показывают очень слабый прогресс FMX в части iOS. В основном, Эмро сделала наконец свой tool chain но качественно не улучшила поведение FMX на iOS. Он все еще тормозной и прожорливый. Вывод: инструмент применим только к созданию iOS версий сервисов уже доступных из Delphi софта.

Что не получится делать на FM3: никакой заказчик просто приложения для iOS не выберет исполнителя с FMX - результат выглядит убого по сравнению с нативными приложениями и даже в сравнении с Xamarin. Также не получится разработать софт для "потребительского" рынка для продажи по причине убогости работы интерфейса - приложения с таким поведением больше 2х звезд в AppStore не получат.

deks
да все понятно, хотелось чтобы все было ок , тем более за такие космические деньги.
В моей ситуации еще все более печально - я бросил старый бизнес и вложился в разработку приложения на fmx, в котором кроме достижения основной цели, пришлось бороться с ордой НЕПРЕКРАЩАЮЩИХСЯ багов, жуткими ТОРМОЗАМИ конечного приложения, КРИВОСТЬЮ реализации фреймворка - на что был просто потерян почти год, и все еще не закончено - неизвестно какие сюрпризы подкинет нам ЗАБЫВЧИВАЯ команда горе-разработчиков в своем детище........

не могу заочно понять, что там он поменял в новой версии своих чудо-овальных часов, и в какой части он использует iAd саймона (размер приложения большой как раньше), но "писает кипятком и плачет как младенец" _http://blogs.embarcadero.com/ao/2013/05/31/39481

Цитата:

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

это будет отлично. Все, что нам нужно от эмбы - это нормальный компилятор + отладчик
И лучше платить за качественные(нативные) решения, чем за поделия FMX

Цитата:

это будет отлично. Все, что нам нужно от эмбы - это нормальный компилятор + отладчик

+1

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

AlekXL

Цитата:

это будет отлично. Все, что нам нужно от эмбы - это нормальный компилятор + отладчик

Это будет ужас. О едином кодбейзе, хотя бы в рамках близких платформ, можно будет забыть. Разработчики компонентов либо будут вынуждены осваиваться на разных платформах, которые им могут быть вообще не интересны, либо забьют на все кроме винды, что вероятнее всего и произойдет. В результате получится, что на виндах будет богатый выбор компонентов, а на всех остальных ОС только стандартные контролы. П-ф-ф, я лучше на Lazarus уйду при таком раскладе.


Цитата:

И лучше платить за качественные(нативные) решения, чем за поделия FMX

В том то и дело, что платить придется и за кривую обезьяну и за решения под каждую платформу.

sergionn

Вот чтобы не влетать на косяки технологии я настоятельно советую делать экспериментальные софтины! ) Причем, в контексте своих задач!) Я так закрыл для себя тему PhoneGap (раньше чем Facebook

А новая версия часиков - он туда вставил обертку над iAd от саймона. У нас iAd вроде бы не показывает ничего (как и в скайпе у нас рекламы нету), а за бугром баннеры крутят)

2 all

Хороший обзор Delphi for iOS от blong: _http://blog.blong.com/2013/05/delphi-for-ios-some-notes.html

Весьма предметно и здраво пишет, мало marketing, много тех деталей.

обзорчик iCL

"Не корысти ради, а токомо по любопытству" посмотрел я в боевых условиях свежую поделку от TMS под зашифрованным именем "iCL". Что бы означало сие название мне неведомо, но скрывается под ним набор native components. Оч любопытно - поэтому решил установить и посмотреть. Ради этого специально залил на клон своей dev vm XE4 (в редакции lite - для экономии времени).

Отдельно хочется сказать про IDE XE4 в целом. Поддержка on-device разработки в XE4 отстает от Oxygene for Cocoa. Во-первых, компилятор для ARM ПРЯМ ТОРМОЗНОЙ. Он реально медленнее раз в пять чем компилятор для iOS Симулятора. Во вторых, PA Server не имеет GUI, в отличие от аналогичного по функциям CrossBox. В тертьих, настройки для deploy приложения разбросаны по разным табам и окнам в опциях, поэтому если нету опыта фиг настроишь без вкуривания документации. В четвертых, система "унаследования" параметров проектов из опций среды глубоко глюкавая. Ну и следует быть готовым к ожиданию деплоя в минуту, неинтуитивным сообщениям об ошибках (например - "не могу скопировать пакет" означает что дивайс не добавлен как development в XCode organizer). Ну и опция developer certificate в настройках - это не dev profile name, это именно имя записи в связке ключей с установленным сертификатом. Выбрать ее из списка как в Oxygene нельзя.

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

Во-первых, что бросается в глаза. В дизайнере дельфи вместо компонентов видны рамки с именами - почти как в XCode когда кастомные контролья дизайнишь) В целом после победы над глюками среды и настройками проект отправляется на дивайс. Софт сырой, падало пару раз. Впрочем - чья это проблема сложно сказать. Например, пока запущен paserver, instruments цепляется с процессу через раз (paserver держит программу хотя она выгружена в менеджере задач - как это можно сделать, хз, аналогичного эффекста с CrossBox мне никогда не удавалось достичь!).

Теперь к результатам тестов под instruments. Все очень даже неплохо, особенно в сравнении с FMX! Расстраивает только вес приложений (15Mb), зато cpu/mem в порядке. Запускается 3-5 секунд. CPU обычно в пределах 10-15%, максимальные скачки до 35%. Эффекты transition стабильно в 7% cpu укладываются. Real mem не поднимается выше 45Mb в обоих приложениях, с 170Mb virtual mem. Это ок. В общем, картина похожа на Xamario.iOS, что не самый грустный вариант! Не понятны только периодические падения CustomCells но закономерности выявить не удалось.

upd посмотрел потроха iCL. Представляет собой обертки над Objective-C контрольями. Все свойства дельфового компонента в геттерах-сеттерах транслируются в Objective-C контрол. Ничего особенно гениального. Вся фича, видимо, в том, что форма FMX является UIView (ну с поддержкой OpenGL), значит можно просто добавлять туда нативные контролья. Все что сделал iCL - это обертки над такими контрольями с понятными для дельфей свойствами. Еще не разобрался как решен вопрос с изменением размеров.

deks
спасибо за обзорчик,
т.е. подитоживая, чтобы этот нативный гибрид сравнялся хотябы с xamarin.ios потребуется еще как минимум 1-2 релиза.....
печально, что и здесь никак не избавиться от 15мб наследия fmx, - начальный размер конечно не большой по современным меркам, но при коммерческой эксплуатации отсечет определенное количество пользователей, остальных отсекут скудная функциональность и возможные баги, вердикт - опять невозможно для ком.разработки.......

sergionn

Не все так печально. Из плюсов: такой подход к UI значительно шустрее FMX контрольев. Выглядит и работает все стандартным образом.

Из минусов: iCL это очередная песочница, то есть доступны только те возможности, которые поддерживает "обертка".

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

Вот и думай: лучше сохранить какой-то багаж legacy кода (и то не факт как он заведется под NextGen компилятором), но иметь геморрой с UI и сторонними библиотеками на платформе. Кстати, я так и не увидел ни одного реального примера программы, которая бы имела одинаковый интерфейс и на телефоне, и на desktop.

По мне лучше как в оксиджене - имеешь реально простой доступ к сторонним компонентам платформы, но под платформу пишешь специальный клиент со своим UI.

Посмотрим, что ЭМРО придумает для Андроида)) Пусть они покажут, как путем смены стиля "брюки превращаются..." (ц)

Есть способ победить tfloatanimation в firemonkey, который идёт рывками?

deks

Цитата:

Из минусов: iCL это очередная песочница, то есть доступны только те возможности, которые поддерживает "обертка".

Может тупость скажу, но разве VCL не те же ограничения? Например, если хочешь использовать ListView по полной, то придётся самому дописывать недописанное, т.к. описано в VCL только 40% функционала.

Честно, не понятно, в чём минус.

DemonMetalist

Я не в курсе про такие способы. Возможно, есть способ задействовать "родные" анимации - по крайней мере slide transition с iCL работает не в пример шустрее того, что на FMX сделано.

Eternal_Shield

Не путайте Win32 которой сто лет в обед, и iOS. Delphi для Win32 был очень родным и нативным средством разработки - поддерживал компонентную модель "в языке" (COM), сообщения (message) и тп. Поэтому дописывание функционала в Delphi для Win32 привело к появлению хороших компонентов, которые неплохо работали внутри Win32. Ну и win32 все ж не был таким объектно-ориентированным.

Под iOS диспозиция другая - если "импортировать" внутрь Delphi какой-то ObjC контрол еще можно, то полноценно расширить его будет сложно. Я до сих пор не понял - можно ли унаследоваться от класса ObjC - походу, нет, так как ObjC классы вроде бы как интерфейсы отображаются в Дельфи. А это значит геморрой с кастомными ячейками для списков и тому подобные проблемы. Еще проблемы - дать библиотеке контейнер, который она заполнит (NSArray / NSDictionary). Для Дельфи это будет не нативный контейнер, который неудобно использовать (for in конструкция вроде как не будет с ними работать). И не путаем: CocoaTouch/Cocoa это вполне себе мощный объектно-ориентированный фреймворк. Беда в том, что его объектно-ориентированные возможности в дельфи задействовать можно довольно убого - типа, на чтение. Вот в этом и проблема!

Upd: сравните ситуацию со строками - для Win32 был введен специальный тип строк, который в COM использовался. А вот под iOS NSString и String - две большие разницы!

Upd2: перефразирую кратко. Для Win32 Дельфи обеспечивал отличное взаимодействие с платформой - и сообщения, и поддержка типов, и компонентной модели, и соглашений о вызовах. Для Cocoa современный дельфи не обеспечивает такого плотного взаимодействия - нет совместимой системы типов (NSString/String, NSNumber/Int, Float etc), нет прямого расширения клсссов Objective-C, сложности с поддержкой исключений и тп.

deks

Цитата:

Не путайте Win32 которой сто лет в обед, и iOS.

А я и не путаю, просто не знаю особенностей последней

В целом ситуация ясна. Не думал, что interop настолько плохой.

Eternal_Shield

Вот вот. Мне потому и импонирует Oxygene, что там interop хороший!) А я прям хочу посмотреть как в дельфи будут выкручиваться с импортированными Objective-C методами, которые дают одинаковую сигнатуру для Дельфи и в Objective-C отличаются разными названиями частей. Ведь Дельфи отличает перегруженные методы только по типам, без учета имен параметров. В Оксиген ввели специальную поддержку таких составных имен. Похоже, другой альтернативы нету.

Ну или вызывать через Objective-С runtime (это как через RTTI) - хотя это через Ж. Впрочем, пока интероп в Дельфи с Cocoa через нее и сделан!

Цитата:

Во-первых, компилятор для ARM ПРЯМ ТОРМОЗНОЙ. Он реально медленнее раз в пять чем компилятор для iOS Симулятора.

Где то читал, что компилятор для симулятора внутри построен на классической архитектуре, а для девайса - на LLVM. То есть тормоза от всех этих внутрених конвертаций и оптимизаций кода внутри LLVM. А значит это не лечится, и все новые компиляторы на LLVM будут тормозными.

Цитата:

А я прям хочу посмотреть как в дельфи будут выкручиваться с импортированными Objective-C методами, которые дают одинаковую сигнатуру для Дельфи и в Objective-C отличаются разными названиями частей.Ведь Дельфи отличает перегруженные методы только по типам, без учета имен параметров. ...
Ну или вызывать через Objective-С runtime (это как через RTTI) - хотя это через Ж.

Все как вы и пишете: http://blog.blong.com/2013/05/delphi-for-ios-some-notes.html

А вообще, если нативность и взаимодействие с платформой так важны, то почему не использовать FPC? У него вроде как уже все готово: http://wiki.freepascal.org/FPC_PasCocoa Еще и старый код можно будет заюзать благодаря похожей RTL.

http://docwiki.embarcadero.com/RADStudio/XE4/en/Conditional_compilation_(Delphi)
вообще да, судя по наличию ассемблера, под симулятор компилируется не через LLVM, а старым компилятором, вероятно наработки еще от Кайликса остались

Frodo_Torbins

Я так понял, что NextGen компилятор сейчас генерирует только ARM код. собственно, LLVM то и нужен был, чтобы генерировать байткод для ARM, так как ЭМРО было бы дорого сделать приличный компилятор еще и для ARM.

Беда в другом - сам по себе LLVM модульный. Но вот RAD Studio вообще не задействует его модульность. То есть, при переписывании ядра IDE с учетом возможностей LLVM все было бы прилично: парсер бы работал в фоне прямо в среде, а бэкэнд отрабатывал бы тоже фоном, а по нажатию кнопки Run только бы бандл приложения паковался б. Например, XCode который тот же LLVM использует - вообще ужастно быстрый, почти как/быстрее Delphi. Сложно сравнивать кто именно быстрее - в последнее время (года 3-4) у меня win живет в vm, а все ж не корректно сравнивать нативно выполняющийся xcode и код внутри vm.

По поводу FPC. Наверное, неплохое решение, кстати, есть даже IDE под OS X, но мне оно кажется менее элегантным, чем Oxygene. Поэтому у меня и подписка на оксиген

По поводу "заюзать старый код". Я тут (года два назад) делал свои прикидки - а чего мне реально нужно тянуть в кросс-платформу? Для этого пару имевшихся проектов (я назвал их "экспериментальными") перешерстили на предмет, разложить "по кучкам" собственно логику приложения, вспомогательные UI-штуки (типа, главная форма с "браузером" формочек, кнопки back, history посещенных форм и тп), вспомогательные платформенно-зависимые штучки (типа, сохранение параметров конфигурации в ini/реестр), вспомогательные штуки для работы с сервисами (rest/собственные сервера приложений), компоненты (отчеты, парсеры всяких XML, JSON, Markdown, YAML, etc).

В общем, оценивая размер кучек пришли к невеселому выводу - большая часть кода она не к приложению относится. Само приложение - это процентов 10-15! Это такой "клей", который сторонние "крипичи" склеивает в некую конструкцию.

Потом глянули, как дела с "кирпичами" в Objective-C (да, были планы миграции/экспансии). Вы знаете, неплохо. Я бы сказал, что с библиотеками отдельных типов там ГОРАЗДО лучше чем в Дельфи. Беда в том, что это именно библиотеки, а не компоненты. Впрочем, особенной трагедии нету - терпимо, я по дизайнеру форм не особо скучаю. Благо значительная часть формочек все равно на лету делается, в коде. И библиотеки есть на любой вкус - и для сервисов, и визуальные компоненты всякие хитрые.

Есть некоторая беда с доступом к базам данных, особенно из iOS. Но все решается веб сервисом. Наверное, даже правильнее такие решать веб-сервисом и кэшированием на клиенте. А это лишний раз говорит о необходимости переделывания приложения под мобильный мир: нельзя вот как в десктопе держать постоянное "живое" подключение к БД. Да и какой админ вам даст выставить БД "в интернет".

Такая же беда с отчетами (reports) - ну нету их как класса под ObjC. Полностью испортило программистов под Cocoa возможность нативно делать PDF. Так что печать документов - ручками. Это не сложно, но визуального дизайнера как в FastReport не предвидится. Не понимаю, почему ушлые фастрепортовцы не сделают Objective-C библиотеку сабжа. Видимо, который год выпускают FR5!

В общем, к чему я это все? Нафиг не нужен "старый код". Хитрые куски алгоритмов перенести не проблема. А вся остальная обвязка делается "по месту". Да и Оксиген то нужен в основном из-за муторного синтаксиса ObjC)

Может кому пригодится
Примеры fibplus для firemonkey http://devrace.com/files/fibplus_examples_fmx.zip

Цитата:

Для Win32 Дельфи обеспечивал отличное взаимодействие с платформой - и сообщения, и поддержка типов, и компонентной модели, и соглашений о вызовах. Для Cocoa современный дельфи не обеспечивает такого плотного взаимодействия - нет совместимой системы типов (NSString/String, NSNumber/Int, Float etc), нет прямого расширения клсссов Objective-C, сложности с поддержкой исключений и тп.

Так и есть, поэтому первые версии Delphi и были прорывом. Причем я не думаю что для ObjC подобная задача не решаема, просто наверное нужны другие инвестиции и кадры.

LadyOfWood

Подобная задача не просто решаема, она фактически решена в Oxygene for Cocoa. И ресурсы у RemObjects - это 2,5 разработчика!

P.S. Разработчики на самом деле хорошие! Они в свое время уделали Borland/CodeGear с поддержкой .NET компилятора, а теперь Cocoa.. У них, кстати, и Java давно работает! "никогда такого не было, и вот снова!" (ц)

deks

Цитата:

Они в свое время уделали Borland/CodeGear с поддержкой .NET компилятора

Не уделать словившего шизу и решившего закопать дельфу Борланда было бы странно. На самом деле Delphi for .NET была совсем даже не плохой, просто в плане языка сильно отстала от моды и кодгиру было бы тяжко тянуть два компилятора да еще и адаптировать RTL + VCL. В общем ремобжектцы годно угадали с моментом. Но что они предлагают? Голый компилятор. Ни собственной RTL, ни чего-то вроде VCL. Ну правда, FPC + Lazarus выглядит куда как интереснее.

valgreesh

Цитата:

FPC + Lazarus выглядит куда как интереснее

Дело вкуса. По мне - так FCL/RTL от FPC довольно скромные в сравнении с .NET/Cocoa. С Java особенно не упражнялся, но там то вообще все в порядке с фреймвоком!))

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