How to become an author
Search
Write a publication
Pull to refresh

Comments 74

Собственно, интересны ваши впечатления от запуска такого приложения на устройстве.
Total votes 2: ↑2 and ↓0+2
А чем такое приложение должно отличаться от любого другого?
Total votes 5: ↑0 and ↓5-5
Требованиями к версии ОС и устройству?
Total votes 5: ↑4 and ↓1+3
А вот вы не правы. Приложение, написанное в XE5, прекрасно работает на Galaxy Tab первой модели под Android 2.3 и 2.2 (старее я просто уже не нашёл).
Total votes 3: ↑1 and ↓2-1
В чем я не прав? Я не утверждал, что оно там не работает. Наоборот, мне интересно узнать, где оно работает, а где нет.
Вот тут (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.
Total votes 6: ↑5 and ↓1+4
Спасибо. Вот эта статистика снимает все вопросы:

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

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

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;


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

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

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

Резюмируя — задержек при работе нет, и надо обязательно делать сплеш, чтобы не светить чёрный экран при запуске. Как сделать — вроде на каком-то форуме про это видел, надо опять поискать.
Total votes 3: ↑2 and ↓1+1
О, тут вообще исчерпывающе про этот вопрос! Нет, где-то на Эмбаркадеровском форуме для разработчиков просто обсуждалось про загрузку картинки в новом потоке, пока приложение стартует — я про это писал. Теперь же материала для размышлений стало гораздо больше. Спасибо.
This comment wasn’t rated yet0
Столько лишних операторов, на Java Будет и быстрее и лучше.
Total votes 3: ↑2 and ↓1+1
Чую набегут делфи-хейтеры и заминусуют всё и вся. Я например рад, что можно разрабатывать под андроид на любимом делфи, и судя по отзывам, с производительностью всё нормально.
Total votes 12: ↑7 and ↓5+2
Вопрос только в том, сколько стоит «любимое делфи» и зачем его покупать, есть на джаве все сделать проще и быстрее?
Total votes 7: ↑6 and ↓1+5
UFO just landed and posted this here
Я вас скажу по секрету, что переписать логику с нуля с джавы на шарп стоило сопоставимо покупки лицензии на делфи. Иногда лучше начать с нуля.
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
UFO just landed and posted this here
Да и Преферанс затянул намного больше, я только указал сумму, в которую обошлось портирование логики. Самое интересное — это отладка на реальном железе.
This comment wasn’t rated yet0
Мне кажется, корректней будет Delphi сравнивать с Xamarin. По цене и возможностям, если я правильно вижу, они похожи.
Total votes 3: ↑3 and ↓0+3
UFO just landed and posted this here
UFO just landed and posted this here
Это если у вас есть дефли специалисты и вы уверены в том, что стоит инвестировать в делфи.
Total votes 4: ↑3 and ↓1+2
UFO just landed and posted this here
Если надо писать хорошее приложение на маркет, то надо делать две отдельные версии для IOS и Android, если писать игру, то можно на юнити написать кросплатформ.

Написать на Делфи, теоретически можно что то с кнопочками для внутреннего пользования, владельцы айфонов на такое не клюнут.
Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this here
А я вот не троллинга ради а интереса для хочу спросить: а вот делфи пока под мобайл не было, бизнес-приложений на айпадах тоже не было?
This comment wasn’t rated yet0
UFO just landed and posted this here
Я не считаю что заблуждаются, более того я всецело за кроссплатформ там где это можно. Просто опять же имхо, есть смысл сделать логику на сервере, а клиенту дать нативный интерфейс, к которому он привык.
This comment wasn’t rated yet0
Я тут Java не пользовался, но в студии вполне за 4 дня накидал бизнес приложение… с геолокацией, картой, чтением QR кодов, ну в общем все как по последней моде и нативненько… Хотя конечно до этого 3 дня репу чесал к чему подступиться… :)) До этого Objective C кусал, ничего докусался, таки интегрировал в мармелад GPUImage, да написал пару фишек и заменил модуль звука мармелада с ихнего на свой нативненький так сказать, работало лучше в разы. Но с объективом возился дольше намного. больше сложно синтаксис осилить не взорвав мозг. Зато теперь рад, что могу продолжаь изучение Java и Objective C.
Total votes 1: ↑1 and ↓0+1
Дешевле нанять C# программиста и купить ему лицензию на Xamarin. И лучше выйдет и платформа гораздо стабильней чем Делфи.
Total votes 1: ↑1 and ↓0+1
У Xamarin ещё одно преимущество — он сам кроссфплатформенный.
Total votes 1: ↑1 and ↓0+1
Изучил Ваш блог и нашел 2 весьма интересных поста.

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

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

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

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

Кстати, по блогам и форумам пишут, что на FireMonkey нету контрола для отображения HTML. Врут? В Android и iOS SDK такие есть.
Total votes 3: ↑3 and ↓0+3
UFO just landed and posted this here
UFO just landed and posted this here
Опять же, бизнес бизнесу рознь. Тот же клиент для онлайн банкинга должен выглядеть супер и быть понятным пользователю устройства. Можно, к примеру, написать кроссплатформ клиент, но клиентам это не понравится. В этом случае лучше написать два отдельных приложения, чтобы клиенты не разбежались.
Total votes 1: ↑1 and ↓0+1
А вот хочется писать на любимом делфи. А на нелюбимой яве — не хочется.
Total votes 4: ↑3 and ↓1+2
Отлично, каждый пишет на том, что ему больше нравится. А там уже будет рынок решать что выгоднее.
Total votes 1: ↑1 and ↓0+1
А разве сейчас не так?
Total votes 3: ↑1 and ↓2-1
Спасибо за информацию. Всё никак не соберусь посмотреть на последние версии Дельфи, хотя пишу на нем уже много лет. С появлением поддержки Android думал уже пересесть на ХЕ5, но прочел довольно много критических обзоров — мол, совсем сырая эта поддержка. Как по Вашим ощущениям, можно что-то серьезное написать, или баловство всё это?
Total votes 2: ↑2 and ↓0+2
Ну по моим ( я не автор статьи, но пробывал ) ощущениям хорошее приложение, занимающее топы вы врятли напишете, но вот специфическое ПО — вполне. Например можно организовать работу выездных специалистов с планшетом. Банальные примеры: инвентаризация на складе, учет техники, техосмотр с занесением всего в журнал. Быстро создать такое приложение вполне возможно. Да и не только такое. Чисто на производстве для внутренних корпоративных целей очень даже подходит, особенно если уже есть специалисты по делфи, а обычно в этом сегменте их есть у них.
Total votes 2: ↑2 and ↓0+2
Я тоже читал подобные отзывы (сырая и т.п.). Пост и посвящен в том числе развенчанию некоторых таких легенд. 3D я, например, использовать не стал, да для этого есть та же Юнити с тесселяциями и скелетными анимациями.

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

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

Будет интересно посмотреть, что у кого получилось.
Total votes 1: ↑1 and ↓0+1
Меня больше всего интересует производительность 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 затянется так…
Total votes 1: ↑1 and ↓0+1
Гуй был простой, чтобы любая девочка разобралась. Главный напряг ресурсов процессора приходится у меня на моменты, когда анимация контрола происходит одновременно с проигрыванием звукового файла. На Виндах явно заметно дёрганье анимации, т.е. что-то перегружено. Как ни странно, на Андроиде такого нет. Вот это поразительно. К слову, одни и те же 3D сцены, сделанные на Юнити, имея на десктопе фпс порядка 150-200, на этом же планшете падают в фпс до 15-20, т.е. на порядок.
This comment wasn’t rated yet0
try
  Create;
finally
  Free;
end


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

Create;
try
  ..  
finally
  Free;
end
Total votes 2: ↑1 and ↓10
А если нужно создать два объекта то писать вот так?
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;
Total votes 1: ↑1 and ↓0+1
Если в конструкторе вылетает исключение, то у Вас по любому будет отрабатываться деструктор, а это черевато.
Total votes 2: ↑1 and ↓10
Чревато не знать делфи. Free если что делает проверку на nil. Код который я привел абсолютно корректен.
Total votes 1: ↑1 and ↓0+1
А вдруг я перекрыл Free? ) Не говорите ерунды, finally нужен для освобождения памяти, если память не была выделена, то и освобождать ничего не надо. Перепишите свой пример с GetMem/FreeMem, например, и все станет ясно.
Total votes 3: ↑0 and ↓3-3
Это вы говорите ерунду. Метод 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 с вашими знаниями этого языка.
Total votes 5: ↑5 and ↓0+5
Как не знали дельфисты про MVC/MVVP, так и продолжают лепить копрокод в конце 2013-го.

Total votes 8: ↑3 and ↓5-2
UFO just landed and posted this here
Вы абсолютно правы. Все дельфисты — профессиональные говнокодеры, неспособные к написанию сложных приложений. MVC им ни о чем не говорит, а всякие ActionManager'ы и LiveBinding запилили в Дельфу просто так, чтобы показать «что и мы так можем».
А Эмбаркадеро финансируется мировой закулисой. Потому что не может быть такого, что нашлось достаточно разработчиков, готовых потратиться на никому ненужную XE3-4-5.
Total votes 10: ↑2 and ↓8-6
iandarken, о себе: «Раздолбай-сисадмин, геймер-задрот и зануда».

Простите, из вашего профиля не совсем ясно какой язык вы предпочитаете? У вас вообще есть собственные разработки, раз вы делаете такие глобальные выводы?
This comment wasn’t rated yet0
> Как не знали дельфисты про MVC
Тащемта, делфя сама по себе — уже MVC.
То, что вы имеете в виду — это MVC поверх MVC.
Спорный вопрос, в общем.
Total votes 1: ↑1 and ↓0+1
Люблю Delphi с детства, был момент когда думал что делфи каюк настал, но вижу, что команда не сдается и так просто не уступит.
Я надеюсь, что делфи будет жить и баги устранят. Спорить чем делфи лучше или хуже не собираюсь, у меня достаточно опыта было на других языках они тоже не совершенны.
Total votes 1: ↑1 and ↓0+1
Спасибо, очень интересный опыт.

Как раз занимаюсь 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 пока не возникало.
Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this 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
This comment wasn’t rated yet0
UFO just landed and posted this here
Стрелять исключениями в деструкторе в делфи — это сразу же стрелять себе в ногу, ибо не отработает TObject.FreeInstance, а соответственно и TObject.CleanupInstance. Грубо говоря имеем сразу же утечку памяти еще до того, как код выйдет за пределы finally.
Кроме того делфя сама создает один блок финализации для автоматически финализируемых типов, и изменить мы это не можем. Поэтому бросать исключения в деструкторе — нельзя.
This comment wasn’t rated yet0
UFO just landed and posted this here
А, ну да, видимо я вас не так понял, когда вы говорили про общий случай. Я думал вы имели ввиду освобождение объектов в общем случае.

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

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

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

Ещё раз прошу прощения.
Total votes 1: ↑0 and ↓1-1
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr