Comments 50
Небольшая просьба: укажите, в каких попугаях нарисован последний график. А то сверху «скорость», а на графике «время» (т.е. прямо противоположное). Или хотя бы «чем больше, тем лучше», или наоборот.
Как по мне (я писал и под Android, и под React Native, Flutter и iOS не пробовал), продуктивность разработки под React Native такова, что за это время в Android Studio можно в три раза больше функционала реализовать. Но это моё субъективное мнение.
Мое субъективное мнение что продуктивность зависит от прямоты рук и понимания языка /фреймворка. Пока соберется приложение из-под Android Studio (Core5/SSD/16Gb) на React Native можно уже пару-тройку компонентов и протестировать.
Мое субъективное мнение что продуктивность зависит от прямоты рук и понимания языка /фреймворка.
Ну понятно, что «кадры решают всё», но как правило, радиус кривизны рук у программистов постоянен и не особо зависит от инструмента. Неопытный программист везде мучается, опытный со всем легко разбирается. А инструмент играет большую роль. Взять тот же UI, в Android Studio вы рисуете вьюху в дизайнере, и запускаете посмотреть, по сути, один раз после того, как закончили рисовать. Под RN вы где-нибудь в VS Code описываете компоненту, запускаете, смотрите, рихтуете, перезапускаете, рихтуете, перезапускаете — и это дёрганье так продолжается до получения нужного результата. Это просто непродуктивно.
В сравнении реализации списков какая-то не полная картина:
В android нужно делать create + bind, а в flutter только create, т.к. виджеты flutter легковеснее android views. Что несколько упрощает разработку.
В android нужно делать create + bind, а в flutter только create, т.к. виджеты flutter легковеснее android views. Что несколько упрощает разработку.
А что там с жором батарейки и вообще скоростью запуска и работы приложений?
Как я понимаю автор топит за Flutter и пишет под Android, ничем иным объяснить график я не могу.
У других экспериментаторов таких проблем не было (https://hackernoon.com/react-native-vs-flutter-which-is-more-startup-friendly-c6e412d0b9ab, https://hackr.io/blog/react-native-vs-flutter)
У других экспериментаторов таких проблем не было (https://hackernoon.com/react-native-vs-flutter-which-is-more-startup-friendly-c6e412d0b9ab, https://hackr.io/blog/react-native-vs-flutter)
Я не понял как Rx относится к многопоточности? На примере того же Свифта, если сабджект дергается не из основного потока (например делался хттп запрос) то юай так просто из него не проапдейтишь
Особенно на флаттере. Стримы кстати как и Rx там асинхронно работают, но по идее в том же потоке. В дарте для многопоточности вроде как отдельный механизм применяется, не стримы, изоляты или как то так. Но вообще посмотреть нужно, может можно для разных стрим трансформеров, или как там подобные объекты в Rx называются, задавать потоки выполнения. В нативном андроиде вроде можно было так Rx использовать, недавно смотрел видео
Если что я только учусь и сильно за искажения фактов не бейте.
Но в целом когда я с флаттером знакомился он мне своей концепцией и простотой понравился кстати.
Если что я только учусь и сильно за искажения фактов не бейте.
Но в целом когда я с флаттером знакомился он мне своей концепцией и простотой понравился кстати.
Выдержка из статьи про RxSwift
оператор — observeOn
Указывает, на каком Scheduler должен выполнять свою работу Observer, особенно критично при работе с GUI.
Консоль:
оператор — observeOn
Указывает, на каком Scheduler должен выполнять свою работу Observer, особенно критично при работе с GUI.
example("\"observeOn\"") {
DispatchQueue.global(qos: .background).async {
Observable
.of(1, 2, 3)
.observeOn(MainScheduler.instance)
.subscribe({ event in
print("Main: \(Thread.isMainThread)\t\tEvent: \(event)")
})
Observable
.of("A", "B", "C")
.subscribe({ event in
print("Main: \(Thread.isMainThread)\t\tEvent: \(event)")
})
}
}
Консоль:
Main: false Event: next(A)
Main: false Event: next(B)
Main: true Event: next(1)
Main: true Event: next(2)
Main: true Event: next(3)
Main: true Event: completed
Main: false Event: next(C)
Main: false Event: completed
А зачем в Реакт тянуть RX, есть там уже есть Promise и Async/Await? Просто для унификации или от нечего делать? Просто странно сравнивать скорость двух лошадей, у одной из которых к ногам привязали костыли, что бы говорить«Ну вот вы видите, не может она быстро бежать»…
А зачем в Реакт тянуть RX, есть там уже есть Promise и Async/Await?
RX вообще не связано никак с promise и async/await.
Что, серьезно? Я вот почему то думал что согласно своему описанию RXJS это «инструмент для удобного контроля последовательных действий». А если в примере автора он не для этого (из-за нежелания пользоваться встроенными механизмами) то зачем?
Зашел на reactivex.io и контроль последовательности действий там упомянут разве что между прочим.
Прежде всего, оно дает абстракцию потока событий и механизмы для манипуляций с такими потоками.
Да, использование rx исключительно для запросов к бэкэнду неоправдано, и async/await куда проще. Но запросами к бэкенду модель в сложном приложении не ограничивается.
Да, использование rx исключительно для запросов к бэкэнду неоправдано, и async/await куда проще. Но запросами к бэкенду модель в сложном приложении не ограничивается.
Всякому инструменту свое применение…
RX далеко не всегда оправдан даже самим разработчиками ReactiveX.
RX далеко не всегда оправдан даже самим разработчиками ReactiveX.
Табличка тут немного кривая: для Asynchronus Multiple Value есть AsyncIterable. А Observable применимо для push-based потоков независимо от их синхронности.
Observable — это просто двойственная к Iterable конструкция со всеми вытекающими.
С асинхронностью это никак не связано все, а правильный аналог в первой колонке — это Get vs OnNext() (= Set)
надо бросать vb.net.
А для теликов (ЛЫЖЫ) что лучше использовать?
А для теликов (ЛЫЖЫ) что лучше использовать?
Cпасибо за статью, интересно узнать про результат, сравнительные характеристики готовых приложений?
Так как приложения очень маленькие — скорость их работы визуально одинакова. Сначала я думал сравнить сколько будут весить Apk для Android. Но сравнивать размеры тоже было некорректно, т.к.:
1)В React Native был добавлен Realm, нативная часть которого очень утяжелила Apk.
2)В Android я запихнул кучу библиотек, без которых я считаю, как “истинный Android разработчик“, приложению не обойтись.
1)В React Native был добавлен Realm, нативная часть которого очень утяжелила Apk.
2)В Android я запихнул кучу библиотек, без которых я считаю, как “истинный Android разработчик“, приложению не обойтись.
в копилку для Flutter:
встроенного в AS редактора UI нет, но есть такой проектик flutterstudio
(спасибо GDGNN и лично Саше Денисову, за то что показал).
Возможно в скором времени это и в студию внесут)
встроенного в AS редактора UI нет, но есть такой проектик flutterstudio
(спасибо GDGNN и лично Саше Денисову, за то что показал).
Возможно в скором времени это и в студию внесут)
Возможно, глупый вопрос. При выключении экрана или увода в фон приложения таймер стопорится в каком-то приложении? Давно смотрел Cordova, а там webview, и внутренний JS таймер то ли стопорился совсем, то ли сильно замедлялся.
Тут нужно обратить внимание: при уходе в фон убивается процесс приложения или нет. В ios процесс убивается у свернутого приложения, через некоторое время. И убийство процесса никакой из вариантов не переживет. А если рассматривать ситуацию сворачивания в Android до момента убийства процесса, то Flutter нормально работает и время не останавливается. А в React Native таймер зависает
А вы точно пробовали на React Native писать? https://github.com/ocetnik/react-native-background-timer
Я реализовывал таймер через RxJs interval
такой код в моем презентере. Именно в такой реализации таймер стопится. После вопроса я специально запустил приложение и проверил.
Приведенную вами библиотеку я не рассматривал. Но видно, что либа строит мост в native и там уже реализуется таймер. Понятное дело, мне ничто не мешает сделать foreground service в Android, запустить в нем таймер и общатьсяс c js через мост, даже без использование либы. И такой таймер на родных прошивках в Android убиваться не будет в принципе.
То что я писал это про выполнение JS
this.subscription = interval(1000)
.pipe(take(list.length))
.subscribe(a => {
this.timer.show(list[a])
})
такой код в моем презентере. Именно в такой реализации таймер стопится. После вопроса я специально запустил приложение и проверил.
Приведенную вами библиотеку я не рассматривал. Но видно, что либа строит мост в native и там уже реализуется таймер. Понятное дело, мне ничто не мешает сделать foreground service в Android, запустить в нем таймер и общатьсяс c js через мост, даже без использование либы. И такой таймер на родных прошивках в Android убиваться не будет в принципе.
То что я писал это про выполнение JS
Пардон, а что, Флаттер как то по другому реализует таймеры, не через foreground service? Всякому инструменту свое место, и в 99% ситуаций таймеру не нужна работа в фоне.
Я понимаю что вы фанат Флаттера, но хотелось бы больше объективности.
Я понимаю что вы фанат Флаттера, но хотелось бы больше объективности.
Во Flutter при той же реализации что и в React — Native c помощью Rx не стопиться
Вот какая реализация во флатере
Я объективно ответил на комментарий — проверив, запустив разработанные приложения
Вот какая реализация во флатере
subscription = new Observable<ModelTimer>.fromIterable(list)
.interval(new Duration(seconds: 1))
.listen((modelTimer) =>
Я объективно ответил на комментарий — проверив, запустив разработанные приложения
Давайте что бы не разводить срач
Ведь можно так написать, а не «в React Native таймер зависает». Тут кстати вопрос к Flatter, он все таймеры выносит в foreground service Android или как то сам принимает решения.
- в ReactNative не работает Ваша реализация таймеров на RxJS
- в ReactNative успешно работают таймеры / процессы в фоне при помощи сторонних модулей
Ведь можно так написать, а не «в React Native таймер зависает». Тут кстати вопрос к Flatter, он все таймеры выносит в foreground service Android или как то сам принимает решения.
В активити Cordov'ы на onPause стопорятся таймауты WebView. Таймеры не работают в фоне.
Спасибо за статью! Очень хотелось бы все же узнать выводы, хотя бы в комментах :) Пусть это и будет с призмы личного опыта. И почему в выборку не попал популярный ionic?
1)Почему не попал ionic? Потому что, лично для меня, были интересны React Native и Flutter
2)Главное для меня при разработке приложений — это их поддерживаемость. Да, я понимаю, что кроссплатформа быстрее и кажется на первый взгляд выгоднее для бизнеса. Но в долгосрочной перспективе, по моему мнению, она себя не окупит, так как все равно придется писать мост к нативу, когда нужно будет писать что-то специфическое под платформу. Хотя, если я буду писать домашний проект, я склонюсь к Flutter.
2)Главное для меня при разработке приложений — это их поддерживаемость. Да, я понимаю, что кроссплатформа быстрее и кажется на первый взгляд выгоднее для бизнеса. Но в долгосрочной перспективе, по моему мнению, она себя не окупит, так как все равно придется писать мост к нативу, когда нужно будет писать что-то специфическое под платформу. Хотя, если я буду писать домашний проект, я склонюсь к Flutter.
По поводу скорости загрузки: специально создавал одинаковые приложения-пустышки для Android с использованием Xamarin, Flutter и Native. Оба кроссплатформенных проиграли на старте в разы. Потом, в работе, особой разницы не заметил.
-Товарищ несите отвертку! — Мне нужно забить гвоздь
По своему опыту, могу сказать, разработка на кросс платформе занимает в разы больше времени и да и поддерживать это все…, короче для себя экономической выгоды не увидел
Условно, написав за месяц приложение(а 70% времени это бизнес логика) для заказчика под андроид, создать тоже самое на ios займает ~неделю.
+Бизнесу постоянно в голову приходят новые свистелки-хотелки, используя натив я уверен, что задача будет реализована и за вменяемое время.
По моему мнению кросс-платформа подходит если:
Пишите собственную лабуду из разряда «Пацаны смотри, че запилил»
Клепаете на заказ 100500 приложений из разряда «Загрузить данные с сервера и нарисовать список»
Создаете приложения из разряда «Ну хотя б раз рекламу посмотри и можешь удалять»
По своему опыту, могу сказать, разработка на кросс платформе занимает в разы больше времени и да и поддерживать это все…, короче для себя экономической выгоды не увидел
Условно, написав за месяц приложение(а 70% времени это бизнес логика) для заказчика под андроид, создать тоже самое на ios займает ~неделю.
+Бизнесу постоянно в голову приходят новые свистелки-хотелки, используя натив я уверен, что задача будет реализована и за вменяемое время.
По моему мнению кросс-платформа подходит если:
Пишите собственную лабуду из разряда «Пацаны смотри, че запилил»
Клепаете на заказ 100500 приложений из разряда «Загрузить данные с сервера и нарисовать список»
Создаете приложения из разряда «Ну хотя б раз рекламу посмотри и можешь удалять»
Также склоняюсь к мнению что на данный момент инструменты разработки мобильных кросс платформенных приложений все еще на стадии развития. Да и разработчики ios и Android особо то и не спешат создать совместными усилиями качественную кросс платформенную среду. Вместо этого они, напротив, еще больше плодят языки/инструментарии.
Если посудить, что выбрать новичку в и начать изучать: нативные (native Android и ios), гибридные (Cordova, Phonegap), или кросс платформенные (React Native, Flutter, Xamarin)? Что более приемлемо с точки зрения затраченных усилий и полученных навыков? Для изучение кросс платформенных иснтрументов нужно затратить такое усилие, которое сопоставимо с изучением основ разработки для Android. Да плюс к тому же, для комфортной разработки на кросс платформенных иснтрументах нужны базовые навыки и знания основ разработки для Android и ios. Если нужно создать простое приложение без затрат значительных усилий, то выбор очевиден — Cordova и Phonegap. Получается, учитывая что разработка для ios затратно финансово (нужна машина на MacOS) и у ios меньшая доля рынка, оптимальная стратегия — выбрать либо native Android либо гибридные.
Если посудить, что выбрать новичку в и начать изучать: нативные (native Android и ios), гибридные (Cordova, Phonegap), или кросс платформенные (React Native, Flutter, Xamarin)? Что более приемлемо с точки зрения затраченных усилий и полученных навыков? Для изучение кросс платформенных иснтрументов нужно затратить такое усилие, которое сопоставимо с изучением основ разработки для Android. Да плюс к тому же, для комфортной разработки на кросс платформенных иснтрументах нужны базовые навыки и знания основ разработки для Android и ios. Если нужно создать простое приложение без затрат значительных усилий, то выбор очевиден — Cordova и Phonegap. Получается, учитывая что разработка для ios затратно финансово (нужна машина на MacOS) и у ios меньшая доля рынка, оптимальная стратегия — выбрать либо native Android либо гибридные.
А я для своих домашних приложений запускаю на андроиде обычные extends Thread из Java. Вроде работает.
Sign up to leave a comment.
Больше всех пахала лошадь, но председателем колхоза так и не стала