Comments 14
Я понимаю что это приложение лишь демонстрация и туториал.
Но даже на примере такого простого приложения видно что использование React не привело к особому ускорению или улучшению процесса разработки, нативный интерфейс был бы роднее, быстрее и более кастомизируем. Сделать такой просто интерфейс в XCode заняло бы минут 20-60 минут, но он бы имел ряд преимуществ. Но даже здесь видно что основной код все равно пришлось писать нативно или адаптировать другие модули.
Можно конечно сказать что кросс-интерфейс решения будут более эффективны на больших проектах, однако это не так, ибо с увеличением сложности возросло бы и количество хаков и тормозов, тем более на огромных проектах обычно хватает времени (денег) на нативную разработку.
Интересно услышать мнение сообщества для какой ниши применение таких инструментов оправдано (из моего опыта есть только миграция большого cordova проекта в нативный код, еще до конца первого цикла разрабоки по выше сказаным причинам).
Но даже на примере такого простого приложения видно что использование React не привело к особому ускорению или улучшению процесса разработки, нативный интерфейс был бы роднее, быстрее и более кастомизируем. Сделать такой просто интерфейс в XCode заняло бы минут 20-60 минут, но он бы имел ряд преимуществ. Но даже здесь видно что основной код все равно пришлось писать нативно или адаптировать другие модули.
Можно конечно сказать что кросс-интерфейс решения будут более эффективны на больших проектах, однако это не так, ибо с увеличением сложности возросло бы и количество хаков и тормозов, тем более на огромных проектах обычно хватает времени (денег) на нативную разработку.
Интересно услышать мнение сообщества для какой ниши применение таких инструментов оправдано (из моего опыта есть только миграция большого cordova проекта в нативный код, еще до конца первого цикла разрабоки по выше сказаным причинам).
Этот подход логичен только для прототипирования приложений, не более того. Меня скорее интересует, как работать с ReactNative не дебажив его в эмуляторе для начала? Например Cordova позволяет сначала дебажить в обычном хроме, после уже билдить на мобилы. Тем самым разработка происходит немного быстрее. Что касается React-Native, когда начинал разбираться, я кроме как подхода билдь и дебаж — не нашел. Плюс ко всему, разочаровывает, что нет стабильности. От версии к версии могут произойти слишком большие изменения, и прошлый код уже не будет работоспособен, потому что некоторые методы удалены из новой. И приходится провозится достаточное время, чтобы всё заработало снова.
Когда хватает денег (и специалистов) на нативную разработку, то нужно выбирать нативную разработку. С этим сложно спорить.
Сравнивать с Cordova тоже не очень правильно, она работает в браузере, а нейтив реакт работает с родными компонентами платформы.
Для чего выбирать? Например, для использования архитектуры реакта. Какие UI-паттерны на iOS и Android? MVP в лучшем случае (я не уверен), императивно описываем все переходы состояний, в том числе работу с данными. Реактивный подход намного удобнее.
Сравнивать с Cordova тоже не очень правильно, она работает в браузере, а нейтив реакт работает с родными компонентами платформы.
Для чего выбирать? Например, для использования архитектуры реакта. Какие UI-паттерны на iOS и Android? MVP в лучшем случае (я не уверен), императивно описываем все переходы состояний, в том числе работу с данными. Реактивный подход намного удобнее.
На днях смотрел на реализацию flux для андроид, плакал и смеялся одновременно, хотя для человека, который пишет фронтенд он показался прекрасным. Проблема в том, что не всегда паттерны из фронтенда хорошо ложатся на мобильную разработку.
«MVP в лучшем случае (я не уверен)» — MVP/MVVM/VIPER может вполне подойти для решения различных проблем. FRP в мире мобилок очень активно развивается и не юзает его только ленивый. Проблема в том, что многие не хотят это все изучать и пишут под android использую концепции из 2010 года
«MVP в лучшем случае (я не уверен)» — MVP/MVVM/VIPER может вполне подойти для решения различных проблем. FRP в мире мобилок очень активно развивается и не юзает его только ленивый. Проблема в том, что многие не хотят это все изучать и пишут под android использую концепции из 2010 года
Насколько я понимаю, здесь как раз (в том числе и для демонстрации) приведён тот самый кейс, когда под необходимый функционал нужно писать (или адаптировать из кордовы) плагин. Но это далеко не всегда необходимо. Если отбросить этот момент, то вполне подойдёт для простых по смыслу приложений, которые занимаются отображением, пересылкой данных, их обработкой и т. д.
Кроме того, даже в данном случае, реализовав плагин под шагомер такое приложение должно быть проще поддерживать. Для добавления новой страницы или нового параметра в график достаточно работать только с одним кодом, а не с двумя нативными.
KitKat и ниже, не поддерживается?
Это UI приложение, хотелось бы видеть скрины, хоть это не главное, но все таки)
Sign up to leave a comment.
Разработка простого приложения «шагомер» на ReactNative