create-react-native-app :)

Да. С create-react-native-app есть особенность в виде дополнительной экосистемы. С которой со временем может стать больно.

Да. С create-react-native-app есть особенность в виде дополнительной экосистемы. С которой со временем может стать больно.

Всем привет! Я Java+Kotlin/Android разработчик. Решил перебежать на сторону кроссплатформенных приложений, так как нужна поддержка iOS с минимальными затратами. Для нового проекта нужны приложения для iOS и Android, синхронизация с публичным web-сайтом (а также добавление информации на сайт через приложение). До последнего момента рассматривал React + React Native + Redux, но сейчас стал чаще встречать и изучать информацию о Dart + Flutter. Как вы считаете, что лучше использовать в данном случае - React + React Native + Redux или Dart + Flutter?

Всем привет! Я Java+Kotlin/Android разработчик. Решил перебежать на сторону кроссплатформенных приложений, так как нужна поддержка iOS с минимальными затратами. Для нового проекта нужны приложения для iOS и Android, синхронизация с публичным web-сайтом (а также добавление информации на сайт через приложение). До последнего момента рассматривал React + React Native + Redux, но сейчас стал чаще встречать и изучать информацию о Dart + Flutter. Как вы считаете, что лучше использовать в данном случае - React + React Native + Redux или Dart + Flutter?

Если есть нужда юзать сторонние плагины, советую посмотреть на их наличие и стабильность. Еще почитать обсуждаемые issues в обоих проектах. dart правда привычнее после java (статическая типизация, ооп).

C методологией программирования JS тоже знаком, пользовался как-то treejs. После того, как я с Паскаля перешел на С++ и мой мирок стал очень быстро ломаться и не понимать, что такое ООП, классы и т. п., изменения в философии и принципах языка меня не особо волнуют. Так что привычно-непривычно - это не тот фактор, который определяет выбранный мной язык, если только там совсем все по-другому. Под сторонними плагинами Вы имеете в виду не-ReactJs плагины?

Подскажите как в RN лучше картинки импортить. Читал что вот так не рекомендуется const splashIcon = require('src/img/splash_logo.png'); Или так лучше: <Image source={require('/react-native/img/favicon.png')}/>

Совершенно случайно вдруг кто-нибудь сталкивался: задача заключается в том что пользователь должен иметь возмодность тачем отредактировать растровую картинку. Те условно говоря нужна примитивная рисовалка на канвасе/контексте В RN нет апи доступа к графическим подисистемам, поэтому нужен врапнутый нативный компонент Мб кто-то с чем-то таким работал

Может будут у кого мысли, я хотел модифицировать mapDispatchToProps внутри connect для передачи туда дополнительных данных, но выходи так, что connect вызывается самым первым еще до рендера самого компонента и соответсвенно данных

Может будут у кого мысли, я хотел модифицировать mapDispatchToProps внутри connect для передачи туда дополнительных данных, но выходи так, что connect вызывается самым первым еще до рендера самого компонента и соответсвенно данных

Все добрый день. А как получить доступ и разрешение на сохранение файло на ios? Юзаю библиотеку joltup/rn-fetch-blob Или вообще возможно сохранять файлы на ios платформу?

А зачем? Какие данные хочешь передать?

Это невозможно. Но если посмотреть внимательно, там есть апи для этого (его использование частично "убивает" оптимизацию рендера, но когда очень надо там всё есть). Если конечно я правильно угадал, почему эта задача возникла.

Да, я видел, но не помогло

Я просто делаю "редаксовский конвейер", и хотел туда подсунуть экшены, чтобы проще было биндить. Ох щас камни полетят)

А... тогда да... но тут я самоустраняюсь, т.к. я - это про mobx )

Т.е. нужны не просто props компонента в мэппере, а что-то ещё? Если стейт нужен - труба... надо бить на два компонента и connect на внутреннем дергать, а стейт во внешнем держать и передавать вниз как props

@iLonny поставил путь сохранения: DocumentDir, записывает файл в директорию /var/mobile/Containers/Data/Application/DC36939.../Documents/y2E7lMsY5ryL1bJ9ewZpvAaC082Gq6ZV.jpg но как мне теперь его просмотреть?

я правильно понимаю, что речь об api запрос - ответ?

Не совсем, там независимо можно команды посылать, как client->server, так и server -> client... и уже поверх этой абстракции, можно послать команду с токеном на сервер, который этот токен назад пришлет (чтоб клиент смог понять, что это именно на такой-то его запрос ответ)

Если коротко, то у нас достаточно сложное корпоративное приложение. Представляет собой многоуровневую систему задач, есть корневые задачи, вложенные и конечные. В конечных задачах есть возможность вести обсуждения в чатах. При этом поступление нового сообщения в чат должно добавлять счетчик сообщения на его задачу и поднимать счетчики вверх по дереву. Изменение наборов свойств родительских задач пораждает измениня вниз по дереву и так далее. Ну еще и свои боты есть, которые динамически создают задачи и сообщения для определенных наборов участников задач и чатов. Я не говорю еще и о разделении прав, администраторах, наследовании при создаании задач и закрытии чатов и задач с пробросом вниз и вверх по дереву. Сейчас все это живет на http подобном api и лонгпуллинг подпиской, которая рассылает ивенты на устройства при тех или иных изменениях в данных. Делать все это мне было достаточно трудоемко. Сервер на python + MSSQL и Clickhouse для агрегации логов и уведомлений + генерация шифрованных токенов для защиты запросов. В итоге все это работает, но есть просадки с зависанием запросов на клиентах + лонгпуллинг может быть требователен к ресурсам ведь фактически приходится дергать Clickhouse раз в 100ms за новым данными. К сожалению, когда эту задачу ставили не дали подниматься вебсокеты, так как у нас прокси сервер достаточно старый и с ними работает плохо, но сейчас уже готовлю сервер для v2 и можно поиграть с сокетами...

Имхо, тут не только в сокетах дело... хотя я считаю, они должны быть неотемлемой частью такой системы (лонг поллинг это хак в любом случае). Тут, если самим делать, большая задача это определение протокола который: 1. позволяет закодировать все изменения данных 2. позволяет сделать это компактно И вторая большая задача это сервер... по опыту такие системы шустро работают, только если working set... те данные про которые сейчас нужно кому-то знать находятся в памяти и изменения по ним рассылаются во сессии всех клиентов которым нужно о них знать одновременно (или непосредственно после) укладки в бд )

Да, но при обычном http-api ты не знаешь кому отправлять данные, потому что никто к тебе и не подключен.. Лонгпуллинг в этом случае позвляет мне отслеживать коннекты по подписке на события и отправлять данные только тем, кто онлайн из тех, кто должен получить данные, потому что остальные и так их получат, когда войдут в приложение обычными запросами

да, да... естественно, я имею ввиду, что long polling это хак по сравнению с нормальным протоколом расчитанным на непрерывное соединение