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

Свежее впечатление по ios приложению от Paul Thornton:

I've finally managed to test one of the XE4 samples on my iPhone4S and I must say I'm a little shocked.
For example, the iOSControls demo (C:\Users\Public\Documents\RAD Studio\11.0\Samples\FireMonkeyMobile\iOSControls) takes around 10 seconds to load. Once loaded, switching tabs has a noticeable delay the first time a tab is displayed. In addition, the animation is very slow and choppy. It's unsightly for controls like checkboxes, but almost unusable for memos and edits when the magnifying glass is displayed.
I really want to start developing iOS apps, but I'm not sure that I can publish them if they behave this way. I'm not even sure that Apple will accept them in the app store

Продолжаем "веселиться":
I have an application made with XE4 it works quite good on windows simulator but on the device(ipad) i got this message ::::
( Access violation et address 00082E6E, accessing address FFFFFFFD )
далее:
I don't know what was the problem but after I restart the device now it work !!!!!
But i have a big problem ::::: loading data in a listbox is very very slow about 1minute for 150 listitem created dynamically (each listitem with 7 ttext )!!!!!!
on win simulator it take about 5 seconds on the device more than 1 minutes !!!!
does any one know how to resolve this problem ?

Цитата:

Свежее впечатление по ios приложению от Paul Thornton:

Вполне ожидаемо. Об этих проблемах уже все говорили. О ответ emb разместило на Apple Store часики.

Цитата:

Вполне ожидаемо. Об этих проблемах уже все говорили. О ответ emb разместило на Apple Store часики.

нет, именно об ЭТОМ и именно о опыте работы РЕЛИЗА delphi for ios еще не говорили,
а часики разместили гораздо раньше, еще в бытность XE2, сейчас их перевели на новый компилер и fmx2 - полистай архив конференции внимательней

Я тут видел в живую XE4

Написали банальное TObject.Create.Free и начали трассировать...

Зашли в system.pas и весь Structure Pane покрылся Error Insight'ами.
Среда не может распарсить собственный галвный модуль.

И ладно бы что-то серьёзное было! Ломается на банальном {$If ...} ... {$EndIf}

Вот не хрен было вымудряться в XE3, надо было раздельные пары директив оставлять ,как в XE2 было

Цитата:

Arioch1

Error insight никогда не работал нормально)) но и System.pas тот еще юнит...

Только начал ставить и сразу увидел ошибку install_RADStudio.exe

Как можно написать такую простую программу с ошибками как install_RADStudio.exe, я понять просто не могу.

mcka

На скриншоте никаких ошибок вы не указали. Заходите в папку Install и запустите файл Setup.exe

sergionn

Ну - его впречателния частично повторяют мои. Он тоже отметил, что старт приложения довольно долгий. Также заметные лаги в интерфейсе - это тоже ожидаемая фигня, так как нативный интерфейс iOS сильно оптимизирован, а FMX - нет. Нужно отметить, что 1,5Ghz мобильный ARM-процессор и даже Intel Atom - это сильно разные по производительности устройства. Так что, то что хоть как то канает на десктопах, совсем малоюзабельное на ARM.

Наких оптимизаций нехватает FMX. Рассмотрим на примере собственных оптимизаций iOS.
Во-первых, однажды прорисованный обьект живет в видеопамяти в виде bmp, что позволяет не обращаться к медленному Objective-C runtme (он там сильно динамический, поэтому несмотря на нативную компиляцию, не самый быстрый). А вот bmp живут прямо в ядре операционки, поэтому выводятся довольно быстро, спасибо железячной поддержке OpenGL с первых версий iOS. FMX стоит тоже кэшировать обьекты, Bitmap styles - шаг в нужном направлении, но нужно идти быстрее. при этом, стоит следить за потреблением памяти - и оперативно убивать ненужные bitmaps.

Во-вторых, нужно оптимизировать создание объектов итерфейса. например, в iOS очень распространен объект список. На его основе сделаны все менюшки, гриды (списки), и даже просмотр фоток. Но у этого объекта довольно хитрое управление памятью. Для каждого видимого элемента списка да, создается объект. Но всего в списке определенное количество обьектов (сколько видно на экране + небольшой запас), которые собраны в пул. Если обьект уходит из зоны видимости, он не уничтожается, а заполняется новыми данными для элемента, который может быть отображен в ближайшее время. Так iOS экономит на отработке конструкторов/менеджеров памяти и деструкторах.

В третьих, все анимации - они hardware accelerated и выполняются не над объектами, а над bitmap, через OpenGL.

Ну и я не вижу смысла все это повторять в коде FMX. Почему бы не взять нативные контролья, которые уже очень оптимизированы и тп, и не делать бы форму из них. Край, можно их стилизовать (a la Pixate). А в дизайнере дельфи показывать те самые эмулированные контролья! Такого дизайнера ни у кого не будет)) А приложение будет шустрым.

Ну и последнее. Не думаю, что быдет много iOS контрольев под Delphi. А вот нативных iOS контрольев - куча, причем большинство free/open source. Зацените на cocoacontrols. Ну и на github зацентие сколько objective-c кода. Дык - почему бы не сделать таки нативный interop с ObjC кодом и классам, и не заюзать эти все контролья? Oxygene же может? Да и в XE4 есть тот же LLVM... Не понимаю..

П.С. Зацените, сколько open-source контрольев используют топовые приложения - _https://www.cocoacontrols.com/apps
Что, ЭМРО хочет быть умнее всех?)

zertyuiop
Вот вам другой скриншот.


PS Уточняю: Образ не битый, комп в порядке.

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

т.е. это не ошибка, просто криво реализован лаунчер.

SolidSnakeRU криво - правильное слово

Цитата:

PS Уточняю: Образ не битый, комп в порядке.

Это нормально у них видно идет CreateProcess, а дальше WaitForSIngleObject, соотв. Цикл обработки сообщений не вызывается и на сообщение WM_NULL ответ не приходит, Windows решает что зависли. У RAD Studio у предыдущих версий также.

Могли бы создать процесс, запомнить ИД и мониторить периодически, кнопки заблокировать и написать что лаунчер ждет завершения установки.

Цитата:

Могли бы создать процесс, запомнить ИД и мониторить периодически,

Могли конечно, но этож надо доп. поток создавать.

Kommunist
XE4 это не просто апдейт XE3 - цена просто апдейта 49 долларов.
За эту цену можно обновить XE3 на 4 той же редакции.
Главная их инновация - ios, этот аддон как раз стоит 450$.

Сперва они хотели выпустить отдельный продукт.
Но посчитали, сколько надо сил, чтоб отрезать функционал на части и решили выпустить в рамках делфи.
Как проще.

Оффтопик: Тут можно как-то получить ссылку на конец темы?
Чтобы ссылка всегда давала последнее сообщение? Надоело в закладках обновлять ссылки.

Цитата:

SolidSnakeRU
XE4 это не просто апдейт XE3 - цена просто апдейта 49 долларов. За эту цену можно обновить XE3 на 4 той же редакции. Главная их инновация - ios, этот аддон как раз стоит 450$.

iOS в XE4 - это epic fail и пользовать его никто реально не будет.
Так что остаются только апдейты...

SolidSnakeRU
Цитата:

получить ссылку на конец темы

[more=Ответ]topic.cgi?forum=33&topic=13680&glp#post
glp = get last page
#post - прокрутка вниз, к форме быстрого ответа. Грубовато, потому что нельзя узнать, сколько сообщений на странице, чтобы подкатить точно к последнему (например, #5). Поэтому можно ещё соригинальничать и перетасовать сообщения:
topic.cgi?forum=33&topic=13680&reverse#1
Кто был последним, станет первым, а кто был первым - станет последним © [/more]

Поставил триал, открыл демку "Delphi\DataSnap\Authorization\SimpleDelphiClient.dpr".
Пишет что в модуле "HTTPProxyProtocol" неизвестный класс "TDBXHTTPLayer".
Ставил все по дефолту. Ключ без исходников, у кого-нибудь работает?

Официальным способом ничего не потестировать? Зачем надо тогда ключи триал делать...

SolidSnakeRU

Цитата:

XE4 это не просто апдейт XE3 - цена просто апдейта 49 долларов. За эту цену можно обновить XE3 на 4 той же редакции.

На самом деле, расклад там следующий:
1. XE3 Pro -> XE4 Pro = 50$
2. XE3 Enterprise -> XE4 Enterprise = 500$
3. XE3 Ultimate -> XE4 Ultimate = 500$
4. XE3 Architect -> XE4 Architect = 500$

Как мы видим, ем-ро не ко всем ещё задницей повернулась

----

Цитата:

открыл демку "Delphi\DataSnap\Authorization\SimpleDelphiClient.dpr".
Пишет что в модуле "HTTPProxyProtocol" неизвестный класс "TDBXHTTPLayer"

Обновили дата снап, демку переписывать надо - чем не open source качество?)

Кто-нибудь пробовал откомпилировать JEDI?

Ошибка на ошибке. На ровном месте. Нужно ждать сервис пак.

Kostyaxp
А что, JediVCL уже есть для ХЕ4?

Никто не подскажет почему свернутая таким образом форма (fmx)
Form1.WindowState := TWindowState.wsMinimized;
кликом по иконке в панели задач, обратно не восстанавливается? В XE3 все было нормально.

p.s. win8x64

Русификация Delphi XE4 версии 18.0.4854.59655 (run-time, .pas-файлы) Пасс - стандартный.
Как устанавливать: содержимое архива распаковать в каталог, прописанный в Library Path, либо в папку с проектом.
Замечания, баги, пожелания - в личку.

з.ы. Сделано на основе Русификации Delphi 2007 (run-time, .pas-файлы) от PoleSoft

Прочитал блогопост _http://blogs.embarcadero.com/jtembarcadero/2013/04/18/true-native/ и немного офигел! Там прямо вводят в заблуждение! Там сказано (см рисунок), что xamarin транслирует для iOS код в vm IL, а уже этот код типа jit-ится в машинный код. Это прямая ложь. На iOS запрещена любая трансляция кода в машинный код, и xamarin monoTouch представляет собой обычный статический компилятор. С этим кстати связаны ограничения на фичи типа Reflection.Emit. См _http://docs.xamarin.com/guides/ios/advanced_topics/limitations

Максимум, что можно припаять для Xamarinа-это то, что он линкует весть свой фреймвок с приложением. Но ровно это же делает дельфи с FMX. Так что они оба не очень native- потому как нету нормального interop с платформой. В Delphi VCL был хороший interop с win32: контролья были обертками над нативными контрольями, была поддержка win messages, была нативная поддержка com как средства взаимодействия с др программами.

С FMX как то не задалось. Win8 не поддерживается толком. На iOS / OSX платформа доступна только через классы-обертки или неявно документированные wrap вызовы и прочие хаки.

Имхо, на iOS / OSX как раз Delphi не особо нативная. Код, да - нативный! Но особо по-другому то на iOS нельзя. Или нативный код, или все внутри web view без nitro js engine.

Неужели в Эмро так не уважают клиентов, что тупо пудрят мозги?! Кстати, комменты к этому блогу закрыты

как-то не особенно понятно:

Цитата:

Delphi не особо нативная, код, да - нативный

То что под ios fmx скорее мёртв чем жив пожалуй соглашусь.
А что с Win8 ? Аргументируйте...

Цитата:

С FMX как то не задалось.

Меня уже второй год не покидает ощущение надвигающейся катастрофы. Нынешний релиз тому подтверждение. Я стал неврастеником?

Цитата:

В Delphi VCL был хороший interop с win32: контролья были обертками над нативными контрольями, была поддержка win messages, была нативная поддержка com как средства взаимодействия с др программами.  

Да но все это было сделано в 1995. Счас к сожалению получается ни рыба ни мясо. Хоть 64-bit компилятор сделали и на том спасибо. А не пойму что мешало сделать VCL for Mac/iOS. Ибо FMX под винду нафиг не нужен когда есть VCL.

Цитата:

Я стал неврастеником?

Реалистом

Цитата:

что мешало сделать VCL for Mac/iOS

Сущая ерунда - отсутствие в MacOS поддержки Win32-программ...

Добавлено:

Цитата:

А что с Win8 ? Аргументируйте...

С ней все хорошо - у нее есть магазин приложенй, для которого Дельфи делать программы не умеет даже для x86...

Добавлено:

Цитата:

а уже этот код типа jit-ится в машинный код.

Это тоже неправда. Про JIT там ни слова. EMBA говорит про чистый интерпретатор, как первые до-JIT'овские версии Mono/Portable.NET