Не согласен, JSI завезли уже около 6 лет назад, процесс миграции шел очень долго и все активные библиотеки давно поддерживают новую архитектуру + есть Interop слой, который позволяет запускать модули написанные под старую архитектуру без полного переписывания
А почему вы не используете например Lottielab для создания анимаций сразу в нужном формате и без необходимости сверяться с возможностями экспорта? И пробовали ли rive? У него больше возможностей, он быстрее развивается и чаще всего выигрывает в производительности
И что получает юзер после установки из стора - там сразу качаются все актуальные обновления?
Все последние на момент сборки самого приложения бандлы зашиваются в apk/ipa, поэтому юезр на первом старте не качает десятки Мб. Но если на момент запуска есть новые бандлы, то они будут обновляться.
(есть же правило сторов - не менять существенно функционал в обход).
На сколько я его понимаю, они просят категорически не менять приложение, а что-то дополнять всем ок. Многие компании используют те же самые флаги для показа того или иного функционала, BDUI или еще что-то и я не знаю случаев что бы за это прилетали баны. Тут подробнее инфа, пункт 3.3.1 B
Да, все так, на гитхабе есть пример, там как раз фичи/экраны с их логикой грузятся только при переходе на них. Это небольшие кусочки кода (если надо, то с ресурсами/картинками), потом код подгружается в движок в рантайм, запускается и рисуется UI.
Кейс обновления интерфейса без закрытия апки мы не пытались решить никак. Мысли такие: технически конечно сложная вещь, но звучит вполне реальной. В таком кейсе есть смысл только если мы юзера оставляем на экране, на котором он был, а значит надо стейт сохранять. А тут в голову сразу приходят проблемы: если стейт поменялся между версиями, то это уже миграции писать надо какие-то... ну и все такое. В общем все это сделать как будто можно, но сложность несравнимо высока с профитом от этого.
Даже банальные команды сборки могли сильно грузить систему. Часто приходилось ждать по несколько минут, пока приложение пересоберётся
Возможно вы не так поняли идею RN и лишний раз пересобирали приложение. Его надо пересобирать только в случае обновления или добавления нативных зависимостей
Простая задача, казалось бы. Но оказалось, что прямое подключение серверной базы к приложению без промежуточного API не имеет смысла
Не до конца понял что вы имеете ввиду. Обычно у сервера есть апи, вы можете к нему обращаться и получать данные в рамках контрактов. Если надо вы можете эти данные сохранить в тот же SQLite или любую другую БД на девайсе. Какой документации вам не тут хватило или какой вы ожидали?
Для одного разработчика с ограниченным временем — нативная разработка на React Native не лучший путь.
Я думаю что для одного разработчика с ограниченным временем - любой незнакомый инструмент не лучший путь. Ну только если вы не хотите его изучить
Для реализации WebView-приложения я выбрал Flutter — фреймворк от Google, построенный на языке Dart
А зачем вообще вы брали Flutter для этого? Почему не нативку учитывая что вы с ИИ прогали, ну или ionic или cardova, на крайняк? Просто взять здоровенный фраемворк исключительно для показа вебвью и навбара звучит как оверхед и такое советовать я бы не стал.
Я однажды подписал основную сборку, и потом пришлось откатываться назад и переорганизовывать проект, чтобы снова собирать без подписи.
Не понял что такое "основная сборка" и зачем потом надо было переорганизовывать проект и что значит "переорганизовывать проект". Предполагаю что речь про андроид. Для него обычно создается дебаг и прод ключи (использование можно посмотреть в файле android/app/build.gradle) и приложение подписывается в зависимости от build variant, который вы используете при сборке. При этом откатываться или что-то переорганизовывать не надо
Flutter — лучшее решение для быстрого и стабильного вывода веб-сайта в формате приложения, особенно если нужен WebView или кастомный UI
А вы пробовали на RN сделать тоже самое с WebView, как пришли к выводу что на Flutter это сделать быстрее?
Information
Rating
Does not participate
Location
Калининград (Кенигсберг), Калининградская обл., Россия
Не согласен, JSI завезли уже около 6 лет назад, процесс миграции шел очень долго и все активные библиотеки давно поддерживают новую архитектуру + есть Interop слой, который позволяет запускать модули написанные под старую архитектуру без полного переписывания
А почему вы не используете например Lottielab для создания анимаций сразу в нужном формате и без необходимости сверяться с возможностями экспорта? И пробовали ли rive? У него больше возможностей, он быстрее развивается и чаще всего выигрывает в производительности
Не такая уж и высосанная из пальца ситуация, в этом случае все отработает хорошо, такой порядок:
При запуске будет скачена вся мета инфа о самых актуальных модулях (этакий пекедж джейсон)
Если после старта будет новый релиз, то юзер все равно до перезапуска про это не узнает
Ну а бандлы будут качаться при заходе на экраны в соответствии с последней загруженной метой
Все последние на момент сборки самого приложения бандлы зашиваются в apk/ipa, поэтому юезр на первом старте не качает десятки Мб. Но если на момент запуска есть новые бандлы, то они будут обновляться.
На сколько я его понимаю, они просят категорически не менять приложение, а что-то дополнять всем ок. Многие компании используют те же самые флаги для показа того или иного функционала, BDUI или еще что-то и я не знаю случаев что бы за это прилетали баны. Тут подробнее инфа, пункт 3.3.1 B
Да, все так, на гитхабе есть пример, там как раз фичи/экраны с их логикой грузятся только при переходе на них. Это небольшие кусочки кода (если надо, то с ресурсами/картинками), потом код подгружается в движок в рантайм, запускается и рисуется UI.
Кейс обновления интерфейса без закрытия апки мы не пытались решить никак. Мысли такие: технически конечно сложная вещь, но звучит вполне реальной. В таком кейсе есть смысл только если мы юзера оставляем на экране, на котором он был, а значит надо стейт сохранять. А тут в голову сразу приходят проблемы: если стейт поменялся между версиями, то это уже миграции писать надо какие-то... ну и все такое. В общем все это сделать как будто можно, но сложность несравнимо высока с профитом от этого.
Возможно вы не так поняли идею RN и лишний раз пересобирали приложение. Его надо пересобирать только в случае обновления или добавления нативных зависимостей
Не до конца понял что вы имеете ввиду. Обычно у сервера есть апи, вы можете к нему обращаться и получать данные в рамках контрактов. Если надо вы можете эти данные сохранить в тот же SQLite или любую другую БД на девайсе. Какой документации вам не тут хватило или какой вы ожидали?
Я думаю что для одного разработчика с ограниченным временем - любой незнакомый инструмент не лучший путь. Ну только если вы не хотите его изучить
А зачем вообще вы брали Flutter для этого? Почему не нативку учитывая что вы с ИИ прогали, ну или ionic или cardova, на крайняк? Просто взять здоровенный фраемворк исключительно для показа вебвью и навбара звучит как оверхед и такое советовать я бы не стал.
Не понял что такое "основная сборка" и зачем потом надо было переорганизовывать проект и что значит "переорганизовывать проект". Предполагаю что речь про андроид. Для него обычно создается дебаг и прод ключи (использование можно посмотреть в файле android/app/build.gradle) и приложение подписывается в зависимости от build variant, который вы используете при сборке. При этом откатываться или что-то переорганизовывать не надо
А вы пробовали на RN сделать тоже самое с WebView, как пришли к выводу что на Flutter это сделать быстрее?