Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Большое спасибо за статью. Интересно было почитать ещё что — нибудь техническое и вкусное про подводные камни на пути при портировании. Ну, и маркетинговую часть интересно послушать, насколько успешен был выход на данную платформу.
Если не поддерживаются блоки на уровне языка, то как например предполагается работа с GDC (Grand Dispatch Central)? Собственно работа с потоками в iOS это в 90% GDC + block.
Ок, на эту тему могу сказать следующее:
- Для iOS (но не для macOS) блоки реализованы в юните Macapi.OCBlocks.pas. Я лично не проверял, как это работает, поскольку для iOS мы пока ничего не пишем, но, теоретически, должно работать.
- GDC вполне «юзабелен», особенно с помощью обертки, о которой идет речь тут: https://ridingdelphi.blogspot.ru/ . Ссылка на сорс там есть внизу. Хотя, замечу, что в macOS у нас пока не возникло необходимости использовать этот код.
- Для работы с потоками нас пока вполне устраивает родной дельфийский TThread (ну и плюс анонимные треды, что тоже очень удобно).
Ощущения забивания гвоздей отверткой совсем нет. Наоборот, приятно и интересно. Мне кажется, что это все же преувеличение. Я как раз писал о том, что инструмент адекватен задаче.
По поводу изучения obj-c — да, это один из возможных путей, и для некоторых из нас даже учить ничего не надо, уже всё выучено, но я объяснил в статье, что нам представилось более разумным решением не переписывать горы кода, а использовать большую часть as is. Так что никаких священных войн, чистая целесообразность.
По поводу изучения obj-c — да, это один из возможных путей, и для некоторых из нас даже учить ничего не надо, уже всё выучено, но я объяснил в статье, что нам представилось более разумным решением не переписывать горы кода, а использовать большую часть as is. Так что никаких священных войн, чистая целесообразность.
А вариант с Lazarus не рассматривался?
Спасибо за статью! Очень познавательно и интересно.
Хардкор язык — это брейнфак. А делфи — отличный язык, позволяющий писать один код для многих платформ сразу, не распыляясь на кучу языков и сред.
если человек очень хорошо знает дельфи/другой хардкор язык,
Хардкор язык — это брейнфак. А делфи — отличный язык, позволяющий писать один код для многих платформ сразу, не распыляясь на кучу языков и сред.
День работы и примерно 50 IFDEF'ов такого вида:...
слышали про Design Patterns? ;)
Да, конечно, только не очень понял, к чему вы в данном случае клоните… Есть Delphi-класс (кстати, написанный не нами) для работы с GPS через COM-порты. Класс для одной платформы, Windows. Мы его сделали мультиплатформенным, используя несколько десятков conditional defines, чтобы под Windows остался WinAPI, а под macOS стал использоваться POSIX. Нам мог бы облегчить жизнь какой-нибудь из design patterns? Если да — расскажите, буду благодарен, и в следующий раз мы пойдем другим путем.
собственно, к тому и клоню, что conditional defines в приведённом Вами виде — это лапша, ведь согласитесь?
представьте (просто в качестве мысленного эксперимента), что вам надо будет портировать этого класса подLinux даже лучше так — Android (Delphi ж как раз умеет)
Вам опять придётся, уверен, ползать по всему коду и вставлять $IFDEF ANDROID… код станет ещё развестистей… вместо добавления модуля для работы с COM-портом в Android (а это та ещё песня, скажу я вам)
а рассказать — рассказано уже всё давно в книжках (как раз сегодня дочитал подаренную на НГ вышеупомянутую «Design Patterns») — паттерны «Фабричный метод» + «Cтратегия», например, КМК…
посмотрите, как реализована работа с Bluetooth или буфером обмена в исходниках самого Delphi:
как Вы понимаете, реализации работы с ними под каждой платформой — свои, но клиентский (ваш) код — не содержит никаких IFDEF'ов, один код на все платформы
всё сделано в коде FMX, причём «красиво» и понятно: под каждую платформу — в своём модуле.
а чтобы добавить, например, поддержку BT в Linux (ну, это я так, абстрактно), им только надо будет добавить модуль реализации для этой платформы, а в вашем коде менять ничего не придётся…
З.Ы. Я сейчас как раз закончил полугодовой марафон по портированию одного нашего (небольшого, в общем-то) проекта под Linux (на Free Pascal). Но код был и без тестов, и лапшой, и с копи-пастой, так что я очень в теме )
прежде, чем менять что-то, надо покрыть тестами, чтобы хоть как-то покрыть тестами, надо мало-мальски отрефакторить… заодно понаходил кучу ошибок…
З.З.Ы. а у вас в этом проекте автотесты есть? ;)
З.З.З.Ы. и кстати,
это продакшн-код? я имею в виду форматирование
представьте (просто в качестве мысленного эксперимента), что вам надо будет портировать этого класса под
Вам опять придётся, уверен, ползать по всему коду и вставлять $IFDEF ANDROID… код станет ещё развестистей… вместо добавления модуля для работы с COM-портом в Android (а это та ещё песня, скажу я вам)
а рассказать — рассказано уже всё давно в книжках (как раз сегодня дочитал подаренную на НГ вышеупомянутую «Design Patterns») — паттерны «Фабричный метод» + «Cтратегия», например, КМК…
посмотрите, как реализована работа с Bluetooth или буфером обмена в исходниках самого Delphi:
как Вы понимаете, реализации работы с ними под каждой платформой — свои, но клиентский (ваш) код — не содержит никаких IFDEF'ов, один код на все платформы
всё сделано в коде FMX, причём «красиво» и понятно: под каждую платформу — в своём модуле.
а чтобы добавить, например, поддержку BT в Linux (ну, это я так, абстрактно), им только надо будет добавить модуль реализации для этой платформы, а в вашем коде менять ничего не придётся…
З.Ы. Я сейчас как раз закончил полугодовой марафон по портированию одного нашего (небольшого, в общем-то) проекта под Linux (на Free Pascal). Но код был и без тестов, и лапшой, и с копи-пастой, так что я очень в теме )
прежде, чем менять что-то, надо покрыть тестами, чтобы хоть как-то покрыть тестами, надо мало-мальски отрефакторить… заодно понаходил кучу ошибок…
З.З.Ы. а у вас в этом проекте автотесты есть? ;)
З.З.З.Ы. и кстати,
if sysctlbyname('hw.physicalcpu',@CoreCount, @Size, nil, 0) = 0
then result:= CoreCount else result:= System.CPUCount;
это продакшн-код? я имею в виду форматирование
Спасибо за разъяснения!
Да, примерно в той же степени, что и System.Sysutils или System.Classes.
Согласен, этот подход неплох. Просто дело в том, что иногда приходится выбирать между красотой и производительностью труда. Можно сделать красиво, как те же platform services в FMX, а можно быстро, с IFDEFs, причем, на мой взгляд, вероятность наделать ошибок во втором случае существенно ниже, потому что не будет такого объема рефакторинга. Когда есть много людей и много времени — это одно, когда людей мало и когда вы торопитесь выкатить продукт быстрее конкурентов — это другое. У нас был сотрудник, который мог потратить несколько дней на то, чтобы написать супер-эффективную function IPv4ToStr(const IP: Cardinal): string, которая работала быстрее станадртной винсоковской в десятки раз. Проблема была только в том, что она вызывалась крайне редко, и ее скорость работы ни на что не влияла… В конце концов мы расстались:-)
Про автотесты — нет. Про форматирование — ну слушайте, давайте не будем обсуждать личные преференции конкретного программиста в части форматирования:-) Опять же, в идеальном мире все форматируют идеально. В реальном — как привыкли. Я никого за это не ругаю, хотя сам часто бурчу под нос, когда читаю код с нестандартным форматированием.
собственно, к тому и клоню, что conditional defines в приведённом Вами виде — это лапша, ведь согласитесь?
Да, примерно в той же степени, что и System.Sysutils или System.Classes.
всё сделано в коде FMX, причём «красиво» и понятно: под каждую платформу — в своём модуле.
а чтобы добавить, например, поддержку BT в Linux (ну, это я так, абстрактно), им только надо будет добавить модуль реализации для этой платформы, а в вашем коде менять ничего не придётся…
Согласен, этот подход неплох. Просто дело в том, что иногда приходится выбирать между красотой и производительностью труда. Можно сделать красиво, как те же platform services в FMX, а можно быстро, с IFDEFs, причем, на мой взгляд, вероятность наделать ошибок во втором случае существенно ниже, потому что не будет такого объема рефакторинга. Когда есть много людей и много времени — это одно, когда людей мало и когда вы торопитесь выкатить продукт быстрее конкурентов — это другое. У нас был сотрудник, который мог потратить несколько дней на то, чтобы написать супер-эффективную function IPv4ToStr(const IP: Cardinal): string, которая работала быстрее станадртной винсоковской в десятки раз. Проблема была только в том, что она вызывалась крайне редко, и ее скорость работы ни на что не влияла… В конце концов мы расстались:-)
Про автотесты — нет. Про форматирование — ну слушайте, давайте не будем обсуждать личные преференции конкретного программиста в части форматирования:-) Опять же, в идеальном мире все форматируют идеально. В реальном — как привыкли. Я никого за это не ругаю, хотя сам часто бурчу под нос, когда читаю код с нестандартным форматированием.
да я, можно сказать, «в курсе» таких «оправданий» )
я называю их «технический долг»
З.Ы. тот код, который я портировал, писался лет 7 назад по такому же принципу: «да зачем заморачиваться — ведь только под Win32 будет работать»… а потом появилась необходимость в Win64 (а работа с преобразованием Pointer в Integer и обратно не менялась (и как оно работало?) )))))… и под Linux (тут во весь рост copy-paste вместо декомпозиции)
и в итоге я потратил ПОЛГОДА(sic!), чтобы только, по большому счёту, заменить реализацию TCP-сервера с Windows-only компонентов OverbyteICS на кроссплатформенные Indy, хотя весь остальной код в общем и целом был практически кроссплатформенный… только вот беда — неоднородный, с дублированием (а в одном месте — так и вообще затроенный(!)), нетестируемый… ))) но «работал же! надо было быстро»
ладно, это пустое (опыт показывает, что мне не убедить даже коллег, которые говорят «да, да! надо!», но продолжаютговнокодить делать по-своему )))
Вы мне скажите, как у вас релизы выпускаются? чем собираются?
я называю их «технический долг»
З.Ы. тот код, который я портировал, писался лет 7 назад по такому же принципу: «да зачем заморачиваться — ведь только под Win32 будет работать»… а потом появилась необходимость в Win64 (а работа с преобразованием Pointer в Integer и обратно не менялась (и как оно работало?) )))))… и под Linux (тут во весь рост copy-paste вместо декомпозиции)
и в итоге я потратил ПОЛГОДА(sic!), чтобы только, по большому счёту, заменить реализацию TCP-сервера с Windows-only компонентов OverbyteICS на кроссплатформенные Indy, хотя весь остальной код в общем и целом был практически кроссплатформенный… только вот беда — неоднородный, с дублированием (а в одном месте — так и вообще затроенный(!)), нетестируемый… ))) но «работал же! надо было быстро»
ладно, это пустое (опыт показывает, что мне не убедить даже коллег, которые говорят «да, да! надо!», но продолжают
Вы мне скажите, как у вас релизы выпускаются? чем собираются?
и в итоге я потратил ПОЛГОДА(sic!), чтобы только, по большому счёту, заменить реализацию TCP-сервера с Windows-only компонентов OverbyteICS на кроссплатформенные Indy
Кстати ICS неплохо работает на macOS, мы его используем в нашей бесплатной утилите TamoSoft Throughput Test (маковская версия тоже на FMX сделана). Жаль, что не работает на Linux и iOS.
Вы мне скажите, как у вас релизы выпускаются? чем собираются?
Не очень понял, о каких именно релизах речь. Windows? macOS? На macOS продукт пока не готов. На Windows — всё билдится из командной строки, собирается в сетап, подписывается, и.п. Или речь о чем-то другом? Единственный «ручной» этап, спасибо новым политикам Microsoft, это подписывание драйверов для Windows 10 на их портале. Это конечно дико неудобно.
Не очень понял, о каких именно релизах речь. Windows? macOS?
а я и не уточнял каких именно )) я обо всех и спрашивал )
всё билдится из командной строки
ну уж я надеялся, что не в самой Delphi )))
а чем билдится? что/кто эту командную запускает?
Мы у себя, например, собираем всё тупо батником. Запускается вручную, собирается под 30 exe, потом упаковывается и отправляется на фтп.
Windows: bat-файл, который:
Bat-файл запускает специально обученный homo sapiens.
Mac (предварительно, как я сказал, коммерческих релизов пока нет): bat-файл, который:
Bat-файл запускает специально обученный homo sapiens, иногда тот же самый.
- Делает MSBuild проекта.
- Делает дистрибутив с помощью SetupBuilder, который в процессе сам подписывает Authenticode.
- Зипует.
Bat-файл запускает специально обученный homo sapiens.
Mac (предварительно, как я сказал, коммерческих релизов пока нет): bat-файл, который:
- Делает MSBuild проекта.
- Деплоит релиз на Мак с помощью embdeploy.
- Подписывает релиз на Маке с помощью того же embdeploy (хотя можно через paclient.exe).
- Делает DMG-файл на Маке с помощью CreateDMG.
Bat-файл запускает специально обученный homo sapiens, иногда тот же самый.
а про форматирование: в приведённом мной куске кода даже не столько дело вкуса (хотя я считаю такой код некрасивым (да и он не Borland-style)), сколько даже неудобно: нельзя поставить точку останова на одну ветку условия
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Delphi со вкусом Cocoa