Вхід і реєстрація
×
Розробка · 29 січня 2018, 17:47 3441
Dmytro Hryppa, Software engineer

Недостатки React Native / Xamarin / Qt? Пилю альтернативу

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

С какими трудностями сталкиваетесь?
Производительность?
Наличие библиотек?
Простота подключения (или написания) нативных библиотек?
Простота установки\настройки среды разработки?
Если бы появился еще один фреймворк, какая киллер-фича заставила бы вас его попробовать?

Теми: Qt, React Native, Xamarin
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі топіки

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Dmytro Gladkyi 05.08.2019 08:57

можна забути про всі ці фрейворки. гугл давно уже зробив flutter.dev. там є і Андроїд, айос, веб, десктоп.

Відповісти
Підтримати
Руслан Сірко 05.08.2019 10:51
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
Відповісти
Підтримати
Dmytro Gladkyi
Руслан Сірко 05.08.2019 10:56

За замовчуванням включена аналітика, яку треба відключати

Відповісти
Підтримати
Dmytro Gladkyi
Denis Suprunenko Працює в CHIPSOFT 31.01.2018 12:02

Ребята, а просветите — разработка на Qt под мобильные приложения — это нативная разработка, или там какие-то внутренние VM используются для трансляции в нативный код?

Відповісти
Підтримати
Dmytro Hryppa Software engineer 31.01.2018 13:32

Без VM. Разве что QML в рантайме интерпретируется (наверное).
Но у Qt свои контролы, своя отрисовка и вообще все свое. Вроде как можно и «нативные» контролы использовать, но это добавляет кучу лишней работы и выхлоп от такой кроссплатформенности сомнительный, имхо.

Відповісти
Підтримати
Denis Suprunenko
De Money 30.01.2018 20:55
киллер-фича

Відсутність «write once run everywhere» ж) Гнучкість у тому, що буде відрізнятись на платформах, а що буде спільне. Написане від тих і для тих, хто робить два окремих додатка для іоs та андроіда без використання подібних кроссплатформених бібліотек. Плагіни — це всюди біль.
Я не в мобілах вже, але склалось таке враження від них.

Відповісти
Підтримати
Dmytro Hrebeniuk Mobile Software Enginner в Self-Employment 30.01.2018 23:38

Реально ли model layer настолько большой в типичном мобильном приложении для что бы выносить это в общий модуль?

Как я это вижу: вместо того что-бы найти одного Android разработчика который глубоко знает Java/Kotlin и ADK, и iOS разработчика который глубоко знает Objective-C/Swift и CocoaTouch, вы предлагаете брать «мастеров на все руки», неужели не возникает в итоге проблем в разработке из-за этого?

Відповісти
Підтримати
anonymous
Dmytro Hryppa Software engineer 31.01.2018 00:19

It depends, как говорится. Ведь с другой стороны, если мы говорим про простое приложение, где общей логики практически нет, то достаточно одного знатока «на все руки», чтобы написать все на кроссплатформенном фреймворке, вместо двоих нативщиков. В такой ситуации — это часто проще поддерживать, быстрее разрабатывать. В таких проектах, как раз таки, особо нету обо что спотыкаться и кроссплатформенные решения тут справляются довольно неплохо.

Відповісти
Підтримати
Dmytro Hrebeniuk
Dmytro Hrebeniuk Mobile Software Enginner в Self-Employment 31.01.2018 00:24

Есть брать Xamarin, то как раз нужно знать особенности и Android и iOS на уровне нативщиков.
Вот если брать React Native, Cordova, Ionic то будет настоящая кроссплатформенность для простых приложений.

Відповісти
Підтримати
Dmytro Hryppa
Dmytro Hryppa Software engineer 31.01.2018 00:33

Верно подмечено, я это и имел ввиду. React Native справляется.
А Xamarin имеет место, если нативщикам нужна общая кодовая база. То есть тут получается все-равно нужны двое нативщиков. Но вопрос в другом, что команде проще: писать на одном языке и расшаривать логику (сособенно если еще и сервер на C#), или же писать всю логику два раза, допуская при этом, потецниально, больше багов.
Как по мне, в дискуссии ниже, Viktor Sinelnikov верно подметил, что это, скорее всего, дело вкуса.

Відповісти
Підтримати
Dmytro Hrebeniuk
Platan 31.01.2018 10:48

Excelsior JET, J2ObjC решают эту-же проблему, но без 16-мегабайтного костыля в виде моно.

сособенно если еще и сервер на C#

Шутка про .Net Remoting.

Відповісти
Підтримати
Dmytro Hryppa
schwarzlichtbezirk 31.01.2018 17:28
Ведь с другой стороны, если мы говорим про простое приложение

Если речь идёт о простом приложении, то вообще нет никакого смысла в фреймвёрках, работающих с ОС. Лучше писать под браузер на js, там есть все возможности, и работать будет на всех платформах. Безсерверное приложение тоже можно написать с UI под HTML. Например, путём создания IWebBrowser2, и открытия там странички. Можно ещё сделать UI под Sciter, заюзать движок Хромиум, и другие способы. Взаимодействовать можно через REST api, или через веб-сокеты, либо в некоторых случаях напрямую с DOM. Графику можно отрисовывать через WebGL, что ещё?

Відповісти
Підтримати
Dmytro Hryppa
Олег Шестаков Forever Jun 02.02.2018 12:02

Это да, Cordova не особо хороша. Но уже появились Progressive Web Apps, если писать что-то простое, помоему, это самый лучший вариант.

Відповісти
Підтримати
anonymous
Artem Valieiev Mobile Developer 31.01.2018 17:42

слой view model еще, пишите так же общий и из платформенных вещей только верстка и привязывание данных. Да спасает, если есть кеширование и сложная бизнесс логика — очень спасает

Відповісти
Підтримати
Dmytro Hrebeniuk
Dmytro Hryppa Software engineer 30.01.2018 20:58

Насчет углубления в платформы я полностью согласен. Но этими же вещами пришлось бы заниматься, если бы нужно было писать два раздельных приложения, отдельно iOS, отдельно Android. А так, выходит, можно хоть что-то свести к общей кодовой базе: какое-то кэширование, работу с базой данных, загрузку контента извне и тд.
Думаю, что, в большинстве случаев, общая кодовая база вполне может быть сведена до 60-80% от общей массы кода. Это ведь лучше, чем все с нуля писать на каждую платформу )

Відповісти
Підтримати
anonymous
Dmytro Hryppa Software engineer 30.01.2018 21:19

Хороший вопрос. У меня встречный: почему, в таком случае, не Xamarin? Там ведь можно писать раздельно (насколько я понимаю, практически идентично обычной нативной разработке) и, как минимум, реализация будет на одном языке, что упрощает коммуникацию команды.

Відповісти
Підтримати
anonymous
schwarzlichtbezirk 30.01.2018 20:08
Если бы появился еще один фреймворк, какая киллер-фича заставила бы вас его попробовать?

Хотите знать, какая киллер-фича заставит перейти всех на ваш фреймвёрк? Какая 100% сработает, однозначно, без вариантов? Киллер-фича, которая заткнёт за пояс все остальные фреймвёрки? Ну так вот. Это поддержка вашего фреймвёрка со стороны по крайней мере 3 гигантов: Google, Microsoft и Apple. И что никаких других киллер-фич разве нет? Все остальные киллер-фичи в конечном счёте сводятся к ковырянию в носу пальцем.

Відповісти
Підтримати
Dmytro Hryppa Software engineer 30.01.2018 20:29

Ну, без самого фреймворка и чего-то интересного в его функционале ни о какой поддержке речи идти не может. И потом, может его и купит кто-то из гигантов, who knows :)

Відповісти
Підтримати
schwarzlichtbezirk
Dmytro Hrebeniuk Mobile Software Enginner в Self-Employment 30.01.2018 19:26

А кто что скажет про Ionic и Apache Cordova?

Відповісти
Підтримати
Fedir Tsapana изобретатель добрых программ 30.01.2018 16:41

А я не жду никакого универсального кроссплатформенного мобильного «фреймворка». Я просто жду когда iOS наконец здохнет.

Відповісти
Підтримати
Not Sure 30.01.2018 17:43

Почему вы так ненавидите ios?)

Відповісти
Підтримати
Fedir Tsapana
Fedir Tsapana изобретатель добрых программ 30.01.2018 18:02

С чего вы взяли?) Просто я фрилансер и мне надоело что всем надо сразу поддержку двух платформ — Android и iOS. Мне было бы удобнее писать только под одну и если выбирать из этих двух, то это пожалуй Андроид — более открытый, меньше контроля и анальных зондов (сравнительно) от «родительской» корпорации, ну и так по мелочам. Вот эти вот кроссплатформенные «фреймворки» не предлагать — скоко я их перепробовал, все с нативной разработкой и рядом не стояло (и не может стоять в принципе, как авторы это не поймут).

Відповісти
Підтримати
Not Sure
Dmytro Lapshyn Tech Lead в Fulcrum Rocks 30.01.2018 18:34

Ну вот любопытства ради — в том же Xamarin ты работаешь с тем же самым API мобильной ОС, только язык программирования другой и есть прослойка в виде Mono.

Чего нельзя такого сделать на Xamarin, что можно сделать нативно?

Відповісти
Підтримати
Fedir Tsapana
Platan 30.01.2018 18:53

Поддержку Android instant app 100% нельзя. (Первое что пришло в голову человеку, ничего не знающего о Xamarin)

Відповісти
Підтримати
Dmytro Lapshyn
Dmytro Hryppa Software engineer 30.01.2018 19:08

Интересно. Я еще не пробовал их, но не вижу пока преград для своего фреймворка в этом вопросе. Будет, значит, одной из киллерфич )

Відповісти
Підтримати
Platan
Fedir Tsapana изобретатель добрых программ 30.01.2018 19:08

В том то и дело, что вроде как все можно, но на деле везде мелкие «но»... То апи для платформы самый новый не завезли, то фичи(платформ а не аппы) на разных платформах так отличаются, что разницы нет — писать две аппы сразу либо одну «кроссплатформенную», но по факту с двумя версиями кода под обе платформы. И почти везде надо искать тонны «плагинов» написанных сторонними индусами сомнительного качества, либо лезть в те самые нативные апи платформ. А еще производительность и размер приложения — да, да тоже играет роль. И в итоге этих мелких «но» накапливается целая лавина, которая нивелирует вообще какую либо пользу от такой кроссплатформенной разработки.
Правда это все в основном касается прикладных мобильных апп где много взаимодействия с пользователем и платформеннозависимых нюансов — игры писать на кроссплатформенных движках еще вполне норм как по мне.

Відповісти
Підтримати
Dmytro Lapshyn
Dmytro Hryppa Software engineer 30.01.2018 19:00

А что именно не устраивает в фреймворках по сравнению с нативной разработкой? Более слабый контроль каких-то системных, нативных функций?

Відповісти
Підтримати
Fedir Tsapana
Fedir Tsapana изобретатель добрых программ 30.01.2018 19:09

См мой комментарий для Dmytro Lapshyn

Відповісти
Підтримати
Dmytro Hryppa
Dmytro Hrebeniuk Mobile Software Enginner в Self-Employment 30.01.2018 19:09

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

Відповісти
Підтримати
Fedir Tsapana
Fedir Tsapana изобретатель добрых программ 30.01.2018 19:15

Ну это отдельная проблема. И скажу сразу — она на данном этапе развития нашей цивилизации нерешаема) Всегда найдутся «заказчики»-мечтатели со $100 в кармане и амбициями как у Илона Маска, и всегда найдутся бедные индусы/украинцы которым надо семью кормить уже сегодня, а не ждать потенциального заказа от нефтяного магната завтра.
А ну и еще разработчиков сейчас стало действительно слишком много, но про это на прекрасном.it отлично написано

Відповісти
Підтримати
Dmytro Hrebeniuk
Vlad Stelmahovsky Software Engineer в Verity AG 30.01.2018 12:28

у Qt нет недостатков ;-)

Відповісти
Підтримати
Dmytro Hryppa Software engineer 30.01.2018 17:22

Так и запишем :)
Однако, минус там — это, как ни странно, С++. Порог вхождения для ньюфагов высокий. Более сложное, чем у остальных фреймворков прикручивание сторонних либ.
Очень мало встречаю мобльной разработки на Qt. Хотя, может это мне только так кажется.

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 30.01.2018 17:40

эээ
для ньюфаков придумали QML
прикручивание сторонних либ не простое, а очень простое — как и везде -L/-l
все боятся плюсов как огня. но тут см п.п.1

Відповісти
Підтримати
Dmytro Hryppa
Dmytro Hryppa Software engineer 31.01.2018 13:38

Ну я бы не согласился насчет библиотек, т.к. в случае с Qt, как правило, предстоит биндить билиотеки самостоятельно. Какой-нибудь Firebase — займет прилично времени описать все методы через JNI, где ньюфаг словит целое корыто костылей. Большая часть либ, готовых к использованию в Qt, которые я встречал, были неактуальные или неполные. Хотя это и было давненько, но думаю, что воз и ныне там.
Тем не менее Qt хорош, в ряде случаев, где внешние зависимости с нативными библиотеками минимальны.

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 13:54

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

Відповісти
Підтримати
Dmytro Hryppa
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 14:59

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

Відповісти
Підтримати
anonymous
Dmytro Hryppa Software engineer 31.01.2018 15:32

Ну так) Кому нужны сишные библиотеки в мобильной разработке? Если это не геймдев или какая-то другая специфика. Как и ожидалось, QtFirebase неполный и на пол года минимум неактуальный, да и это капля в море.
Львиная доля сторонних API под Андроид поставляются в виде Java зависимостей. С++ либ очень мало. Да и вообще, мало кто из сторонних сервисов задумывается о поддержке С++.
Писать самостоятельно биндинги ко всему и вся, обмызываться JNI, вместо того, чтобы пилить приложение — сомнительная задача. Это не плохо и не хорошо, просто это сложнее, чем взять ReactNative, я вот про это. Потому-то, на Qt падает выбор только тогда, когда команда знакома с ним не понаслышке, потому что дополнительной работы, помимо логики приложения, там достаточно.

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 15:55

на во первых. как насчет иос? там явы нет.
во вторых, с логикой «ааа, да тут учить надо, вместо того, чтобы пилить приложение» я спорить не буду. каждому свое. ктото хочет по быстрому «запилить приложение» и начать грести бабло лопатой, ктото пытается быть инжинером и разобраться как оно работает под капотом

Відповісти
Підтримати
Dmytro Hryppa
Dmytro Hryppa Software engineer 31.01.2018 16:19

С iOS, конечно, проще. И я придерживаюсь аналогичного мнения, насчет инженерии. Но от правды не уйдешь, если мы говорим про коммерцию (а мы говорим про комерцию) и какую-нибудь галеру, то там всем пофиг на инженерную мысль. Ибо: «давай, фичи надо, за две недели, давай быстрее, дедлайны! А теперь переделай все по-другому, старый варинат нам не нравится». И вот приходишь ты со своим Qt, рассказываешь про его плюсы, а тебе в ответ: «Мы слышали на реакте это делается за неделю, а Петя из веб отдела знает JS, так что давай реакт».

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 16:32

ну я на кьюте сделаю за неделю. и шо?
если менеджмент не видит дальше своего носа надо либо смириться либо искать другого менеджера

Відповісти
Підтримати
Dmytro Hryppa
Dmytro Hryppa Software engineer 31.01.2018 17:22

Ну это не аргумент, я тоже много чего могу, но это частный случай. Как правило, команда Qt не знает. Новенькие в Qt и кресты не полезут. В ответе на вопрос: «А какой фреймворк возьмем?» Qt будет далеко не на первом месте, потому что сложно.
Так вот из всего этого и вытекает, собственно, спор с тезисом, что, мол, у Qt нет недостатков.

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 17:45

дааа, новичок уже не торт

Відповісти
Підтримати
Dmytro Hryppa
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 16:34

а что у явы под капотом? а у андроида? а у иос? а что такое хореографер в курсе? ну и тп. я к тому, что не зная как устроены вещи, картину мира понять практически невозможно. вы сидите в своем окопе и практически ничего не видите

Відповісти
Підтримати
anonymous
Andrii Batyiev Senior Expert C++ Developer 30.01.2018 17:54
Очень мало встречаю мобльной разработки на Qt.

Просто symbian умер, а замены не выросло

Відповісти
Підтримати
Dmytro Hryppa
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 15:00

симбиан убили, а вместо него выросло то, что само потом сдохло
ну а кьют остался

Відповісти
Підтримати
Andrii Batyiev
Andrii Batyiev Senior Expert C++ Developer 31.01.2018 16:17

Убили как раз maemo/meego, а последние версии симбиана уже переходили на кьют в системном софте. Идея была в том, что обеспечить простое портирование приложений с Qt/Symbian на Qt/Meego.

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 31.01.2018 16:30

убили все: и симбиан, у которого было ок 30% рынка и харматтан, который и сейчас по скорости затыкает за пояс большинство телефонов и с котрого слизали свайп интерфейс все кому не лень и убили нерожденную ось для среднего ценового сегмента

Відповісти
Підтримати
Andrii Batyiev
Олег Шестаков Forever Jun 02.02.2018 12:04

Да, жаль что maemo/meego не выстрелили. У меня даже телефон с этой осью был.

Відповісти
Підтримати
Andrii Batyiev
Dmytro Hryppa Software engineer 30.01.2018 20:25

Крутая фича. Кстати, это можно реализовать в виде некоторых шаблонных проектов, в которых останется только свои картинки и текст вставить :)

Відповісти
Підтримати
anonymous
Andrii Batyiev Senior Expert C++ Developer 29.01.2018 23:29
Если бы появился еще один фреймворк, какая киллер-фича заставила бы вас его попробовать?

Если бы в QML вместо js юзался бы C++, я бы точно его бы попробовал.

Суть такова: в QML есть проперти байдинги, типа width: innerObj.width + 10. Оно позволяет прописать, что какое-то поле должно иметь определенное значение в зависимости от значений других и динамически обновляться при изменении этих зависимых полей. Но вот для определения, к каким сигналам нужно коннектиться (а точнее, какие проперти используются) используется js с костыльным враппером. Суть в том, что при каждом вызове js кода оно просматривает, к каким поля были обращения и меняет коннекшены соотв.

Вот вместо всего этого, я хотел бы видеть expression templates и C++ и компайлтайм.

Відповісти
Підтримати
Vlad Stelmahovsky Software Engineer в Verity AG 30.01.2018 12:27

простые биндинги типа вышеприведенного там на плюсах имплементированы

Відповісти
Підтримати
Andrii Batyiev
Andrii Batyiev Senior Expert C++ Developer 30.01.2018 13:03

Не-а. Они парсятся в рантайме куда-то, весь QML в рантайме парсится (и вызывает вопросы о защите от копирования)

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 30.01.2018 13:53

1. еще раз — простые биндинги транслируются прямо в с++ код (вернее вызывают с++ для обработки)
2. есть компилятор

Відповісти
Підтримати
Andrii Batyiev
Andrii Batyiev Senior Expert C++ Developer 30.01.2018 14:30
1. еще раз — простые биндинги транслируются прямо в с++ код (вернее вызывают с++ для обработки)

Что? JIT?

2. есть компилятор

Который вяжется на конкретную версию Qt (и ее приватные API) и ломает ABI между версиями

Відповісти
Підтримати
Vlad Stelmahovsky

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.