Comments 54
Первый раз слышу о таком, интересно. И приятно, что прям native-native.
Хотелось бы увидеть статью: «Вот у нас мокап калькулятора» -> «Вот код» -> «Вот нюансы под iOs» -> «Тут мы берем и подключаем push'и да камеру» -> «магия» -> «Вот у нас готовые приложения под обе платформы»
Хотелось бы увидеть статью: «Вот у нас мокап калькулятора» -> «Вот код» -> «Вот нюансы под iOs» -> «Тут мы берем и подключаем push'и да камеру» -> «магия» -> «Вот у нас готовые приложения под обе платформы»
Калькулятор — это просто, пока что в планах на январские выходные — трекинг финансов.
Состоять это дело будет из {N}+Angular+ngrx/store+Firebase.
Состоять это дело будет из {N}+Angular+ngrx/store+Firebase.
Я тоже в своё время заинтересовался Angular 2 + Ionic 2 (конкурент NativeScript и в каком то роде аналог) и за 2 недели сделал приложение для учёта долгов. И уже второй код допиливаю до состояния продукта — альфа/бета, интеграция с соцсетями, боты для Телеграм и Вайбера и т.п.
Что нравится в подходе Ionic и NativeScript что можно тот-же код для web-приложения использовать.
Я например прямо на сайте выкладываю live-demo чтобы сразу понятно было как будет выглядеть и работать приложение на мобиле — DebtsTracker.io
Что нравится в подходе Ionic и NativeScript что можно тот-же код для web-приложения использовать.
Я например прямо на сайте выкладываю live-demo чтобы сразу понятно было как будет выглядеть и работать приложение на мобиле — DebtsTracker.io
Скажите, а если закончатся бюджетные деньги и у вас все гикнется, что будут делать бедные разработчики со своей кодовой базой под стремительно стареющий фреймворк, который больше не поддерживается?
Какой фреймворк не поддерживается? Angular 2 в самом расцвете, nativescript точно так же.
И какие бюджетные деньги?:)
И какие бюджетные деньги?:)
Вот знаете, абсолютно нет ощущения, что NativeScript в самом расцвете, скорее на стадии отчаянной альфы. Рассматривали тут месяца два назад — проблемы с документацией (точнее примерами на гитхабе — не все даже компилируется/работает, а Telerik и не в курсе). Проблемы с количеством существующих компонентов (ну вот карт, например, не было). Можно да, написать свою собственную обертку. И над iOS, и над Android. Ужасным синтаксисом. Только вот не вижу тут тогда никакой выгоды.
Как результат, сделали вывод — Todo-list приложения писать можно :) А еще, как еще один результат, пришлось чуть-чуть пожить с ужасающим аддоном к VS и кучей спама от Телерика.
Как результат, сделали вывод — Todo-list приложения писать можно :) А еще, как еще один результат, пришлось чуть-чуть пожить с ужасающим аддоном к VS и кучей спама от Телерика.
Если для вас синтаксис TS ужасен — я даже не знаю, что предложить:)
По поводу не компилируется — тестил различные модули и продолжаю с ними работать, стоило создать issue, вам бы помогли.
Ужасающий аддон? Для VS Code и WebStorm есть достаточно хорошие плагины.
По поводу не компилируется — тестил различные модули и продолжаю с ними работать, стоило создать issue, вам бы помогли.
Ужасающий аддон? Для VS Code и WebStorm есть достаточно хорошие плагины.
синтаксис TS то не ужасен, это просто я криво выразился :) Ужасно различное количество доп. плясок вокруг всего этого для создания врапперов — http://docs.nativescript.org/plugins/ui-plugin
Все проблемы с документацией (вот код по линку в предыдущем абзаце — не работал) были пофиксены где-то в ноябре, спустя месяц как мы на него пожаловались. Нет, ну можно сказать что помогли :) Я не говорю, что этим невозможно пользоваться — я говорю о том, что при выборе стратегии мобильного девелопмента на длительное время вперед, это не то, что я лично готов выбрать или кому-то порекомендовать.
PS: Под ужасающим я имел в виду примерно ту кучу спама (в виде попапов, доп. окошек, доп. таргетов output'ов, которые почему-то на каждый перезапуск по дефолту выбираются и т.д.), которую он везде прокидывал.
Все проблемы с документацией (вот код по линку в предыдущем абзаце — не работал) были пофиксены где-то в ноябре, спустя месяц как мы на него пожаловались. Нет, ну можно сказать что помогли :) Я не говорю, что этим невозможно пользоваться — я говорю о том, что при выборе стратегии мобильного девелопмента на длительное время вперед, это не то, что я лично готов выбрать или кому-то порекомендовать.
PS: Под ужасающим я имел в виду примерно ту кучу спама (в виде попапов, доп. окошек, доп. таргетов output'ов, которые почему-то на каждый перезапуск по дефолту выбираются и т.д.), которую он везде прокидывал.
Еще добавлю к sAntee. Лучше держитесь по дальше от Telerik, мы работали с продуктами этой компании и от них у нас были одни проблемы + ужаснейший саппорт.
Лично мне больше интересно, можно ли как-то разрабатывать кроссплатформенно, находясь в винде/линуксе. Теоретически я понимаю, что можно поднять виртуальную машину с макосью, и на ней билдить через консольные xcode tools.
Практически — не представляю как всё это вообще поднять, и какую IDE для разработки использовать.
Практически — не представляю как всё это вообще поднять, и какую IDE для разработки использовать.
Под виндой можно легко разрабатывать под андроид, ios — тут уж извините, можно арендовать сервер и пробрасывать билд через него.
Из IDE-лично рекомендую WebStorm.
Из IDE-лично рекомендую WebStorm.
Любую IDE для javascript
Можно использовать PhoneGap. В облаке у них приложения собирать для iOS. Как вариант.
А как насчёт установить макось в виртуалке? У меня коллега так делает, работая на винде.
ReactNative ограничивает вас в компонентах
Не понимаю, это как?
Не так выразился.
Чтобы использовать CocoaPods/AA в react-native вам придется писать соответствующие классы на objC/Java.
Создавать, так скажем, мост между ними.
Однако вызывать нативные библиотеки, не JS — у вас не получится из JS'а.
Чтобы использовать CocoaPods/AA в react-native вам придется писать соответствующие классы на objC/Java.
Создавать, так скажем, мост между ними.
Однако вызывать нативные библиотеки, не JS — у вас не получится из JS'а.
Спасибо.
По этому преимущества {N} не совсем очевидны (если они конечно есть).
По этому преимущества {N} не совсем очевидны (если они конечно есть).
На сколько я знаю в React Native, там тоже можно подключать через NativeModule (тот же самый мост), преимущества по сравнению с NativeScript не вижу. Если есть подробнее, можете изъяснить в чем же отличие то что описали выше?
Я правильно понял, что в основе — что-то вроде js-ctypes? Или получилось удобнее? (использование js-ctypes всё-таки включает в себя кучу возни и великолепные возможности для выстрела себе в ногу)
Выстрелить себе в ногу вам не даст execution flow.
Для начала, вам не дает выстрелить себе в ногу TypeScript(по понятным причинам, compile-time type-checking).
Затем во время уже исполнения, вам будет мешать TypeConversion, если что-то пойдет не так — вам укажут где и почему.
Но опять-таки, возвращаясь к теме TS — его не просто так выбрали для Ангуляра, он действительно не дает вам возможности пострелять вдоволь.
Вообще, Telerik предоставляет декларацию типов для всех нативных вызовов. Для тех модулей, которые вы пишите сами — вы так же можете описать декларацию, заранее уберегая себя и дальнейших разработчиков от проблем с типизацией.
Для начала, вам не дает выстрелить себе в ногу TypeScript(по понятным причинам, compile-time type-checking).
Затем во время уже исполнения, вам будет мешать TypeConversion, если что-то пойдет не так — вам укажут где и почему.
Но опять-таки, возвращаясь к теме TS — его не просто так выбрали для Ангуляра, он действительно не дает вам возможности пострелять вдоволь.
Вообще, Telerik предоставляет декларацию типов для всех нативных вызовов. Для тех модулей, которые вы пишите сами — вы так же можете описать декларацию, заранее уберегая себя и дальнейших разработчиков от проблем с типизацией.
В чем приемущество перед ReacNative совершенно не ясно. За ReactNative стоит FB и его используют уже AirBnb и другие гиганты и у меня нет сомнений в его будущем. Будущее же Native Script очень сомнительно. Я в своей компании, пытаюсь организовать переход с нативной разработки на ReactNative, так как это позволит нам больше и быстрее проводить эксперименты и a/b тестирования без обновления приложения в сторе. Если у вас этой культуры нет и не предвидится, то я бы трижды подумал, почему не писать нативный код для каждой платформы.
Вы планируете использовать CodePush, который точно так же будет введен и для NativeScript.
NativeScript развивается Telerik и только начинает свой путь в связке c Angular.
Возможно, когда-нибудь он станет AngularNative;)
Команда Angular тесно сотрудничает с Telerik, Microsoft тесно сотрудничает с Angular.
Все просто:)
Выбирая же путь ReactNative — вы выбираете путь react, NativeScript — angular.
Все зависит от того, с чем уже работала ваша команда, если у вас есть опыт с Angular2 — выбор очевиден.
NativeScript развивается Telerik и только начинает свой путь в связке c Angular.
Возможно, когда-нибудь он станет AngularNative;)
Команда Angular тесно сотрудничает с Telerik, Microsoft тесно сотрудничает с Angular.
Все просто:)
Выбирая же путь ReactNative — вы выбираете путь react, NativeScript — angular.
Все зависит от того, с чем уже работала ваша команда, если у вас есть опыт с Angular2 — выбор очевиден.
UFO just landed and posted this here
Поправлю, VirtualDOM.
Суть меняется, но не столь критично. При изменении состояния компонента все-равно идет проверка, нужно ли его ререндерить.
Суть меняется, но не столь критично. При изменении состояния компонента все-равно идет проверка, нужно ли его ререндерить.
С чего вы решили, что в ReactNative используется DOM?
Очень интересная статья. Буду ждать продолжения.
Хочется увидеть полный цикл разработки от настройки IDE до компиляции.
Идея хорошая и возможности интересные.
Хочется увидеть полный цикл разработки от настройки IDE до компиляции.
Идея хорошая и возможности интересные.
Я правильно понимаю, что получился прямой аналог Xamarin.Forms (даже разметка с местным XAML схожа до степени смешения), только на яваскрипте и ещё более тормозной?
Производительность у nativescript проигрывает только при запуске приложений, маршаллинге примитивов.(информация годичной давности, {n} был версии 1.3-1.4, сейчас 2.4.
Однако при этом, сам fps стабильно выдает 60 кадров, при маршаллинге комплексных переменных NS проигрывает только нативному коду.
История с запуском лечится lazy-loading'ом.
Конкретно сейчас по цифрам сказать можно одно, где-то NS будет быстрее, где-то медленнее, но на UX это не скажется никак.
С XAML'ом похоже засчет того, что оба были построены на xml.
Вот только XAML вышел слегка ущербным, а здесь при дополнении ангуляром мы получается очень удобный и мощный инструмент для создания шаблонов
Однако при этом, сам fps стабильно выдает 60 кадров, при маршаллинге комплексных переменных NS проигрывает только нативному коду.
История с запуском лечится lazy-loading'ом.
Конкретно сейчас по цифрам сказать можно одно, где-то NS будет быстрее, где-то медленнее, но на UX это не скажется никак.
С XAML'ом похоже засчет того, что оба были построены на xml.
Вот только XAML вышел слегка ущербным, а здесь при дополнении ангуляром мы получается очень удобный и мощный инструмент для создания шаблонов
Ну коли полезли в лес, покажите, на основе чего вы решили, что разметка ангуляра менее ущербна, чем xaml. А то, судя по статье и комментам, выглядит, что, скрываясь за крайне интересным NS, вы пытаетесь продать ng2. Не надо так
Ng2 продают другие, а по поводу сравнения xaml с ng2 — Все очень просто, разметка в ангуляре удобнее за счет его директив, т.е. это и циклы в разметке, и условия, ngIf,ngFor(в xaml'е отсутствует)
Conditional's в xaml'е устанавливаются через триггеры(что увеличивает лэйаут на N строк.
Согласитесь, куда более удобно написать:
[class.active]=«isActive», чем писать в через триггеры и сеттеры.
А по поводу крайне интересного NS — все верно, он интересен, но в связке с ng2 он становится в разы интереснее, тут вам и встроенный DI, и шаблоны, и структурные директивы.
Никто не запрещает писать на чистом NS, но гораздо удобнее все-таки в связке с ng2.
Conditional's в xaml'е устанавливаются через триггеры(что увеличивает лэйаут на N строк.
Согласитесь, куда более удобно написать:
[class.active]=«isActive», чем писать в через триггеры и сеттеры.
А по поводу крайне интересного NS — все верно, он интересен, но в связке с ng2 он становится в разы интереснее, тут вам и встроенный DI, и шаблоны, и структурные директивы.
Никто не запрещает писать на чистом NS, но гораздо удобнее все-таки в связке с ng2.
С точки зрения мобильной разработки мне всегда интересно, а сколько рантайма такие приложения будут тащить с собой? Во времена прошлые оно тащило 12+ мегабайт V8 в дополнение к другим ресурсам, которые вместе с запущенным приложением занимают место в оперативке. А как сейчас?
Ничего не изменилось, все улучшения были сделаны в пользу уменьшения нагрузки на cpu/gpu.
Извините за дилетантский вопрос — а насколько это важно/критично? Можно где то об этом почитать?
А то вот не могу понять нужно ли включать в моё приложение на Ionic Crosswalk или нет.
А то вот не могу понять нужно ли включать в моё приложение на Ionic Crosswalk или нет.
Самое очевидное вот, статья старая, но принцип думаю сильно не поменялся. Менее очевидное касается странных конфигураций андроидофонов, на которых весьма немного памяти, и +12мб там — много.
UFO just landed and posted this here
Для андроида сейчас пока что тащит тоже, разве что можно исключить ненужные ABI (x86, arm64-v8a, armeabi-v7a) путем ручного выпила по соответствующему пути и указанию в конфиге. Каждая ABI весит как раз чуть больше 4 Мб.
а что с производительностью? смотрел демки от Телерик на андроид устройстве — оно реально подтормаживало, там где Cordova не сказать бы что летал, но работал хорошо. А тут еще ng2 добавили…
Вызов нативного апи одновременно заманивает и настораживает. Действительно любое нативное апи можно вызывать со всей спецификой из NS или только для которого позаботились написать интерфейс? К Objective-C и Java можно гарантировано не обращаться по задачам оптимизации, реализации js api к сторонним нативным компонентам? Можно пример работы с 2D графикой (нарисовать полигон)?
Действительно любое, если вдруг какого-то нативного метода нет в декларации, достаточно просто его описать(тип возвращаемого значения и параметры)
Работа с 2д — специфична для каждой платформы, есть плагины, которые уже реализуют подобное, достаточно их подключить, описав common функции и специфичные для каждой платформы(думаю, здесь понятно, один плагин будет иметь свою спецификацию для андроида, второй будет из cocoapods).
Чуть позже приведу пример
Работа с 2д — специфична для каждой платформы, есть плагины, которые уже реализуют подобное, достаточно их подключить, описав common функции и специфичные для каждой платформы(думаю, здесь понятно, один плагин будет иметь свою спецификацию для андроида, второй будет из cocoapods).
Чуть позже приведу пример
Sign up to leave a comment.
NativeScript, что за зверь и для чего он нужен?