Лидеры

Я смотрел. На сессии вопросов выступил шеф московского офиса. Мне показалось что само московское руководство не особо одобряет этот шаг, но резюме такое: Идера ведет разработку всех своих продуктов силами наемных компаний разработчиков (и надо сказать видимо весьма успешно, раз хватило денег на выкуп Ембаркадеро), вот теперь и разработка RAD тоже полностью подчиняется этой стратегии. Летом офис с Испании, теперь Россия. Немного рассказали про линукс - он будет только в энтерпрайз версии PS: Поздравьте меня, теперь я наконец легальный пользователь! Купил Prof+mobile по акции. Еще и скидку 10% получил как индивидуальный. Так что я верю в светлое будущее!

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

Ссылка: http://blog.rzaripov.kz/2016/11/0-modernlistview.html Автор: Равиль Зарипов @ZuBy Описание: Знакомство с ModernListView

Всеволод, я совсем не согласен с вашей гипотезой "сами разработчики виноваты" Начиная c XE4 всем говорили - волк, волк вот, программируйте на Андроид. А оно не работает. XE5, XE6, XE7, XE8 и все равно падает на ровных местах и никакой работодатель не хочет слушать, что я не знаю, почему (( Править исходники Delphi квалификация не позволяет, да и слишком темная магия там ... Репутация сложилась, однако. С Сиэтла, наконец, программы перестали просто падать, а репу-то уже трудно поправить. Ну вот я сумел практически шантажом и обманом выкатить один проект на делфи в релиз. Но больше пока никто не соглашается выплатить мне 150000 для покупки апгрейда...

Все было бы намного лучше, если бы использовалась родная канва платформы, поддерживающая Clipping, как это происходит на Windows и MacOS, но на мобилах используется тормозная TGPUCanvas, которая ко всему прочему еще и без сглаживания рисует.

Берлину нужен XCode 8. С 8.1 у вас просто не подтягивается список устройств симулятора. Любому берлину, начиная от просто и заканчивая Upd2. Можно поставить 8.0 рядом с 8.1, зайти в XCode - Preferences - Locations и в Command Line Tools выбрать XCode 8.0. После этого - перезапустить PAServer, в Delphi подтянуть новые SDK и обновить список устройств в TargetPlatforms для симулятора

Всем спасибо большое за тесты и советы. Частично проблему решил - "причесал" код, удалил неиспользуемые переменные и теперь вроде на других устройствах заработало. Еще были жалобы на неактивные edit'ы, Родительским объектам присвоил значение свойства Locked в True и проблема решилась. Тему прошу пока не закрывать, пока приложение на бета тестировании.

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

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

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

1C-RARUS в качестве кейса. МРК - мобильное рабочее место кассира. С кучей периферии (POS-терминал, ВТ-сканнер, фискальник) - я обзор сделал на CodeRage XI. По-русски тоже напишу. И только не надо тут писать, что 1С - это гуано. Каким бы то ни было ядро, мобильный клиент выполнен в работоспособном качестве, на FMX и (!) кроссплатформенно. Т.е. именно две портации реально существуют. Kitty - вопрос по TurboCocoa и С++Builder. Пока - нет. Ждём первой волны Дельфийцев, которые не могут пользоваться FMX, но готовы продолжать использовать Дельфи и для мобильной разработки. По-поводу "ничего путного не сделали на Дельфи". Вот тут точно - вопрос не к Эмбаркадеро, а к разработчикам. Я (работая в Эмбаркадеро) огрёб кучу "позитива" от Виталия Кривякова - как раз разработчика мобильного клиента МРК. И я по пальцам могу пересчитать людей (в рунете), которые пробовали что-то делать мобильное. Соответственно, вопрос к Дельфистам. Сели на VCL и занимаются "поддержкой legacy-кода" до бесконечности в статусе "придворного программиста". Как-то лень начинать новый проект, проталкивать его через начальство, разбираться в FMX, гораздо проще сесть на привычное место, скривиться и сказать "вон кады Э сделает мне FMX как VCL для всех платформ одновременно с автоматической загрузкой мне 10 000 баков на счёт от одной публикации приложения в магазине, тогда ещё подумаю...". Или грант безвозмездный даст на разработку. Так что, коллеги, взгляд надо и на себя обращать. Хотя бы из уважения (к сожалению) бывшим отечественным разработчикам Delphi и FMX.

Коллеги, Приглашаю всех прийти на ближайший вебинар по RAD Studio 10.1 Berlin Update 2 и задать там вопросы. Я оставлю больше времени для ответов, и мы сможем обсудить более подробно большинство из поднятых здесь тем.

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

ListView1.Items[0].Text := 'Сменим текст для Itema под индексом 0'; В ListView нельзя скрывать отдельные Item'ы

Здравствуйте. Есть один вариант с использованием TBitmapListAnimation: Кидаем обычный TImage на форму. Под TImage создаём TBitmapListAnimation. Структура должна выглядеть так: В свойствах TBitmapListAnimation: AnimationBitmap - загружаем ленту картинок. Например: Для коротких Gif -ок можно использовать онлайн конверторы: http://ezgif.com/split - разделение Gif на отдельные фреймы (картинки) http://www.photojoiner.net/merge-photos/editor/# - соединение нескольких картинок в одну (соединяет до 8 штук) AnimationCount - сколько раздельных картинок в нашей объеденённой по горизонтали (в нашем слечае 8) AnimationRowCount - сколько рядов в нашей картинке (в нашем случае 1) Enabled = True Duration - указываем промежуток времени, которое должна занимать гифка (в секундах). PropertyName - прописываем Bitmap