» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

ego666


Цитата:

как на нём гуи под ios писать

Двумя способами - или в "родном" для iOS XCode (Interface builder) через xib/storyboard, или "руками" в коде (что мне больше нравится). Не проблема заюзать кучу компонентов с cocoacontrols. Ситуация аналогична и под андроид.


Цитата:

нафига он тогда нужен

Для эстетики и некоторой унификации кросс-платформенной разработки: используется довольно неплохая и удобная VS (на всех платформах), схема работы также одинаковая для всех платформ.


Цитата:

свой платформозависимый код

Не видел практических и хороших примеров кросс-платформенного кода, особенно между desktop / mobile. Даже iOS / Android "изнутри" архитектурно довольно разные. Для себя я пока не вижу возможности "абстрагировать" различия и не потерять в практически используемом функционале. Пример потери функциональности у дельфи: виджеты для OSX / Android и нативные контролья (сторонние) в iOS.


Цитата:

писать на родных для платформы языках

Как раз оксиген / гидроген дает возможность использовать знакомый язык (Delphi / C#) с некоторыми наворотами для поддержки платформы. И не ударяться в синтаксис ObjC/Java. Я ж говорю - эстетика! ))


Цитата:

зачем эта "прослойка"

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


Цитата:

Оксиген, как ЯП

Я бы отметил еще DWS - много хороших идей.


Цитата:

её платформа, rtl

Нету у оксигена платформы и RTL, только платформы, на которых оно работает. Это не баг, это фича))

deks

Цитата:

Нету у оксигена платформы и  RTL, только платформы, на которых оно работает. Это не баг, это фича))

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

valgreesh

Тут ключевой фокус - в отношении к вашей фразе "единство кода". У RO позиция в том, что единство кода применимо для довольно узкой ниши: собственные куски кода, собственная прикладная логика. Если дело касается взаимодействия с платформой, то код индивидуален для каждой платформы.

Кстати, у Xamarin подход в части UI/платформы аналогичен, но Xamarin тащит довольно пухлый невизуальный RTL .NET. К сожалению, это не опционально.

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

Опять же, я не видел живьем реальных кросс-платформенных приложений, нормально вписанных в платформу (игры не считаются - у них взаимодействие с платформой минимально). То есть "one codebase" - это маркетинговый buzz.

deks

Цитата:

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

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


Цитата:

Кстати, у Xamarin подход в части UI/платформы аналогичен, но Xamarin тащит довольно пухлый невизуальный RTL .NET. К сожалению, это не опционально.

Я ничего не знаю о ксамарине, но вот тут пишут, что результирующий файл получается довольно небольшой, по крайней мере по сравнению с XE5


Цитата:

Опять же, я не видел живьем реальных кросс-платформенных приложений, нормально вписанных в платформу

Да ладно... Lazarus, GoldenDict, VirtualBox, VLC. Это только то, что первым в голову пришло.

На мой взгляд чужеродность VLC и VBвидна невооруженным взглядом

Впрочем, смотря кто насколько придирчив, конечно же

Arioch1
В чем выражена чужеродность их внешнего вида? Ну у VLC ползунок совмещенный с указателем прогресса отличается от системного, у VB градиентные заголовки для сворачиваемых групп. Так и Delphi тогда выглядит чужеродной с её TButtonGroup используемом для списка компонентов, с её нестандартными табами в редакторе кода. Про студию так и вообще можно не говорить - сама чужеродность. Не, что VLC, что VB выглядят вполне себе по-системному, в отличии от той же FMX, например. А небольшие украшательства сейчас позволяет себе чуть ли не каждая софтина.

Цитата:

Двумя способами - или в "родном" для iOS XCode (Interface builder) через xib/storyboard, или "руками" в коде (что мне больше нравится).

этож адъ и израиль?


Цитата:

Ситуация аналогична и под андроид.

так ведь под андроид только руками?

Добавлено:

Цитата:

Не видел практических и хороших примеров кросс-платформенного кода, особенно между desktop / mobile.

INDY?

Добавлено:

Цитата:

Нету у оксигена платформы и RTL, только платформы, на которых оно работает

я про это и говорю, это и отталкивает

Tulnov

Цитата:

Русификация Delphi XE5

Фай не найден. Породнее обменник можно?

Добрый день.
Подскажите, плз, менялось ли что-нибудь в XE4/XE5 в части работы с VCL Styles? Желательно, в лучшую сторону, конечно .
Может встроенный редактор Bitmap Style Designer допилили, работу с самими стилями и т.д. Сейчас стоит XE3.
Спасибо всем откликнувшимся.

Цитата:

Фай не найден. Породнее обменник можно?

У меня без проблем скачалось.
Перезалил на rghost
http://rghost.ru/download/49276167/4ed135df863e24c08c460ef1a236ff1610ff8c38/19.0.13476.4176_RU.7z

Если у кого-то есть проблемы с подключением китайских No-Name девайсов через USB к RAD Studio XE5 из-за отсутствия драйверов или по другим причинам, то эта проблема решается подключением и дебагом через Wi-Fi вместо USB. Подробнее можете прочитать блоге DevArt:

http://blogs.devart.com/dac/index.php/remote-debug-of-android-application-in-rad-studio-xe5-via-wifi.html

Судя по QC, GPU Vivante не поддерживаются. Признаком того, что вы столкнулись с этой проблемой, является появление сообщения "Cannot find shader variable 'MVPMatrix'" в логах девайса. Визуально это выглядит как белый или черный экран вместо формы. На своем планшете видел

После компиляции и установки стандартных семплов из FireMonkeyMobile желание писать под Android в XE5 полностью пропало.
Здесь уже писали, что приложение занимает от 6МБ, что при запуске первые секунды приложение тормозит.
И самое печальное, это когда в приложении (MobileControls) нет не единой строчки, при этом оно может вылететь с ошибкой. Вот скриншот:



P.S. Тестил на HTC One X (1500MHz - 4 ядра)

проголосуем! против разгильдяйства!

кстати да, они мне что предлагают хэши в юникоде хранить??

Цитата:

проголосуем! против разгильдяйства!

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

Я переходил с Delphi 2006 сразу на XE3, не было ни одной проблемы со строками (про указатели и работу с данными строк напрямую не предлагать - зачем привязывать себя к текущей версии платформы, если можно писать "устойчевый код").

Цитата:

кстати да, они мне что предлагают хэши в юникоде хранить??

Сами хэши как и раньше - в байтах.
А их hex- или base64- текстовое отображение, да в юникодных строках. там, где это нужно.

Цитата:

Я переходил с Delphi 2006 сразу на XE3, не было ни одной проблемы со строками

это лишь говорит, на каком низком уровне у тебя находилась работа со строками. Даже поиск без учета регистра в юникоде -- не так реализуется, как в АНСИ.
Не, серьезно ARC- ну кукан с ним, пусть будет. Нуль-индекс строки отключаемы..
Но выпил 8-битовых строк это ваще ни в какие ворота. Если кто лицензионный юзер Дельфей, не поленитесь, проголосуйте, и , если можно, напишите камент, типа "bring the bleeding Utf8String back! I mean it!".

Цитата:

это лишь говорит, на каком низком уровне у тебя находилась работа со строками. Даже поиск без учета регистра в юникоде -- не так реализуется, как в АНСИ.

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

Я лицензионный пользователь, проголосовал за возврат 8-битных строк, но ИМХО - не смертельно.

В том же FastReport уже нет AnsiString, и ничего. Жизнь продолжается

Приведите пожалуйста пример, который невозможно реализовать на UnicodeString ?

Цитата:

Я переходил с Delphi 2006 сразу на XE3, не было ни одной проблемы со строками

Что Вы имеете в виду? В Ваших проектах нигде не использовался, например, тип Char?

Цитата:

Что Вы имеете в виду? В Ваших проектах нигде не использовался, например, тип Char?

Конечно использовался, строк валом. Только какая разница занимал этот тип 1 байт или стал двумя ?

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


Цитата:

Тотальная «уникодификация» затронула практически все составляющие IDE. Прежде всего, это изменение строковой концепции языка. Был добавлен новый строковой тип UnicodeString. Для UnicodeString внутренним форматом будет UTF16. Тип string, который ранее описывался как AnsiString, стал UnicodeString. Типы Char и PChar, которые ранее соответствовали AnsiChar и PAnsiChar, соответственно стали WideChar и PWideChar. Как следствие, все заголовочные файлы для работы с WinAPI изменены под юникод. Если ранее все функции соответствовали A функциям Windows, то теперь они будут соответствовать W функциям... Например, если в Delphi 2007 MessageBox определялась как MessageBoxA, то в Delphi 2009 она это будет MessageBoxW.

http://www.xakep.ru/post/44864/default.asp

MGAlex, так я и не писал о проблемах. Наоборот, считаю что ничего не изменится с удалением AnsiString.

NickNNN
Определенные неудобства безусловно возникнут. Хотя бы банально нужно будет менять типы данных.
Но со временем все привыкнут.

Но вот специфический подтип COW-массивов мог бы быть и полезен.

Правда если народ путается с какой цифры конейнеры и строки индексировать, путают интерфейсы и объекты, то от разных видов массивов вообще бы крышей потёк

valgreesh

Цитата:

Lazarus, GoldenDict, VirtualBox, VLC

У VirtualBox нету интерфейса своего. У VLC есть отдельный порт для iOS с родным интерфейсом. Lazarus на OSX довольно страшный. GoldenDict не юзал.

Я ж говорю - качественных кросс-платформенных портов не бывает.

ego666


Цитата:

этож адъ и израиль?

Нативный XCode при работе со сторонними компонентами тоже вместо компонентов заглушки показывает. Поэтому проще в коде все сделать, чем связываться с дизайнерами и всякими глюками nib/xib/storyboard. "тут так принято" (ц) Зато в результате все выглядит хорошо и работает шустро!


Цитата:

под андроид только руками

Да вроде нет - можно заюзать стороннюю рисовалку интерфейсов - все равно на выходе xml будет. Хотя я под андроид ходил только ознакомительно, без особой практики.


Цитата:

INDY?

Я про UI часть. В невизуальный кросс-платформенный код я верю, с оговорками))

deks

Цитата:

У VirtualBox нету интерфейса своего.

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


Цитата:

У VLC есть отдельный порт для iOS с родным интерфейсом

Было бы странно, еслиб было иначе. Я же не о переносе десктопной морды на мобильную ОС говорю.


Цитата:

Lazarus на OSX довольно страшный.

Он и под виндами, и под линуксом красотой не блещет, но это не от того, что LCL не позволяет делать красиво, а от того, что разработчики Лазаря не парятся по этому поводу. Просто при разработке именно "кросс" есть нюансы о которых нужно помнить. Но это не делает такую разработку невозможной.

valgreesh

Ну - в перенос между двумя основными десктопными платформами еще можно поверить. Благо, и win и linux довольно активно передрали интерфейс с с OSX. Хотя блага в таком переносе немного: сложно заюзать платформенные фичи.

Но вот в перенос между десктопом и мобильной платформой - never.

Ну и между iOS/Android тоже сомнительно, за исключением игр со своим фейсом! Мобильные платформы еще слишком молодые, чтобы отрасль выработала общие подходы к мобильной платформе. Хотя вот нотификации уже похожи до безобразия. Осталось разобраться с многозадачностью, фоновыми приложениями, виджетами и тп. Но пока унифичировать что-то между платформами - смысл? Гораздо проще переписать "морды" (view/activity) и привязать к общему backend.

А вот кросс-портабельный backend я хочу! Именно поэтому очень уважаю RO за RO/DA. Ну и еще кучу хорошего софта бы между платформами не помешало: http/rest/oauth пакеты, social sharing, multithread, да тот же xUnit!

deks

Цитата:

Хотя блага в таком переносе немного: сложно заюзать платформенные фичи.

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


Цитата:

Но вот в перенос между десктопом и мобильной платформой - never.

О такой глупости никто и не говорит - слишком разные устройства, слишком разный UX.


Цитата:

Ну и между iOS/Android тоже сомнительно

Да они же все ближе и ближе становятся, iOS7 с HOLO чуть не близнецы братья Да и взаимодействие с пользователем не сказать, что сильно отличается.


Цитата:

Гораздо проще переписать "морды" (view/activity) и привязать к общему backend.

Гораздо проще сделать так, как делает дельфя. Вопрос лишь в качестве реализации и охвате абстрагирующего слоя (я вообще поражаюсь, как они умудряются год за годом фейлить такую не сложную задачу, как отрисовка кастомного гуя).


Цитата:

А вот кросс-портабельный backend я хочу! Именно поэтому очень уважаю RO за RO/DA

А вот с подходом Oxygen'а это через чур геморойная задачка (с RO/DA все понятно, это их продукт, еще бы им его не поддерживать на всех платформах покрываемых кислородом). Поддержка даже нескольких версий дельфей в большом нетривиальном проекте выливается в некислые пляски из-за различий в RTL. А уж сколько их будет при поддержке совершенно разных RTL и подумать страшно.

так ни кто и не написал что надо править что бы утечки не было, написать было бы думаю не плохо, итак:
утечка памяти в 3d программах, баг в XE5 в модуле FMX.Types3d
найти строки

else
begin
if not (TCanvasStyle.NeedGPUSurface in Self.CanvasClass.GetCanvasStyle) and FTextureNeedUpdate then

заменить на

else if FTextureNeedUpdate then
begin
if not (TCanvasStyle.NeedGPUSurface in Self.CanvasClass.GetCanvasStyle) then

описано здесь http://qc.embarcadero.com/wc/qcmain.aspx/qcmain.aspx?d=118923

в FM шрифты сглаживаются некрасиво, что бы боле менее лучше стали отображаться можно сделать так:
в dpr или dproj файл добавляем в
uses
.....
FMX.Types,
.....

begin

FMX.Types.GlobalUseDX10:=false;
и по желанию
FMX.Types.GlobalUseDX10Software:=false;

.........

этим отключается прорисовка через DirectX и включается прорисовка текста через GDI+ шрифты стали лучше смотреться.