Представлен (https://www.nativescript.org/blog/nativescript-first-public-...первый публичный выпуск проекта NativeScript (https://www.nativescript.org/), в рамках которого развивается фреймворк, позволяющий создавать универсальные мобильные приложения для платформ iOS, Android и Windows Phone, используя язык JavaScript или TypeScript (http://www.opennet.me/opennews/art.shtml?num=39488). Код NativeScript распространяется (https://github.com/NativeScript/) под лицензией Apache 2.0.Разработка ведётся (http://docs.nativescript.org/getting-started) с использованием парадигмы проектирования MVVM (https://ru.wikipedia.org/wiki/Model-View-ViewModel) (Model View ViewModel) и не требует изучения основных для мобильных платформ языков, таких как Java, Objective-C и .NET. В итоге формируется единое универсальное приложение на JavaScript, которое выполняется при помощи специфичной для каждой платформы runtime-прослойки. Используемое для выполнения NativeScript-приложений runtime-окружение построено на базе JavaScript-движка V8 на платформе Android, и движка JavaScriptCore в iOS. Разработка runtime для Windows Phone пока только в планах.
Для формирования интерфейса используется CSS и специальная универсальная библиотека, позволяющая абстрагировать различия в построении интерфейсов для разных мобильных платформ. Вместо WebView для интерфейса используются родные для каждой платформы движки отрисовки. Таким образом, одна кодовая база приложения NativeScript позволяет сформировать версии для iOS, Android и Windows Phone, которые мало чем будут отличаться от обычных нативных приложений для каждой мобильной платформы. При этом кроме универсального кроссплатформенного API разработчикам приложений при необходимости предоставляется (http://developer.telerik.com/featured/nativescript-works/) возможность прямого обращения из JavaScript к любым специфичным для каждой платформы API и доступа к любым предоставляемым платформой библиотекам, доступным для программ на Objective-C, Java и .NET.
<center><img src="http://www.opennet.me/opennews/pics_base/0_1426155134.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>
URL: https://www.nativescript.org/blog/nativescript-first-public-...
Новость: http://www.opennet.me/opennews/art.shtml?num=41828
О, наконец-то, давно хотел увидеть что-то подобное. Если там ещё UI декларативный, вообще круто.
чем тебе qt не угодил?
Тем что не нативный, т.е всегда все равно с оверхедом
runtime qt самый что ни на есть нативный под все поддерживаемые им платформы
На андроиде сей рантайм запускается параллельно и жрёт лишние ресурсы.http://achipa.blogspot.ru/2014/11/native-ui-in-qt-on-android...
Проблемы недолинуксов и недоосей.
Какая в попу разница чьи это проблемы. Qt на Андроиде ненативен и все тут.
> О, наконец-то, давно хотел увидеть что-то подобноеНу что же, Виталиф, раз ты давно хотел увидеть нечто подобное, то тебе непременно понравится вот это:
"Write once, run anywhere" (WORA), брать здесь http://java.oracle.com
За концультациями по использованию обращаться к Изе.
Лол этот булщит запустится только на андроиде и то не без правок.
"native" - это в смысле "фиг вы больше одног приложения на ЭТОМ за раз запустите!" ? =)
ЕМНИП, для андроида "native" - это значит "бинарный код, исполняемый непосредственно процессором, а не байткод, исполняемый в Dalvik", что там с ios и wm - хз, не интересовался.
К сожалению, в iOS всё сильно лучше. У них полноценный компилируемый в нативный байткод язык без сборщика мусора. Посему и приложения у них работают раза 2 быстрее и потребляют памяти раз в 10 меньше.
> ... У них полноценный компилируемый в нативный байткод язык без сборщика мусора...Давай подробности про нативный байткод, попкор уже заготовлен, все удобно устроились в своих уютных креслах и просют.
> "native" - это в смыслеЭто в смысла, какая-то буита, не имеющая ничего общего с нативным приложением под платформу, но бьющая себя пяткой в грудь доказать что это не так. Это называется "маркетинговый булшит".
Эк же до сих пор некоторых выбешивает тот факт, что JS с некоторых давних пор стал компилируемым.
То есть, всякие браузерные HTML5 фичи на этом недоступны?
да, плюс тебе еще придется пилить для каждой платформы свой гуй.
нет
С фигали нет то? Или вы думаете что у всех платформ одинаковый API к элементам управления и везде элементы одинаковые?
> С фигали нет то? Или вы думаете что у всех платформ одинаковый
> API к элементам управления и везде элементы одинаковые?сходи по ссылке
>Develop your business logic with JavaScript or TypeScript, design and style your user interface using XML and CSS
Вот для этого поверх них и наворачивают универсальные API. Переписывать морду под каждую платформу никому не в радость.
>>...при помощи специфичной для каждой платформы runtime-прослойкиАга, но мы то знаем что поднимается веб сервер и туда кладется "нативное" приложение. Действительно, а куда еще девать процессорное время 8-ти ядерного смартфона?
нет
веб-сервер - это вообще одна из легчайших задач
"мы-то знаем, что поднимается веб-сервер", позорище
Точку не поставил в конце. Позорище.
> Точку не поставил в конце. Позорище.Воспрепятствование законной деятельности Grammar Nazi, находящегося при исполнении служебных обязанностей?!? Ты очень рискуешь.
А вам не кажется, что нужно уже адаптировать интерробанг для русского языка и требовать его применения‽
> А вам не кажется, что нужно уже адаптировать интерробанг для русского языка
> и требовать его применения‽Нет, не кажется. Чтобы я отказался от контроля над количеством вопросительных и восклицательных знаков, их соотношением и последовательностью в пользу какого-то непонятного возБУХательного знака?!? Да никогда!!!
А вы часом не старый пердун ли, батенька‽!з.ы. Кстати, я как-то думал как этот знак мог бы называться. Ваш вариант мне пока больше всего нравится. А то обозвали бедолагу вопроцательным, что суть передаёт лишь отчасти.
> А вы часом не старый пердун ли, батенька‽!А то как же!?! Именно так.
> ‽!
Хорошая идея, но всё же недостаточно хорошая. Сочетая новый знак с традиционными, можно менять пропорцию восклицание-вопрос, но не последовательность. "‽" может означать как "!?", так и "?!". А для меня это две большие разницы.
> А для меня это две большие разницы.Какаянахренразница?
Подловил :-)
Сударь, нет, вы не правы. Мы не знаем, это вы так знаете. А мы знаем как на самом деле все происходит. И вам бы не мешало.Вот "Веб-сервер (значение)" - https://ru.wikipedia.org/wiki/%D0%92%D0%...
Очередная инкарнация идиотской идеи. Мало того, что любой из "нативных" языков более удобен для разработки, чем JS, мало того, что нативные инструменты дизайна гуя для любой из платформ на голову выше, чем CSS - так ещё и сам дизайн (а часто - и сама логика работы) для каждой платформы должен быть своим - иначе получается не приложение, а неудобное не пойми что. Не, можно фронт и бэкэнд разделить - но делать универсальный бэкэнд на JS - уж очень странное извращение.
> мало того, что нативные инструменты дизайна гуя для любой из платформ на голову выше, чем CSSда, давайте будем писать ios+mac в xcode, windows в vs, linux в чём-то ещё, android в android studio. и одно и то же приложение создавать и поддерживать аж в пяти экземплярах.
мобильные разработчики почему-то уже ленятся для ios и android делать разные приложения и покупают xamarin т.к. это дешевле с точки зрения бизнеса. универсальной и бесплатной gui-платформы под mac, win, linux, ios и android -- пока нет. но рынок её хочет.
>универсальной и бесплатной gui-платформы под mac, win, linux, ios и android -- пока нет. но рынок её хочет.Qt?
Под ios и андроид? Вы это пробовали?
следующий вопрос: как вам понравилась common codebase для этогш всего и удобство gui-дизайнера?
А с чего ты взял что остальные принципиально лучше? И да, у кутей есть преимущество: на них есть програмы заслуживающие внимания. А ваш мобилочный шит оставьте хомякам - без лоха жизнь плоха, не так ли? :)
> А с чего ты взял что остальные принципиально лучше?Какие остальные? Я начал с того, что адекватного инструмента, тем более бесплатного, пока нет. Про Qt я в курсе.
Перечитай диалог.
>> А с чего ты взял что остальные принципиально лучше?
> Какие остальные? Я начал с того, что адекватного инструмента, тем более бесплатного,
> пока нет. Про Qt я в курсе.Да эка невидаль. Припёрся некто йю в трэд и жирно смачно соврал. Потом ещё раз. Тут таких как грязи - проходи не задерживай :)
> Перечитай диалог.
Лучше уж труды профессора Выбегайло ... всё больше толку будет :)
>>> А с чего ты взял что остальные принципиально лучше?
>> Какие остальные? Я начал с того, что адекватного инструмента, тем более бесплатного,
>> пока нет. Про Qt я в курсе.
> Да эка невидаль. Припёрся некто йю в трэд и жирно смачно соврал.Покажите ваш проект на куте под андроид и иос, потом видно будет, кто соврал.
Qt в плане мобильного девелопмента под несколько распространённых платформ -- увы, не фонтан.
> Qt в плане мобильного девелопмента под несколько распространённых платформ -- увы, не фонтан.Это пока.
> пока нет.Да вот знаете, гибрид подводной лодки и самолета делать пытались наверное лет сто. А как получалось г-но, так и получается. И чего бы это вдруг? Может секрет в том что вода и воздух сильно разные по свойствам? :)
Это не значит, что не нужно пробовать. Просто текущего уровня технологий пока ещё недостаточно для того, чтоб напрочь игнорировать эту разницу. Но если не пробовать, то никогда и не получится.
> Под ios и андроид? Вы это пробовали?Пробовал под венду, мак и линь. А что, с айосом и андроидом все так плохо?
>> Под ios и андроид? Вы это пробовали?
> Пробовал под венду, мак и линь. А что, с айосом и андроидом
> все так плохо?похуже, чем с вин-мак-лин, да
> похуже, чем с вин-мак-лин, даА вы на этом чуде природы сделайте что-нибудь под вин-мак-лин и посмотрим наскольо лучше оно будет ;)
> А вы на этом чуде природы сделайте что-нибудь под вин-мак-лин и посмотрим
> наскольо лучше оно будет ;)popcorn time для десктопа вообще на nw.js и ничего
> popcorn time для десктопа вообще на nw.js и ничегоИ правда, "ничего": я вообще ни одного живого пользователя этой штуки не видел. Штиль. А так то да, то что можно удалять гланды через ж...у автогеном - я и не сомневался вроде.
нее, GTK
> нее, GTKСкейлинг-то уже запилили или всё так же хреново с мобильными девайсами и high dpi-дисплеями?
>пока нетQt
дайте ссылку на ваш проект на qt для android, ios и десктопа, поговорим детальнее
Не дам. Но под андроид и нормальную систему у меня код почти одинаков. IOS не использую и что там происходит не знаю.
вы про функциьнальность в свежием 5.4 или Necessitas?
Я писал где-то полтора года назад. Сомневаюсь, что ситуация стала хуже сейчас. А тогда были небольшие проблемы с некоторыми виджетами, но в общем и целом было юзабельно.
> Я писал где-то полтора года назад. Сомневаюсь, что ситуация стала хуже сейчас.Речь таки про несесситас или стоковый куте?
> А тогда были небольшие проблемы с некоторыми виджетами, но в общем
> и целом было юзабельно.Очень многое зависит от того, что вы делаете, какие сторонние библиотеки вам нужны, насколько нативный ui, ну и т.д.
Обычный Qt, без каких-либо несесситас.
>какие сторонние библиотеки вам нужныКакая разница? Они собираются и ладно.
>насколько нативный uiНе знаю что эта фраза значит, но интерфейс я рисовал в десигнере...
> Обычный Qt, без каких-либо несесситас.Тогда для понимания мне нужна версия Qt и то, как вы собирали это под андроид.
>> насколько нативный ui
> Не знаю что эта фраза значит, но интерфейс я рисовал в десигнере...Она значит, что под разные ос приложения выглядят и ведут себя по-разному. Большую часть разницы вин-мак-линукс Qt сглаживает. С мобильными платформами чуть сложнее.
>Тогда для понимания мне нужна версия Qt и то, как вы собирали это под андроид.Где-то в недрах IDE-шки был пункт "проект под андроид".
>приложения выглядят и ведут себя по-разному.Ведут? Я ещё могу поверить про выглядят (хотя и не наблюдал такого), но ведут... Не-не-не...
> Где-то в недрах IDE-шки был пункт "проект под андроид"qtdevelop? Найдите версию Qt, которой собирали apk, это должно быть несложно и дать мне понять, хотя бы, речь о четвёрке или пятёрке. В пятёрке, как я знаю, поддержка андроида появилась лишь недавно.
>>приложения выглядят и ведут себя по-разному.
>Ведут? Я ещё могу поверить про выглядят (хотя и не наблюдал такого), но ведут... Не-не-не...Да наблюдали. В иксах выделение должно копировать в буфер обмена, в винде и маке такого прикола нет, в андроиде выделение вызывает диалог "скопировать". И из сотни таких мелочей складывается то поведение, которое пользователь ожидает от приложения на данном устройстве, т.е. с поправкой на то, что все приложения на его устройстве ведут себя подобно.
> В иксах выделение должно копировать в буфер обмена,Кому должно? С фига должно? Вот у меня ничего никуда не копируется при выделении, пока я этого явно не возжелаю. Зато у меня есть многоуровневый клипборд. О котором программам правда знать совершенно не требуется.
Qt уже давно умеет в iOS и Android.
http://doc.qt.io/qt-5/android-support.html
http://doc.qt.io/qt-5/ios-support.html
ага, аж с 5.4 (конец 2014), судя по оф. доке. очень давно, да.
> ага, аж с 5.4 (конец 2014), судя по оф. доке. очень давно,
> да.не, наврал. с 5.2 (декабрь 2013). два года -- это "очень давно"? ну-ну.
и опять ошибся. год и три месяца, как по мне -- это недавно.
Кхм, сюрприз - именно так и пишется. А что делать - конкуренция большая, гуй, не играющий про принятым на платформе правилам, никому не нужен. Да и кроме гуя различия велики, если у вас что-то большее, чем формочка из двух полей.А что кто-то пытается удешевить разработку за счёт качества и не прогорает сразу - ну так дело времени.
Вы правда мобильные приложения разрабатываете или так, экстраполируете?
> Вы правда мобильные приложения разрабатываете или так, экстраполируете?А куть для начала в отличие от этого мобилочного шита еще и на десктопах нормально работа. А софт на ведроиде и прочих ios такой крап что портировать его на десктоп никто особо и не рвется.
Я понял. Вы к мобилочному софту отношения не имеете -- раз.Про свифти (мак и иос) вы тоже не в курсе.
Я с интересом уже лет 15 наблюдаю за развитием qt, но доля мобильных проектов с её использованием очень мала. Хотите узнать, почему? Напишите один такой.
> Про свифти (мак и иос) вы тоже не в курсе.Да упаси меня боже иметь дело с яблочными фашистами. У них в апсторе условия концлагерные какие-то.
> Да упаси меня боже иметь дело с яблочными фашистами. У них в
> апсторе условия концлагерные какие-то.из россии пишете? удачи в светлом нелагерном будущем.
> из россии пишете? удачи в светлом нелагерном будущем.А вы знаете, я не жалую любых лагерщиков. И эппл в этом плане ничем таким не лучше остальных - лагерщики все одинаковые.
Правда разрабатываю. И очень хорошо знаю, о чём говорю. Вплоть до того, что фичи и архитектура на андроидной и айосовской версиях совпадают далеко не всегда.
> Правда разрабатываю. И очень хорошо знаю, о чём говорю. Вплоть до того,
> что фичи и архитектура на андроидной и айосовской версиях совпадают далеко
> не всегда.тогда реально могу пожелать удачи. у вас коммерчески востребованное дело, позволяющее держать в четыре раза больше программистов, чем могли бы, имея унифицированный инструмент. к сожалению, с этими унифицированными инструментами пока проблема, мы оба это чувствуем, но каждый со своей стороны.
Боюсь, что унифицированный просто не продали бы. User experience - великая вещь.
> Боюсь, что унифицированный просто не продали бы. User experience - великая вещь.вы не alexm@, случайно? или не alexclear?
> универсальной и бесплатной gui-платформы под mac, win, linux, ios и android -- пока нет. но рынок её хочет.Apache Cordova. На десктопе можно запускать в браузере если позаботиться об этом на этапе разработки, например, понаставив кучу проверок типа if(window.plugin)...
> Apache Cordova.И, что, на ней много софта пишут? На nw.js пишут, на замарине тоже, на титаниуме писали, а вот про популярность phonegap в первый раз слышу.
> На десктопе можно запускать в браузере
Вот уж невиданная интеграция в нативный gui, да. Nw.js и то круче.
Насколько я понимаю, вы любите поговорить о том, в чем не разбираетесь. NW.js не предназначен для мобильных приложений ))
что не отменяет, что он предоставляет лучший desktop gui experience, чем phonegap.и вообще, мы не с вами об этом говорили.
>мобильные разработчики почему-то уже ленятся для ios и android делать разные приложения и покупают xamarin т.к. это дешевле с точки зрения бизнеса.И попадают в те 99% фирмочек-*oвнoшлёпoв которые не проживают и года. Вот прям удивил.
А у тех кто живёт (и неплохо) - всё печально, да. Бакэнд на серверах общий, а фронтэнд, уникальный для каждой платформы. Такие дела :)
>>мобильные разработчики почему-то уже ленятся для ios и android делать разные приложения и покупают xamarin т.к. это дешевле с точки зрения бизнеса.
> И попадают в те 99% фирмочек-*oвнoшлёпoв которые не проживают и года. Вот
> прям удивил.Вы работаете в фейсбуке? В вотсаппе? В майкрософте? Да ла-адно?
> А у тех кто живёт (и неплохо) - всё печально, да. Бакэнд
> на серверах общий, а фронтэнд, уникальный для каждой платформы. Такие дела
> :)Ага, и это всё ещё без интернета не работает: бэк-енд-то в интернете.
> Вы работаете в фейсбуке? В вотсаппе? В майкрософте? Да ла-адно?Ну то-есть про *овношлепов и однодневки он видимо угадал :).
> универсальной и бесплатной gui-платформы под mac, win, linux, ios и android -- пока нет. но рынок её хочет.Почему же нет? Cocos2d-x, бесплатна и универсальна.
Конечно, GUI под десктоп и планшет в любом случае разный - так он и в "универсальном" JS будет разный.Писал на С++ с Кокосом приложение для iOS и Андроид. Нет, оно не из одной формочки.
Для iOS - страничка кода на Objective-C, для Android - пара страничек на Java.
Остальной код единый и кроссплатформенный. Собран, соответственно, в Eclipse и Xcode.
Собственно, основная масса кода позаимствована из десктоп-версии программы, но код GUI, конечно, совершенно разный.У того же Кокоса есть и JS-версия, но ее не щупал, ничего не скажу.
Меня смущают два момента:1. Нету нативного интерфейса под мак и линукс. Только через HTML5. Т.е. иос и андроид, но не десктоп.
2. Оно же вроде позиционируется для гейм-дева. Отрасль перспективная, но может быть своя специфика. Я уверен, вы больше меня об этом знаете, расскажите.
Да, там беда с нативными контролами. Рисованные - кнопка и поле ввода, например - есть, и родная экранная клавиатура к этому вводу вызывается без танцев со стороны программиста.
Так что экран с настройками мне вполне удалось сделать. Но на разных платформах он выглядит одинаково, а не по постулатам дизайнеров платформы.
Опять-таки повторю: я не щупал JS у Кокоса. Там вполне может быть сколько угодно гуя.Или, раз уж мы говорим про С++ и гуй все равно отличается для десктопа, можно для десктопного гуя выбирать из доступных библиотек (у меня, скажем, используется wxWidgets).
1. понял поинт насчёт мобильного и десктопного приложения. он имеет место быть. т.е. унификация android + ios -- хорошо, унификация с десктопом -- не факт. впрочем, если бы свифт компилировался под винду, линукс и андроид -- я бы писал на свифте. такого решения пока нет, хоть насколько оно необходимо -- спорно (и, возможно, имеет смысл разделять мобильный и десктопный код).2. wxwidgets ещё живо? я его видел лет десять назад. как у него с наличием графического дизайнера форм в иде? а как с тулчейном для кросс-компиляции, как девелоперу поставить тулчейн, чтобы кросс-компилировать в линукс, мак, винду (на линуксе, маке и винде соотв.)?
1. Если основной код - это гуй, то унификация смысла не имеет. И тут уж действительно можно смотреть на JS-обертки. Если же гуй - это только фронт-энд, то использование С++ обычно оправдано, и издержки на разные гуи не так страшны.
2. wxWidgets скорее живо и вполне юзабельно. Сравнительно недавно доползло до 3 версии. Дизайнеры давно существуют, но я, признаться, не любитель. Кросс-компиляцией не баловался, ибо по большей части мои программки используются под оффтопик.
> Кросс-компиляцией не
> баловался, ибо по большей части мои программки используются под оффтопик.лет десять назад я видел wxwidgets в той же роли. насколько, я понимаю, современные модные десктопные кросс-платформенные gui (virtualbox там или parallers) почему-то тяготеют к qt -- и я могу это понять.
вас зовут алекс? а фамилия начинается не на букву К.? может, мы знакомы?
ой, не, алекс в другом треде был, сорри. видимо, мимо.в любом случае, в последнее время я вижу больше активности вокруг qt, чем wxwidgets -- и я могу понять, почему.
если можно, кратко черкните, почему, имея оффтопик и плюсы, вы предпочитаете wxwidgets, а не qt.
Мимо - и зовут меня иначе, и знакомых программистов у меня нет.
Про wx получится совсем кратко - когда делался выбор, он уже был LGPL, а кьют - нет. Ну, а потом выкинуть наработки и начать с нуля всегда не находится времени, даже если бы захотелось. Впрочем, и нужды пока не было - хватает wx.
Мобильный разработчик - это, в смысле, разработчик-неинвалид?
Товарищ в костюме мега-разработчика, расскажите, а сколько вы лично сделали "многоплатформенных приложений"? Насколько они были успешны? Тысячи/миллионы продаж? И на всех этих платформах не было аналогов ваших изделий? Каждая ли платформа оправдала вложенные в "многоплатформенность" деньги? Все пользователи всех платформ довольны внешним видом ваших приложений? Их юзабилити? А сколько квалифицированных саппортов у вас работает и сколько платформ они могут обслужить? Вас знают на всех трёх мобильных площадках и десктопных файлопомойках?Спрашиваю, потому что заранее знаю ответ - кроме ТРЫНДЕНИЯ про "многоплатформенность" ничего хорошего от трындельщиков не выходит - не могут они ни инструмент найти, ни написать толком, ни маркетинг провести, ни даже толком ответить "а кому вообще нужна ваша свистелка".
Многоплатформенность - это миф от (и для) тупых и ленивых индусов. Её никогда не было ни в одном продукте, а где она появлялась, представляла из себя жалкий гибрид павлиноуткоежа, всё равно не дающего "нативного" выхлопа. Можно бесконечно оттачивать внешний вид "как бы многоплатформенных" виджетов, и всё равно где-то вылезет несоответствие поведению "родных" компонент. Это не говоря об убогом "универсальном" бэкенде, обеспечивающем "наибольший общий делитель" всех платформ и очевидно уступающем каждому из поддерживаемых API.
Итого, прежде чем заикаться о каких-то многоплатформенностях (где нередко подразумевается всего лишь Линукс/Винда/Макось), лучше спросить себя вопросы в начале коммента и прекратить маяться дурью. Любой нишевый профессионал напишет в сто крат более полезное приложение, чем все эти бывшие похапэшные "умельцы", ищущие "один на всё" инструмент.
Ты такой умный, я аж теку.А скажи-ка, сколько стоит один нишевый профессионал? А три нишевых профессионала под каждую платформу? А где взять деньги на трех нишевых профессионалов в начале пути потенциально перспективного стартапа, чью перспективность, собственно, еще предстоит проверить? А почему в _реальном мире_ получается так, что сначала появляется приложение под iOS, потом, спустя долгое время под Android, а чтобы оно появилось под Windows Phone пользователям вообще молиться приходится?
> А почему в _реальном мире_ получается так, что сначала появляется приложение под iOS, потом, спустя долгое время под Android, а чтобы оно появилось под Windows Phone пользователям вообще молиться приходится?По причине бабла, естественно.
Яблочники - жирная аудитория, меньше андроидной, но легче расстающаяся с деньгами (собственно, яблофон работает как индикатор). Андроид - аудитория тощая, но большая, глядишь, накапает по копеечке. А вот связываться с теми дурнями, которые все еще пользуются WP, просто нерентабельно - они и платить не хотят, поскольку на Виндах привыкли пиратить, так вдобавок их тупо мало.Однако там, где решает не маркетинг, а технарь, первым вполне может выйти приложение под Андроид. Его и написать легче, и в магазин положить. У Яблока к разработчику постоянно обращено альтернативное лицо - любой багфикс две недели маринуют...
Вот именно, твой ответ очевиден. И сабж может в корне поменять подход к запуску новых сервисов. Он позволит сразу на всех аудиториях провести исследования, а дальше уже можно будет принимать решение о том, разрабатывать ли нативные приложения или сервис никому не нужен.
Это слишком сферичное предположение. Есть приложения, где нативный клиент реально имеет смысл, и их разработка на абы-как-движке, чтобы потом ее выкинуть, будет дорогим удовольствием. Да еще, глядишь, и отпугнет аудиторию получившимся монстром...
Этот движок, полагаю, как раз для того сонмища как-бы-программ, которое все равно, на чем писать.
О том и речь. Сонмище создает спрос на подобные фреймворки. А те кто этого не понимает пытаются доказать на примере единичных приложений, что они, фреймворки, вообще не нужны.
Пусть тогда эти разработчики своим говном и пользуются. А то вообще уже умом тронулись денег за такую халтуру просить. Лень им видите ли.
Как твой комментарий относится к сабжу? Ты веткой не ошибся?
Не ошибся.Если ты не понял - "универсальных мобильных приложений для платформ iOS, Android и Windows Phone" хоть сколько-нибудь приличного качества не бывает в природе - платформы слишком разные.
При этом разработка на JS, пожалуй, выйдет дороже, чем создание отдлельного кода для iOS и Android - там хоть средства разработки приличные есть, в отличие от.
Вы точно в курсе, сколько стоит добавить одну незначительную галочку в приложение:1. Если это пять различных приложений на разных яп, делаемых разными командами?
2. Если это common codebase?Если да и вы по-прежнему говорите, что пять codebase рулят, вы делаете мобильные приложения для газпрома, не меньше.
> 2. Если это common codebase?А вы в курсе про анекдот про автоматическую машину для бриться? Вот пользоваться такими программами примерно так же приятно как машиной для бритья, которая подравнивает всем физиономию до общего знаменателя.
>> 2. Если это common codebase?
> А вы в курсе про анекдот про автоматическую машину для бриться? Вот
> пользоваться такими программами примерно так же приятно как машиной для бритья,
> которая подравнивает всем физиономию до общего знаменателя.и это мнение адвоката qt-программ на андроид и иос? Ну-ну
Пять команд? Ну-ну. Кстати, для "незначитльеной галочки" даже на пяти платформах цена будет одной и той же - потому что для добавить её - пять минут, а вот протестировать гуй - существенно больше, а тестировать всё равно на каждой платформе отдельно (а на Андроиде/иОС - ещё и не на одном устройстве).А ещё я в курсе, как эта "незначительная галочка" на доной из платформ заканчивается рефакторингом и шаманскими пляскамипотому что платформа такого вообще не даёт. Поэтому подход "по приложению на платформу" запросто оказывается практичнее. И уж тем более нет ничего общего в функционале десктопного приложения и мобильного - если десктоп ещё кому-то нужен.
Ну и да, если логика сложная - бэкэнд пишется общий, на плюсах - их везде засунуть можно. В общем и целом - вполне подъёмно всё это, что я и наблюдаю вокруг себя. И это определённо не газпром.
> если десктоп ещё кому-то нужен.да вот тут выше со мной спорят, что десктоп -- это наше всьо, а андроид и иос -- для неудачников.
повторюсь -- мы оба сходимся в том, что сейчас нет реального инструмента для унификации между платформами. разногласие в том, что вы считаете, что это нормально, а я думаю, что всё может быть ещё лучше. тут пока нет противоречия, посмотрим, что будет через какое-то время.
>> 1. Если это пять различных приложений на разных яп, делаемых разными командами?Вы какой-то чересчур уж крайний случай рассматриваете.
Мы делаем игры под ios, android, winPhone, всякие амазоновские девайсы и т.д. - вполне обходимся одной кодовой базой на с++ и несколькими врапперами для платформ и для этого не нужен JavaScript.
Конечно, у нас в играх свой гуй (и вообще я мимо шел), но ваши противопосталения все равно имеют фантастический характер.
Выше почитайте про gui experience и gui designer'ы для нативных платформ.Само по себе наличие ios+android+wp в одной codebase -- не повод для гордости. Хотя, выше меня убеждают, что ios надо разрабатывать в xcode, wp -- в vs, android -- в android studio, даже если это три codebase.
> Выше почитайте про gui experience и gui designer'ы для нативных платформ.Да, я понимаю, что встрял немного сбоку от темы.
> Само по себе наличие ios+android+wp в одной codebase -- не повод для
> гордости.Безусловно) Это была констатация.
> Хотя, выше меня убеждают, что ios надо разрабатывать в xcode,
> wp -- в vs, android -- в android studio, даже если
> это три codebase.Вообще, звучит разумно. Или, хотя бы, практично. Хотя это вопрос, скорее, к конкретному программисту - в чем ему код писать.
> Хотя это вопрос, скорее, к конкретному программисту - в чем ему код писать.Это также и вопрос того, сколько программистов нужно. Есть разница, писать ли новую галочку три раза в трёх ide либо один раз в одной. Тестировать надо будет столько же, но это как раз вопрос написания и поддержки codebase. Один вопрос -- один кодер и два тестера, другой -- три кодера (синьоров, feature request же) и два тестера.
>> Хотя это вопрос, скорее, к конкретному программисту - в чем ему код писать.
> новую галочку три раза в трёх ide либо один раз в
> одной.Не понял тезиса. Зачем писать галочку три раза в трех ide? Можно написать один раз в одной и (N.B.!) сохранить! Я вообще не понимаю, какая разница в какой иде код пишется?
Разница в том: есть исходный код, который идёт в app store, google play и мс-маркет. Есть приложение, цель: добавить новую галочку.1. Если три команды программистов пишут разный код под три платформы, они пишут его три раза.
2. Если одни девелоперы пишут код, который компилируется под wp, ios & android, программистов надо меньше.Тот момент, на котором вы появились в дискуссии, был следующий конфликт:
- Писать один раз под все мобилки выгодно
- Чтобы приложение было качественным, надо писать его код три раза, это будут разные codebaseУ вас общий код между платформами, т.е. вы понимаете плюсы унификации. У нас с вами нет противоречия, объясните моему оппоненту, почему иметь общую codebase на несколько мобильных платформ -- это хорошо. :-)
> - Чтобы приложение было качественным, надо писать его код три раза, это
> будут разные codebaseНи разу не видел ничего подобного, разве что при написании дров)
Не понимаю, какие фичи в "софте под мобилки" требуют окупают это?> У вас общий код между платформами, т.е. вы понимаете плюсы унификации. У
> нас с вами нет противоречия, объясните моему оппоненту, почему иметь общую
> codebase на несколько мобильных платформ -- это хорошо. :-)Видимо, я где-то не вкурил иронию.
Не нравится не ешь. Это же мечта, одна программа для 3х мобильных ос.
Не правда, javascript один из самых удобных языков в плане написания кода и использования библиотек, в любом случае удобнее чем плюсы и сишка. css очень хорош для установки стилей, поэтому его УЖЕ используют на десктопе(темы gtk,например). Просто ты не разобрался с js
Я надеюсь там нет DOM
Круто! Они изобрели Apache Cordova / Phonegap!
Еще один не осилил прочитать пару строк новости.
> Еще один не осилил прочитать пару строк новости.Не осёлил.
Ничиво ни меняет!!!
Есть некоторое отличие от PhoneGap, а именно использование API для интерфейса.
Так что считайте, что Вам сделали кросплатформенный интерпретатор JS с родным(native) связыванием(binding) с UI платформы.Ref.: Вместо WebView для интерфейса используются родные для каждой платформы движки отрисовки.
Можно не благодарить.
Задолбали уже эти халтурщики с вебом головного мозга. Начитаются всякой хипстерской белиберды и лезут клепать стильные, модные, молодежные приложения на скриптах под все платформы без разбора. Гнать таких тряпками с магазинов и не пускать до тех пор, пока не выучат родной API.
Согласен. Они думают, что JS - это язык длля п-я, хотя на самом деле это "язык написания OnClick'ов". :)
А что в этом плохого?
Он динамический. Со временем код превращается в лапшу коллбэков, которую очень сложно поддерживать. Дебага не завезли. Референсной имплементации нет, поэтому каждый пейсатель интерпретатора дро..т как хочет.
> Он динамический.Если использовать с умом - в скорости отличий на глаз не заметите.
> Со временем код превращается в лапшу коллбэков, которую очень сложно поддерживать.
Это звучит как необоснованный страх перед JS-коллбеками. Всё отлично поддерживается если правильно организовано. Внезапно - если правильно организовать, нет никаких проблем в разработке даже таких монстров на JS как Google Docs.
> Референсной имплементации нет, поэтому каждый пейсатель интерпретатора дро..т как хочет.
Странно слышать минусом фреймворка отсутствие экосистемы вокруг него во время анонса пре-релизной версии.
Короче, минусы натянутые и выглядят как попытка прикопаться.
>Если использовать с умом - в скорости отличий на глаз не заметите.Tell me moar...
>Это звучит как необоснованный страх перед JS-коллбеками. Всё отлично поддерживается если правильно организовано. Внезапно - если правильно организовать, нет никаких проблем в разработке даже таких монстров на JS как Google Docs.
Мусье писал что-то сложнее хэллоу ворлда? Я в проекте их 50к классов на джаве теряюсь, иногда даже средства поиска в IDE и grep не особо помогают разобраться как же вся эта хрень должна работать и это без всяких коллбэков.
>Странно слышать минусом фреймворка отсутствие экосистемы вокруг него во время анонса пре-релизной версии.
Какой фрэймворк? Я про интерпретатор JS. Спецификации не могут покрыть все случаи, для этого нужна референсная имплементация (см. пример Java EE).
> Tell me moar...
> Мусье писал что-то сложнее хэллоу ворлда? Я в проекте их 50к классов на джаве теряюсь, иногда даже средства поиска в IDE и grep не особо помогают разобраться как же вся эта хрень должна работать и это без всяких коллбэков.Мусье работает в известной российской компании разработчиком сопоставимых по сложностям гугловским проектов. Мусье знает о чем говорит и с недоумением смотрит на барахтание Java-кодера. Может ты не настолько крут, каким себе кажешься, сверху вниз посматривая на фронтендщиков?
> Какой фрэймворк? Я про интерпретатор JS. Спецификации не могут покрыть все случаи, для этого нужна референсная имплементация (см. пример Java EE).
Ок, я понял о чем речь. Написано же что внутри у него V8. А еще написано что программировать можно на TypeScript. Если ты считаешь что разбираешься в вопросе, почему такие вещи проигнорировал и бросился опускать сабж?
> Мусье работает в известной российской компании разработчиком сопоставимых по сложностям
> гугловским проектов.Зачем такой длинный синоним к слову "говнокодер"?
>нет никаких проблем в разработке даже таких монстров на JS как Google DocsЕсли всё так хорошо и прекрасно, то зачем Гугль сделал Dart?
Затем, что всегда можно сделать еще лучше.
Отличные новости. Хоть какая то перспектива заработать на яхту) Поддержка typescript это очень и очень хорошо. Конечно скорость не Си но для маленькой инди студии хороший инструмент. Экономия времени и сил разраба.
