Лидеры

Основатель FMX Евгений Крюков в поисках работы: https://plus.google.com/u/0/105338484741532774705/posts/SnK5twK939Y Основатель FireDAC Дмитрий Арефьев тоже больше не работает. По Вашему мнению какие все же перспективы RAD при такой кадровой политике?

Ссылка: http://delphifmandroid.blogspot.ru/2016/11/html.html Автор: Андрей Ефимов Описание:

Выберите Edit1.ControlType := Platform;

Мужики, простите, форму с каким мишкой?

использовать VCL'ный вариант например procedure TForm1.FormMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); // uses WinApi.Windows, WinApi.Messages, FMX.Platform.Win begin ReleaseCapture; SendMessage(FmxHandleToHWND(Handle), WM_SYSCOMMAND, $F012, 0); end;

Изучите эту тему: http://fire-monkey.ru/topic/3307-tlistview-как-отловить-нажатие-на-картинку-в-tlistview/ Там с примером.

Лучше использовать ForceDirectory, она создает все промежуточные папки, если их не находит

LThread может и не запуститься на андроиде и удалиться до старта, после выхода из метода.

Почему? Для некоторых нужд очень даже. К примеру регулярно пользуюсь ftp-сервером на телефоне - намного удобнее заливать/сливать (по wifi) книги, музыку и прочее, сидя за компьютером в Far manager, чем перетаскивая мышкой в убогих индусских синхронизаторах или пользоваться облачными решениями (залить 30 гигов в dropbox с компьютера (тут нет проблем, инет 450 мегабит), а потом их выкачивать из инета на телефон даже по wifi ac то еще удовольствие).

Я отказался от TActions ввиду глючности и не предсказуемости. Попробуйте этот код: procedure TFormMain.ListBoxMultiViewItemClick(const Sender: TCustomListBox; const Item: TListBoxItem); Var LThread: TThread; S : String; begin if Not Item.Selectable then exit; if Not Item.Enabled then exit; MultiView.HideMaster; if Item = ListBoxItemShare then begin SendError('Share url'); S:='Всем срочно ставить моё крутое приложение для Android'+#10+URLGooglePlay; LThread:=TThread.CreateAnonymousThread( procedure begin ShareUrl(S); TThread.CurrentThread.Terminate; end); LThread.FreeOnTerminate := true; LThread.Start; end; end; procedure ShareUrl(AURL : String); {$IFDEF ANDROID} Const SMediaLibraryOpenTextWith = 'Send text using:'; var MIMETypes: string; Intent: JIntent; IntentChooser: JIntent; ChooserCaption: string; {$ENDIF ANDROID} begin {$IFDEF ANDROID} try Intent := TJIntent.Create; MIMETypes := 'text/plain'; // Intent.setAction(TJIntent.JavaClass.ACTION_SEND_MULTIPLE) Intent.setAction(TJIntent.JavaClass.ACTION_SEND); Intent.setType(StringToJString(MIMETypes)); Intent.setFlags(TJIntent.JavaClass.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET); Intent.addFlags(TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION); Intent.putExtra(TJIntent.JavaClass.EXTRA_TEXT, StringToJString(AURL)); ChooserCaption := SMediaLibraryOpenTextWith; IntentChooser := TJIntent.JavaClass.createChooser(Intent, StrToJCharSequence(ChooserCaption)); SharedActivity.startActivity(IntentChooser); finally end; {$ENDIF ANDROID} end;

Если компанию собираются продавать, то обычно увеличивают её капитализацию. а самый простой способ это сделать - набрать побольше сотрудников. Так что нет, не думаю. Да и банально кому нужен продукт без разрабов.

Грустно конечно, но я полагаю стоит подождать полгода-год, за это время может что-то станет видно, или вообще измениться? Вот кстати C++Builder - наняли нового человека, который занимается теперь плюсами, пока только лучше стало - появился бесплатный LLVM компилятор от Embarcadero.

Посмотрите свою старую тему http://fire-monkey.ru/topic/3303-ошибка-при-подключении-pas-файла

Коллеги, всем привет! Сначала хочу всех немного успокоить. Часто бывает, что в команде (а то и в сборной) по футболу меняют тренера, ведущих игроков, стратегию игры и т.д. Для футбола это - нормально. Нормально ли это для разработки софта? Отвечу комплексно. Сначала скажу, что я - MVP Embarcadero, но работаю я в www.workspad.ru - компании, организованной Сергеем Орликом. Во многом моя работа в Embarcadero до Samsung-а повлияло на то, что Сергей меня взял себе сотрудником - сейчас я занимаюсь развитием международного бизнеса www.workspad.com. Delphi остаётся моим любимым инструментом, недавно я начал писать что-то на блоге, просто жизнь позволила заниматься этим активно. Также мы начали проект TurboCocoa, где мне доверили роль frontman-а. Это такая тулза поверх Delphi, чтобы можно было писать 100% нативные по UI/UX приложения (Mac OS, iOS, Android). Но это - отдельный разговор. Конкретно про IT-бизнес, разработку ПО, зрелость продукта и кадровую политику Embarcadero. Я могу себе позволить её комментировать, т.к. я НЕ сотрудник Embarcadero (that's really impossible from inside). Разработка современного ПО - не вся, а определённого класса - стала настолько зрелой, что может быть правильным образом формализована с точки зрения требований и разбита на изолированный класс задач. Первый небольшой софт писался человеком, который "всё-в-одном", мы знаем, что первые версии Pascal писались одним человеком. Теперь это - большой коллектив. Как только Delphi как продукт стала большой и (!) зрелой, то стало возможным оптимизировать вовлечение специалистов. Это нормально для строительства - каждый новый дом - отдельный релиз. Вот наняли архитекторов, вот - проектантов, вот - бригаду бетонщиков, вот - электриков. А вот - систему кондиционирования взяли у другой компании с их проектом и их монтажом, которые тоже сами кондиционеры не производят. А обслуживать здание будет вообще другая компания (багфиксинг). Поймите правильно - я связан тесными личными отношениями с Егвением Крюковым, Ярославом Бровиным и другими разработчиками Embarcadero. Но есть и объективные процессы, которые лично меня по жизни двигали часто не туда, куда я хотел двигаться сам - есть обстоятельства непреодолимой силы. Т.е. мой анализ - безличностный. Если мы побьём задачи развития Дельфи на составные компоненты, то - да - есть совсем изолированные задачи: - компоненты - компиляторы - надстройки над IDE Возможно, именно такая организация Delphi как открытой среды и явилось причиной модульности не только её самой, но и команды специалистов, её развивающей. Т.е. я бы не стал сейчас резко негативно высказываться (опять же, несмотря на дружбу с разработчиками-Эмбаркадеровцами). Вопрос контрактной схемы развития продукта существует. Например, есть такая компания - SoftServe. Я её знаю ещё со времён Samsung. Потому как эта компания выполняет заказные разработки для крупнейших вендоров в мире, что совсем не вредит продукту. Какие минусы. Конечно, если в основе продукта не стоит узкая команда эксклюзивных архитекторов, то могут быть проблемы. Но, положа руку на сердце, даже FMX уже стала зрелой платформой, архитектурно созданной и отработанной Евгением Крюковым. Вспомним Андерса Хейлсберга. Да и даже Вирта - совсем не обязательно, чтобы он работал в Embarcadero для развития языка Object Pascal. Компоненты - ну тут мы вообще видели, что многие компоненты (наш же всеми любимый FireDAC) как раз и создавался вне Borland/Embarcadero. Компилятор - вообще отдельная песня. Какие плюсы. Плюсы - возможность оптимизировать затраты на разработку. Всякий из нас знает, можно нанять строителей на оклад и на "объем - сделал/получил" - дают существенную разницу в результатах. Более того, это - мировой тренд. Если свой разработчик может "пудрить мозг", то сдельный - не сделал, не получил. Наняли другого. А ещё с внешней рабочей силой можно поддержать любой релизный темп. Нужно упереться и выполнить обещание перед пользователями - до-няняли ещё 10 разработчиков и уложились. Стегать своих сотрудников, работающих на постоянке - бесполезно. Что можно ждать в будущем. В будущем нужно ждать следующего релиза. Не секрет, что у Embarcadero roadmap существенно расходится с релизами. В случае с сторонней разработкой это будет невозможно. Всё будет выполняться точнее. Что по деньгам? Не думаю, что это - вопрос денег. Можно больше вложить и "резче" сделать релиз, чем "растягивать удовольствие годами" (то же Linux-компилятор, я ещё до-Embarcadero это слышал). И получить больше продаж. И более сильные рыночные позиции. В любом случае, контроля над разработкой у Embarcadero теперь больше, а средства - гибче. Нужно посмотреть на следующий релиз.

можно вот так смотреть какой сейчас компонент имеет фокус procedure TForm1.FormFocusChanged(Sender: TObject); var aControl: TControl; begin if Screen.FocusControl <> nil then begin aControl := Screen.FocusControl.GetObject as TControl; Caption := aControl.ClassName + ' x ' + aControl.Name; end; end; если конкретный проверить, то if Edit1.IsFocused then Caption := 'Edit1.IsFocused';

Извините за возможный глупый вопрос, а каким образом влияют на загрузку приложения звуковые файлы, которые при загрузке,как вы пишите, даже не используются??? Ну при диплойменте, да, дельфи их долго копирует, но при повторном (первичном без диплоймента) приложение должно запускаться быстро. Ведь это просто файты, которые лежат в соседней директории и все! Попровьте, если я не правильно что то понял.

Если говорить о размере приложения. То первоначально нужно понять, что входить в состав пакета? Затем определить, что нужно и не нужно? Давайте посмотрим на примере состав пакета небольшого Андроида приложения, написанного в RAD Studio XE5 Delphi. В качестве примера, я взял приложение PhotoEditorDemo, доступный на официальном Open Source проекте примеров RAD Studio XE5 Это пример кроссплатформенного простого фоторедактора: Описание примера: http://docwiki.embarcadero.com/CodeExamples/XE5/en/FMX.Mobile.PhotoEditorDemo_Sample_(Delphi) Исходники: http://sourceforge.net/p/radstudiodemos/code/HEAD/tree/branches/RadStudio_XE5_Update/FireMonkeyMobile/Delphi/PhotoEditorDemo/ Размер сжатого приложения Собираем приложение и смотрим на результирующий пакет PhotoEditorDemo.apk (Он располагается в директории .\Android\Debug\PhotoEditorDemo\bin относительно корня проекта). После сборки приложения его размер ~6 760 КБ (в зависимости от Debug or Release сборки). Это размер сжатого пакета нативного приложения. Размер распакованного приложения Если мы распакуем ZIP архиватором этот файл, то увидим его содержание: В распакованном виде, пакет занимает 21,7 МБ. Состав пакета Что же входит в его состав: lib - место хранения собранных натиных библиотек приложения. Поскольку приложение нативное, то оно работает на основании библиотеки .so. res - место хранения ресурсов приложения (картинки, иконки и тд) META-INF - хранение подписи приложения, контрольные суммы файлов ресурсов (картинок, звуков и т.д.) AndroidManifest.xml - манифест приложения (расширенный аналог VersionInfo в Windows) classes.dex - файл с java реализацией дополнительного функционала FireMonkey. resources.arsc - таблица ресурсов. В этом файле собраны xml-описания всех ресурсов. Самый значительный вклад в размер пакета вносят: libPhotoEditorDemo.so (20 060 КБ) - непосредственно сам бинарник приложения classes.dex (1 948 КБ) - частичная реализация FireMonkey на java. Размер самого приложения большой потому, что включает в себя полностью все Delphi библиотеки, которые используется FireMonkey. А это: RTL Хедеры для доступа к Android API Нативные стили для Android (три стиля - 1х, 1.5x, 2х, 3х скалирования экрана). Каждый стиль содержит исходную png картинку нативного стиля. Фильтры и эффекты FireMonkey Вся остальная реализация FireMonkey. Довольно большой набор того, что нужно включить в пакет и тяжело выбросить. Если говорить о приложении написанном в Eclipse, то приложение включает в себя только часть пользовательского кода. И размер мал за счет того, что весь Android API находится перманентно на самом устройстве (не в пакете). Если бы используемая часть библиотек FireMonkey находилась на каждом устройстве, то размер приложения сократился бы раза в четыре. Вывод Размер установочного пакета приложения, написанного на FireMonkey не большой для нативных приложений порядка 6 760 КБ для реализации простого фоторедактора (Хотя для кого-то это может быть много). В установленном виде приложение занимает от 20 000 КБ. Основная причина полная интеграция используемых библиотек в пакет приложения. Вероятность уменьшить этот размер маловероятна. Однако увеличение функционала приложения не так сказывается на дальнейший рост приложения. Можно попробовать сделать усеченные библиотеки, сократить функциональность. Но это не даст ощутимого уменьшения результирующего размера приложения. На сколько важен размер приложения для конкретной работы приложения каждый заказчик решает сам. P.S. Цель этого ответа дать подробный ответ о причинах такого размера, а не попытка вызвать обсуждение на тему сравнения сред разработки. Каждый framework обладает своими достоинствами и недостатками. И выбор средства разработки диктуется совокупностью требования заказчика.