Больше всех пахала лошадь, но председателем колхоза так и не стала

[hdfan2]

Небольшая просьба: укажите, в каких попугаях нарисован последний график. А то сверху «скорость», а на графике «время» (т.е. прямо противоположное). Или хотя бы «чем больше, тем лучше», или наоборот.

[ivanlardis]

Спасибо поправил. Там речь о времени

[justboris]

Все равно непонятки остались. В чем выражается время? Часы, дни, недели?

[DrPass]

Как по мне (я писал и под Android, и под React Native, Flutter и iOS не пробовал), продуктивность разработки под React Native такова, что за это время в Android Studio можно в три раза больше функционала реализовать. Но это моё субъективное мнение.

[shadek]

Мое субъективное мнение что продуктивность зависит от прямоты рук и понимания языка /фреймворка. Пока соберется приложение из-под Android Studio (Core5/SSD/16Gb) на React Native можно уже пару-тройку компонентов и протестировать.

[DrPass]

Мое субъективное мнение что продуктивность зависит от прямоты рук и понимания языка /фреймворка.

Ну понятно, что «кадры решают всё», но как правило, радиус кривизны рук у программистов постоянен и не особо зависит от инструмента. Неопытный программист везде мучается, опытный со всем легко разбирается. А инструмент играет большую роль. Взять тот же UI, в Android Studio вы рисуете вьюху в дизайнере, и запускаете посмотреть, по сути, один раз после того, как закончили рисовать. Под RN вы где-нибудь в VS Code описываете компоненту, запускаете, смотрите, рихтуете, перезапускаете, рихтуете, перезапускаете — и это дёрганье так продолжается до получения нужного результата. Это просто непродуктивно.

[shadek]

Мусье, а вы точно на Реакте пробовали?
Раскрою вам секрет, цепляетесь дебаггером к приложению и меняете стили прямо вот налету, без всяких перезапусков, как в браузере в консоли разработчика. Быстрее чем на Андроиде выходит.

[noktigula]

Причем наибольшее преимущество получается на больших проектах, где сборка приложения занимает пару минут, а Instant Run по разным причинам не работает.

[HotIceCream]

В сравнении реализации списков какая-то не полная картина:
В android нужно делать create + bind, а в flutter только create, т.к. виджеты flutter легковеснее android views. Что несколько упрощает разработку.

[Gorthauer87]

А что там с жором батарейки и вообще скоростью запуска и работы приложений?

[ivanlardis]

Жор батарейки мною не рассматривался. Насчет скорости — разрабатываемые приложения очень маленькие. Всего 3 экрана. И разницу в скорости визуально ощутить не получилось, так как все приложения выглядят шустро. А программное измерение скорости я не производил

[shadek]

Как я понимаю автор топит за Flutter и пишет под Android, ничем иным объяснить график я не могу.
У других экспериментаторов таких проблем не было (https://hackernoon.com/react-native-vs-flutter-which-is-more-startup-friendly-c6e412d0b9ab, https://hackr.io/blog/react-native-vs-flutter)

[Golem765]

Я не понял как Rx относится к многопоточности? На примере того же Свифта, если сабджект дергается не из основного потока (например делался хттп запрос) то юай так просто из него не проапдейтишь

[Neikist]

Особенно на флаттере. Стримы кстати как и Rx там асинхронно работают, но по идее в том же потоке. В дарте для многопоточности вроде как отдельный механизм применяется, не стримы, изоляты или как то так. Но вообще посмотреть нужно, может можно для разных стрим трансформеров, или как там подобные объекты в Rx называются, задавать потоки выполнения. В нативном андроиде вроде можно было так Rx использовать, недавно смотрел видео
Если что я только учусь и сильно за искажения фактов не бейте.
Но в целом когда я с флаттером знакомился он мне своей концепцией и простотой понравился кстати.

[ivanlardis]

Выдержка из статьи про RxSwift
оператор — 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


[shadek]

А зачем в Реакт тянуть RX, есть там уже есть Promise и Async/Await? Просто для унификации или от нечего делать? Просто странно сравнивать скорость двух лошадей, у одной из которых к ногам привязали костыли, что бы говорить«Ну вот вы видите, не может она быстро бежать»…

[Druu]

А зачем в Реакт тянуть RX, есть там уже есть Promise и Async/Await?

RX вообще не связано никак с promise и async/await.

[shadek]

Что, серьезно? Я вот почему то думал что согласно своему описанию RXJS это «инструмент для удобного контроля последовательных действий». А если в примере автора он не для этого (из-за нежелания пользоваться встроенными механизмами) то зачем?

[Neikist]

Зашел на reactivex.io и контроль последовательности действий там упомянут разве что между прочим.

[shadek]

Ну уж не знаю, не для асинхронности же его ввел автор в проект ReactNative, там как бы изначально все асинхронно. Ваши идеи зачем его добавили?

[Neikist]

Поскольку код на реакт нейтиве не смотрел поэтому не могу ответить зачем его там ввел автор, но допустим когда я посматривал на флаттер я стримы и await всякие для заметно разного использовал. await, future не дает реактивности по факту, а Rx или даже просто стримы дают.

[shadek]

Цифра с тобой. мой друг :)

[mayorovp]

Прежде всего, оно дает абстракцию потока событий и механизмы для манипуляций с такими потоками.

Да, использование rx исключительно для запросов к бэкэнду неоправдано, и async/await куда проще. Но запросами к бэкенду модель в сложном приложении не ограничивается.

[shadek]

Всякому инструменту свое применение…
RX далеко не всегда оправдан даже самим разработчиками ReactiveX.

[mayorovp]

Табличка тут немного кривая: для Asynchronus Multiple Value есть AsyncIterable. А Observable применимо для push-based потоков независимо от их синхронности.

[Druu]

Observable — это просто двойственная к Iterable конструкция со всеми вытекающими.
С асинхронностью это никак не связано все, а правильный аналог в первой колонке — это Get vs OnNext() (= Set)

[dimanhursky]

надо бросать vb.net.
А для теликов (ЛЫЖЫ) что лучше использовать?

[nochnoy]

надо бросать тяжёлые препараты :)

[VikkoS]

Cпасибо за статью, интересно узнать про результат, сравнительные характеристики готовых приложений?

[ivanlardis]

Так как приложения очень маленькие — скорость их работы визуально одинакова. Сначала я думал сравнить сколько будут весить Apk для Android. Но сравнивать размеры тоже было некорректно, т.к.:
1)В React Native был добавлен Realm, нативная часть которого очень утяжелила Apk.
2)В Android я запихнул кучу библиотек, без которых я считаю, как “истинный Android разработчик“, приложению не обойтись.

[EviGL]

И всё-таки, шёпотом, вне зачёта, сколько вышло?

[Imrahil]

в копилку для Flutter:
встроенного в AS редактора UI нет, но есть такой проектик flutterstudio
(спасибо GDGNN и лично Саше Денисову, за то что показал).
Возможно в скором времени это и в студию внесут)

[tsukasa_mixer]

который опять ни в чем кроме хрома не работает?

[bromzh]

В safari работает

[Imrahil]

Я не в курсе) не проверял. В хроме работает и норм.

[FRiMN]

Возможно, глупый вопрос. При выключении экрана или увода в фон приложения таймер стопорится в каком-то приложении? Давно смотрел Cordova, а там webview, и внутренний JS таймер то ли стопорился совсем, то ли сильно замедлялся.

[ivanlardis]

Тут нужно обратить внимание: при уходе в фон убивается процесс приложения или нет. В ios процесс убивается у свернутого приложения, через некоторое время. И убийство процесса никакой из вариантов не переживет. А если рассматривать ситуацию сворачивания в Android до момента убийства процесса, то Flutter нормально работает и время не останавливается. А в React Native таймер зависает

[shadek]

А вы точно пробовали на React Native писать? https://github.com/ocetnik/react-native-background-timer

[ivanlardis]

Я реализовывал таймер через RxJs interval

 this.subscription = interval(1000)
            .pipe(take(list.length))
            .subscribe(a => {
                this.timer.show(list[a])
            })

такой код в моем презентере. Именно в такой реализации таймер стопится. После вопроса я специально запустил приложение и проверил.
Приведенную вами библиотеку я не рассматривал. Но видно, что либа строит мост в native и там уже реализуется таймер. Понятное дело, мне ничто не мешает сделать foreground service в Android, запустить в нем таймер и общатьсяс c js через мост, даже без использование либы. И такой таймер на родных прошивках в Android убиваться не будет в принципе.
То что я писал это про выполнение JS

[shadek]

Пардон, а что, Флаттер как то по другому реализует таймеры, не через foreground service? Всякому инструменту свое место, и в 99% ситуаций таймеру не нужна работа в фоне.
Я понимаю что вы фанат Флаттера, но хотелось бы больше объективности.

[ivanlardis]

Во Flutter при той же реализации что и в React — Native c помощью Rx не стопиться
Вот какая реализация во флатере

  subscription = new Observable<ModelTimer>.fromIterable(list)
        .interval(new Duration(seconds: 1))
        .listen((modelTimer) =>

Я объективно ответил на комментарий — проверив, запустив разработанные приложения

[shadek]

Давайте что бы не разводить срач

1. в ReactNative не работает Ваша реализация таймеров на RxJS
2. в ReactNative успешно работают таймеры / процессы в фоне при помощи сторонних модулей

Ведь можно так написать, а не «в React Native таймер зависает». Тут кстати вопрос к Flatter, он все таймеры выносит в foreground service Android или как то сам принимает решения.

[mayorovp]

Rx использует таймеры из стандартной библиотеки без каких-то особых хитростей. Так что правильно писать вот так:

в ReactNative не работает setInterval

[C_arter]

В активити Cordov'ы на onPause стопорятся таймауты WebView. Таймеры не работают в фоне.

[romiras_spb]

Спасибо за статью! Очень хотелось бы все же узнать выводы, хотя бы в комментах :) Пусть это и будет с призмы личного опыта. И почему в выборку не попал популярный ionic?

[ivanlardis]

1)Почему не попал ionic? Потому что, лично для меня, были интересны React Native и Flutter
2)Главное для меня при разработке приложений — это их поддерживаемость. Да, я понимаю, что кроссплатформа быстрее и кажется на первый взгляд выгоднее для бизнеса. Но в долгосрочной перспективе, по моему мнению, она себя не окупит, так как все равно придется писать мост к нативу, когда нужно будет писать что-то специфическое под платформу. Хотя, если я буду писать домашний проект, я склонюсь к Flutter.

[zhigar]

По поводу скорости загрузки: специально создавал одинаковые приложения-пустышки для Android с использованием Xamarin, Flutter и Native. Оба кроссплатформенных проиграли на старте в разы. Потом, в работе, особой разницы не заметил.

[Romario21]

-Товарищ несите отвертку! — Мне нужно забить гвоздь

По своему опыту, могу сказать, разработка на кросс платформе занимает в разы больше времени и да и поддерживать это все…, короче для себя экономической выгоды не увидел
Условно, написав за месяц приложение(а 70% времени это бизнес логика) для заказчика под андроид, создать тоже самое на ios займает ~неделю.

+Бизнесу постоянно в голову приходят новые свистелки-хотелки, используя натив я уверен, что задача будет реализована и за вменяемое время.

По моему мнению кросс-платформа подходит если:
Пишите собственную лабуду из разряда «Пацаны смотри, че запилил»
Клепаете на заказ 100500 приложений из разряда «Загрузить данные с сервера и нарисовать список»
Создаете приложения из разряда «Ну хотя б раз рекламу посмотри и можешь удалять»

[erkesh]

Также склоняюсь к мнению что на данный момент инструменты разработки мобильных кросс платформенных приложений все еще на стадии развития. Да и разработчики ios и Android особо то и не спешат создать совместными усилиями качественную кросс платформенную среду. Вместо этого они, напротив, еще больше плодят языки/инструментарии.
Если посудить, что выбрать новичку в и начать изучать: нативные (native Android и ios), гибридные (Cordova, Phonegap), или кросс платформенные (React Native, Flutter, Xamarin)? Что более приемлемо с точки зрения затраченных усилий и полученных навыков? Для изучение кросс платформенных иснтрументов нужно затратить такое усилие, которое сопоставимо с изучением основ разработки для Android. Да плюс к тому же, для комфортной разработки на кросс платформенных иснтрументах нужны базовые навыки и знания основ разработки для Android и ios. Если нужно создать простое приложение без затрат значительных усилий, то выбор очевиден — Cordova и Phonegap. Получается, учитывая что разработка для ios затратно финансово (нужна машина на MacOS) и у ios меньшая доля рынка, оптимальная стратегия — выбрать либо native Android либо гибридные.

[Tarson]

А я для своих домашних приложений запускаю на андроиде обычные extends Thread из Java. Вроде работает.