Комментарии 119
У них пока настолько крутые breaking changes, что для бизнеса юзать страшно. Ну а сам концепт то весьма хорош
Не знаете, они обещались что то для десктопа пилить или нет?
Нужно, потому что оно ближе к нативной производительности, собственно и меньше потребление ресурсов.
Если же мы говорим о «классических» элементах управления Windows, то тут возникает другой вопрос — много ли найдётся желающих пользоваться фреймворком, который предоставляет весьма узкие возможности для творчества в плане внешнего вида пользовательского интерфейса. Да, разумеется, есть subclassing, во только он подразумевает отрисовку средствами GDI, которое, если мне не изменяет склероз, не очень «дружит» с аппаратным ускорением графики.
Признаю, далек от вопросов рендеринга и производительности отрисовки в WPF, Qt Quick на нейтиве. Просто исторически сформировалось мнение, что DOM всегда требует для своей поддержки большое количество памяти, а операции с DOM всегда медленные.
Почти всегда хватает 5-10 минут, чтобы адаптировать приложение. Если изменения серьезные, то о них объявляют за 3-4 версии. Зато взамен ты получаешь очень быстрое развитие платформы и фикс багов.
Опять же, никто не заставляет постоянно обновляться. Но намного проще раз в пару месяцев исправить что-то небольшое, чем раз в год получать нерабочее приложение с 20 мажорными изменениями.
Приложение нужно под обе эти платформы. Может кто сталкивался? Что посоветуете?
Учить iOS и заморачиваться с настройкой среды? (Мака, айфона и т.п. на руках нет, небыло и не планируется)
Использовать что-то как в статье?
Учить iOS и заморачиваться с настройкой среды?
Угу, иначе велик шанс создать монстра, вызывающего отчуждение у потребителя, привыкшего к родной инфраструктуре
С ios придется заморачиваться, даже в случае кроссплатформенных решений. Даже если представить, что приложение написано на базе cordova и идеально работает на всех платформах, для android правила сборки для деплоя одни, для ios — другие. Люди, работавшие для android, считают, что деплой в ios адово сложен — и наоборот...
На деле же сложное кроссплатформенное приложение в некоторых случаях ведёт себя по-разному на разных платформах, так что требуются фиксы в коде под отдельные платформы. Плюс, в случае cordova, хорошо бы точно понимать список необходимых нативных функций, посмотреть, какими плагинами они поддерживаются, в каком объёме р всеми ли нужными платформами. Чтобы не было неприятных сюрпризов в самый разгар разработки, когда отступать уже поздно.
В общем, да, заморачиваться придётся в любом случае. Так что совет начать с мобильной версии сайта / адаптивного дизайна очень правильный, поддерживаю!
Т.к. если ваше приложение работает, скажем, в XCode iOS emulator, это НЕ означает, что оно будет точно так же работать на физическом устройстве (iPhone/iPad)
Hint: если вы проверили на iPhone 5 и все работает отлично, это не означает, что на iPhone 7 все будет точно так же. Нам это в свое время много нервов попортило.
Qt: Небольшое сообщество
Чего? Пойдите на тот же Stackoverlow и поищите по хештегу Qt. Сравните с Xamarin и phonegap. После этого исправьте в статье на «самое большое сообщество из всех рассмотренных».
Мне кажется, автор недавно в теме, потому как не упомянул ReactNative, на котором Facebook, AirBnB, Instagram. Возможно оно сейчас сыровато, зато имхо, трендовей чем Appcelerator Titanium или Talerik. Для чистоты, в обзоре стоило упомянуть.
Только вот этот ваш пример с СО не будет иметь ничего общего только с мобильной разработкой в контексте Qt. С таким же успехом можно всех жс-ников записать в сообщества Фонгаппа и т.п.
Видео с разработкой мобильной игры на Qt.
Игры или Tiled Map Editor?
У вас минусы xamarin, это минусы xamarin.forms в основном. При том в там никто не запрещает использовать нативные xib, storyboard, axml.
Qt
Android, iOS, WinRT, Windows, Symbian и Ubuntu
Уже работает под tvOS и watchOS, но пока в превью. Но у меня работает.
Плюс Sailfish и Ubuntu Phone изначально написаны на Qt (в смысле интерфейс и SDK), а BlackBerry (который упомянут в другом столбце, так что не понятно, почему он упущен здесь) тоже использует Qt как официальную среду разработки.
Плюс не понятно, почему их всех дистрибутивов линукса указана только Ubuntu, хотя оно работает и на остальных. Можно было просто Linux написать =). Ещё QNX самая что ни на есть официально поддерживаемая, на ней тесты гоняют.
Ну и плюс все остальные операционки, на которых оно тоже работает.
Плюс ещё я тут потихоньку QmlWeb пилю для рендеринга QML прямо в браузере, но писать полноценную статью на хабр мне об этом очень лениво.
Платные версии начинаются от 7$.
От $79.
В смысле не поддерживается?
Возможно, с тех пор интерпретатор Ruby под Android был сильно оптимизирован, но, в целом, у меня точно возникли бы вопросы о сравнении производительности Ruby и JavaScript движков на мобильных устройствах. Последние очень сильно оптимизируются под ARM платформу. Что в этом плане происходит в Ruby сообществе — мне сложно сказать.
Кстати основная проблема PhoneGap/Cordova и всех решениях построенных на их базе (а их навалом) это то что все крутиться в одной вебвьюхе и соот.в ка ктолько приложение начинает разрастаться то все приплыли — все начинает тормозить, а вынести код и данные из вебвьюхи некуда.
Но в целом, да — для тяжёлых приложений с богатым интерфейсом чувствуется нагруженность вебвьюхи.
Недостатки:Да ладно, почти все можно делать на JS, а С++/Qt довольно простой, магии нет, хорошая документация и т.д.
Qt сложен для начинающих
Реальные минусы в том что технология местами все еще сырая, а под iOS нет стиля контролов.
Что хуже, она сырая удручающе долго...
Визуальный QML дизайнер неюзабелен, я не знаю кто им пользуется, но IDE в целом весьма быстрая и удобная, это да.
Telerik AppBuilder по сути вообще платформа для разработки на Cordova или NativeScript.
> Titanium — это полностью открытая платформа для разработки
Неправда, у них кусок движка с закрытым кодом и доступен только в бинарных библиотеках.
> ReactNative
> Также стоит учитывать, что при разворачивании приложения на устройство пользователя попадет весь JS, поэтому на уровне презентации не стоит держать секретную бизнес-логику.
Ну, секретной бизнес-логики вообще не должно быть (ну или хотя бы на сервере). Security through Obscurity не работает. Что разреверсить js, что нативный код — разница только в удобстве. А переиспользовать этот минифицированный фарш где-то еще все равно не получится.
Для фанатов питона есть еще такая замечательная штука, как Киви https://kivy.org
Ну, роутеры, пакеты (не завязанние на UI) можно шарить между веб-версией и Mobile App, например реализацию API держать одной библиотекой.
Разрабатываю на Corona SDK. Очень доволен. Не понял почему её нету в списке-опроснике.
Но генерация выходного кода мне в нем не особо нравится: слишком много лишнего кода. Напоминает, как если из ворда сохранять html. Можно, но выходной файл будет _слегка_ не оптимизирован. Да и не читаем изнутри, имхо.
У Haxe почему-то нет и никогда не было нормального маркетинга. Сам писал на нём больше 5 лет, когда Flash был в горе.
На OpenFL можно делать отличные кроссплатформенные игры и не париться вообще. Всё из коробки прекрасно работает.
Насчет бизнес прилжений — наврядли Haxe это хороший выбор. По-хорошему бизнес-приложения должны соблюдать дизайнерские гайдлайны для платформы. А крутых гуёв, которые выглядят нативненько, под Haxe нету. Да и доступ к нативным API на Haxe проблематичен. Т.е. как бы всё есть для этого, есть много всяких мелких либ, которые что-то умеют. Но нет одной большой и добротной, которая умела бы все нативные API на всех платформах
Скажите, пожалуйста, где вы находите заказчиков, готовых платить за Haxe? Его ж никто не знает и не сможет поддерживать кроме вас самих.
А под какие compiler-targets разрабатываете?
Qt сложен для начинающих
не совсем согласен. Qt — самое простое из всего, что есть в с++ на сегодня. Просто сам по себе с++ считается одним из сложнейших среди популярных яп.
Native Hybrid: используется когда вам нужны нативные UI элементы, в этом случае приложение будет включать несколько WebView в контейнере.
Ничерта не понял из этой фразы. Что имелось ввиду?
https://godoc.org/golang.org/x/mobile/app
Android и iOS
Замечу что поддержка GUI на довольно примитивном уровне.
Стоит рассматривать прежде всего как вспомогательный код для ресурсоемких вычисления, ибо Go компилируется в код микропроцессора, а не выполняется на эмуляторе или транслятором.
Если кто-то знает примеры сложного открытого кода для GUI на Go — киньте сюда.
В теории, особо тормозить там нечему — приложения должны получаться очень даже шустрые.
Стоит рассматривать прежде всего как вспомогательный код для ресурсоемких вычисления
Действительно, тормозить нечему :D
Так нет гуй инструментов — нет и тормозов. Когда смогут написать нормальный UI фраемворк (а лучше и правильние — хороший интероп с java 3rd party компонентами\контролами — тогда будем говорить. А так это как свифт — Hello world запустить-то на андроиде можно — но бесполезно. А если нужна скорость — C++. Не вижу пока никакого смысла в го на мобилках.
Так нет гуй инструментов — нет и тормозов
Когда GUI-ем занимается сама ОС, а именно это вы сами и упомянули:
а лучше и правильние — хороший интероп с java 3rd party компонентами\контролами
то ответственность за тормоза опять таки на ОС,
а не на языке.
Ну тогда удачи в реализации огромного UI фраемворка, который будет в себе содержать уже все эти сотни готовых контролов, к которым привыкли пользователи. Дизайнер, декларативный интерфейс, вот это всё. В лучшем случае получится какой-нибудь qt.
Ну тогда удачи в реализации огромного UI фраемворка, который будет в себе содержать уже все эти сотни готовых контролов, к которым привыкли пользователи. Дизайнер, декларативный интерфейс, вот это всё. В лучшем случае получится какой-нибудь qt.
При прочих равных — то есть при использовании одного и того UI — программа, созданная c golang, будет шустрее всех упомянутых вариантов, даже быстрее родной для Android Java (ну тут от вида софта зависит, для некоторых особо интенсивно выводящих в UI игр и т.п., может и не быстрее; но для таких как раз и придуман OpenGL-вариант). Обойти golang сможет только C/C++/Objective C
Т.е. смысла использовать golang нет. понял. Под инструмент быстрого и удобного создания интерфейса он не подходит, для создания перфоманс приложений тоже не нужен т.к. есть плюсы.
Т.е. смысла использовать golang нет. понял. Под инструмент быстрого и удобного создания интерфейса он не подходит, для создания перфоманс приложений тоже не нужен т.к. есть плюсы.
Если бы было всегда достаточно 1 языка программирования и с ним было бы все заведомо удобно и круто — 1 язык и существовали бы.
У плюсов дороже разработка — следить за памятью нужно строже, concurrency не столь удобна и пр.
К тому же мы обсуждаем конкретные инструменты для конкретно Android+iOS, которые позволяют минимизировать телодвижения по созданию кода под 2 системы сразу.
Плюсы сами по себе этого не позволяют.
Ну вот смотрите, у плюсов есть огромное количество библиотек (всё что связанное с обработкой видео, аудио, изображений, геймдев и т.п.). У Xamarin/js/java/obj c есть Ui тулкиты, дизайнеры, иде в которые вложено огромное количество человекочасов и выточенные годами + огромное комьюнити и море 3rd parties. А go ни того, ни сего. Только пяток хипстеров, которые на нем пишут микросервисы на бэкенде. Как язык довольно спорный и точно не лучше других.
Ну вот смотрите, у плюсов есть огромное количество библиотек (всё что связанное с обработкой видео, аудио, изображений, геймдев и т.п.). У Xamarin/js/java/obj c есть Ui тулкиты, дизайнеры, иде в которые вложено огромное количество человекочасов и выточенные годами + огромное комьюнити и море 3rd parties. А go ни того, ни сего. Только пяток хипстеров, которые на нем пишут микросервисы на бэкенде. Как язык довольно спорный и точно не лучше других.
Что значит — лучше?
Вариант — да.
Насчет количества библиотек — вы просто не в курсе.
Счет библиотек в Go (pure Go и биндингов к C-шным) давно уже идет на сотни тысяч.
Кстати, о библиотеках — в плюсы Go против C++ можно добавить намного более прозрачную работу с библиотеками.
Вариант, вполне такой же вариант как и js, к примеру.
Для соответствующих своих задач, разумеется.
Скажем, те варианты с js, что я смотрел для Android+iOS — подвешивал даже не самое старое (не топовое) железо.
У всех есть достоинства и недостатки.
Я сам не буду использовать Go для UI на Android+iOS в ближайшее время, помучаюсь пока с тормозными, но более комплексными решениями.
давно уже идет на сотни тысяч.
Спасибо, улыбнулся :)
Хотя бы родной гугловый Skia хоть забайндили уже в го чтобы сделать нормальный UI фраемворк? Или вы планируете на голом opengles сделать сами? :))
То, что у вас там где-то жс тормозил — не повод тащить в мобилки очередной язык и клепать к нему всю мобильную инфраструктуру с нуля. На java/swift ничего не тормозит. Тормозит только в кривых руках, но в таких же руках и го будет тормозить.
Спасибо, улыбнулся :)
Хотя бы родной гугловый Skia хоть забайндили уже в го чтобы сделать нормальный UI фраемворк? Или вы планируете на голом opengles сделать сами? :))
исходники golang'овых библиотек под skia живут на go.skia.org
То, что у вас там где-то жс тормозил — не повод тащить в мобилки очередной язык и клепать к нему всю мобильную инфраструктуру с нуля. На java/swift ничего не тормозит. Тормозит только в кривых руках, но в таких же руках и го будет тормозить.
У нас тут вполне конкретное обсуждение:
Инструментарий под одновременно Android+iOS
Насчет «Ява не тормозит» — не надо врать-то:
Ускоряем приложение Android с помощью Golang
1) ссылка go.skia.org вы уверены что это байндинги golang на Skia?
2) ссылка на проблему с java порадовала — никакого кода "клянусь, посоны, написал на джаве — дико тормозила!".
3) Раз одновременно под Android+iOS давайте возьмем Xamarin ;-)
Нативный код процессора против эмуляции в виртуальной машине
эмуляция в виртуальной машине омг. про aot, llvm видимо не стоит даже заикаться. Про реализацию сборки мусора — в вас опять же говорит бэкендщик.
1) ссылка go.skia.org вы уверены что это байндинги golang на Skia?
Может бандинги, а может и pure Go.
А что это по вашему?
2) ссылка на проблему с java порадовала — никакого кода «клянусь, посоны, написал на джаве — дико тормозила!».
Для глубокой аналитики, согласен, недостаточно.
Но опять таки, исходить нужно из того, что большинство программистов ничуть не лучше.
Про реализацию сборки мусора — в вас опять же говорит бэкендщик.
При чем здесь backend?
Когда тормозит интерфейс на сборке мусора — это очень даже не здорово.
эмуляция в виртуальной машине омг. про aot, llvm видимо не стоит даже заикаться.
Вы Intellij IDEA что ли не видели?
Всем хороша.
Много лет как развивается.
Сомнений в квалификации разработчиков нет никаких.
Но — притормаживает.
Даже на современном неслабом железе.
Тормозит только в кривых руках, но в таких же руках и го будет тормозить.
От криворукости все равно никуда деться. И нужно брать её в расчет всегда.
При одинаковой исходной криворукости разработчика программа на Go тормозит меньше программы на Java.
Это чисто архитектурно, ибо:
1) Нативный код процессора против эмуляции в виртуальной машине
2) Наилучшая на сегодня реализация сборки мусора в параллельной среде.
C++ быстрее Go только за счет п.2)
Правда за счет этого же пункта у С++ получается более трудоемкая разработка.
зато плюсы вкупе с Qt позволяют реализовывать и хороший параллелизм, и упрощение работы с памятью, и создавать код для android+ios сразу…
Ну а почему же Qt не является основным продуктом разработки для мобильных платформ на сегодня? Отчего же тут так бурно обсуждают пару десятков альтернатив?
;)
1. с++ — компилируемый язык.
2. QML появился только в 2009-м.
3. Symbian умер, blackberry еле дышит (продвигать Qt особо некому)
1. с++ — компилируемый язык.
Java и ObjectiveC — все так же компилируемые. Разве это мешает делать нативные приложения для каждой из платформ в отдельности.
2. QML появился только в 2009-м.
Ну а Android — в конце 2008, а распространение массовое началось только с версии 2, которая в 2010-ом.
3. Symbian умер, blackberry еле дышит (продвигать Qt особо некому)
Qt-то как раз не только Symbian и Blackberry.
Иначе бы мы его тут не обсуждали в кросс-платформенных средствах.
Qt-то как раз не только Symbian и Blackberry.
Иначе бы мы его тут не обсуждали в кросс-платформенных средствах.
Я так понимаю, имелись ввиду маркетинговые вливания.
Лично мне не хватает хорошего WYSIWYG редактора для QtQuick.
Xamarin давно уже OpenSource и любой может отправить PR и при чем регулярно публикуют кто и что за PR отправилял:
https://releases.xamarin.com/pre-release-xamarin-forms-2-3-4-184-pre1/
В статье ссылки на цены версий IDE а не на Xamarin который полностью бесплатный.
- О том что есть отдельно Xamarin без какого либо XAML (который сам по себе не меньше популярен чем Forms) и есть совсем другая платформа Xamarin Forms с XAML разметкой (надстройка над Xamarin) который относительно недавно стал набирать популярность в сообществе Xamarin в статье вообще ни слова.
Судя по всему в остальных платформах Вы разбираетесь примерно на таком же уровне.
Я могу понять (хотя на самом деле не могу понять), что вы не захотели разобраться в теме о которой Вы пишете. Но неужели было слишком трудно хотя бы пройти по той ссылке что вы привели в таблице и посмотреть на что именно Вы указываете в ссылке?
Я бы не советовал при выборе учитывать результаты голосования, так как и так уже отобраны самые популярные решения.
При выборе решения есть несколько разных аспектов сильно влияющих на результат.
Для потребительских приложений, если они сложны и массовы, на мой взгляд, лучше вообще отказаться от кроссплатформенности.
Все эти(кросс-платформенные) решения наиболее массово применяются в корпоративной сфере, так что считайте все написанное далее касается только корпоративной сферы.
Прежде всего стоит остановиться на популярности гибридных решений (PhoneGap/Cordova)
Я лично считаю что будущее за гибридными решениями — сейчас это фактически стандарт. Все крупные игроки предлагают собственные варианты решений на базе Кордовы.
Причины: можно привлекать веб разработчиков(которые все равно нужны и как правило уже есть), можно шарить код с сайтом(который обычно все равно нужен). Кроме того веб разработчиков много.
Немаловажная причина и в том что это решение open source.
Первое — зачем вообще понадобилось именно приложение.
Обычно ответа два:
- нужен оффлайн доступ к функциональности
- нужен доступ к различным возможностям устройства, например Barcode/RFID сканер и т.п.
Во всех остальных случаях можно ограничится веб приложением, которое вполне себе будет кросс-платформенным — браузер есть везде.
Кроме того сейчас есть такая тема как “улучшенный браузер” — то есть никто не мешает собрать браузер на базе той же Кордовы и подключить туда все нужные плагины(доступ к сканеру, функциональности устройства и т.п.). А потом вы устанавливаете этот браузер на устройства пользователей а дальше они работают с вашими веб-апликухами с вашего сайта, но теперь из веб апликуха есть доступ ко всему.
Кстати я думаю что такое решение будет становиться все популярнее — это просто и удобно всем.
Второе — сложность приложения
Если приложение нетяжелое, то однозначно стоит выбрать Кордову. Это стандарт де-факто.
С ростом мощности устройств все более и более тяжелые приложения можно спокойно писать на Кордове.
Основная проблема Кордовы — все висит в одной ВебВью и в одном треде. Теоретически можно использовать треды в JS, но слишком много ограничений.
Но с ростом производительности граница простое-сложное приложение смещается все дальше в сторону сложное.
Если приложение очень тяжелое, то стоит рассмотреть нативные кросс-платформенные решения. Чем лини отличаются от гибридных? Тем что вам просто предлагается программировать на каком либо языке и обеспечивается доступ ко всем АПИ. Иногда предлагают универсальный UI иногда он требует написания на каждой платформе отдельно.
Безусловным лидеров среди таких решений является Xamarin. Особенно после того как он стал бесплатным и open source.
При выборе на чем писать тяжелое приложение стоит также рассмотреть на чем сделано ваше серверное решение (приложение в корпоративном секторе это как оправило всего лишь один из элементов инфраструктуры, а не вещь в себе) и какие программисты у вас имеют в наличии.
Если у вас серверное решение и много программистов под .NET — берите Xamarin и не парьтесь.
Если на Java — стоит рассмотреть Codename One, но я бы посоветовал все же Xamarin (Java и C# практически одно и то же)
Если на Ruby (Ruby on Rails), то можно брать RubyMotion, но на мой взгляд лучше Rhomobile. Rhomobile это гибридное решение, то есть можно все писать в ВебВью на джаваскрипте с переносом кода из веб апликуха и использованием веб программистов(как в Кордова), но также можно писать код и на руби — выглядит это все как Ruby on Rails прямо на самом устройстве — тем кто программирует на Ruby on Rails ничего и изучать особо не нужно.
Если на JavaScript (Node.js), то можно брать Appcelerator или NativeScript/Telerik.
Из особых случаев хотел бы упомянуть поддержку WinCE/WinMobile — промышленные устройства(терминалы сбора данных и т.п.) на этих платформах самые распространенные и до сих пор выпускаются!
Сейчас переход таких устройств на Android уже идет и продолжается и будет продолжаться еще много лет — это очень инерционный рынок.
Если вам нужно поддерживать такие устройства в том числе, то есть писать софт для них и для iOS, Android и т.п. То тут вас ждет разочарование — эту платформу вообще никто не поддерживает кроме Rhomobile.
Есть еще костыли типа iFactr — они предлагают ваши программы написанные на .NET под WinCE/WM конвертировать в приложения Xamarin, но конвертация однонаправленная. Это хорошо только если вы разово меняете все ваши устройства на WinCE/WM на новые устройства на Android.
Хочу предложить ознакомиться с докладом на эту тему, с конференции CEE-SECR 2016:
http://2016.secr.ru/program/submitted-presentations/current-state-and-future-of-solutions-for-develop-enterprise-cross-platform-mobile-applications
Обзор кросс-платформенных решений для разработки мобильных приложений