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

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

Arioch1

Не - ну, кроме шуток, пока не ясно с ситуацией FMX на дроиде.

Например, на iOS к FMX 2 существенные претензии: лаги интерфейса и неприличное потребление памяти. В результате - приложение близко к unusable. Впрочем, от лагов может спасти iCL (но теряем маркетинговую флагманскую фишку с multi-device, тк iCL - это iOS only). А вот с памятью - проблемы. Особенно в связке с Interbase. Просто у эпплов традиционно памяти ставится довольно скромно, и на ранних iPad и не очень свежих iPhone приложение FMX может быть слабо юзабельно.

Для дроидов теоретически памяти на флагманах больше, бывает и 2gb. Но дроид славен не столько флагманами (они с iPhone сопоставимы), сколько бюджетными смартами. Но на бюджетных (менее 10к руб) телефонах - по 512-1gb памяти. Плюсом - Dalvik и Java с GC, что в совокупности вроде бы тяжелее native кода на iOS. Это означает, что side by side с NDK-приложением на FMX будет работать Java приложения. Для Android NDK - не самый нативный компонент, его будут прибивать в первую очередь. Не совсем владею темой, могут ли SDK/NDK приложения под Android "впадать в спячку" и есть ли у них такая тема.

К тому же, даже на iOS потребление памяти на FMX было под 200Mb даже для несложных приложений. А отдать 50% памяти под приложение - почти гарантированно столкнуться с выгрузкой его из памяти после каждого принятого звонка или полученной смс. В свою очередь, это ведет к повторному запуску приложения с загрузкой состояния. Приложения FMX и на iOS, и, видимо, на Android обладают еще одним существенным недостатком - они "жирные", по 10-15Mb минимум (за счет статически линкованного фреймворка по типу "все свое несу с собой"). И при старте они будут грузиться и инициализироваться заново. Вспомним, что старт приложения FMX на iOS и самом свежем железе iPhone5 занимает под 10-15 секунд (загрузка волшебных стилей в тч). Не вижу причин, чтобы на Android было быстрее: думаю, даже медленнее за счет использования вместо встроенной flash-памяти внешней (возможно, не самой скоростной) карточки.

Так что - ОПАСНОСТЭ!

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

Цитата:

Если FMX была нужна для других платформ, нафига нужно FMX решение для Win?

Для дебага

Цитата:

Скорее всего купились на обещания Майкрософта и лезли в Метро, чтобы один exe и на десктопе и на планшете.

И это тоже, причем Майкрософту никто не мешает одуматься. Тем более у них сейчас руководство меняется.

Цитата:

Ну так я как услышал про "нативный код на андроиде" сразу для себя крест поставил.

С каждым новым релизом Андроида, нативный код все сильнее внедряют в систему. Очень возможно, что в 5.0 никакой разницы в функционале, по сравнению с Джавой, уже не будет.

Цитата:

Цитата:
т.е. есть что-то новое вместо UpperCase?

Подробнее:
http://edn.embarcadero.com/ru/article/38446
http://edn.embarcadero.com/ru/article/38582
http://edn.embarcadero.com/ru/article/38703

ты не умничай, ты пальцем покажи

Arioch1
На твои вопросы мною уже неоднократно были даны ответы.


Цитата:

Зато вдруг проснулся ego666, влез в чужой спор на стороне Алекса, и до сих пор доказывает, что VCL не нуждается в докусментации

Отстань от меня со своей документацией, я вёл разговор о конкретных твоих претензиях к VCL.


Цитата:

Можно ли развивать VCL? Думаю, безусловно да.

Вопрос куда? VCL - уже давно законченная библиотека, путь для развития только один - в ширь, наращивать компоненты как, к примеру, DevExpress.


Цитата:

Также считаю зря, что VCL не рефакторят, избавляясь от косяков реализации или архитектуры (часть вы упомянули).

От той части, что мы упомянули, не избавиться, т.к. это дизайн-фичи Винды.
По поводу рефракторинга не соглашусь, VCL со времён Delphi7 довольно заметно изменили: прикрутили юникод, подтянули на новые платформу (Виста/Вин7), добавили немного новых компонентов, расширили полезными методами старые компоненты, сильно были изменены сами исходники VCL (много чего добавили/исправили).

Добавлено:

Цитата:

нафига они поддержку других платформ сделали вообще с другой идеологией, архитектурой?!

Вопрос к Крюкову, а EMB просто досталось наследие от VG-Scene.


Цитата:

нафига нужно FMX решение для Win?

Как это "нафига"? Одна технология под все платформы.

Добавлено:

Цитата:

ты не умничай, ты пальцем покажи

Нет сейчас под рукой XE.

Чисто случайно наткнулся на вот такой код в System.Generics.Defaults.pas:

Код: function GetHashCode_Class(Inst: PSimpleInstance; Value: TObject): Integer;
begin
if Value = nil then
Result := 42
else
Result := Value.GetHashCode;
end;

Ха-ха-ха))) Просто процитирую:


Цитата:

No compromises: finally 100% Mac OS-X look & feel Delphi apps with TMS mCL:
http://t.co/V6ZR9lM1Vr

Это к вопросу об архитектуре FMX) же и для OSX сделали а-ля VCL обертки)))

ego666


Цитата:

Вопрос куда? VCL - уже давно законченная библиотека

Да куча вопросов - прежде всего довольно системного уровня RTL. почему нету async библиотеки кросс-платформенной? Почему убогий web? Почему нету нормальной поддержки сетевых штук (кросс-платформенной?)? где ORM/OPF? И тп. В общем, смотрим на .NEt/Java и тупо пытаемся сделать feature parity.

Можно вернуться в сторону более прикладных штук - хотя это уже спорно: почему нету поддержки облачных систем (а-ля TMS CloudPack)? Как насчет довести поддержку ribbon до малоглючного состояния?

Не забываем, что фреймворк должен удачно поддерживать разработку реальных программ. И покупать среду за $2k + докупать на $1k компонентов..

Цитата:

No compromises: finally 100% Mac OS-X look & feel Delphi apps with TMS mCL:

Даже не сомневался, что подобное сделают.

Ribbon не глючный есть. http://www.bilsen.com/windowsribbon/index.shtml

Цитата:

Можно вернуться в сторону более прикладных штук - хотя это уже спорно: почему нету поддержки облачных систем (а-ля TMS CloudPack)? Как насчет довести поддержку ribbon до малоглючного состояния?  

Они просто делают кучу мелких наборов
TMS Cloud Pack for iOS
TMS Component Studio for iOS
TMS Filters for FireMonkey
TMS Instrumentation WorkShop for FireMonkey
TMS Pack for FireMonkey
TMS TableView for FireMonkey
TMS WebGMaps for iOS
TMS WebOSMaps for iOS
TMS iCL
TMS mCL
чтобы, больше бабла сбить.

alexgala
TMS Component Studio for iOS - это пачка из всего для iOS.

DeathMAD
alexgala

Да я про ЭМРО писал. Понятно что у компоненто-поставщиков все есть! Не ясно позиционирование VCL от ЭМРО: или это бесплатный шлак, который все равно пользовать малореально. Или стоит довести компоненты до приличной функциональности! Ну, имхо.

HeMet
Ха-ха это к вопросу того, что у fMX хорошая архитектура!)

Добавлено:
alexgala

Кстати - да! Как раз у TMS компоненты есть в любую нарезку по вкусу - и Subscription, и Packи всякие разные, и бандлы, и отдельные компоненты. Довольно удобно.

Флейм про компоненты относился к комплектности стандартной VCL: в которую входит с визуальной точки зрения непойми чего - особенно в VCL часть. Стандартный набор довольно функционально ограничен.

Цитата:

 Ха-ха это к вопросу того, что у fMX хорошая архитектура!)

Оно бы появилось вне зависимости от его архитектуры, я так считаю. Раньше-позже, но появилось бы - свято место пусто не бывает.

Цитата:

Оно бы появилось вне зависимости от его архитектуры, я так считаю. Раньше-позже, но появилось бы - свято место пусто не бывает.

может, на это и был расчет? Два возможных подхода к созданию интерфейса лучше одного.
Очевидно, кросс-платформенный способ сложнее в реализации, чем нативный. Навряд ли кто-нибудь из сторонних вендоров за это бы взялся, -- и, тем более, преуспел. Ergo, эмба эту задачу взяла на себя. У нее хотя бы не нулевой шанс довести FMX до кондиции. Если всерьез за это взяться.

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

Так что, FMX -- либо плод результат вдумчивого расчета, либо имманентная придурь "пиджаков".

----
Но вообще, у меня другой вопрос.

Вы заметили, что, ВНЕЗАПНО, TMemoryStream стал deprecated?

Код:
// deprecated 'Use TBytesStream';

Цитата:

Это что, синтаксис нетизированных var-параметров в NextGen не работает? Или это очередное волюнтаристское решение разрабов?

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

AlekXL

Цитата:

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

У Lazarus team получается


Цитата:

Вы заметили, что, ВНЕЗАПНО, TMemoryStream стал deprecated?

Пока еще не стал, это же комментарий. Да и сам TBytesStream является наследником от TCustomMemoryStream, у которого тоже deprecated закоментирован.

А не думают-ли они воскресить Delphi for .NET с этой движухой по выкидыванию "unsafe" кода? Какие еще причины ломать совместимость со старым кодом?

KDV сказал, что Xe5 release объявят "завтра в 16-00"

Не совсем понятно по какому времени и имел он в виду 11.09 или 12.09

Ну и всегда может появиться какой-нибудь last moment blocker bug (хотя... у EMBT ? из-за какого-то бага...)

Добавлено:

Цитата:

Навряд ли кто-нибудь из сторонних вендоров за это бы взялся

Они в общем-то и купили у стороннего вендора...
А пираты из Pilot Logic пытаются его развивать в сторону Линукса, не знаю с каким рещультатом

Arioch1

Цитата:

А пираты из Pilot Logic пытаются его развивать в сторону Линукса, не знаю с каким рещультатом

Пока тишина, 4.5 все ни как не релизнут. Но там для развития нужно все сломать до основания (чем абракадабра и занимается, похоже), а потом... В общем, проще было-бы с нуля писать, хотя пираты делать этого не будут. VG/DXScene это же просто кладезь говнокода и кривой архитектуры, не удивительно, что оно такое тормозное.

Кладезь-то кладезь, а другого нет...

у EMB в роудмапе после андроида есть что то ещё? а то может теперь хоть за FM плотнее возьмутся..

так winrt же

ну собственно fmx'ом они и занимаются, не vcl'ем же

Цитата:

у EMB в роудмапе после андроида есть что то ещё? а то может теперь хоть за FM плотнее возьмутся..

Весной на семинаре говорили о Linux также. Сам жду когда закончат с новыми платформами и возьмутся за стандартные компоненты FMX

Цитата:

У Lazarus team получается

хм. А получается ли? Там код как в альфе.. И, я так понимаю, отладчика под многие платформы нет.. Поддерживают мильон платформ, но всюду получается так себе. Ресурсы свои невеликие распыляют. Тогда как реально важны только пара платформ сегодня. Это Windows и Android.


Цитата:

Они в общем-то и купили у стороннего вендора...

который, может , и осмелился написать свой UI layer, но не так, чтобы преуспел:"кладезем" вот его называют.


Цитата:

Но там для развития нужно все сломать до основания (чем абракадабра и занимается, похоже), а потом...

ну,лучше ломать и строить на ходу, чем два-три года пилить что-то новое, не получая на это финансирования.

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

AlekXL

Цитата:

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

Какая?)

AlekXL

Цитата:

А получается ли? Там код как в альфе..

Нормальный там код. Влегкую собираю своей проектик под винды и линукс. Допилят поддержку GTK3 и вообще красота будет.


Цитата:

И, я так понимаю, отладчика под многие платформы нет..

Под виндами и линуксом работает, на маке вроде тоже.


Цитата:

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

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


Цитата:

ну,лучше ломать и строить на ходу, чем два-три года пилить что-то новое, не получая на это финансирования.

Показав говно можно очень сильно испортить себе репутацию. Думаешь так просто они обезьяну в FM Platform переименовали в XE5. И ведь наверняка баги относящиеся к десктопу в очередной раз не пофиксили.


Цитата:

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

XE5 еще не видел, но судя по четверке можно сказать, что улучшается качество реализации в рамках текущей архитектуры. Кто-то им рассказал об использовании хэш-таблиц Вообще, в FMX хорошо сделали, что реализовали слой сервисов, это добавляет гибкости самой платформе. Но там есть очень серьезные архитектурные просчеты в области поддержки стилей. Я тут уже описывал задачку которая принципиально не решается стилями FMX. Стилям не хватает хотя бы простенького скриптования. Объекты стиля получаются "тупыми", и оживить их можно только триггерами, при том, что возможности триггеров сильно ограничены. В общем, в двух словах этого не описать, но кто решится делать собственный стиль очень скоро столкнется с этим. Печалит, что фичи добавляют без проработки, руководствуясь лишь сиюминутными потребностями самой FMX.

Цитата:

Нормальный там код. Влегкую собираю своей проектик под винды и линукс. Допилят поддержку GTK3 и вообще красота будет.

а нафиг под линукс? оно себя окупает там?

Цитата:

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

там нем анонимных методов. Базовая штука, необходимая для многопоточного программирования. Ее нет. И немало еще чего не реализовано.
Не надо им опережать. Сначала нужно все, как есть, поддерживать. И что с того, что бесплатно, если малоюзабельно?


Цитата:

Показав говно можно очень сильно испортить себе репутацию.

она просто сырая. Все это понимали, кто в теме.

Цитата:

Думаешь так просто они обезьяну в FM Platform переименовали в XE5. И ведь наверняка баги относящиеся к десктопу в очередной раз не пофиксили.

В жопу десктоп. Там ее не надо. А если Firemonkey переименовали во что-то более благозвучное, ну я писал, что так и будет.

Цитата:

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

В жопу свисто перделки. Программа должна привлекать удобством и функционалом, а не "красотой". Тем более когда эту "красоту" делает программист.

AlekXL

Цитата:

а нафиг под линукс? оно себя окупает там?

Потому что могу Ну и вообще рассматриваю линукс, как кандидата на основную ОС. Кстати, в убунтовом маркете софт продается, даже отчеты ежемесячные публикуют в omgubuntu.


Цитата:

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

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


Цитата:

она просто сырая. Все это понимали, кто в теме.

От этого легче что-ли?


Цитата:

В жопу десктоп. Там ее не надо.

Если ты хочешь писать переносимый проект - еще как надо. Десктоп это и макОС, между прочим.


Цитата:

В жопу свисто перделки. Программа должна привлекать удобством и функционалом, а не "красотой".

Стили для FMX это не свистоперделки, это базовая идея вокруг которой строится платформа. И в ней изъян.

Цитата:

Сначала нужно все, как есть, поддерживать

Кому ? Вы полагаете, что FPC - это Дельфи для бедных ? А я думаю, для разработчиков FPC эта цель не то что не главная, а хорошо если вообще в первый десяток входит

Добавлено:

Цитата:

анонимные методы без полноценной поддержки компилятором GC или ARC не более чем игрушка

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


Цитата:

ARC у дельфей только на мобилках

А как на delphi 5 писaть для мобилки ???

Arioch1

Цитата:

А как на delphi 5 писaть для мобилки ???

Предполагаю, тезис относился к тому, что ARC только у NEXTGEN компилятора. Для всех десктопных вариаций даже на XE5 - без ARC.

AlekXL

Цитата:

В жопу свисто перделки

К сожалению, отказаться от стилей как свистоперделок на FMX не выйдет - только с использованием iCL/mCL от TMS. Все контролья FMX построены на стилях и тормозят. Согласен 100% с товарисчем valgreesh:
Цитата:

Стили для FMX это не свистоперделки, это базовая идея вокруг которой строится платформа. И в ней изъян.

Кстати, не понимаю, почему нельзя было допилить идею стилей перед превращением VG/DXScene в FMX? Могли бы чего нидь типа компилируемых шейдеров забабахать!