Embarcadero (Borland)
Компания
33,21
рейтинг
1 ноября 2013 в 15:16

Разработка → Разработка кроссплатформенных мобильных приложений в Delphi #2

Delphi for Android

Часть #1

В предыдущей части цикла мы сделали обзор основных возможностей новой RAD Studio XE5. Сегодня же перейдем к практике. Прежде всего, давайте определимся с задачей.

Постановка задачи


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

Пересчет количества требуемых продуктов.

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

Таймер.

Если вы новичок в кулинарии, то, вам следует использовать рецепты, в которых четко указано время той или иной операции. И таймер на планшете, телефоне или нетбуке вполне может стать удобной заменой кухонному таймеру.
Часто бывает, что несколько операций выполняются параллельно. Каждая операция может иметь свой «таймер».
При этом нас интересует, как «настольная», так и мобильная реализация приложения. Мобильное приложение будет использоваться в качестве пособия для визуализации рецепта и сопровождения процесса подготовки. Настольная версия может быть использована в более расширенном функционале для, например, формирования новых рецептов.


Здесь следует оговориться, что в принципе, поваренные книги, как и книги по программированию, могут быть рассчитаны на разный уровень подготовленности читателей. В нашем случае речь идет о «рецептах для чайников», т. е. тех, в которых указывается точное количество продуктов и точное время того или иного действия.

Данное приложение мы реализуем для Windows и для Android. Затем на основе единой базы исходных кодов мы сможем выполнить портирование приложения на MacOS и iOS.

Выбор средств разработки


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

Для чистоты эксперимента в качестве СУБД используем SQLite. Эта СУБД обладает рядом преимуществ, среди которых скорость работы, простота использования, экономичность в отношении ресурсов. Она идеально подходит для решения несложных задач, а кроме того, Android имеет встроенную поддержку SQLite.

В дальнейшем мы рассмотрим, каким образом можно перевести приложение на использования СУБД InterBase и покажем все преимущества «родного» решения от Embarcadero.

Вместе с приложением мы будем распространять уже готовую СУБД, созданную отдельно. Такой подход обусловлен спецификой задачи.

Конечно же, нам понадобиться Delphi XE5. Для создания Windows приложения в принципе мы могли бы ограничиться Professional редакциях. Но для т.н. мобильной разработки нам понадобиться как минимум Enterprise редакция продукта. В качестве альтернативы можно воспользоваться пакетом Mobile Add-On Pack for Delphi XE5 Professional.

Для работы с SQLite в Windows нам понадобится скачать с официального сайта библиотеку sqlite-dll-win32-x86-3080100.zip. Проще всего поместить данную библиотеку в одну из системных папок (например, Windows/SYSTEM32).
В настоящий момент существует довольно большое количество бесплатных средств администрирования баз данных SQLite. Вы вполне можете воспользоваться одним из них.

Доступ к базе данных из приложения мы будем осуществлять с помощью библиотеки FireDAC.

FireDAC — это универсальная библиотека доступа к данным, предназначенная для разработки приложений, подключаемых к различным базам данных. С помощью FireDAC можно разрабатывать, как VCL, так и FireMonkey приложения. Библиотека поддерживает следующие СУБД: InterBase, SQLite, MySQL, SQL Server, Oracle, PostgreSQL, DB2, SQL Anywhere, Advantage DB, Firebird, Access, Informix. Однако, на данном этапе, в мобильных приложениях «напрямую» (без использования технологии DataSnap) с помощью FireDAC можно подключиться только к SQLite и InterBase.

Создание базы данных


Процесс разработки мы начнем с создания структуры базы данных. Логическая модель ее приведена на диаграмме.
Логическая модель БД, созданная с помощью Embarcadero ER/Studio

Данная диаграмма получена с помощью еще одного инструмента от компании Embarcadero Technologies — ER/Studio. Developer редакция этого продукта доступна пользователям RAD Studio Architect. В рамках настоящей публикации мы не станем детально останавливаться на описании ER/Studio. Этот мощный инструмент вполне заслуживает того, что бы посвятить ему отдельный материал.


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

В таблице tblFoodstuff мы будем хранить список всех возможных продуктов. В таблице tblUnit – список единиц измерения (грамм, ложка, стакан и т.д.). Таблица tblRecipe содержит список рецептов. В таблицах tblIngredientes и tblAction содержатся перечень ингредиентов (с указанием количества в поле qty) и действий (с указанием времени и описаниями), соответственно.

Для создания SQLite базы вы можете просто воспользоваться приведенным ниже скриптом.

CREATE TABLE [tblAction] (
[Id] INTEGER  NOT NULL PRIMARY KEY AUTOINCREMENT,
[IdRc] INTEGER  NOT NULL,
[Sec] INTEGER  NULL,
[DescriptionShort] VARCHAR(128)  NOT NULL,
[DescriptionExtendent] TEXT  NOT NULL
);

CREATE TABLE [tblFoodstuff] (
[Id] INTEGER  PRIMARY KEY AUTOINCREMENT NULL,
[Abbr] VARCHAR(10)  NULL,
[Title] VARCHAR(50)  NULL
);

CREATE TABLE [tblIngredientes] (
[Id] INTEGER  NOT NULL PRIMARY KEY AUTOINCREMENT,
[IdCB] INTEGER  NOT NULL,
[IdFS] INTEGER  NOT NULL,
[IdUnit] INTEGER  NOT NULL,
[qty] INTEGER  NULL
);

CREATE TABLE [tblRecipe] (
[Id] INTEGER  NOT NULL PRIMARY KEY AUTOINCREMENT,
[Title] VARCHAR(150)  NOT NULL
);

CREATE TABLE [tblUnit] (
[Id] INTEGER  NOT NULL PRIMARY KEY AUTOINCREMENT,
[UnitName] VARCHAR(25)  NOT NULL,
[Abbr] VARCHAR(7)  NOT NULL
);

CREATE INDEX [IDX_TBLACTION_Recipe] ON [tblAction](
[IdRc]  ASC
);

CREATE INDEX [IDX_TBLINGREDIENTES_] ON [tblIngredientes](
[IdCB]  ASC
);

CREATE INDEX [idxFoodStuff] ON [tblIngredientes](
[IdFS]  ASC
);

CREATE INDEX [idxRecipe] ON [tblIngredientes](
[IdCB]  ASC
);

CREATE INDEX [idxUnit] ON [tblIngredientes](
[IdUnit]  ASC
);



Создание Windows приложения


Непосредственно процесс разработки приложения мы организуем следующим образом. Начнем с создания базовой версии приложения для Windows, затем портируем его на платформу Android. Далее будем расширять функционал обоих приложений параллельно. MacOS и iOS версии приложения станут заключительным этапом. К их созданию мы приступим после того, как будем иметь готовую Windows и Android версию.

IDE Delphi предоставляет несколько шаблонов новых приложений. В данном случае нас интересует FireMonkey Desktop Application.

Создание нового FM приложения в Delphi

После выбора соответствующего пункта меню на экран будет выведен дополнительный диалог, в котором будет предложено выбрать тип нового FireMonkey приложения – HD (High Definition) или 3D.

image

Переименуем главную форму приложения (в инспекторе объектов меняем свойство Name) и сохраним вновь созданный проект. Добавим в проект новый Data Module (меню File| Other ветка Delphi Files), переименуем и сохраним его.

Создание нового модуля данных в Delphi

Таким образом, мы создали новый проект и подготовились непосредственно к разработке.

Настройка FireDAC соединения

habrahabr.ru/topic/edit/200490/#
Первое, что нам необходимо сделать – настроить подключение к базе данных. В FireMonkey данная процедура существенно не отличается от VCL.
Поместим в DataModule компоненты TFDConnection, TFDGUIxWaitCursor и TFDPhysSQLiteDriverLink. В Object Inspector изменим значение свойства LoginPrompt компонента TFDConnection:

LoginPrompt = False

Двойной щелчок по компоненту на форме вызовет диалог настройки подключения.

FireDAC. Настройка соединения

В качестве Driver ID в нашем случае следует указать SQLite, а также в качестве значения параметра Database указать путь к файлу базы данных. Проверить правильность настроек можно с помощью кнопки Test.

Сразу же создадим функцию, отвечающую за подключение к БД в Run Time.

function TDM.ConnectToDB: Boolean;
begin
try
  FDConnection1.Connected := True;
except
end;
 Result:= FDConnection1.Connected;
end;


Для того, что бы данную функцию можно было вызвать из главного модуля, вынесем ее заголовок в секцию public.

Главная форма приложения


На главную форму приложения последовательно поместим компоненты TGroupBox, TTabControl и TSplitter. Настроим для каждого из них свойство Align (alLeft, alLeft и alClient, соответственно). На левую панель помещаем два компонента – TListBox и TBindNavigator. Размещаем их как показано на рисунке. Двойным щелчком мыши вызовем дизайнер пунктов компонента TTabControl, и создадим два пункта.
Главная форма приложения
В левом части нашего приложения будет отображаться список рецептов. На вкладках в правой части – список ингредиентов блюда (с указанием количества) и, непосредственно, сам рецепт, состоящий из определенного списка действий.

Подключение данных


Как мы уже говорили, в FireMonkey нет специальных компонентов отображения данных. Вместо этого используется механизм связывания LiveBinding. Давайте посмотрим, как он работает. Подключим список рецептов к компоненту TListBox на главной форме. Прежде всего, нужно создать набор данных для работы со списком рецептов. В модуле данных используем компонент TFDTable. Настроим его свойства следующим образом:
Настройка набора данных

В код нашей функции ConnectToDB добавим вызов метода открытия набора данных.

FDTRecipe.Open;


Для того, что бы установить соединение с базой в режиме Run Time следует добавить вызов функции ConnectToDB. Можно привязать его к событию OnCreate модуля данных.

procedure TDM.DataModuleCreate(Sender: TObject);
begin
DM.ConnectToDB;
end;


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

Организуем вывод данных из таблицы TRecipe в список на главной форме. Для этого, прежде всего, добавим модуль данных в секцию Uses модуля главной формы программы.
interface

uses
  uDM,
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,


В редакторе формы вызовем контекстное меню и выберем пункт Bind Visually. В нижней части экрана откроется LiveBinding Designer. В нем в виде элементов диаграммы представлены объекты и их основные свойства. Простым перетаскиванием свяжем свойства трех объектов так, как это показано на рисунке.

Visual Binding

Собственно, это все, что нужно для отображения данных из таблицы рецептов (т.е. списка названий рецептов). Если мы сейчас запустим программу, она покажет список, но он будет пустым, и нам следует позаботиться о том, как добавлять рецепты.

Создадим новую FireMonkey HD форму. Настроим ее свойства следующим образом:

Name = fAddRecipe
BorderStyle = bsToolWindow
Position = poMainFormCenter


Подключим модуль данных и поместим на форме компонент TEdit и две кнопки. В LiveBinding Designer свяжем свойство Text компонента TEdit с полем Title набора данных.

Форма редактирования рецепта

Сохраним новую форум и удалим ее из списка автоматически создаваемых форм (меню Project|Options вкладка Forms).

Для главной формы приложения создадим метод:

procedure TfMain.RecipeAfterInsert(DataSet: TDataSet);
var
  fAddRecipe: TfAddRecipe;
begin
    try
    fAddRecipe:= TfAddRecipe.Create(Application);
    fAddRecipe.ShowModal;
    if fAddRecipe.ModalResult = mrOk then
    begin
     if DataSet.State in [dsInsert, dsEdit] then
      DataSet.Post;
    end
    else
    begin
     if DataSet.State in [dsInsert, dsEdit] then
      DataSet.Cancel;
    end;

  finally
    FreeAndNil(fAddRecipe);
  end;
end;


При запуске программы определим событие AfterInsert для набора данных с рецептами.

procedure TfMain.FormShow(Sender: TObject);
begin
DM.FDTRecipe.AfterInsert:= RecipeAfterInsert;
end;



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

В этой части цикла мы создали простейшее FireMonkey приложение для Windows. Научились устанавливать соединение с базой данных при помощи пакета FireDAC и рассмотрели простейший пример использования LiveBinding.

В следующей, возможно самой интересной, части цикла мы создадим первое Android приложение.

Оставайтесь с нами…

Часть #3
Автор: @FireMonkey
Embarcadero (Borland)
рейтинг 33,21
Компания прекратила активность на сайте

Комментарии (65)

  • +8
    Эх, Delphi, в другое время, в другом месте как бы мы с тобой могли повеселиться… А сейчас — прости, у меня есть Java.
  • +19
    Технология в принципе не плоха. Я правда давно уже мигрировал с Delphi/Builder на Qt и другие фреймворки. Цены на Delphi уж очень кусаются.
    • +13
      я тоже считаю, что это замечательная технология.Но популяризировать её с такими ценами невозможно. Сделали бы например бесплатно для разработки бесплатных приложений с обязательным сплэшом. Вобщем популяризировать — привлекать разработчиков и всячески способствовать этому. Я вот «на попробовать» на один проект как инди-разработчик не хочу платить $4к.
      • +3
        Так о чем и речь. Мне маркетинговая политика не понятна. Можно, наверное, сделать версию для обучения бесплатной как у той же студии. И продавать модульно. Скажем версию для мобильной разработки отдельно и не по космическим ценам. Ну вот не верю я, что компания разориться, если такой продукт будет стоить, скажем 300 долларов для платных приложений. Зато народ подтянется. Что бы изменить ситуацию, все таки надо, имхо, пойти немного на встречу разработчикам. Ведь лишних нескольких килобаксов нет у людей, которые публикуют бесплатные приложения, приносящие им от рекламы по 100 долларов в год.Сменится поколение и тяжело будет привлечь разработчиков обратно.
      • +5
        Но популяризировать её с такими ценами невозможно.

        Кто-то в Эмбаркадере вообще думает о популяризации? Я ещё не видел ни одного положительного отзыва о FireMonkey или новой кросс-платформенности. Все поголовно ноют про невменяемые тормоза в любых приложениях, выходящих за рамки «Hello World», про баги, про недоработки (вон, снизу уже комментарии подоспели). На официальном форуме нескончаемый срач. Популяризовать в буквальном смысле нечего, потому что новые фичи использовать невозможно.

        Сейчас Эмбаркадера банально высасывает деньги из тех, кто уже «подсел» на Дельфи и никак не смог перебраться на что-то другое. Очевидно, что подсевшие — это в основном огромные неповоротливые компании, которые эти килобаксы могут потянуть без особых проблем. Вот их и доют. Это рационально.

        Есть, конечно, некоторая надежда, что FM и кросс-платформенность доведут до нормального состояния, и тогда подумают о привлечении новых разработчиков, но я бы не задерживал дыхание в предвкушении.
        • +1
          Сейчас Эмбаркадера банально высасывает деньги из тех, кто уже «подсел» на Дельфи и никак не смог перебраться на что-то другое. Очевидно, что подсевшие — это в основном огромные неповоротливые компании, которые эти килобаксы могут потянуть без особых проблем.

          Деньги не вопрос. Вот только перевести огромный проект 12-летней давности с D5 или D7 на XE5 та ещё проблема. Можно купить XE только для того, чтобы легализовать старые версии IDE.

          А новые проекты на XE начинать никто не будет.
          • 0
            Если переводить, оставаясь на VCL, то не особая проблема. Хотя времени и съест порядком.
          • +1
            А новые проекты на XE начинать никто не будет.

            Вы ошибаетесь, начинаем и мы и многие вокруг.
  • +16
    Спасибо за конкретный пример разработки, а не маркетинговый буллшит.
    Возможно вы сами столкнетесь с багами FireMonkey, и наконец начнете исправлять их.
  • +4
    Простите за занудство, но SQLite игнорирует размер строковых полей. Потому что в любое поле можно поместить строку неограниченной длины ( «в пределах разумного» © ).
  • +8
    С нетерпением ждем следующих статей. Delphi люблю и глубоко уважаю с детства. Возможность разработки под мобильные платформы для меня — один из ключевых факторов.

    К сожалению, с такими ценами плохо представляю, как будет выглядеть отвоевывание утраченного рынка. $1000+ — это даже не смешно. Как я ни люблю Delphi, но можно гарантировать, что любые проекты, которые я буду начинать в ближайшем будущем, будут сделаны не на нем. А то, что начинают фрилансеры, в дальнейшем часто уходит на корпоративный уровень, и развивается и поддерживается без смены системы разработки.

    Искренне жаль.
    • –7
      Цена в 1000у.е. считаю разумной. Т.к. у программиста зарплата два раза больше. Имею виду компаний. Фрилансеры… когда у низ было лицензионное ПО)?
      • +4
        PHPStorm/IDEA/PyCharm/ReSharper у многих лицензионный в виду более адекватных цен.

        Ну и мне таки кажется, что в основном выбирают не пиратское ПО, а бесплатные варианты: Qt, Java, Visual Studio Express (Express тоже можно для коммерческого, ну и там еще есть всякие бизспарки, по которому можно на год получить Pro студию).

        Для веб и мобильной разработки вообще много бесплатных сред, а вышеупомянутые продукты JetBrains, если уж совсем не хочется платить, то можно использовать вроде бы вполне легально EAP версии.
      • +3
        Считаете разумной? Кто я, что бы спорить )

        Вопрос разумности цены в условиях рыночной экономики очень неоднозначен. Когда вокруг полно подобных инструментов по более демократичным ценам или вообще бесплатно, я, пожалуй, продолжу считать, что цена для меня неприемлема.
  • +7
    FireMonkey — ни разу не юзабельна. Я откровенно разочарован текущей маркетинговой политикой от Embarcadero. FireMonkey в текущем виде годится только для создания небольших семплов и туториалов. Посмотреть 3 записи в БД — да. Когда же форма обрастает компонентами — оно начинает люто бешено тормозить.
    Я как то поставил себе XE3, и решил попробовать начать проект на FireMonkey. Думаю, если все пойдет — то по истечении 30 дней куплю таки себе в личное пользование XE3. Читал кучу туториалов, лазил по справке, в общем делал все как надо. Идеология работы с компонентами понравилась, но смотрю — что то как-то тормозит, хотя тормозить еще толком нечему. Чуть-чуть усложнил проект, на форме появились новые елементы, списки и т.п. Тормозит. Но почему? Полез разбираться.
    А тормозит потому, что написано влоб for i := 0 to Childs.Count — 1 do… и гоняет код без каких либо оптимизаций по всем чайлдам/контролам. Лучшие оптимизации какие я там видел — это досрочный выход из циклов, и объединение 20 InvalidRect-ов в один через union :)
    Ребят, в самом деле, вы что? Ту текущую реализацию, которая у вас вышла — её надо полностью выкинуть, потому что всего 100 записей в списке — и все, оно на скроллинге тормозит дико.

    Я искренне желаю, чтобы маркетологи заставили программистов реализовать IDE на FireMonkey. Может тогда я думаю выйдет наконец то FireMonkey 3.0 с нормальной реализацией. А то уже 5 версий делфи с FM, а IDE никак не портируют на другие платформы.

    Я бы мог еще тут рассказать про то как сама IDE падает при работе с FM, про замечательный новый RTTI, который полон багов и сюрпризов, про то как поломали и без того неудобный редактор библиотек типов. Но я считаю все это мелочью по сравнению с паршивой реализацией FM библиотеки.

    p.s. Я очень люблю делфи как язык. С точки зрения удобства использования — мне нравятся те изменения, которые происходят в языке и в библиотеках. Я очень хотел бы пользоваться всем этим, но я очень не доволен тем, что этим практически невозможно пользоваться. Из всего нового, что появилось в языке с приходом Embarcadero, я использую (и мне нравится использовать) — юникодные строки и дженерики. Все. Я бы очень хотел опробовать новые платформы, но я не могу. На текущий момент новые платформы проще осваивать на Lazarus-е, чем на Delphi.
    • –1
      Подозреваю, что их ресурсов еле еле хватает, чтобы хоть что то успевать релизить, какие там оптимизации?
      И потом много ли энтерпрайз кодеров умеют сложность алгоритма оценить и понизить. ООП вообще ее часто скрывает. А она берет и вылезает где нибудь между красивыми паттернами.
    • +5
      Я искренне желаю, чтобы маркетологи заставили программистов реализовать IDE на FireMonkey. Может тогда я думаю выйдет наконец то FireMonkey 3.0 с нормальной реализацией. А то уже 5 версий делфи с FM, а IDE никак не портируют на другие платформы.

      Портировать малой кровью у Embacadero не выйдет.
      Т.к. к сожалению Delphi IDE, уже давно, не только на Delphi написана:
      Скрин

      Refactor и новомодный LiveBindings Designer явно сделаны на .Net, по крайней мере их GUI.
      Я бы на месте Embacadero постыдился и переписал их на Delphi.
      • +1
        Ну если так, то о чем вообще можно говорить. Разработчики Delphi уходят от Delphi… Короче вся надежда на лазарус.
      • +1
        Refactor и новомодный LiveBindings Designer явно сделаны на .Net, по крайней мере их GUI.

        Обоснуйте пожалуйста. Сырцы доступны, где Вы там. net нашли?
        • +1
          Вы имя класса окна на скриншоте видите?
          • –2
            Это хвосты от самой IDE, которые еще Borland оставил. Оно есть во всяких инспекторах, да и в редакторах моделей тоже.
            Но не думаю, что это касается непосредственно реализации LiveBindings дизайнера. Скорее всего, просто где-то использованы старые классы.
            В принципе я согласен. .Net это полное убожество и от него нужно избавляться.
        • +2
          Где это исходники самой IDE доступны?
          • 0
            а resharper уже отменили? Если это сделано на. net в чем проблема получить исходники?
            • 0
              Вы наверно хотели сказать reflector.
              Нет, не отменили. В папке bin куча .NET'овских dll.
              Рефакторинг, например, как и писали (формы, по крайней мере)
              image
              • 0
                Да, вы правы reflector в данном случае уместнее (привык к решарперу в студии, автоматом написал). В принципе была ведь версия delphi ориентированная на net. Возможно еще в те времена что то сваяли на net. Хотя, хоть убейте, не приложу ума, зачем они могли это сделать, чего им не хватало своего. Интересно было бы исследовать этот момент.
                • 0
                  Ну, исследовали новую технологию, сделали фичу. Не выкидывать же? А переписывать некогда, упущенная экспансия зовёт.
    • 0
      Из всего нового, что появилось в языке с приходом Embarcadero, я использую (и мне нравится использовать) — юникодные строки и дженерики.

      Юникодные строки чем-то принципиально отличаются от тех, которые в Delphi 7?
      • +1
        Юникодность протянута по всему VCL и работает из коробки, а не дюти хаками как в TNT контролах. Счетчик ссылок не всегда = 1.
        Алсо Indy стала на порядок лучше работать с кодировками.
        • +2
          Правильно я понял про счётчик ссылок, что старые дельфи для WideString каждый раз при присваивании делают копию?
          • 0
            Именно так.
  • +11
    Выглядит так, будто бы людям из 96 года дали в руки айпад и попросили их написать приложение для айпада.
    Отдельно умиляет предложение положить библиотеку в system32
  • –1
    Непонятно, для чего это делать? Специалистов на Дельфи в мире почти не осталось. Те, кто остались, менее всего заинтересованы в каких-то планшетах: они сидят по НИИ в лабораториях и ждут пенсии.

    Для чего это все?
    • +3
      Толсто. :)

      Хотя ситуация с Дельфи плачевная, сложно спорить с тем, что идея с кросс-платформенностью и современной UI библиотекой — всё-таки хороша. Дело за малым — сделать так, чтобы оно всё работало. :) Думаю, если нормально реализовать новые фичи и продавать среду по адекватным ценам, то Дельфи может вернуться с того света.
    • +2
      Считаете, что меня в мире не осталось? Или я сижу в НИИ и жду пенсии? Ни разу не угадали. Для чего вообще это написали в ветке, где тусуются делфисты? Карма мешает? )
      • +3
        Я сам писал и пишу на дельфи с 1996 года. Это не мешает мне объективно смотреть на мир и констатировать факт, что при всех плюсах технологии она в настоящий момент не живая. По разным причинам, но поезд этот ушел. Специалистов нет, подготовки нет, ничего нет. Технология стала маргинальной.
        • +4
          Это не мешает мне объективно смотреть на мир и констатировать факт

          Вы уж извините, но Ваше высказывание никак не может претендовать ни на объективность, ни на констатацию факта:
          Специалистов на Дельфи в мире почти не осталось. Те, кто остались, менее всего заинтересованы в каких-то планшетах: они сидят по НИИ в лабораториях и ждут пенсии.

          Бред ведь. Даже комментировать не буду. А это:
          Непонятно, для чего это делать?

          Вы правда считаете, что на C# или PHP писали до их появления? Но ничего, с нуля начинались, а сейчас очень популярны.

          Ну да ладно, кто бы и что бы не начинал делать, он обязательно делает это под стройных хор «объективных» пессимистов, которые заранее знают, что у него ничего не получится.
          • 0
            Есть совершенно объективные «таблицы» и графики, показывающие уровень популярности тех или иных технологий. В РФ и пост-совке — да, Дельфи популярен в сегменте десктопных приложений для Win. Но а если посмотреть в мире?
            • +2
              Да, Delphi сильно сдал позиции за последние годы. И что? Как это соотносится с Вашим первым постом в этой ветке? И какой Вы хотели сделать из этого вывод?
          • +2
            Кто-то должен был это сказать. Паскаль — это шаг назад, и туда трудно заставить кого-то идти. Его можно бесконечно допиливать и добавлять фич, только главный вопрос — зачем? Это можно оспорить технологически, но с точки зрения маркетинга (среди программистов) паскаль имеет высокий антирейтинг в плане перспективности, в том числе и в связи с великим кидаловым со стороны Борланда. Для меня сейчас возвращение в Дельфи — это возвращение в прошлое, куда я не хочу. Да, я субъективный пессимист…
          • 0
            Вы правда считаете, что на C# или PHP писали до их появления? Но ничего, с нуля начинались, а сейчас очень популярны.

            Разница в том, что все новые языки бесплатны и опенсорсны. Только этим можно смягчить риски непопулярности. (Попробую, не понравится, не сильно теряю. Если где-то будет полный затык или баг, который проявляется только на моём проекте, допилю под себя среду/компилятор).
            • +1
              Шарп как бы не очень опен-сорсен. :) (Впрочем, компилятор шарпа и вбасика переписывают на дотнет, так что, как минимум, скоро можно будет декомпилировать большую часть кода компилятора.) Вот бесплатность языка и среды — да, важный критерий, потому что без него нет опен-сорса, без которого язык загнётся.
              • 0
                Шарп особый случай, т.к. это язык под платформу от вендора платформы, как Objective-C от эппл.
                Сторонним фирмам с платным продуктом эти рынки сильно не покусать.
                Вот когда появился открытый компилятор, c# стал уже рассматриваться серьёзно.
  • +4
    Эх, Дельфи, Дельфи, но поезд уже ушел, и давно…
  • +3
    Сейчас увидите… после выхода RAD XE5 у старого доброго Дельфи действительно новая жизнь! Ведь многие студенты ничего не смыслят в Яве, но у очень многих в универах учили дельфи. И сейчас желающих стрепать свое «мега-крутое» приложение и выложить на андроид-маркет явно повысится, а значит и популярность Делфи взлетит!
    • +2
      К сожалению, мега-крутые поделки на Дельфи XE5 под андроид действительно пока могут таковыми называться лишь в кавычках…
    • 0
      Если бы не цена в тыщу евро…
      • 0
        Давайте смотреть правде в глаза: 99.99% его просто скачают с интернета… Я помню когда мы учились в универе, у них там на всех компах Дельфи 5-й стоял, а ключ с кейгена…
        • +3
          Вы рассуждаете категориями лаборатории при советском НИИ пошива 1990 года.
          Сейчас к этому в ИТ индустрии несколько иное отношение.
        • +3
          Давайте смотреть правде в глаза: скачают пиратку несколько маргиналов, а большинство воспользуется бесплатными нативными средствами разработки.
          • +3
            В этом топике такой вывод запрещен :)
            • +3
              Да, это я понял по минусам в карму :)
              • +1
                Это Вы в такие минуса после этого коммента ушли? Жесть. Плюсанул, чем смог.
                • 0
                  Да нет, что вы!
                  Я во всех топиках про Делфи жалуюсь на высокую цену лицензии :)
    • 0
      Но это «мега-приложение» получится также и мегатяжёлое (тот же «Hello World» занимает 5 Мб), и к тому же не совместимое с Android x86 (потому что таким его сделали в Embarcadero и на это уже многие плюются — нативная виртуальная машина с эмуляцией ARM жутко тормозит и зачастую не запускает приложения, а под шустрыми виртуалками типа Genymotion приложение не выполняется принципиально).
  • +2
    После Visual FroPro 9 уже несколько лет использую и Delphi XE2 +VCL и C# +.Net одновременно на разных проектах. Причем проекты большие и серьёзные что позволяет сравнить скорость достижения конечного результата и удобство. У обоих технологий есть свои плюсы и минусы но отдавать преимущество какой то одной я бы не стал. С точки зрения скорости разработки delphi даже немного впереди. Могу на вскидку назвать минимум 6 контор только в моём городе которые работают в Delphi по серьёзному и слазить с него не собираются (и это только те кого я знаю). А с приходом мультиплатформенности уже точно останутся на нём. FireMonkey рано или поздно допилят и сделают быстрым и стабильным (как в своё время сделали это с VCL). Насколько я знаю основная задача на данном этапе была показать намерения компании. А для меня, как разработчика важно видеть куда продукт двигается. И я вижу что ребята настроены серьёзно и идут именно в том направлении куда мне хочется. Хотя повторюсь, на данном этапе знания обеих продуктов мне все равно на чем писать, справлюсь на обоих но мне до сих пор не была нужна мультиплатформенность. Если завтра клиент захочет что то под iOS или Android мне есть на чем это реализовать. Ну а по поводу стоимости, для России возможно и дороговато а по Европейским меркам вполне приемлемо даже в частном порядке купить лицензию, а для фирмы даже обсуждать смешно. Опять же большая часть стоимости списывается с прибыли и соответственно с налогов. Эти деньги отдать или государству или разработчикам которые что то делают полезное для твоего будущего. Потому, думаю, реализовав мультиплатформенность, embarcadero окончательно поставило точку в споре о будущем delphi. Жить будет и вполне успешно.
    • +2
      FireMonkey рано или поздно допилят и сделают быстрым и стабильным (как в своё время сделали это с VCL).

      Основу VCL составляют тонкие обёртки над уже имеющимися встроенными в винду контролами, то есть по определению очень быстрыми, качественными и проверенными временем. FM — реализация всего с нуля, причём сложность самих контролов на порядок выше, и обещается невменяемая кросс-платформенность. Масштаб очень разный.

      Потому, думаю, реализовав мультиплатформенность, embarcadero окончательно поставило точку в споре о будущем delphi. Жить будет и вполне успешно.

      Точка будет, когда всё это будет использоваться… VCL, может, и достойный конкурент WinForms, но прогресс UI в лице WPF/Qt/JavaFX шагнул вперёд. FM — это попытка догнать убегающий поезд, и именно его успех определит будущее дельфи, ИМХО.
      • 0
        т.е. Вы считаете что если сложность увеличилась то не допилят?
        Приложения на WPF в отличии от FM не несут мультиплатформенность, да и по спорости WPF далёк от идеала, притом, насколько мне известно, какого то повального массового применения WPF не получил, народ попробовал и вернулся на WinForms и ждёт когда допилят (по крайней мере говорю о конторах с которыми сталкиваюсь по работе). Не буду говорить о Qt и JavaFX т.к. ситуацией не владею. Но в случае с WPF говорить о том что поезд ушел я бы не рискнул, думаю вся борьба ещё впереди. Возможно у Вас какая то другая статистика по WPF. Если да то поделитесь, возможно я неправ.
        • 0
          Delphi vs C# это скорее Native vs Managed и Двузвенка vs Трёхзвенка.
          Так что подтягивать там много чего придётся помимо FM.
        • 0
          Допилить-то могут, но когда? Судя по всему, у Эмбаркадеры сейчас приоритет накрутить побольше фич, а не сделать эти фичи работоспособными. Например, все ноют про производительность FM, но в этом направлении ничего не делается; вместо этого на основе этого же тормозного FM прикручивается кросс-платформенность на тормозных девайсах. Какой к чертям iOS, если приложение космически тормозит даже на современном писюке? Сужу я исключительно по обсуждениям на форумах, баг-трекерах и прочих местах, но впечатление складывается именно такое.

          Что в WPF допиливать? Там всё есть. Дизайнер только кошмарный. WPF медленнее, чем WinForms, но скорости объективно хватает, если не заниматься странными вещами (вроде графиков с миллионом анимированных точек или тысячами элементов в списке без виртуализации).

          Если кто-то не перешёл на WPF — это их проблемы. :) Кривая обучения крутая, но оно того стоит. Хотя если делать тонкий клиент к БД с сотнями гридов на тысячи столбцов, то, пожалуй, разницы особо нет.
          • 0
            По производительности — делается, хоть и маловато. Насколько я понял выступления на последнем мировом туре, они пихают в FM кучу нативного более оптимизированного кода, специализированного для разных платформ.
          • 0
            WPF медленнее, чем WinForms, но скорости объективно хватает, если не заниматься странными вещами (вроде графиков с миллионом анимированных точек или тысячами элементов в списке без виртуализации).

            Мне вот, напротив показалось, что скорость WPF выше, чем winforms. Просто в свое время заморочился переходом на WPF и WPF оправдал надежды и по скорости и по красивости.
      • 0
        А вот кстати, кто-нибудь исследовал способность Дельфи работать с сторонней библиотекой контролов, не имеющей отношения ни к FireMonkey, ни к VCL? Проекты типа KOL, вроде бы, на уровне дизайнера не очень поддерживались?..

        Может, теперь, с диверсификацией поддержки библиотек в IDE, сообщество cможет что-нибудь ещё более альтернативное предложить? С повышенной нативностью, в отличие от FM, где она радикально понижена…
        • +1
          Одна из основных фишек Дельфи — это подход «накидал кнопок — и готово». Соответственно, без дизайнера и прочих примочек никто не будет воспринимать альтернативу всерьёз.

          Про героические подвиги сообщества мечтать не приходится, потому что дельфи при текущих ценах несовместима с серьёзным опен-сорсом.
          • 0
            Ну, у сообщества ещё fpc есть с лазарусом, что-то может вырасти и оттуда…
            Хотя могло бы — выросло бы. Там дизайнер изначально под свои компоненты заточить можно, ибо он весь в исходниках…
  • 0
    Начал читать статью — прям вдохновился дать вторую жизнь своему бесплатному проекту с помощью XE5.
    Почитал комменты про тормоза, разочаровался =(

    В одной из прошлых моих работ мы довольно долго, и с не слабым трудом переводили один старый проект с D7 на XE2. Перевели. Работало. Все относительно не плохо… Но! В итоге все ж таки проект в последствии был потихоньку переписан на C#, и разрабы просто в восторге от тех результатов производительности, которых им удалось достичь с помощью технологий .net. Большие объемы данных просто летают, никаких тормозов ни при больших расчетах, ни при импортах\экспортах.

    С одной стороны я как бывший дельфист радуюсь развитию продукта. И хочу верить в то что он станет доступным, популярным и будет таки на уровне того же C# + .Net. Но с другой стороны, лучше я выучу ещё один новый язык, разберусь с не знакомым фреймворком и не буду платить сумму равную половине стоимости моего автомобиля, ради того что бы писать ради забавы, бесплатное ПО.

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

Самое читаемое Разработка