Comments 54
Хотелось бы увидеть статью: «Вот у нас мокап калькулятора» -> «Вот код» -> «Вот нюансы под iOs» -> «Тут мы берем и подключаем push'и да камеру» -> «магия» -> «Вот у нас готовые приложения под обе платформы»
Состоять это дело будет из {N}+Angular+ngrx/store+Firebase.
Что нравится в подходе Ionic и NativeScript что можно тот-же код для web-приложения использовать.
Я например прямо на сайте выкладываю live-demo чтобы сразу понятно было как будет выглядеть и работать приложение на мобиле — DebtsTracker.io
И какие бюджетные деньги?:)
Как результат, сделали вывод — Todo-list приложения писать можно :) А еще, как еще один результат, пришлось чуть-чуть пожить с ужасающим аддоном к VS и кучей спама от Телерика.
По поводу не компилируется — тестил различные модули и продолжаю с ними работать, стоило создать issue, вам бы помогли.
Ужасающий аддон? Для VS Code и WebStorm есть достаточно хорошие плагины.
Все проблемы с документацией (вот код по линку в предыдущем абзаце — не работал) были пофиксены где-то в ноябре, спустя месяц как мы на него пожаловались. Нет, ну можно сказать что помогли :) Я не говорю, что этим невозможно пользоваться — я говорю о том, что при выборе стратегии мобильного девелопмента на длительное время вперед, это не то, что я лично готов выбрать или кому-то порекомендовать.
PS: Под ужасающим я имел в виду примерно ту кучу спама (в виде попапов, доп. окошек, доп. таргетов output'ов, которые почему-то на каждый перезапуск по дефолту выбираются и т.д.), которую он везде прокидывал.
Практически — не представляю как всё это вообще поднять, и какую IDE для разработки использовать.
Из IDE-лично рекомендую WebStorm.
ReactNative ограничивает вас в компонентах
Не понимаю, это как?
Чтобы использовать CocoaPods/AA в react-native вам придется писать соответствующие классы на objC/Java.
Создавать, так скажем, мост между ними.
Однако вызывать нативные библиотеки, не JS — у вас не получится из JS'а.
По этому преимущества {N} не совсем очевидны (если они конечно есть).
Я правильно понял, что в основе — что-то вроде js-ctypes? Или получилось удобнее? (использование js-ctypes всё-таки включает в себя кучу возни и великолепные возможности для выстрела себе в ногу)
Для начала, вам не дает выстрелить себе в ногу TypeScript(по понятным причинам, compile-time type-checking).
Затем во время уже исполнения, вам будет мешать TypeConversion, если что-то пойдет не так — вам укажут где и почему.
Но опять-таки, возвращаясь к теме TS — его не просто так выбрали для Ангуляра, он действительно не дает вам возможности пострелять вдоволь.
Вообще, Telerik предоставляет декларацию типов для всех нативных вызовов. Для тех модулей, которые вы пишите сами — вы так же можете описать декларацию, заранее уберегая себя и дальнейших разработчиков от проблем с типизацией.
NativeScript развивается Telerik и только начинает свой путь в связке c Angular.
Возможно, когда-нибудь он станет AngularNative;)
Команда Angular тесно сотрудничает с Telerik, Microsoft тесно сотрудничает с Angular.
Все просто:)
Выбирая же путь ReactNative — вы выбираете путь react, NativeScript — angular.
Все зависит от того, с чем уже работала ваша команда, если у вас есть опыт с Angular2 — выбор очевиден.
Суть меняется, но не столь критично. При изменении состояния компонента все-равно идет проверка, нужно ли его ререндерить.
Вообще-то суть меняется радикально.
В Ангуляре тоже есть проверка, только немного другая. Упрощенно можно сказать, что в Ангуляре сравниваются данные, в Реакте — сравнивается виртуальный DOM (однако можно вмешаться и сделать проверку данных).
С чего вы решили, что в ReactNative используется DOM?
В прочем, к статье RN не имеет никакого отношения и стоило его убрать.
Спасибо.
Хочется увидеть полный цикл разработки от настройки IDE до компиляции.
Идея хорошая и возможности интересные.
Я правильно понимаю, что получился прямой аналог Xamarin.Forms (даже разметка с местным XAML схожа до степени смешения), только на яваскрипте и ещё более тормозной?
Однако при этом, сам fps стабильно выдает 60 кадров, при маршаллинге комплексных переменных NS проигрывает только нативному коду.
История с запуском лечится lazy-loading'ом.
Конкретно сейчас по цифрам сказать можно одно, где-то NS будет быстрее, где-то медленнее, но на UX это не скажется никак.
С XAML'ом похоже засчет того, что оба были построены на xml.
Вот только XAML вышел слегка ущербным, а здесь при дополнении ангуляром мы получается очень удобный и мощный инструмент для создания шаблонов
Ну коли полезли в лес, покажите, на основе чего вы решили, что разметка ангуляра менее ущербна, чем xaml. А то, судя по статье и комментам, выглядит, что, скрываясь за крайне интересным NS, вы пытаетесь продать ng2. Не надо так
Conditional's в xaml'е устанавливаются через триггеры(что увеличивает лэйаут на N строк.
Согласитесь, куда более удобно написать:
[class.active]=«isActive», чем писать в через триггеры и сеттеры.
А по поводу крайне интересного NS — все верно, он интересен, но в связке с ng2 он становится в разы интереснее, тут вам и встроенный DI, и шаблоны, и структурные директивы.
Никто не запрещает писать на чистом NS, но гораздо удобнее все-таки в связке с ng2.
А то вот не могу понять нужно ли включать в моё приложение на Ionic Crosswalk или нет.
Вызов нативного апи одновременно заманивает и настораживает. Действительно любое нативное апи можно вызывать со всей спецификой из NS или только для которого позаботились написать интерфейс? К Objective-C и Java можно гарантировано не обращаться по задачам оптимизации, реализации js api к сторонним нативным компонентам? Можно пример работы с 2D графикой (нарисовать полигон)?
Работа с 2д — специфична для каждой платформы, есть плагины, которые уже реализуют подобное, достаточно их подключить, описав common функции и специфичные для каждой платформы(думаю, здесь понятно, один плагин будет иметь свою спецификацию для андроида, второй будет из cocoapods).
Чуть позже приведу пример
NativeScript, что за зверь и для чего он нужен?