Пописываю, на досуге, подобный фреймворк (полностью нативный, без каких-либо VM)... Хочется узнать, чего людям не хватает.
С какими трудностями сталкиваетесь?
Производительность?
Наличие библиотек?
Простота подключения (или написания) нативных библиотек?
Простота установки\настройки среды разработки?
Если бы появился еще один фреймворк, какая киллер-фича заставила бы вас его попробовать?
можна забути про всі ці фрейворки. гугл давно уже зробив flutter.dev. там є і Андроїд, айос, веб, десктоп.
Warning: The flutter tool uses Google Analytics to anonymously report feature usage statistics and basic crash reports. This data is used to help improve Flutter tools over time.
To disable reporting, type flutter config —no-analytics
За замовчуванням включена аналітика, яку треба відключати
Ребята, а просветите — разработка на Qt под мобильные приложения — это нативная разработка, или там какие-то внутренние VM используются для трансляции в нативный код?
Без VM. Разве что QML в рантайме интерпретируется (наверное).
Но у Qt свои контролы, своя отрисовка и вообще все свое. Вроде как можно и «нативные» контролы использовать, но это добавляет кучу лишней работы и выхлоп от такой кроссплатформенности сомнительный, имхо.
киллер-фича
Відсутність «write once run everywhere» ж) Гнучкість у тому, що буде відрізнятись на платформах, а що буде спільне. Написане від тих і для тих, хто робить два окремих додатка для іоs та андроіда без використання подібних кроссплатформених бібліотек. Плагіни — це всюди біль.
Я не в мобілах вже, але склалось таке враження від них.
Реально ли model layer настолько большой в типичном мобильном приложении для что бы выносить это в общий модуль?
Как я это вижу: вместо того что-бы найти одного Android разработчика который глубоко знает Java/Kotlin и ADK, и iOS разработчика который глубоко знает Objective-C/Swift и CocoaTouch, вы предлагаете брать «мастеров на все руки», неужели не возникает в итоге проблем в разработке из-за этого?
It depends, как говорится. Ведь с другой стороны, если мы говорим про простое приложение, где общей логики практически нет, то достаточно одного знатока «на все руки», чтобы написать все на кроссплатформенном фреймворке, вместо двоих нативщиков. В такой ситуации — это часто проще поддерживать, быстрее разрабатывать. В таких проектах, как раз таки, особо нету обо что спотыкаться и кроссплатформенные решения тут справляются довольно неплохо.
Есть брать Xamarin, то как раз нужно знать особенности и Android и iOS на уровне нативщиков.
Вот если брать React Native, Cordova, Ionic то будет настоящая кроссплатформенность для простых приложений.
Верно подмечено, я это и имел ввиду. React Native справляется.
А Xamarin имеет место, если нативщикам нужна общая кодовая база. То есть тут получается все-равно нужны двое нативщиков. Но вопрос в другом, что команде проще: писать на одном языке и расшаривать логику (сособенно если еще и сервер на C#), или же писать всю логику два раза, допуская при этом, потецниально, больше багов.
Как по мне, в дискуссии ниже, Viktor Sinelnikov верно подметил, что это, скорее всего, дело вкуса.
Excelsior JET, J2ObjC решают эту-же проблему, но без
сособенно если еще и сервер на C#
Шутка про .Net Remoting.
Ведь с другой стороны, если мы говорим про простое приложение
Если речь идёт о простом приложении, то вообще нет никакого смысла в фреймвёрках, работающих с ОС. Лучше писать под браузер на js, там есть все возможности, и работать будет на всех платформах. Безсерверное приложение тоже можно написать с UI под HTML. Например, путём создания IWebBrowser2, и открытия там странички. Можно ещё сделать UI под Sciter, заюзать движок Хромиум, и другие способы. Взаимодействовать можно через REST api, или через веб-сокеты, либо в некоторых случаях напрямую с DOM. Графику можно отрисовывать через WebGL, что ещё?
Это да, Cordova не особо хороша. Но уже появились Progressive Web Apps, если писать что-то простое, помоему, это самый лучший вариант.
слой view model еще, пишите так же общий и из платформенных вещей только верстка и привязывание данных. Да спасает, если есть кеширование и сложная бизнесс логика — очень спасает
Насчет углубления в платформы я полностью согласен. Но этими же вещами пришлось бы заниматься, если бы нужно было писать два раздельных приложения, отдельно iOS, отдельно Android. А так, выходит, можно хоть что-то свести к общей кодовой базе: какое-то кэширование, работу с базой данных, загрузку контента извне и тд.
Думаю, что, в большинстве случаев, общая кодовая база вполне может быть сведена до
Хороший вопрос. У меня встречный: почему, в таком случае, не Xamarin? Там ведь можно писать раздельно (насколько я понимаю, практически идентично обычной нативной разработке) и, как минимум, реализация будет на одном языке, что упрощает коммуникацию команды.
Если бы появился еще один фреймворк, какая киллер-фича заставила бы вас его попробовать?
Хотите знать, какая киллер-фича заставит перейти всех на ваш фреймвёрк? Какая 100% сработает, однозначно, без вариантов? Киллер-фича, которая заткнёт за пояс все остальные фреймвёрки? Ну так вот. Это поддержка вашего фреймвёрка со стороны по крайней мере 3 гигантов: Google, Microsoft и Apple. И что никаких других киллер-фич разве нет? Все остальные киллер-фичи в конечном счёте сводятся к ковырянию в носу пальцем.
Ну, без самого фреймворка и чего-то интересного в его функционале ни о какой поддержке речи идти не может. И потом, может его и купит кто-то из гигантов, who knows :)
А кто что скажет про Ionic и Apache Cordova?
А я не жду никакого универсального кроссплатформенного мобильного «фреймворка». Я просто жду когда iOS наконец здохнет.
С чего вы взяли?) Просто я фрилансер и мне надоело что всем надо сразу поддержку двух платформ — Android и iOS. Мне было бы удобнее писать только под одну и если выбирать из этих двух, то это пожалуй Андроид — более открытый, меньше контроля и анальных зондов (сравнительно) от «родительской» корпорации, ну и так по мелочам. Вот эти вот кроссплатформенные «фреймворки» не предлагать — скоко я их перепробовал, все с нативной разработкой и рядом не стояло (и не может стоять в принципе, как авторы это не поймут).
Ну вот любопытства ради — в том же Xamarin ты работаешь с тем же самым API мобильной ОС, только язык программирования другой и есть прослойка в виде Mono.
Чего нельзя такого сделать на Xamarin, что можно сделать нативно?
Поддержку Android instant app 100% нельзя. (Первое что пришло в голову человеку, ничего не знающего о Xamarin)
Интересно. Я еще не пробовал их, но не вижу пока преград для своего фреймворка в этом вопросе. Будет, значит, одной из киллерфич )
В том то и дело, что вроде как все можно, но на деле везде мелкие «но»... То апи для платформы самый новый не завезли, то фичи(платформ а не аппы) на разных платформах так отличаются, что разницы нет — писать две аппы сразу либо одну «кроссплатформенную», но по факту с двумя версиями кода под обе платформы. И почти везде надо искать тонны «плагинов» написанных сторонними индусами сомнительного качества, либо лезть в те самые нативные апи платформ. А еще производительность и размер приложения — да, да тоже играет роль. И в итоге этих мелких «но» накапливается целая лавина, которая нивелирует вообще какую либо пользу от такой кроссплатформенной разработки.
Правда это все в основном касается прикладных мобильных апп где много взаимодействия с пользователем и платформеннозависимых нюансов — игры писать на кроссплатформенных движках еще вполне норм как по мне.
А что именно не устраивает в фреймворках по сравнению с нативной разработкой? Более слабый контроль каких-то системных, нативных функций?
См мой комментарий для Dmytro Lapshyn
Проблема не в том что 2е платформы, а в жадных заказчиках и разработчиках что на это соглашаются.
Допустим завтра будет только одна мобильная платформа.
Так заказчик на фоне этого будет просить сделать мобильное приложение + сайт(бекенд) и дизайн нарисовать(мол зачем дизайнер, тут просто), как в 2000х на местном рынке.
Ну это отдельная проблема. И скажу сразу — она на данном этапе развития нашей цивилизации нерешаема) Всегда найдутся «заказчики»-мечтатели со $100 в кармане и амбициями как у Илона Маска, и всегда найдутся бедные индусы/украинцы которым надо семью кормить уже сегодня, а не ждать потенциального заказа от нефтяного магната завтра.
А ну и еще разработчиков сейчас стало действительно слишком много, но про это на прекрасном.it отлично написано
у Qt нет недостатков ;-)
Так и запишем :)
Однако, минус там — это, как ни странно, С++. Порог вхождения для ньюфагов высокий. Более сложное, чем у остальных фреймворков прикручивание сторонних либ.
Очень мало встречаю мобльной разработки на Qt. Хотя, может это мне только так кажется.
эээ
для ньюфаков придумали QML
прикручивание сторонних либ не простое, а очень простое — как и везде -L/-l
все боятся плюсов как огня. но тут см п.п.1
Ну я бы не согласился насчет библиотек, т.к. в случае с Qt, как правило, предстоит биндить билиотеки самостоятельно. Какой-нибудь Firebase — займет прилично времени описать все методы через JNI, где ньюфаг словит целое корыто костылей. Большая часть либ, готовых к использованию в Qt, которые я встречал, были неактуальные или неполные. Хотя это и было давненько, но думаю, что воз и ныне там.
Тем не менее Qt хорош, в ряде случаев, где внешние зависимости с нативными библиотеками минимальны.
вы путаете хрен с пальцем. я вам про сишные библиотеки, вы мне про ява. кьют это плюсовый фремворк, при чем тут ява вообще? тоже самое будет если вам нужно будет биндить яву (или что там) к любому плюсовому фреймворку
насчет файрбез гуглите QtFirebase
да и у самого firebase есть плюсовые либы, насколько я помню
я думаю, что библиотек под ++ все таки больше
с андроид сдк кьют общается через jni. с ndk — напрямую.
по сути кьют программа на андроиде это активити из которой вызывается точка входа в нативную .so библиотеку и дальше вся работа происходит в нативе
андроидная специфика реализуется на яве (если нет аналога в ндк) и пробрасывается в кьют все тем же jni
Ну так) Кому нужны сишные библиотеки в мобильной разработке? Если это не геймдев или какая-то другая специфика. Как и ожидалось, QtFirebase неполный и на пол года минимум неактуальный, да и это капля в море.
Львиная доля сторонних API под Андроид поставляются в виде Java зависимостей. С++ либ очень мало. Да и вообще, мало кто из сторонних сервисов задумывается о поддержке С++.
Писать самостоятельно биндинги ко всему и вся, обмызываться JNI, вместо того, чтобы пилить приложение — сомнительная задача. Это не плохо и не хорошо, просто это сложнее, чем взять ReactNative, я вот про это. Потому-то, на Qt падает выбор только тогда, когда команда знакома с ним не понаслышке, потому что дополнительной работы, помимо логики приложения, там достаточно.
на во первых. как насчет иос? там явы нет.
во вторых, с логикой «ааа, да тут учить надо, вместо того, чтобы пилить приложение» я спорить не буду. каждому свое. ктото хочет по быстрому «запилить приложение» и начать грести бабло лопатой, ктото пытается быть инжинером и разобраться как оно работает под капотом
С iOS, конечно, проще. И я придерживаюсь аналогичного мнения, насчет инженерии. Но от правды не уйдешь, если мы говорим про коммерцию (а мы говорим про комерцию) и какую-нибудь галеру, то там всем пофиг на инженерную мысль. Ибо: «давай, фичи надо, за две недели, давай быстрее, дедлайны! А теперь переделай все по-другому, старый варинат нам не нравится». И вот приходишь ты со своим Qt, рассказываешь про его плюсы, а тебе в ответ: «Мы слышали на реакте это делается за неделю, а Петя из веб отдела знает JS, так что давай реакт».
ну я на кьюте сделаю за неделю. и шо?
если менеджмент не видит дальше своего носа надо либо смириться либо искать другого менеджера
Ну это не аргумент, я тоже много чего могу, но это частный случай. Как правило, команда Qt не знает. Новенькие в Qt и кресты не полезут. В ответе на вопрос: «А какой фреймворк возьмем?» Qt будет далеко не на первом месте, потому что сложно.
Так вот из всего этого и вытекает, собственно, спор с тезисом, что, мол, у Qt нет недостатков.
дааа, новичок уже не торт
а что у явы под капотом? а у андроида? а у иос? а что такое хореографер в курсе? ну и тп. я к тому, что не зная как устроены вещи, картину мира понять практически невозможно. вы сидите в своем окопе и практически ничего не видите
Очень мало встречаю мобльной разработки на Qt.
Просто symbian умер, а замены не выросло
симбиан убили, а вместо него выросло то, что само потом сдохло
ну а кьют остался
Убили как раз maemo/meego, а последние версии симбиана уже переходили на кьют в системном софте. Идея была в том, что обеспечить простое портирование приложений с Qt/Symbian на Qt/Meego.
убили все: и симбиан, у которого было ок 30% рынка и харматтан, который и сейчас по скорости затыкает за пояс большинство телефонов и с котрого слизали свайп интерфейс все кому не лень и убили нерожденную ось для среднего ценового сегмента
Да, жаль что maemo/meego не выстрелили. У меня даже телефон с этой осью был.
Крутая фича. Кстати, это можно реализовать в виде некоторых шаблонных проектов, в которых останется только свои картинки и текст вставить :)
Если бы появился еще один фреймворк, какая киллер-фича заставила бы вас его попробовать?
Если бы в QML вместо js юзался бы C++, я бы точно его бы попробовал.
Суть такова: в QML есть проперти байдинги, типа width: innerObj.width + 10. Оно позволяет прописать, что какое-то поле должно иметь определенное значение в зависимости от значений других и динамически обновляться при изменении этих зависимых полей. Но вот для определения, к каким сигналам нужно коннектиться (а точнее, какие проперти используются) используется js с костыльным враппером. Суть в том, что при каждом вызове js кода оно просматривает, к каким поля были обращения и меняет коннекшены соотв.
Вот вместо всего этого, я хотел бы видеть expression templates и C++ и компайлтайм.
простые биндинги типа вышеприведенного там на плюсах имплементированы
Не-а. Они парсятся в рантайме куда-то, весь QML в рантайме парсится (и вызывает вопросы о защите от копирования)
1. еще раз — простые биндинги транслируются прямо в с++ код (вернее вызывают с++ для обработки)
2. есть компилятор
1. еще раз — простые биндинги транслируются прямо в с++ код (вернее вызывают с++ для обработки)
Что? JIT?
2. есть компилятор
Который вяжется на конкретную версию Qt (и ее приватные API) и ломает ABI между версиями
Dmytro Gladkyi
Руслан Сірко
Dmytro Gladkyi
Maksym Leonidov
Alexander Mazuruk
Denis Suprunenko
De Money
anonymous
Dmytro Hrebeniuk
Платан Дориан
schwarzlichtbezirk
Олег Шестаков
Artem Valieiev
anonymous
schwarzlichtbezirk
Dmytro Hrebeniuk
Fedir Tsapana
Not Sure
Fedir Tsapana
Dmytro Lapshyn
Vlad Stelmahovsky
Vlad Stelmahovsky
67 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів