Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
учите яву, что еще посоветуешь…
>Правда у меня при закрытии каждый раз пишет «Прекращена работа программы...».
А Punto Switcher у вас случайно не запущен? Я постоянно сталкивался с таким поведением в XE5. «Помогала» только полная выгрузка PS-а и рестарт IDE.
А Punto Switcher у вас случайно не запущен? Я постоянно сталкивался с таким поведением в XE5. «Помогала» только полная выгрузка PS-а и рестарт IDE.
Насколько я понял из FAQ-а это по сути та же XE5 но без VCL-a. С другой стороны, если этот продукт вдруг выстрелит — то в теории это позволит Embarcadero-вцам оперативнее развивать Firemonkey. Так как AppMethod доступен только по подписке и содержит только FM код а значит не придётся тратить силы на VCL, хотя наверняка это притормозит развитие Delphi.
Запустил из AppMethod-a демку фоторедактора на своём Gigabyte GSmartu Aku A1 — никаких проблем с шарингом. При запуске других демок под виндой вышеупомянутой проблемы с закрытием программы тоже не воспроизвелось.
Выходит эти глюки еще и не стабильны.
Чтобы не быть голословным записал пример падения FireMonkey.
Извиняюсь за качество видео, записывал с вебкамеры ноутбука.
Чтобы не быть голословным записал пример падения FireMonkey.
Извиняюсь за качество видео, записывал с вебкамеры ноутбука.
Вчера запустил у себя демку TabSliding — у меня ничего не падало.
Думаю, что тут либо проблема в несовместимости файрманки и телефона, либо в глюкавости AppMethod-a. Я собрал эту демку у себя и выложил в Google Play. Если не сложно — проверь, пожалуйста как будет работать версия собранная на другой машине (я использовал для сборки последние версии ADK & NDK).
Думаю, что тут либо проблема в несовместимости файрманки и телефона, либо в глюкавости AppMethod-a. Я собрал эту демку у себя и выложил в Google Play. Если не сложно — проверь, пожалуйста как будет работать версия собранная на другой машине (я использовал для сборки последние версии ADK & NDK).
Здравствуйте, Error1024!
Спасибо за проведённые исследования. Если Вам удалось наловить ошибок, пожалуйста, создайте на них отчёт в qc.embarcadero.com, так они гораздо быстрее будут рассмотрены инженерами по качеству.
Что касается AppMethod — да, это «подвид» Delphi для новых не-дельфи-пользователей.
Язык теперь называется Object Pascal.
Сама IDE претерпела некоторые изменения косметического характера, т.к. базовый функционал IDE не требовал каких-то особых доработок при переходе от «настольной» к «мобильной» разработке.
Что касается «трудновоспроизводимых» глюков.
Бывает, что от аппарату к аппарату состав и переодичность багов меняется. У нас есть список рекомендованных устройств:
docwiki.embarcadero.com/RADStudio/XE5/en/Android_Devices_Supported_for_Application_Development
Я провожу неформальный опрос по устрйоствам
blogs.embarcadero.com/vsevolodleonov/category/android-devices/
Проведенный конкурс www.delphimobile.ru/ показал, что в широком диапазоне приложений (19 поданных проектов) Delphi for Android вполне работоспособна как инструмент создания приложений.
Процесс фиксации багов — нужно понимать — требует времени и помощи со стороны пользователей. Т.е. запощивания ошибок на qc.embarcadero.com, который — поверьте — очень внимательно прорабатывается.
Скажу так — по результатам неформального общения с участниками конкурса я также сформировал кумулятивный wish-list, который передал инженерам и который будет «исполнет» в ближайшее время.
Что же до AppMethod — да, это Delphi минус VCL.
Для корпоративных разработчиков останется «старая-добрая Дельфи» со всеми-всеми возможностями (настольная + мобильная разработка).
Для «индивидуальных» разработчиков будет реализовываться «новый-злой Аппметод» с удобными и доступными вариантами приобретения, ориентированными на быструю окупаемость лицензии за счёт продаж продукта через магазины приложений.
Да, Вы — абсолютно правы, есть досадные ошибки, но в целом технологическое ядро (для Delphi и AppMethod) в контексте мобильной разработки вполне эффективно. Остальное — дело эволюции и стабилизации продуктов, чем усиленно занимается Embarcadero в последнее время!
С уважением,
Всеволод Леонов
Developer Evangelist
Embarcadero Technologies,
Russia and CIS
Спасибо за проведённые исследования. Если Вам удалось наловить ошибок, пожалуйста, создайте на них отчёт в qc.embarcadero.com, так они гораздо быстрее будут рассмотрены инженерами по качеству.
Что касается AppMethod — да, это «подвид» Delphi для новых не-дельфи-пользователей.
Язык теперь называется Object Pascal.
Сама IDE претерпела некоторые изменения косметического характера, т.к. базовый функционал IDE не требовал каких-то особых доработок при переходе от «настольной» к «мобильной» разработке.
Что касается «трудновоспроизводимых» глюков.
Бывает, что от аппарату к аппарату состав и переодичность багов меняется. У нас есть список рекомендованных устройств:
docwiki.embarcadero.com/RADStudio/XE5/en/Android_Devices_Supported_for_Application_Development
Я провожу неформальный опрос по устрйоствам
blogs.embarcadero.com/vsevolodleonov/category/android-devices/
Проведенный конкурс www.delphimobile.ru/ показал, что в широком диапазоне приложений (19 поданных проектов) Delphi for Android вполне работоспособна как инструмент создания приложений.
Процесс фиксации багов — нужно понимать — требует времени и помощи со стороны пользователей. Т.е. запощивания ошибок на qc.embarcadero.com, который — поверьте — очень внимательно прорабатывается.
Скажу так — по результатам неформального общения с участниками конкурса я также сформировал кумулятивный wish-list, который передал инженерам и который будет «исполнет» в ближайшее время.
Что же до AppMethod — да, это Delphi минус VCL.
Для корпоративных разработчиков останется «старая-добрая Дельфи» со всеми-всеми возможностями (настольная + мобильная разработка).
Для «индивидуальных» разработчиков будет реализовываться «новый-злой Аппметод» с удобными и доступными вариантами приобретения, ориентированными на быструю окупаемость лицензии за счёт продаж продукта через магазины приложений.
Да, Вы — абсолютно правы, есть досадные ошибки, но в целом технологическое ядро (для Delphi и AppMethod) в контексте мобильной разработки вполне эффективно. Остальное — дело эволюции и стабилизации продуктов, чем усиленно занимается Embarcadero в последнее время!
С уважением,
Всеволод Леонов
Developer Evangelist
Embarcadero Technologies,
Russia and CIS
Здравствуйте!
Сделал набросок парсера, и компонент для вывода выражения с подсветкой синтаксиса, TEdit были есть глючен, поэтому я не стал его использовать.
На компьютере все было хорошо, но на телефоне получил ужасные тормоза в функции, рисующей на Canvas всего лишь 30-50 символов разных цветов. Причем настолько огромные тормоза, что интерфейс был не юзабилен. Пришлось забросить и, судя по всему, не один я столкнулся с тормозами при выводе текста.
Если Вам удалось наловить ошибок, пожалуйста, создайте на них отчёт в qc.embarcadero.com, так они гораздо быстрее будут рассмотрены инженерами по качеству.FireMonkey делается в России нашими разработчиками, может будет проще напрямую, или с вашей помощью отписаться о багах?
Проведенный конкурс www.delphimobile.ru/ показал, что в широком диапазоне приложений (19 поданных проектов) Delphi for Android вполне работоспособна как инструмент создания приложений.Я тоже писал приложение на конкурс, калькулятор с возможностью строить графики.
Сделал набросок парсера, и компонент для вывода выражения с подсветкой синтаксиса, TEdit был
На компьютере все было хорошо, но на телефоне получил ужасные тормоза в функции, рисующей на Canvas всего лишь 30-50 символов разных цветов. Причем настолько огромные тормоза, что интерфейс был не юзабилен. Пришлось забросить и, судя по всему, не один я столкнулся с тормозами при выводе текста.
>>FireMonkey делается в России нашими разработчиками, может будет проще напрямую, или с вашей помощью отписаться о багах?
Да, платформа FM делается российскими разработчиками, но не только ими. Вообще, сложно разделить производственные подразделения компании на «Россию» и «не-Россию».
Самое эффективное — описывать баги на qc.embarcadero.com, т.к. это есть прямой путь. Есть хорошие новости — в ближайшем roadmap обозначены явные намерения сделать технологию более стабильной (ссылка не вставляется, но edn.embarcadero.com/article/43677).
>>Я тоже писал приложение на конкурс, калькулятор с возможностью строить графики.
Компонент TChart вполне применим, на Nexux 7 мне удавалось воспроизвести достаточно насыщенные построения графиков.
>>но на телефоне получил ужасные тормоза в функции
Печально читать, но в ближайшее время мы озабочены проблемами стабильности и быстродействия (см. roadmap). Надеемся, что в ближайшее время большинство проблем будут устранены.
Да, платформа FM делается российскими разработчиками, но не только ими. Вообще, сложно разделить производственные подразделения компании на «Россию» и «не-Россию».
Самое эффективное — описывать баги на qc.embarcadero.com, т.к. это есть прямой путь. Есть хорошие новости — в ближайшем roadmap обозначены явные намерения сделать технологию более стабильной (ссылка не вставляется, но edn.embarcadero.com/article/43677).
>>Я тоже писал приложение на конкурс, калькулятор с возможностью строить графики.
Компонент TChart вполне применим, на Nexux 7 мне удавалось воспроизвести достаточно насыщенные построения графиков.
>>но на телефоне получил ужасные тормоза в функции
Печально читать, но в ближайшее время мы озабочены проблемами стабильности и быстродействия (см. roadmap). Надеемся, что в ближайшее время большинство проблем будут устранены.
Выложи, пожалуйста, исходники проекта, который тормозит — это будет лучший багеропорт.
Тут есть ряд аспектов, технологических, исторических, политических, экономических, (о-боже!) маркетинговых :)
В до-FireMonkey-овский период были стремления Embarcadero сделать библиотеку визуальных компонентов, выходящую за рамки Windows. Совсем углубляться в историю с CLX сейчас смысла большого нет. Тогда тоже были «кроссплатформенные» инициативы, вызванные рыночной ситуацией (Linux в предустанове шёл практически на каждом втором ноутбуке — ну или по крайней мере был заметен в качестве бизнес-настольной ОС — не путать с «вашей» домашней настольной ОС — разные вещи). Почему Linux не стал «альтернативой» — вопрос очень интересный. Факт более высокой стоимости владения? Маркетинговый разгром? Предчувствие облаков и снижение интереса к настольным баталиям? Стоимость Windows-компетенции сисадмина vs «Линуксоида»? Протекционизм? Возьмём узкий сегмент — школы. Деньги экономит школа/гос-во, а напрягаюсь я (учитель). Хотя есть и специалисты с опытом (не) успешного распространения Linux, которые, возможно, захотят пролить бОльший свет, хотя общая тема здесь другая.
Закончу лишь тем, что Kylix до сих пор продаётся/используется.
К релизу Delphi XE назрела необходимость сделать что-то новое. Если компания (от поставщика йогуртов до автопрома) не выдаёт ежегодно что-то новое (желательно революционное), то начинаются здоровые сомнения в её (блин) креативных возможностях. А имиджевая составляющая в IT (какими бы функциональными прагматиками мы, разработчики/пользователи, себя бы не считали) очень высока. Можно сказать, выше не бывает, т.к. мне продают функционал, полезность которого я могу оценить только в перспективе, а чем выше уровень технического совершенства, тем дальше эта перспектива. А тут нам (Embarcadero) хорошо поддал рынок с 16% доли Mac-ов в корпорациях США и хорошим ростом на фоне стагнации десктопных Windows-машин. Было принято решение сделать VCL+ и ей-же войти в новый сегмент средств разработки под Mac OS.
VCL+ была хорошей идеей, Mac OS с хорошей имиджевой составляющей особенно в контексте ЛПР в нашем случае «двигал» средства разработки за собой (хотя, в большинстве случаев, бывает и наоборот). Перед инженерами Embarcadero встала задача разделения VCL на функционально-поведенческий и визуализационный уровень. Пилёжка VCL оказалась чуть сложнее, чем распиливание барышень в ящике, WinAPI слишком жёстко был прописан в генах этой библиотеки (что ранее как раз и было громадным её преимуществам, качество визуальных приложений на её основе не уступало «нативным» тулзам). Создавать «Delphi for MacOS» с полностью различными исходниками относительно классических «Delphi for Windows» было плохой идеей – биться сразу на двух фронтах (с Visual Studio и с Xcode) Embarcadero явно не улыбалось.
Выло выбрано следующее стратегическое решение. Слово «стратегический» здесь нужно воспринимать неэмоционально. Просто «стратегия» означает – линия поведения в ситуации неопределенности – такова стратегия IT-рынка средств разработки. Вместо деления VCL с весьма сомнительными перспективами в плане совместимости со «старыми» VCL-неразделёнными кодами, компания Embarcadero решила взять новую библиотеку. Да, она в прототипе основывалась на KSDev с последующим развитием и ре-брендингом в FireMonkey (сейчас «платформа FM»).
FireMonkey изначально основывалась на единстве функционального поведения (кнопка нажимается, «поле ввода» получает символы, чекбокс – чекится), при вариациях механизмов отображения – Quartz для Mac OS и DirectX (и GDI+) для Windows. Тут и проявлен «исторический» аспект «не-нативности» контролов FireMonkey. Уже были известны библиотеки, «рендерящие» в GPU-based режиме. Для Mac OS это вообще не было проблемой, а хилые Windows-машины оставались на откуп общей генеральной линии развития аппаратного обеспечения компаний (GDI+ был оставлен именно по этой причине). Вышла Delphi XE2, которая включала не только VCL практически без изменений, но и новую библиотеку кроссплатформенной разработки на основе единого кода FireMonkey.
Технология дала основу для достаточно вменяемого и, как оказалось, эффективного маркетинга.
— VCL forever – весь legacy-код будет эффективен и работоспособен;
— Delphi готова к освоению новых платформ.
В довесок Embarcadero усилила инструмент 64-битным компилятором и занесла ногу на поле iOS. В релизе XE2 можно было создавать «нативные» приложения для iOS с использованием той же самой FireMonkey. Object Pascal – он и в Африке такой (в буквальном смысле этого слова, в ЮАР принята гос-программа обучения на Delphi), а рендеринг/отображение компонентов сводится к элементарным операциям отрисовки графических примитивов.
Технологически – функциональность визуальных компонентов неизменна, под конкретную платформу на уровне сервисов подключается «аппарат рисования». Конечно, это – не «нативные» конторы. Зато интерфейс был 100% единый кроссплатформенный на уровне дизайнера Delphi.
Рынок отреагировал на это ростом более 50% продаж средств разработки Embarcadero поколения XE2. Разработчикам – пользователям Delphi – очень понравилась идея сохранения компетенции в современных динамически изменяющихся условиях в сфере платформ. Маркетингово это звучит как one «codebase – one team – one project schedule». Проблема «нативности» контролов никого не парила – поверьте, большинству разработчиков важны интегральные качества инструмента разработки, а не мифическая близость к платформе. В целом, идея хорошо проинвестированной технологии быстро вылилась в растущий имидж Delphi, сказалась на росте и послужила основой дальнейшего развития.
Если в области Windows-desktop-client-server-rich-GUI-разработки Delphi начинала с тотальной монополизации, то вход в рынок средств мобильной разработки требовал сверхусилий. VCL оставлена была «как есть» из-за невозможности четкого выделения границ функциональности/отображения. А без этого всё-равно получалась не «новая VCL с нативным отображение», а «ещё одна VCL для Mac OS» или iOS или Android и т.д. Достаточно дерзкая попытка взять iOS из Delphi XE2 при помощи конвертации проекта в Xcode и до-компилирования Free Pascal Compiler для ARM удалась. Но полноценное решение появилось в Delphi XE4 на основе своего компилятора и полного отказа от Xcode.
Возвращаясь к теме дискуссии – «нужны ли нам нативные контролы в противовес рисованными руками»? Ещё раз хочется подчеркнуть, что тема – не чисто технологическая. Любое инженерное решение должно основываться на комплексе показателей. Но есть же средства мульти-платформенной разработки, которые используют нативные конторлы? Да, есть, но они не идеальны. Сохранение единства кода и дизайна интерфейса сильно под вопросом. В смысле, что вопроса то и нет, т.к. нет единства. Есть «скриптовики» и «гибридные» средства. Но нативный исполняемый код и нативный интерфейс при 100% едином исходном коде – это проблема, которая должна быть решена. Подход Embarcadero в том, чтобы (возможно) придти к «нативному» решению от «рисованного», тогда как можно было тормознуть релизы (XE4 – iOS и XE5 – Android), чтобы «впилить лобзиком» нативные контролы в FireMonkey.
Чуть коснёмся проблематики FM vs VCL (и далее “VCL.mobile” – мне вполне нравится это название). Когда вводили новую библиотеку FireMonkey, конечно, был вопрос. Сделать их максимально близкими для облегчения миграции (хотя бы на уровне свойств-событий) или сбросить оковы «совместимости». Пошли вторым путём, FM сильно отличается от VCL. Победителей не судят, а мессидж «FireMonkey – не VCL» был воспринят спокойно. Все-таки кроссплатформенный (и далее мобильный) проект обычно новый и мало тащит за собой коды прошлых desktop-проектов.
Нативизация – проблемы и задачи.
Не-нативность (рисованность) контролов FM дала гигантское ускорение. Для покрытия новой платформы потребовалось лишь создать новый платформенный стиль (чуть больше, чем просто «шкурка» или «скин»). Это дало возможность в 2013 году обеспечить поддержку и iOS, и Android. Некоторые «особо злые в плане само-рисования» контролы уже нативные («календарчик», к примеру).
Нужна ли FM истинная нативность? Вопрос реакции пользователей (разработчиков мобильных приложений). Пока наблюдается достаточно ярко выраженная реакция что: «наконец-то Delphi делает под Android/iOS» с весьма весомым притоком пользователей Visual Studio и Xcode в ряды «дельфистов». Скорее всего, задачей будет в первую очередь дальшейшая стабилизация как платформы FM, так и IDE в целом, а нативизация будет там, где она критична. По крайней мере на ближайшую перспективу, о чём было сказано при обсуждении roadmap выше.
В до-FireMonkey-овский период были стремления Embarcadero сделать библиотеку визуальных компонентов, выходящую за рамки Windows. Совсем углубляться в историю с CLX сейчас смысла большого нет. Тогда тоже были «кроссплатформенные» инициативы, вызванные рыночной ситуацией (Linux в предустанове шёл практически на каждом втором ноутбуке — ну или по крайней мере был заметен в качестве бизнес-настольной ОС — не путать с «вашей» домашней настольной ОС — разные вещи). Почему Linux не стал «альтернативой» — вопрос очень интересный. Факт более высокой стоимости владения? Маркетинговый разгром? Предчувствие облаков и снижение интереса к настольным баталиям? Стоимость Windows-компетенции сисадмина vs «Линуксоида»? Протекционизм? Возьмём узкий сегмент — школы. Деньги экономит школа/гос-во, а напрягаюсь я (учитель). Хотя есть и специалисты с опытом (не) успешного распространения Linux, которые, возможно, захотят пролить бОльший свет, хотя общая тема здесь другая.
Закончу лишь тем, что Kylix до сих пор продаётся/используется.
К релизу Delphi XE назрела необходимость сделать что-то новое. Если компания (от поставщика йогуртов до автопрома) не выдаёт ежегодно что-то новое (желательно революционное), то начинаются здоровые сомнения в её (блин) креативных возможностях. А имиджевая составляющая в IT (какими бы функциональными прагматиками мы, разработчики/пользователи, себя бы не считали) очень высока. Можно сказать, выше не бывает, т.к. мне продают функционал, полезность которого я могу оценить только в перспективе, а чем выше уровень технического совершенства, тем дальше эта перспектива. А тут нам (Embarcadero) хорошо поддал рынок с 16% доли Mac-ов в корпорациях США и хорошим ростом на фоне стагнации десктопных Windows-машин. Было принято решение сделать VCL+ и ей-же войти в новый сегмент средств разработки под Mac OS.
VCL+ была хорошей идеей, Mac OS с хорошей имиджевой составляющей особенно в контексте ЛПР в нашем случае «двигал» средства разработки за собой (хотя, в большинстве случаев, бывает и наоборот). Перед инженерами Embarcadero встала задача разделения VCL на функционально-поведенческий и визуализационный уровень. Пилёжка VCL оказалась чуть сложнее, чем распиливание барышень в ящике, WinAPI слишком жёстко был прописан в генах этой библиотеки (что ранее как раз и было громадным её преимуществам, качество визуальных приложений на её основе не уступало «нативным» тулзам). Создавать «Delphi for MacOS» с полностью различными исходниками относительно классических «Delphi for Windows» было плохой идеей – биться сразу на двух фронтах (с Visual Studio и с Xcode) Embarcadero явно не улыбалось.
Выло выбрано следующее стратегическое решение. Слово «стратегический» здесь нужно воспринимать неэмоционально. Просто «стратегия» означает – линия поведения в ситуации неопределенности – такова стратегия IT-рынка средств разработки. Вместо деления VCL с весьма сомнительными перспективами в плане совместимости со «старыми» VCL-неразделёнными кодами, компания Embarcadero решила взять новую библиотеку. Да, она в прототипе основывалась на KSDev с последующим развитием и ре-брендингом в FireMonkey (сейчас «платформа FM»).
FireMonkey изначально основывалась на единстве функционального поведения (кнопка нажимается, «поле ввода» получает символы, чекбокс – чекится), при вариациях механизмов отображения – Quartz для Mac OS и DirectX (и GDI+) для Windows. Тут и проявлен «исторический» аспект «не-нативности» контролов FireMonkey. Уже были известны библиотеки, «рендерящие» в GPU-based режиме. Для Mac OS это вообще не было проблемой, а хилые Windows-машины оставались на откуп общей генеральной линии развития аппаратного обеспечения компаний (GDI+ был оставлен именно по этой причине). Вышла Delphi XE2, которая включала не только VCL практически без изменений, но и новую библиотеку кроссплатформенной разработки на основе единого кода FireMonkey.
Технология дала основу для достаточно вменяемого и, как оказалось, эффективного маркетинга.
— VCL forever – весь legacy-код будет эффективен и работоспособен;
— Delphi готова к освоению новых платформ.
В довесок Embarcadero усилила инструмент 64-битным компилятором и занесла ногу на поле iOS. В релизе XE2 можно было создавать «нативные» приложения для iOS с использованием той же самой FireMonkey. Object Pascal – он и в Африке такой (в буквальном смысле этого слова, в ЮАР принята гос-программа обучения на Delphi), а рендеринг/отображение компонентов сводится к элементарным операциям отрисовки графических примитивов.
Технологически – функциональность визуальных компонентов неизменна, под конкретную платформу на уровне сервисов подключается «аппарат рисования». Конечно, это – не «нативные» конторы. Зато интерфейс был 100% единый кроссплатформенный на уровне дизайнера Delphi.
Рынок отреагировал на это ростом более 50% продаж средств разработки Embarcadero поколения XE2. Разработчикам – пользователям Delphi – очень понравилась идея сохранения компетенции в современных динамически изменяющихся условиях в сфере платформ. Маркетингово это звучит как one «codebase – one team – one project schedule». Проблема «нативности» контролов никого не парила – поверьте, большинству разработчиков важны интегральные качества инструмента разработки, а не мифическая близость к платформе. В целом, идея хорошо проинвестированной технологии быстро вылилась в растущий имидж Delphi, сказалась на росте и послужила основой дальнейшего развития.
Если в области Windows-desktop-client-server-rich-GUI-разработки Delphi начинала с тотальной монополизации, то вход в рынок средств мобильной разработки требовал сверхусилий. VCL оставлена была «как есть» из-за невозможности четкого выделения границ функциональности/отображения. А без этого всё-равно получалась не «новая VCL с нативным отображение», а «ещё одна VCL для Mac OS» или iOS или Android и т.д. Достаточно дерзкая попытка взять iOS из Delphi XE2 при помощи конвертации проекта в Xcode и до-компилирования Free Pascal Compiler для ARM удалась. Но полноценное решение появилось в Delphi XE4 на основе своего компилятора и полного отказа от Xcode.
Возвращаясь к теме дискуссии – «нужны ли нам нативные контролы в противовес рисованными руками»? Ещё раз хочется подчеркнуть, что тема – не чисто технологическая. Любое инженерное решение должно основываться на комплексе показателей. Но есть же средства мульти-платформенной разработки, которые используют нативные конторлы? Да, есть, но они не идеальны. Сохранение единства кода и дизайна интерфейса сильно под вопросом. В смысле, что вопроса то и нет, т.к. нет единства. Есть «скриптовики» и «гибридные» средства. Но нативный исполняемый код и нативный интерфейс при 100% едином исходном коде – это проблема, которая должна быть решена. Подход Embarcadero в том, чтобы (возможно) придти к «нативному» решению от «рисованного», тогда как можно было тормознуть релизы (XE4 – iOS и XE5 – Android), чтобы «впилить лобзиком» нативные контролы в FireMonkey.
Чуть коснёмся проблематики FM vs VCL (и далее “VCL.mobile” – мне вполне нравится это название). Когда вводили новую библиотеку FireMonkey, конечно, был вопрос. Сделать их максимально близкими для облегчения миграции (хотя бы на уровне свойств-событий) или сбросить оковы «совместимости». Пошли вторым путём, FM сильно отличается от VCL. Победителей не судят, а мессидж «FireMonkey – не VCL» был воспринят спокойно. Все-таки кроссплатформенный (и далее мобильный) проект обычно новый и мало тащит за собой коды прошлых desktop-проектов.
Нативизация – проблемы и задачи.
Не-нативность (рисованность) контролов FM дала гигантское ускорение. Для покрытия новой платформы потребовалось лишь создать новый платформенный стиль (чуть больше, чем просто «шкурка» или «скин»). Это дало возможность в 2013 году обеспечить поддержку и iOS, и Android. Некоторые «особо злые в плане само-рисования» контролы уже нативные («календарчик», к примеру).
Нужна ли FM истинная нативность? Вопрос реакции пользователей (разработчиков мобильных приложений). Пока наблюдается достаточно ярко выраженная реакция что: «наконец-то Delphi делает под Android/iOS» с весьма весомым притоком пользователей Visual Studio и Xcode в ряды «дельфистов». Скорее всего, задачей будет в первую очередь дальшейшая стабилизация как платформы FM, так и IDE в целом, а нативизация будет там, где она критична. По крайней мере на ближайшую перспективу, о чём было сказано при обсуждении roadmap выше.
Не знаю как кого, а меня XE2 привлекла в своё время лишь боле-мене дозревшей, как казалось, работой с Unicode, несмотря на всё ещё глючную новую IDE, новые возможности языка типа шаблонизации и перегрузки операторов, новые библиотеки в комплекте, типа регулярных выражений. Плюс перспектива собрать что-то под 64 бита, с удобным доступом к большому адресному пространству.
Правда, перегрузка операторов оказалась только для record, а шаблоны в сам VCL так и не проникли… Но хоть модуль есть с шаблонными заготовками. legasy, понимаю… (
Возня с FireMonkey ощущалась как досадное отвлечение ресурсов компании от исправления багов и неудобств IDE и VCL, которые с незапамятных времён висят без движения в хвалёном QC. Ведущиеся под знаменем FireMonkey активные работы по портированию компилятора Delphi под другие платформы и библиотек этих платформ под Delphi — были и есть единственным реально перспективным вкладом FireMonkey в развитие Delphi. Осталось дождаться, чтоб кто-нибудь заморочился, и таки написал на этих портированных библиотеках VCL-образные обёртки для нативных контролов. Может, купите потом их вместе с автором…
Нативные контролы операционки — это не только внешний вид, соответствующий общесистемной теме оформления не только в статике, но и в динамике со всеми анимациями, это ещё и скорость работы, непротиворечивое и знакомое по другим приложениям полноценное поведение, предусмотренное для как всех видов поддерживаемого системой оборудования типа мышей, клавиатур, перьев и сенсорных экранов, так и всевозможных общесистемных расширений типа экранного диктора. Это ещё и встроенная системная локализация текстов, если они в контроле есть.
Нужно больше native, тоньше обёртки, меньше самописных вмешательств в встроенное поведение контролов! Любая фича, не предусмотренная в родном контроле, если уж и реализована самописно — должна быть отключаема, и в документации должно быть сказано: включите — выключится нативность, будем рисовать/реагировать сами, как сумеем. (Я сейчас, например, пункты меню вспоминаю. Зачем их VCL сама рисует??? Ну зачем??!!) Неужели невозможно сделать хоть одну среду разработки, которая удобно даст доступ к родным контролам ОС?
Или ненативный редактор кода Delphi XE2 — он не поддерживает прокрутку пальцем! Воспринимает палец как нажатую мышь, и тягает им курсор, выделяя текст. Это ужасно огорчает на сенсорном экране. Но редактору кода ещё как-то просительно, нативного редактора кода в винде нет. А эти прямоугольные выпуклые кнопки на андроиде? Это ж даже смотрится безобразнейше!
Про баги и странности IDE. Тулбар в IDE настроить невозможно, при таскании панелей остальные скачут непредсказуемо. У редактора кода непонятным образом иногда включается ReadOnly. Из Watches убили Break when changed для просматриваемых переменных. Зачем?? При том, что создать точку останова на изменение данных всё равно можно, но надо изгаляться, самому адрес через Evalute/Modify вычислять и в новый брейкпоинт вписывать.
Или вот подходы к архитектуре. OSX предлагает средства Automator и AppleScript, Windows предлагает VBScript и PowerShell. Приложения Delphi никак не готовы к применению этих инструментов, нет в библиотеках VCL и FMX ничего для их поддержки, насколько я знаю. Всю поддержку нужно делать с нуля, борясь с предлагаемым каркасом приложения, считающим, что среду ОС нужно использовать по-своему, а не как задумано её разработчиками. Или вот это окно от Application, из-за которого главное окно приложения пришито к кнопке на таскбаре белыми нитками и периодически отрывается то так то эдак. Или подход MVC, пропагандировавшийся MS, от которого в дельфи при предлагаемой архитектуре приложений остаются одни шкурки, если самостоятельно сильно не заморочиться? Почти всё поперёк style guides и архитектурных рекомендаций.
уф, выдохся пока.
Правда, перегрузка операторов оказалась только для record, а шаблоны в сам VCL так и не проникли… Но хоть модуль есть с шаблонными заготовками. legasy, понимаю… (
Возня с FireMonkey ощущалась как досадное отвлечение ресурсов компании от исправления багов и неудобств IDE и VCL, которые с незапамятных времён висят без движения в хвалёном QC. Ведущиеся под знаменем FireMonkey активные работы по портированию компилятора Delphi под другие платформы и библиотек этих платформ под Delphi — были и есть единственным реально перспективным вкладом FireMonkey в развитие Delphi. Осталось дождаться, чтоб кто-нибудь заморочился, и таки написал на этих портированных библиотеках VCL-образные обёртки для нативных контролов. Может, купите потом их вместе с автором…
Нативные контролы операционки — это не только внешний вид, соответствующий общесистемной теме оформления не только в статике, но и в динамике со всеми анимациями, это ещё и скорость работы, непротиворечивое и знакомое по другим приложениям полноценное поведение, предусмотренное для как всех видов поддерживаемого системой оборудования типа мышей, клавиатур, перьев и сенсорных экранов, так и всевозможных общесистемных расширений типа экранного диктора. Это ещё и встроенная системная локализация текстов, если они в контроле есть.
Нужно больше native, тоньше обёртки, меньше самописных вмешательств в встроенное поведение контролов! Любая фича, не предусмотренная в родном контроле, если уж и реализована самописно — должна быть отключаема, и в документации должно быть сказано: включите — выключится нативность, будем рисовать/реагировать сами, как сумеем. (Я сейчас, например, пункты меню вспоминаю. Зачем их VCL сама рисует??? Ну зачем??!!) Неужели невозможно сделать хоть одну среду разработки, которая удобно даст доступ к родным контролам ОС?
Или ненативный редактор кода Delphi XE2 — он не поддерживает прокрутку пальцем! Воспринимает палец как нажатую мышь, и тягает им курсор, выделяя текст. Это ужасно огорчает на сенсорном экране. Но редактору кода ещё как-то просительно, нативного редактора кода в винде нет. А эти прямоугольные выпуклые кнопки на андроиде? Это ж даже смотрится безобразнейше!
Про баги и странности IDE. Тулбар в IDE настроить невозможно, при таскании панелей остальные скачут непредсказуемо. У редактора кода непонятным образом иногда включается ReadOnly. Из Watches убили Break when changed для просматриваемых переменных. Зачем?? При том, что создать точку останова на изменение данных всё равно можно, но надо изгаляться, самому адрес через Evalute/Modify вычислять и в новый брейкпоинт вписывать.
Или вот подходы к архитектуре. OSX предлагает средства Automator и AppleScript, Windows предлагает VBScript и PowerShell. Приложения Delphi никак не готовы к применению этих инструментов, нет в библиотеках VCL и FMX ничего для их поддержки, насколько я знаю. Всю поддержку нужно делать с нуля, борясь с предлагаемым каркасом приложения, считающим, что среду ОС нужно использовать по-своему, а не как задумано её разработчиками. Или вот это окно от Application, из-за которого главное окно приложения пришито к кнопке на таскбаре белыми нитками и периодически отрывается то так то эдак. Или подход MVC, пропагандировавшийся MS, от которого в дельфи при предлагаемой архитектуре приложений остаются одни шкурки, если самостоятельно сильно не заморочиться? Почти всё поперёк style guides и архитектурных рекомендаций.
уф, выдохся пока.
До кучи:
VirtualTreeView: почему всё ещё опенсорсный
4 мая, 2012
Компания Embracadero Technologies известна яростной скупкой компонентов. По крайней мере PNG for Delphi уже в общем доступе не найдёшь, да и FireMonkey изначально был разработан русскими.
Однажды на что-то потребовался VirtualTreeView. Скачал, установил, внедрил, переделал под себя… и вдруг удивился: Project Manager и Object TreeView явно сделаны на этом компоненте (VTV написан с полнейшего нуля, и его легко узнать по необычному способу множественного выделения и специфичным недоработкам с клавиатурой). Почему его-то не купили?
Хотя о причине догадываюсь. VTV, несмотря на 30 тыс. строк кода, всё ещё «сырой». Не работает множественное выделение с клавиатуры, да и «мышиное» небезгрешно. Хотелось бы заменять drag&drop на множественное выделение в тех местах, где таскать мышью не нужно. «Грязный» explorer'овский стиль. Глюки на крупных шрифтах. Наконец, ради скорости пожертвовали чистотой API.
я 21 го поеду на презентацию XE6 в оснабрюке, можно донести крик масс :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор Appmethod [Много картинок]