Comments 17
В целом Qt можно было бы рекомендовать как вещь в себе — только готовые модули самого фреймворка плюс платформонезависимые библиотеки на C++. Но в реальных проектах его использовать будет очень непросто — неродной UI, отсутствуют сторонние компоненты (только библиотеки “из коробки”), возникают сложности при сборке и отладке приложения, а также при доступе к нативной функциональности. Из плюсов — высокая производительность кода на C++.Не, ну это несерьезно:
- Неродной UI — получаем тот же Look and Feel, но быстрее! На винде Alien-виджеты работают намного быстрее честных виндовых окошек.
- отсутствуют сторонние компоненты (только библиотеки “из коробки”) — в Qt из коробки есть не только лишь все… Серьезно, Qt обычно только за это и ругают, что он тяжелый, потому как там реально все есть.
- возникают сложности при сборке и отладке приложения — какие? Я с одной машины могу под все платформы Qt собрать, да еще и свое мобильное приложение под Desktop'ом покрутить в окошке
- сложности также при доступе к нативной функциональности — тут да, однако C++ могучий, с ним до куда угодно можно дотянуться, без всяких PInvoke'ов
Qt очень хорош, хотя и действительно нужна квалификация разрабов.
Все зависит от специфики проекта, конечно. Из моего опыта работы с Qt (более 5 лет для desktop, maemo, symbian, windows mobile и embedded):
Так UI все равно не родной, а для получения нужного Look'n'Feel (стандартные анимации и поведение элементов) потеть приходится очень усердно для каждой платформы.
Современный mobile это в первую очередь работа со сторонними библиотеками ;) В Qt очень ограниченный доступ к нативке, только через свои обертки.
Отладка и тестирование реальных приложений на реальных устройствах с полной функциональностью. Десктоп-версия далеко не весь функционал позволяет посмотреть, но судя по всему вы пока с этим не сталкивались.
К Java и Objective C дотянуться ой как непросто ;) В реальных проектах, конечно же.
Но это все мое IMHO, основанное на моем опыте работы с большим количеством реальных мобильных проектов.
Неродной UI — получаем тот же Look and Feel, но быстрее! На винде Alien-виджеты работают намного быстрее честных виндовых окошек.
Так UI все равно не родной, а для получения нужного Look'n'Feel (стандартные анимации и поведение элементов) потеть приходится очень усердно для каждой платформы.
отсутствуют сторонние компоненты (только библиотеки “из коробки”) — в Qt из коробки есть не только лишь все… Серьезно, Qt обычно только за это и ругают, что он тяжелый, потому как там реально все есть.
Современный mobile это в первую очередь работа со сторонними библиотеками ;) В Qt очень ограниченный доступ к нативке, только через свои обертки.
возникают сложности при сборке и отладке приложения — какие? Я с одной машины могу под все платформы Qt собрать, да еще и свое мобильное приложение под Desktop'ом покрутить в окошке
Отладка и тестирование реальных приложений на реальных устройствах с полной функциональностью. Десктоп-версия далеко не весь функционал позволяет посмотреть, но судя по всему вы пока с этим не сталкивались.
сложности также при доступе к нативной функциональности — тут да, однако C++ могучий, с ним до куда угодно можно дотянуться, без всяких PInvoke'ов
К Java и Objective C дотянуться ой как непросто ;) В реальных проектах, конечно же.
Но это все мое IMHO, основанное на моем опыте работы с большим количеством реальных мобильных проектов.
Современный mobile это в первую очередь работа со сторонними библиотеками ;) В Qt очень ограниченный доступ к нативке, только через свои обертки.
Можно пояснить, к каким сторонним библиотекам я не могу динамически слинковаться или сделать dlopen с extern c? Для этого необязательно совсем использовать Qt Interface, хотя и можно. Разница вся будет только в том, что в первом случае всю работу по работе с библиотеками делает сам пользователь, а во втором — Qt, зная свои метаданные и интерфейс, к которому, благодаря метаданным, QPlugin или другой модуль будет делать qobject_cast.
Ну, или я все не так понял?
Блог компании майкрософт же — понятно дело тут будут рекламировать не Qt.
Да ладно вам ;) Я большой фанат Qt и очень любил работать с ним, однако для iOS/Android/Windows UWP он просто не подходит в реальных проектах
Да и я как бе шарпист и за мелкомягких т. е. aps/wpf/xmarin/uwp. Просто не люблю когда такие сравнения проводят просто ряди рекламы своего продукта.
Вы о чем? Везде ищите заговор зеленых массонов с планеты Нибиру?
Продуктом нашей компании Binwell являются услуги по заказной разработке ПО с использованием кроссплатформенных инструментов (сейчас Xamarin). Эти услуги мы и рекламируем такием ветиеватым образом — за годы работы дико достали невежды кричащие «ненативно» и не понимающие как что работает. В России с низкой общей культурой промышленной разработки ПО это стало просто каким-то звиздецом.
Если вы считаете, что я необъективно оценил возможности Qt (имея опыт, сертификаты и статусы), то готов принять вашу позицию и внести нужные правки в статью или руководство.
Продуктом нашей компании Binwell являются услуги по заказной разработке ПО с использованием кроссплатформенных инструментов (сейчас Xamarin). Эти услуги мы и рекламируем такием ветиеватым образом — за годы работы дико достали невежды кричащие «ненативно» и не понимающие как что работает. В России с низкой общей культурой промышленной разработки ПО это стало просто каким-то звиздецом.
Если вы считаете, что я необъективно оценил возможности Qt (имея опыт, сертификаты и статусы), то готов принять вашу позицию и внести нужные правки в статью или руководство.
Спасибо за статьи! При всей любви к Xamarin, стал все чаще заглядываться на React Native. В продакшн пока все равно его страшно правда. Хотя для веба в последнее время всё на Vue/Nuxt, хорошо было бы юзать Weex, но он там вовсе в зачаточном состоянии.
Так что альтернатив Xamarin (скорее даже Forms) всё еще не вижу… нативно, в основе достаточно примитивно, и вполне продуктивно.
Так что альтернатив Xamarin (скорее даже Forms) всё еще не вижу… нативно, в основе достаточно примитивно, и вполне продуктивно.
Фигня этот Реакт Натив.
Изначально в компании решили сэкономить, поэтому было принято взять React Native, чтобы написать одно приложение под все устройства, и вообще все красиво и ровно. Приложение достаточно большое и сложное, которое подтягивало куча всего.
В итоге, через год борьбы с тем, что «в общем, все работает», но частности на каких-то пограничных ситуациях и весьма сомнительных китайских девайсах, все отваливается и не работает, либо адски тупит.
Мы в пошли на встречу нашим кастомерам и мольбам технической поддержки, и переписали под дваву и свифт для каждой платформы. Косяки определенные остались, конечно, но работает в разы стабильнее.
Изначально в компании решили сэкономить, поэтому было принято взять React Native, чтобы написать одно приложение под все устройства, и вообще все красиво и ровно. Приложение достаточно большое и сложное, которое подтягивало куча всего.
В итоге, через год борьбы с тем, что «в общем, все работает», но частности на каких-то пограничных ситуациях и весьма сомнительных китайских девайсах, все отваливается и не работает, либо адски тупит.
Мы в пошли на встречу нашим кастомерам и мольбам технической поддержки, и переписали под дваву и свифт для каждой платформы. Косяки определенные остались, конечно, но работает в разы стабильнее.
Вот и я того же опасаюсь. С хамарином я публиковал (Forms-)приложения с реально небольшими переделками и в аппстор, и в гуглплэй (причем контролы все нативные). Стабильность росла с уровнем выпрямления моих рук по мере нарастания опыта с Хамарин и его, кстати, стабилизацией тоже. А глядя на тот как реакт ломает обратную совместимость с каждой версией… пока что «да ну». Хотя JS/ES6 я предпочитаю шарпу, но тут не тот случай.
Спасибо за обзор!
Такой вопрос.
Есть ли на Qt проработанная, законченная, известная архитектурная модель построения приложения под Android (и, возможно, iOS), при которой возможно было бы запускать приложение одновременно как с пользовательским интерфейсом (Активити), так без него (Сервис)?
Или, другими словами, чтобы одна часть приложения загружалась с пользовательским интерфейсом, которую можно будет, например, позже закрыть (или эта часть будет позже «прибита» системой), а другая часть приложения параллельно загружалась бы как сервис?
Понятно, что можно сделать приложение отдельно с пользовательским интерфейсом, а отдельно — как сервис. Т.е. два отдельных приложения. А, вот, чтобы это всё в одном приложении жило, есть ли какие методики под Android на Qt (и, возможно, iOS)?
Может, знаете какие-нибудь ссылки на открытые проекты с похожей архитектурой, или на описание её в блогах гуру Qt?
Такой вопрос.
Есть ли на Qt проработанная, законченная, известная архитектурная модель построения приложения под Android (и, возможно, iOS), при которой возможно было бы запускать приложение одновременно как с пользовательским интерфейсом (Активити), так без него (Сервис)?
Или, другими словами, чтобы одна часть приложения загружалась с пользовательским интерфейсом, которую можно будет, например, позже закрыть (или эта часть будет позже «прибита» системой), а другая часть приложения параллельно загружалась бы как сервис?
Понятно, что можно сделать приложение отдельно с пользовательским интерфейсом, а отдельно — как сервис. Т.е. два отдельных приложения. А, вот, чтобы это всё в одном приложении жило, есть ли какие методики под Android на Qt (и, возможно, iOS)?
Может, знаете какие-нибудь ссылки на открытые проекты с похожей архитектурой, или на описание её в блогах гуру Qt?
По Qt могу только дать рекомендацию — либо используйте только Qt как вещь в себе (например, для простых игр или небольших развлекательных приложений), либо не используйте его на iOS/Android/Windows UWP. Все остальное — скользкий и нестандартный путь, по которому если кто и ходит, то о своих результатах пишет большое количество негатива на форумах. Просто нет ценной информации в публичном доступе, особенно по вопросам такого уровня как архитектуры и паттерны. И причина проста — никто не ходит этим путем. Любой фреймворк это всего лишь инструмент. Для разного класса задач подходят разные инструменты.
Вообще тема Qt на iOS и Android очень очень очень плохо раскрыта. При подготовке обзора пришлось ковыряться в исходниках Qt, чтобы лучше понять как оно работает на каждой платформе.
Вообще тема Qt на iOS и Android очень очень очень плохо раскрыта. При подготовке обзора пришлось ковыряться в исходниках Qt, чтобы лучше понять как оно работает на каждой платформе.
Мне кажется в этой серии статей Xamarin немного превознесён над остальными. Надеюсь мой опыт поможет сомневающимся. Я долго искал кроссплатформенный инструмент разработки моб. приложений для команды, прочитал много аналитики и работал с Cordova, Xamarin.Forms, ReactNative длительное время. В итоге сделал выбор в пользу последнего.
В Cordova слишком много кейсов, при которых начинаются тормоза, тяжело выстроить правильную архитектуру приложения.
В Xamarin.Forms очень много времени отнимали непредвиденные баги контролов, баги компиляции, проблемы с библиотеками. Даже имея почти год опыта использования Xamarin.Forms периодически наталкивался на странные ошибки, связанные с ошибками в Mono, на решение которых уходила уйма времени. Другие минусы: долгая компиляция, неочевидное поведение контейнеров, работа с изображениями, многословность описания интерфейса. Из плюсов — действительно почти нативная скорость, строгая архитектура приложения, хорошие возможности к абстрагированию кода благодаря C#.
Скорость разработки на ReactNative гораздо выше чем на Xamarin.Forms, компилировать не надо, можно использовать Hot Reloading, который обновляет интерфейс сразу после изменения кода, без перезагрузки страницы. Интерфейсы описываются коротко и интуитивно понятно. В целом интерфейс описывается как в вебе, с упором на flexbox. Контроль за состоянием приложения гораздо лучше чем в Xamarin, особенно с использованием Redux/Mobx, следовательно и отладка гораздо проще. Минусы: слишком много библиотек решающих одну и ту же проблему, иногда тяжело выбрать, а если нет нужной, придётся писать свою на нативных языках под каждую платформу(хотя мне ещё не приходилось, всегда находил нужную). Кроме того, большие списки иногда тормозят, но в целом производительность примерно как у Xamarin, в каких-то тестах он даже обходит Swift, но не думаю что можно им слепо верить.
В целом Xamarin.Forms и ReactNative можно использовать в продакшене и для больших приложений. Xamarin имеет хорошую задумку, но до сих пор, спустя столько времени, слишком сырой. ReactNative несмотря на версию 0.49 гораздо стабильнее чем Xamarin и практически во всём выигрывает.
В Cordova слишком много кейсов, при которых начинаются тормоза, тяжело выстроить правильную архитектуру приложения.
В Xamarin.Forms очень много времени отнимали непредвиденные баги контролов, баги компиляции, проблемы с библиотеками. Даже имея почти год опыта использования Xamarin.Forms периодически наталкивался на странные ошибки, связанные с ошибками в Mono, на решение которых уходила уйма времени. Другие минусы: долгая компиляция, неочевидное поведение контейнеров, работа с изображениями, многословность описания интерфейса. Из плюсов — действительно почти нативная скорость, строгая архитектура приложения, хорошие возможности к абстрагированию кода благодаря C#.
Скорость разработки на ReactNative гораздо выше чем на Xamarin.Forms, компилировать не надо, можно использовать Hot Reloading, который обновляет интерфейс сразу после изменения кода, без перезагрузки страницы. Интерфейсы описываются коротко и интуитивно понятно. В целом интерфейс описывается как в вебе, с упором на flexbox. Контроль за состоянием приложения гораздо лучше чем в Xamarin, особенно с использованием Redux/Mobx, следовательно и отладка гораздо проще. Минусы: слишком много библиотек решающих одну и ту же проблему, иногда тяжело выбрать, а если нет нужной, придётся писать свою на нативных языках под каждую платформу(хотя мне ещё не приходилось, всегда находил нужную). Кроме того, большие списки иногда тормозят, но в целом производительность примерно как у Xamarin, в каких-то тестах он даже обходит Swift, но не думаю что можно им слепо верить.
В целом Xamarin.Forms и ReactNative можно использовать в продакшене и для больших приложений. Xamarin имеет хорошую задумку, но до сих пор, спустя столько времени, слишком сырой. ReactNative несмотря на версию 0.49 гораздо стабильнее чем Xamarin и практически во всём выигрывает.
Полностью согласен по поводу производительности программистов на ReactNative — когда все созреет, то будет быстро. Но и по Xamarin.Forms тоже есть подходы, когда уникального кода (отдельные экраны и фоновые сервисы, работа с данными) получается немного и как следствие основное время уходит на UI.
Скоро выложим пример лаконичного кода на XF вместе с новым руководством ;)
Скоро выложим пример лаконичного кода на XF вместе с новым руководством ;)
Добавлю немного своих пару копеек… Очень давно занимаюсь андройдом (с версии 1.6), с Qt работал в общей сложности примерно 2 года. По этой причине ясень пень Qt на андройд пилить глупо, т.к. андройд сам по себе куда приятнее и удобнее в плане имеющихся инструментов. На С# тоже приходлось работать, с WPF.
На Qt приходилось всякое делать, начиная от приложения с прорисовкой большой 2D сцены на OpenGL с полупрозрачными виджетами поверх, полностью кастомно отрисованный, заканчивая последними опытами по поднятию с колен говнокод проекта… У Qt есть множество проблем в Ui части, например большинство вьюх вообще не живут с большими объемами данных. Как раз при поднятии с колен пришлось например полностью заимплементить логику по сортировке с сохранением стейтов айтемов в QTreeView… т.к. нативная для Qt QProxySortModel при количестве айтемов с 3мя и более нулями тупо умирает вместо со всей вьюхой унося с собой на дно весь Main Thread. Радости это приносит мало, по большей части боль в области соприкасающейся с плоскими поверхностями при работе…
На Qt приходилось всякое делать, начиная от приложения с прорисовкой большой 2D сцены на OpenGL с полупрозрачными виджетами поверх, полностью кастомно отрисованный, заканчивая последними опытами по поднятию с колен говнокод проекта… У Qt есть множество проблем в Ui части, например большинство вьюх вообще не живут с большими объемами данных. Как раз при поднятии с колен пришлось например полностью заимплементить логику по сортировке с сохранением стейтов айтемов в QTreeView… т.к. нативная для Qt QProxySortModel при количестве айтемов с 3мя и более нулями тупо умирает вместо со всей вьюхой унося с собой на дно весь Main Thread. Радости это приносит мало, по большей части боль в области соприкасающейся с плоскими поверхностями при работе…
Со своей стороны хочу добавить про то, что сейчас Qt — это больше QML, нежели C++. Конечно, с мобильными платформами все посложнее будет, но ситуация постепенно улучшается. Я все же надеюсь на появление библиотек нормального качества для работы с API мобильных платформ. А то прокидывать, например, все через JNI — то еще удовольствие.
Что мне нравится в QML, так это внятная декларативность. А в случае, когда декларативности не хватает — можешь писать на JavaScript. И то и другое может освоить даже дизайнер. Таким образом, можно иметь одного опытного чувака, который будет работать на C++ glue и предоставлять все нужное для QML. А в QML могут работать люди, которые знакомы с JS, или даже дизайнеры. Например подкрутить анимации или накидать экран — реально просто.
На счет подгона под Look&Feel платформы — все так. Это может быть та еще боль и страдания. Один скролл чего стоит.
Что мне нравится в QML, так это внятная декларативность. А в случае, когда декларативности не хватает — можешь писать на JavaScript. И то и другое может освоить даже дизайнер. Таким образом, можно иметь одного опытного чувака, который будет работать на C++ glue и предоставлять все нужное для QML. А в QML могут работать люди, которые знакомы с JS, или даже дизайнеры. Например подкрутить анимации или накидать экран — реально просто.
На счет подгона под Look&Feel платформы — все так. Это может быть та еще боль и страдания. Один скролл чего стоит.
Sign up to leave a comment.
Архитектуры ReactNative, Xamarin, PhoneGap и Qt. Часть 2