Уточнил у издателя. Электронную версию можно купить на сайте ДМК Пресс (ссылки в статье), в комментариях к заказу достаточно написать, что нужна электронная книга.
Получил ответ от издателя: PDF можно купить на сайте https://dmkpress.com. Но для этого надо в комментарии к заказу написать, что нужна эл. версия, и в ручном режиме операторы вышлют ссылку на PDF. По ценам PDF пока не знаю, сколько это будет. Скоро электронная версия также будет доступа на ЛитРес.
Avalonia выглядит неплохо на бумаге, но на практике там очень мало готовых компонентов/библиотек, что пока не позволяет говорить о реальном использовании — постоянно надо переизобретать велосипед. За Avalonia стоит относительно небольшое сообщество разработчиков, а за Xamarin — довольно большой штат профессионалов из Microsoft.
Ведь вопрос же не в инструменте, а в команде, которая этим инструментом умеет пользоваться. Так что «занозой» что-то может быть только в том случае, если оно используется не по назначения или неопытной командой.
Честно говоря, не ковырял устройство flutter, но по первому впечатлению — это верхеуровневый фреймворк (Qt низкоуровневый), работающий поверх верхеуровневых системных API для Objective C и Java. Но целом да, проблемы будут примерно те же, что с Qt/QML, но только без танцев с wrappers при доступе к нативке. Скорее всего flutter получит свою нишу для несложных информационных проектов.
Я правильно понимаю, что вас в статье напряг момент о том, что можно с меньше или большей интенсивностью взаимодействовать с платформой через мост? То есть о том, что есть большой класс задач, которые могут быть выполенены без взаимодействия с нативкой? Парсинг, хранение и обработка данных, бизнес-логика поведения приложения (viewmodels/controllers, плюс сервисы). Это именно то, что не требует постоянной (по каждому чиху) интеграции с нативкой и живет себе комфортно в виртуальной среде, лишь изредка дергая нужные методы из операционной системы.
Или это ваши общие доводы в пользу того, что кроссплатформа должна умереть, ибо это «тормоза и костыли»? Плюс вы почему-то сваливаете в кучу все кроссплатформенные инструменты и приравниваете провал Facebook с HTML5 с проектами на Xamarin или ReactNative.
А причем здесь кроссплатформенные инструменты? У них свои бизнес-задачи и своя доля рынка. Это не 100% замена стандартных инструментов от самих владельцев экосистем
> При этом очень много разных элементов интерфейса нужно перерисовать, предварительно рассчитав новые позиции и размеры, а так же подтянув необходимые для отображения данные.
Это все обычно за вас делает ОС, а не ваш код, не важно на каком языке. Если конечно вы свои методы отрисовки и обработки скролла сделали… То это ваши проблемы.
> Ага, я прям вспоминаю старое приложение фейсбука и рекомендации по использованию браузера вместо него.
Если вы следили за развитием событий, то приложение фейсбук было сделано на HTML5 и потом сам Цукерберг признал это ошибкой.
Так в чем ваш вопрос? Я только понял, что реальной разработкой мобильных приложений, тем более кроссплатформенной, вы не занимались.
> Вот только у меня такой вопрос к статье: а что это у вас за мобильное приложение, которое мало использует этот мост?
Обычные приложения ;) Вы хоть раз писали реальные кроссплатформенные программы?
Открою вам маленький секрет. В реальных сценариях приложение ЖДЕТ и НИЧЕГО НЕ ДЕЛАЕТ основную часть времени, эпизодически реагируя на действия пользователя. И вот в этих эпизодах иногда возникает потребность обратиться к платформе — только здесь задействуется мост. И только здесь может чуть-чуть больше задействоваться процессор и как следствие батарейка. А игры тут вообще при чем? ;)
А почему его необходимо рассматривать? Он пока сырой и не пригоден к реальным проектам, в отличие от рассмотренных в статье фреймворков. Оно даже ReactNative тоже сыроват еще.
182 мс это не «5 кадров в секунду» (откуда вообще fps взялись?), а просто 182 мс (~1/5 секунды) задержки перед открытием экрана или первого в приложении создания контрола — дальше все кешируется. Перфекционизм это хорошо, конечно :)
В плане роста и развития — да, в XF еще много всякого будет дорабатываться и улучшаться.
Вы о чем? Везде ищите заговор зеленых массонов с планеты Нибиру?
Продуктом нашей компании Binwell являются услуги по заказной разработке ПО с использованием кроссплатформенных инструментов (сейчас Xamarin). Эти услуги мы и рекламируем такием ветиеватым образом — за годы работы дико достали невежды кричащие «ненативно» и не понимающие как что работает. В России с низкой общей культурой промышленной разработки ПО это стало просто каким-то звиздецом.
Если вы считаете, что я необъективно оценил возможности Qt (имея опыт, сертификаты и статусы), то готов принять вашу позицию и внести нужные правки в статью или руководство.
Полностью согласен по поводу производительности программистов на ReactNative — когда все созреет, то будет быстро. Но и по Xamarin.Forms тоже есть подходы, когда уникального кода (отдельные экраны и фоновые сервисы, работа с данными) получается немного и как следствие основное время уходит на UI.
Скоро выложим пример лаконичного кода на XF вместе с новым руководством ;)
По Qt могу только дать рекомендацию — либо используйте только Qt как вещь в себе (например, для простых игр или небольших развлекательных приложений), либо не используйте его на iOS/Android/Windows UWP. Все остальное — скользкий и нестандартный путь, по которому если кто и ходит, то о своих результатах пишет большое количество негатива на форумах. Просто нет ценной информации в публичном доступе, особенно по вопросам такого уровня как архитектуры и паттерны. И причина проста — никто не ходит этим путем. Любой фреймворк это всего лишь инструмент. Для разного класса задач подходят разные инструменты.
Вообще тема Qt на iOS и Android очень очень очень плохо раскрыта. При подготовке обзора пришлось ковыряться в исходниках Qt, чтобы лучше понять как оно работает на каждой платформе.
Уточнил у издателя. Электронную версию можно купить на сайте ДМК Пресс (ссылки в статье), в комментариях к заказу достаточно написать, что нужна электронная книга.
Все книги должны позже появиться на ЛитРес в электронном виде
Кстати, POSIX и в Windows есть (сам не проверял, но тема старая): en.wikipedia.org/wiki/Windows_Services_for_UNIX
Или это ваши общие доводы в пользу того, что кроссплатформа должна умереть, ибо это «тормоза и костыли»? Плюс вы почему-то сваливаете в кучу все кроссплатформенные инструменты и приравниваете провал Facebook с HTML5 с проектами на Xamarin или ReactNative.
> При этом очень много разных элементов интерфейса нужно перерисовать, предварительно рассчитав новые позиции и размеры, а так же подтянув необходимые для отображения данные.
Это все обычно за вас делает ОС, а не ваш код, не важно на каком языке. Если конечно вы свои методы отрисовки и обработки скролла сделали… То это ваши проблемы.
> Ага, я прям вспоминаю старое приложение фейсбука и рекомендации по использованию браузера вместо него.
Если вы следили за развитием событий, то приложение фейсбук было сделано на HTML5 и потом сам Цукерберг признал это ошибкой.
Так в чем ваш вопрос? Я только понял, что реальной разработкой мобильных приложений, тем более кроссплатформенной, вы не занимались.
> Вот только у меня такой вопрос к статье: а что это у вас за мобильное приложение, которое мало использует этот мост?
Обычные приложения ;) Вы хоть раз писали реальные кроссплатформенные программы?
Открою вам маленький секрет. В реальных сценариях приложение ЖДЕТ и НИЧЕГО НЕ ДЕЛАЕТ основную часть времени, эпизодически реагируя на действия пользователя. И вот в этих эпизодах иногда возникает потребность обратиться к платформе — только здесь задействуется мост. И только здесь может чуть-чуть больше задействоваться процессор и как следствие батарейка. А игры тут вообще при чем? ;)
Статья не про MFC, а про Xamarin.Forms :)
В плане роста и развития — да, в XF еще много всякого будет дорабатываться и улучшаться.
Продуктом нашей компании Binwell являются услуги по заказной разработке ПО с использованием кроссплатформенных инструментов (сейчас Xamarin). Эти услуги мы и рекламируем такием ветиеватым образом — за годы работы дико достали невежды кричащие «ненативно» и не понимающие как что работает. В России с низкой общей культурой промышленной разработки ПО это стало просто каким-то звиздецом.
Если вы считаете, что я необъективно оценил возможности Qt (имея опыт, сертификаты и статусы), то готов принять вашу позицию и внести нужные правки в статью или руководство.
Скоро выложим пример лаконичного кода на XF вместе с новым руководством ;)
Вообще тема Qt на iOS и Android очень очень очень плохо раскрыта. При подготовке обзора пришлось ковыряться в исходниках Qt, чтобы лучше понять как оно работает на каждой платформе.