Pull to refresh

Comments 74

Собственно, интересны ваши впечатления от запуска такого приложения на устройстве.
А чем такое приложение должно отличаться от любого другого?
Требованиями к версии ОС и устройству?
А вот вы не правы. Приложение, написанное в XE5, прекрасно работает на Galaxy Tab первой модели под Android 2.3 и 2.2 (старее я просто уже не нашёл).
В чем я не прав? Я не утверждал, что оно там не работает. Наоборот, мне интересно узнать, где оно работает, а где нет.
Вот тут (http://docwiki.embarcadero.com/RADStudio/XE5/en/FireMonkey_Platform_Prerequisites) написано:
RAD Studio supports the development of applications for Android devices running on an ARMv7 processor with NEON support.
Спасибо. Вот эта статистика снимает все вопросы:

Проверено устройств: 118
Не установилось на: 10
Зависло (Application not responding) на: 3
Успешно запустилось на: 105
Процент успеха: 89%

Но там проверяли Hello World, на более сложных приложениях проблем будет, очевидно, больше.
Уверен, что реально работает практически на всём. Поясню почему.
Использовались, судя по всему, не тесты, а кривые «антитесты». Почитал про свой аппарат:

Samsung Galaxy Tab2 10 Bug reported about Location Demo and Audio Recording

Обиделся. Это же не клон какой-то, это наоборот то, с чего все клоны и делаются. Я его специально для разработки брал, чтобы был самый что ни есть стандартный.

Посмотрел Location Demo. Запустил. Действительно, показывает, что я в Канзасе. Видимо, и Тотошка с Железным Дровосеком где-то рядом. А долгота-широта-то сверху на лейблах — правильные!

Смотрим текст. В Гугл-мап строку передаются координаты, полученные через ToString. В России, я так понимаю, будут они с десятичными запятыми. Ищем 1 мин и находим, как надо эту строку формировать:

support.google.com/maps/answer/18539?hl=ru

Прямо сказано, что через точку. А цепкому глазу к тому же видно, что после точки — 5 знаков. Не 6, не 123, а пять! Переписываем процедуру из демки:

procedure TLocationForm.LocationSensor1LocationChanged(Sender: TObject;
  const OldLocation, NewLocation: TLocationCoord2D);
const
  LGoogleMapsURL: String = 'https://maps.google.com/maps?q=%s,%s&output=embed';
var
  latS, lonS: string;
begin
  { convert the location to latitude and longitude }
  Str(NewLocation.Latitude:8:5, latS);
  Str(NewLocation.Longitude:8:5, lonS);
  lbLatitude.Text := 'Latitude: ' + NewLocation.Latitude.ToString;
  lbLongitude.Text := 'Longitude: ' + NewLocation.Longitude.ToString;

  { and track the location via Google Maps }
//  WebBrowser1.Navigate(Format(LGoogleMapsURL, [NewLocation.Latitude.ToString, NewLocation.Longitude.ToString]));
  WebBrowser1.Navigate(Format(LGoogleMapsURL, [latS, lonS]));
end;



Запускаем. Показывает улицу, дом. Чуть ли не квартиру. Всё правильно.

Я вот сижу и думаю — а сколько в Эмбаркадеро писателям тестов платят, может, устроиться? И сразу всё на всём заработает как часы…
Через это проходят все пользователи их продуктов. Я таким образом менеджер пакетов для Дельфы сделал. Штатные средства — это ужас.
Если про отличия от десктопного приложения — то в первую очередь дизайном интерфейса (ну, понятно, один палец для работы, никаких всплывающих меню и т.п.). А по памяти и быстродействию гаджеты уже догоняют десктопы. Вот у меня на Tab-2 — 1 Gb ОЗУ. Даже неизвестно, чем его можно израсходовать — программа моя ела, я смотрел, лишь 70 Mb. Быстродействие, конечно, пока сильно отстаёт, ну, так не нагружать слишком!
Вы правда думаете что в распоряжении вашей программы весь гигабайт?

Кстати, а что делает ваша программа? 70 Мб это довольно много даже на десктопе.
Это симулятор гадания на картах. Там множество картинок загружается, и ни на качестве их, ни на размере я не экономил.
Если запускать напрямую с устройства готовую Release сборку, всё работает очень быстро. Я вообще никаких задержек не заметил. Единственно, запуск занимает 3-4 сек, и при этом чёрный экран. Кажется, что долго. Для сравнения запустил Маркет. Те же 4 сек. Только он сразу показывает верхнюю панель и выставляет крутящийся курсор ожидания, потому кажется, что запустился мигом. Вообще надо было бы какой-нибудь сплеш сделать, да времени не хватило.

Резюмируя — задержек при работе нет, и надо обязательно делать сплеш, чтобы не светить чёрный экран при запуске. Как сделать — вроде на каком-то форуме про это видел, надо опять поискать.
О, тут вообще исчерпывающе про этот вопрос! Нет, где-то на Эмбаркадеровском форуме для разработчиков просто обсуждалось про загрузку картинки в новом потоке, пока приложение стартует — я про это писал. Теперь же материала для размышлений стало гораздо больше. Спасибо.
Столько лишних операторов, на Java Будет и быстрее и лучше.
Чую набегут делфи-хейтеры и заминусуют всё и вся. Я например рад, что можно разрабатывать под андроид на любимом делфи, и судя по отзывам, с производительностью всё нормально.
Вопрос только в том, сколько стоит «любимое делфи» и зачем его покупать, есть на джаве все сделать проще и быстрее?
Вы об этом своем вопросе вспомните, когда захотите свое «быстро и легко сделанное на джаве» приложение перенести на iOS и вдруг окажется, что нужно все начинать с нуля.
Я вас скажу по секрету, что переписать логику с нуля с джавы на шарп стоило сопоставимо покупки лицензии на делфи. Иногда лучше начать с нуля.
Полторы тысячи долларов? Меньше месяца работы квалифицированного программиста? Что же у вас там за приложение такое?
Это замечательно, но существуют приложения со стоимостью разработки намного превышающей $1500. Думаю, вы не станете спорить.
Да и Преферанс затянул намного больше, я только указал сумму, в которую обошлось портирование логики. Самое интересное — это отладка на реальном железе.
Мне кажется, корректней будет Delphi сравнивать с Xamarin. По цене и возможностям, если я правильно вижу, они похожи.
Конечно корректнее. Я, собственно, и не понимаю как можно сравнивать кроссплатформенные средства с сугубо нативными.
В целом, есть ниши, где проще купить делфи за 1500 долларов, чем нанимать толпу специалистов по разным платформам, управлять этой толпой и ежемесячно платить зарплату.
Это если у вас есть дефли специалисты и вы уверены в том, что стоит инвестировать в делфи.
Даже если их нет. Дешевле нанять одного делфи-специалиста и купить ему Delphi, чем нанять двух программистов (Android+iOS). Delphi покупается один раз (ну или раз в N лет, если обновления покупать), а «лишнему» программисту нужно каждый месяц зарплату платить.

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

Написать на Делфи, теоретически можно что то с кнопочками для внутреннего пользования, владельцы айфонов на такое не клюнут.
С ценой разобрались, теперь претензии к кнопочкам? Какие конкретно претензии к кнопочкам, если не секрет?

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

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

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

P.S. Если уж вам так хочется отстоять игры, я даже отдельно специально для вас скажу — не надо делать на Delphi игры :)
А я вот не троллинга ради а интереса для хочу спросить: а вот делфи пока под мобайл не было, бизнес-приложений на айпадах тоже не было?
Были конечно. Но мобильные приложения в бизнес-среду медленно просачиваются, там все еще поле не паханное. Сейчас спрос похоже растет, не спроста ведь именно в последние пару лет так много кроссплатформенных средств разработки стало появляться. Delphi лишь одно из них. Вы похоже считаете, что все вокруг заблуждаются — и Embarcadero, и Xamarin, и Adobe, и многие-многие другие.
Я не считаю что заблуждаются, более того я всецело за кроссплатформ там где это можно. Просто опять же имхо, есть смысл сделать логику на сервере, а клиенту дать нативный интерфейс, к которому он привык.
Я тут Java не пользовался, но в студии вполне за 4 дня накидал бизнес приложение… с геолокацией, картой, чтением QR кодов, ну в общем все как по последней моде и нативненько… Хотя конечно до этого 3 дня репу чесал к чему подступиться… :)) До этого Objective C кусал, ничего докусался, таки интегрировал в мармелад GPUImage, да написал пару фишек и заменил модуль звука мармелада с ихнего на свой нативненький так сказать, работало лучше в разы. Но с объективом возился дольше намного. больше сложно синтаксис осилить не взорвав мозг. Зато теперь рад, что могу продолжаь изучение Java и Objective C.
Дешевле нанять C# программиста и купить ему лицензию на Xamarin. И лучше выйдет и платформа гораздо стабильней чем Делфи.
У Xamarin ещё одно преимущество — он сам кроссфплатформенный.
Изучил Ваш блог и нашел 2 весьма интересных поста.

Первый пост — про разницу в реализации модальных форм на десктопе и мобильных девайсах. Да, в Android при запуске каждого окна старое не ожидает, пока новое закроется. Но ведь и колбеки не используются, потому что Android может в любой момент закрыть предыдущие окна, даже если они ожидают результата от других окон. Все компоненты действительно разделены и при необходимости будут убираться из памяти. В случае же Delphi в памяти будут висеть все предыдущие окна, так как они получают результаты в виде колбека, в котором могут модифицироваться элементы окна, где этот колбек был создан. Если уж стандартное поведение Андроида не используется, не проще было бы в собственной графической песочнице эмулировать привычное дельфистам поведение? Не говоря уже, что так лучше для кроссплатформенности.

Второй пост — про то что линии с одинаковой толщиной рисуются в Delphi по разному. В нашем Преферансе достаточно серьезно используется Canvas из Android SDK и такая проблема неведома. Координаты и размеры линий задается в числах с плавающей точкой и выглядят на экране сглажено и одинаково. Можете посмотреть на скриншоты пули в Android-версии преферанса. С градиентами и изогнутыми линиями. Мне страшно представить, каких бы усилий стоило бы нарисовать такое в Delphi.

Возникает вопрос — а не проще ли использовать нативный и предсказуемый инструмент, чем искать, как обходить баги вот в таком вот «кроссплатформенном»? Я уж не представляю, что будет, когда придется искать какую-то платформозависимую багу.

Еще вопрос, почему такой довольно взрослой и недешевой среде для каждой новой версии требуются патчи от некоего Andreas Hausladen? Неужели в такой бизнес-ориентированной компании как Embarcadero не могут нанять квалифицированный QA отдел и программистов, которые имея полный исходный код фиксили бы те баги, которые один скромный программист фиксит, имея лишь дизассемблер?

Кстати, по блогам и форумам пишут, что на FireMonkey нету контрола для отображения HTML. Врут? В Android и iOS SDK такие есть.
Про работу с окнами на Android… я сам не очень понял почему они сделали все так, как сделали. Про это и был тот пост в общем :)

В целом же программ без багов не бывает. Тем более в таких молодых (Android всего-то в сентябре зарелизили). Постепенно стабильность появится, а багов будет меньше. Некоторая сырость — это общий бич кроссплатформенных средств на данный момент. Они все еще молоды.

P.S. Про HTML врут. Когда-то его не было, но сейчас есть.
Говоря про бизнес, я имел ввиду только то, что у них иные приоритеты. Они вполне будут готовы простить неидеальную прорисовку, если это даст экономию по деньгам или времени.
Опять же, бизнес бизнесу рознь. Тот же клиент для онлайн банкинга должен выглядеть супер и быть понятным пользователю устройства. Можно, к примеру, написать кроссплатформ клиент, но клиентам это не понравится. В этом случае лучше написать два отдельных приложения, чтобы клиенты не разбежались.
А вот хочется писать на любимом делфи. А на нелюбимой яве — не хочется.
Отлично, каждый пишет на том, что ему больше нравится. А там уже будет рынок решать что выгоднее.
А разве сейчас не так?
Спасибо за информацию. Всё никак не соберусь посмотреть на последние версии Дельфи, хотя пишу на нем уже много лет. С появлением поддержки Android думал уже пересесть на ХЕ5, но прочел довольно много критических обзоров — мол, совсем сырая эта поддержка. Как по Вашим ощущениям, можно что-то серьезное написать, или баловство всё это?
Ну по моим ( я не автор статьи, но пробывал ) ощущениям хорошее приложение, занимающее топы вы врятли напишете, но вот специфическое ПО — вполне. Например можно организовать работу выездных специалистов с планшетом. Банальные примеры: инвентаризация на складе, учет техники, техосмотр с занесением всего в журнал. Быстро создать такое приложение вполне возможно. Да и не только такое. Чисто на производстве для внутренних корпоративных целей очень даже подходит, особенно если уже есть специалисты по делфи, а обычно в этом сегменте их есть у них.
Я тоже читал подобные отзывы (сырая и т.п.). Пост и посвящен в том числе развенчанию некоторых таких легенд. 3D я, например, использовать не стал, да для этого есть та же Юнити с тесселяциями и скелетными анимациями.

А вот что-то «обычное» — панели, кнопки, списки, сетки — это вполне можно делать на Делфи. Если там ещё с базой надо общаться — тогда именно на Делфи (а на чём же ещё?!). Она всегда была именно под это и заточена.

Надеюсь, с конкурса чего-нибудь опубликуют для всеобщего обозрения, вот и посмотрим, что там и насколько серьёзное получилось. У меня-то программа несерьёзная выложена, но красивая. Анимации, звуки и прочее (в 2D).

Будет интересно посмотреть, что у кого получилось.
Меня больше всего интересует производительность FMX. Последний раз я пробовал работать с FM на Delphi XE3, и производительность меня очень не порадовала. Мне всего-то нужен был примерно такой список:
Картинко

Само собой элементы списка должны уметь динамически меняться. На них появляются прогрессбары, в момент загрузки, статус загрузки и т.п. иногда на них анимация может крутиться.
Я реализовал этот список. Закинул в него около 150-200 элементов, и оно стало заметно подтормаживать, особенно заметно на скроллинге. И это всего лишь один список. Для меня это оказалось не приемлемо, ибо у меня машина не самая слабая, а приложение я хотел очень легкое, шустрое и отзывчивое. Подобные списки с тысячами элементов, сортировками, поисками и всем чем только можно — я прекрасно реализую на TVirtualTreeView, и оно на VTV работает на порядки шустрее с десятками тысяч — чем этот чудосписок со 100 элементами. Список на картинке как раз на VTV.

Собственно вопрос, улучшилась ли ситуация в XE5? А то тут говорят производительность норм… Насколько сложный был гуй? Было что-то сложнее картинки, трех кнопок и двух чекбоксов? Просто на FMX который был в Delphi XE3 написать что-то по сложности сопоставимое с Delphi IDE — невозможно на том FMX который с ним поставлялся. Простенькое приложение написать можно, но зачем оно на мобильных платформах? Батарею жрать? А на десктопах под винду — VCL шустрее.

p.s. У меня есть наработки типа библиотеки контролов, которые используют OpenGL для вывода графики. Когда то, когда навелосипедил для себя (когда еще никаких этих FireMonkey не было). Плюнул развивать это дело, когда выкатили FMX c XE. Но даже сейчас мои контролы работают шустрее. Потому что я заморачивался по поводу оптимизаций. Эх, знал бы что этот цирк с FMX затянется так…
Гуй был простой, чтобы любая девочка разобралась. Главный напряг ресурсов процессора приходится у меня на моменты, когда анимация контрола происходит одновременно с проигрыванием звукового файла. На Виндах явно заметно дёрганье анимации, т.е. что-то перегружено. Как ни странно, на Андроиде такого нет. Вот это поразительно. К слову, одни и те же 3D сцены, сделанные на Юнити, имея на десктопе фпс порядка 150-200, на этом же планшете падают в фпс до 15-20, т.е. на порядок.
try
  Create;
finally
  Free;
end


аж глаз режет, никогда не понимал такого подхода — всегда пишу так:

Create;
try
  ..  
finally
  Free;
end
А если нужно создать два объекта то писать вот так?
obj1 := TMyObj1.Create;
try
  obj2 := TMyObj2.Create;
  try
    ....
  finally
    obj2.Free;
  end;    
finally
  obj1.Free;
end;

Я лично предпочитаю так:
obj1 := nil;
obj2 := nil;
try
  obj1 := TMyObj1.Create;
  obj2 := TMyObj2.Create;
  ...
finally
  obj1.Free;
  obj2.Free;
end;
Если в конструкторе вылетает исключение, то у Вас по любому будет отрабатываться деструктор, а это черевато.
Чревато не знать делфи. Free если что делает проверку на nil. Код который я привел абсолютно корректен.
А вдруг я перекрыл Free? ) Не говорите ерунды, finally нужен для освобождения памяти, если память не была выделена, то и освобождать ничего не надо. Перепишите свой пример с GetMem/FreeMem, например, и все станет ясно.
Это вы говорите ерунду. Метод TObject.Free — не виртуальный, и если вы его перекрыли — то ССЗБ.
Не знаю что вам не ясно в примере выше, но вот то же самое на GetMem-ах
item1 := nil;
item2 := nil;
try
  GetMem(item1, SizeOf(item1^));
  GetMem(item2, SizeOf(item2^));
  ...
finally
  if assigned(item1) then FreeMem(item1);
  if assigned(item2) then FreeMem(item2);
end;

p.s. Видимо не стоит ввязываться в спор о Delphi с вашими знаниями этого языка.
Как не знали дельфисты про MVC/MVVP, так и продолжают лепить копрокод в конце 2013-го.

UFO landed and left these words here
Вы абсолютно правы. Все дельфисты — профессиональные говнокодеры, неспособные к написанию сложных приложений. MVC им ни о чем не говорит, а всякие ActionManager'ы и LiveBinding запилили в Дельфу просто так, чтобы показать «что и мы так можем».
А Эмбаркадеро финансируется мировой закулисой. Потому что не может быть такого, что нашлось достаточно разработчиков, готовых потратиться на никому ненужную XE3-4-5.
iandarken, о себе: «Раздолбай-сисадмин, геймер-задрот и зануда».

Простите, из вашего профиля не совсем ясно какой язык вы предпочитаете? У вас вообще есть собственные разработки, раз вы делаете такие глобальные выводы?
> Как не знали дельфисты про MVC
Тащемта, делфя сама по себе — уже MVC.
То, что вы имеете в виду — это MVC поверх MVC.
Спорный вопрос, в общем.
Люблю Delphi с детства, был момент когда думал что делфи каюк настал, но вижу, что команда не сдается и так просто не уступит.
Я надеюсь, что делфи будет жить и баги устранят. Спорить чем делфи лучше или хуже не собираюсь, у меня достаточно опыта было на других языках они тоже не совершенны.
Спасибо, очень интересный опыт.

Как раз занимаюсь Android-разработкой, а на Дельфи пришлось плотно поработать в прошлом месяце (поддерживал немного Windows-СУБД на Delphi XE2). До 2009 года писал на Delphi 7 более двух лет.
В общем, с одной стороны хорошо, что появляются такие возможности выбора, но с другой строны лично я добровольно с Java на Delphi никогда бы не перешёл вернулся.

Простые причины на поверхности:
* Стандартными средствами можно легко разрабатывать под Android, не вкладывая денег в ПО. Сейчас работаю в Ubuntu и с Android Studio. В случае Delphi — это покупка Windows + самой среды разработки как минимум (?)
* Уровень документации. Официальная документация просто отличная + куча тематических блогов, StackOverflow, хабр в конце-концов. Нерешаемых проблем практически нет.
* Просто эстетическое удовлетворение от работы и удобство IntelliJ IDEA Android Studio. После неё XE2 — это просто адъ и израиль какой-то :) Надеюсь в XE5 всё гораздо лучше, никогда её не видел.

Конечно, это всё касается чистого Андроида, задач писать под iOS/Windows Phone/Whatever пока не возникало.
UFO landed and left these words here
Вы почти правы. В первом случае проблема не столько в том что TStringList.Create внутри try, а в том что в StrList может быть не nil до входа в try, соответственно код лучше переделать либо как вы сказали на:
StrList := TStringList.Create;
try
  //some code here
finally
  StrList.Free;
end;

либо на:
StrList := nil;
try
  StrList := TStringList.Create;
  //some code here
finally
  StrList.Free;
end;

Я лично предпочитаю второй способ, потому что если надо создать несколько объектов — можно все в один try впихнуть.

Во втором же случае — в DeleteFile исключение не должно стрельнуть, т.к. функция вызывает системную, возвращающую код ошибки.

Таким образом код содержит потенциально одну проблему, с TStringList.Create, который может стрельнуть только одним исключением: EOutOfMemory, при этом будет утечка в один TStringList
UFO landed and left these words here
Стрелять исключениями в деструкторе в делфи — это сразу же стрелять себе в ногу, ибо не отработает TObject.FreeInstance, а соответственно и TObject.CleanupInstance. Грубо говоря имеем сразу же утечку памяти еще до того, как код выйдет за пределы finally.
Кроме того делфя сама создает один блок финализации для автоматически финализируемых типов, и изменить мы это не можем. Поэтому бросать исключения в деструкторе — нельзя.
UFO landed and left these words here
А, ну да, видимо я вас не так понял, когда вы говорили про общий случай. Я думал вы имели ввиду освобождение объектов в общем случае.

Тогда позвольте мне немного расширить ваше условие:
Но в общем случае рекомендуют использовать один try-finally блок на один ресурс для ресурсов, которые могут создавать исключения на этапе освобождения.
По поводу try..finally. Это был псевдокод, показывающий, что на обеих платформах можно спокойно использовать Free для освобождения объекта.

Если по сути дискуссии — использование того или иного подхода зависит от того, велика ли вероятность ошибки в конструкторе. Ошибка, например, при создании стринглиста, крайне маловероятна (кончилась память? Ничего другого сразу и не придумаешь.).

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

Ещё раз прошу прощения.
Only those users with full accounts are able to leave comments. Log in, please.