Comments 6
Даже банальные команды сборки могли сильно грузить систему. Часто приходилось ждать по несколько минут, пока приложение пересоберётся
Возможно вы не так поняли идею RN и лишний раз пересобирали приложение. Его надо пересобирать только в случае обновления или добавления нативных зависимостей
Простая задача, казалось бы. Но оказалось, что прямое подключение серверной базы к приложению без промежуточного API не имеет смысла
Не до конца понял что вы имеете ввиду. Обычно у сервера есть апи, вы можете к нему обращаться и получать данные в рамках контрактов. Если надо вы можете эти данные сохранить в тот же SQLite или любую другую БД на девайсе. Какой документации вам не тут хватило или какой вы ожидали?
Для одного разработчика с ограниченным временем — нативная разработка на React Native не лучший путь.
Я думаю что для одного разработчика с ограниченным временем - любой незнакомый инструмент не лучший путь. Ну только если вы не хотите его изучить
Для реализации WebView-приложения я выбрал Flutter — фреймворк от Google, построенный на языке Dart
А зачем вообще вы брали Flutter для этого? Почему не нативку учитывая что вы с ИИ прогали, ну или ionic или cardova, на крайняк? Просто взять здоровенный фраемворк исключительно для показа вебвью и навбара звучит как оверхед и такое советовать я бы не стал.
Я однажды подписал основную сборку, и потом пришлось откатываться назад и переорганизовывать проект, чтобы снова собирать без подписи.
Не понял что такое "основная сборка" и зачем потом надо было переорганизовывать проект и что значит "переорганизовывать проект". Предполагаю что речь про андроид. Для него обычно создается дебаг и прод ключи (использование можно посмотреть в файле android/app/build.gradle) и приложение подписывается в зависимости от build variant, который вы используете при сборке. При этом откатываться или что-то переорганизовывать не надо
Flutter — лучшее решение для быстрого и стабильного вывода веб-сайта в формате приложения, особенно если нужен WebView или кастомный UI
А вы пробовали на RN сделать тоже самое с WebView, как пришли к выводу что на Flutter это сделать быстрее?
Здравствуйте, спасибо за критику.
Хочу уточнить, что моя статья — это субъективный опыт человека, который до этого не имел опыта в мобильной разработке. Главная задача стояла — создать работающее мобильное приложение в кратчайшие сроки, а не изучить всё досконально. И именно с этой задачей я успешно справился.
Сначала я выбрал React Native, поскольку это один из самых популярных инструментов для кроссплатформенной разработки. Однако по ходу работы столкнулся с рядом сложностей: нехваткой понятной информации для новичка (например, по работе с серверными базами), необходимостью постоянной установки дополнительных библиотек и довольно тяжёлой сборкой, особенно на слабом ноутбуке. Это замедляло процесс, вызывало раздражение и съедало время.
При этом контент и дизайн у меня уже были реализованы в виде веб-приложения — оставалось только адаптировать их под мобильную среду. В такой ситуации WebView оказался логичным решением. Он позволяет повторно использовать готовый веб-контент, добавив к нему нативную оболочку и, при необходимости, элементы навигации или локальной логики.
Я рассматривал возможность использовать WebView как на React Native, так и на Flutter. На основе своего опыта и проведённого сравнения (в том числе с помощью AI и обзоров в сети), я выбрал Flutter. Он показался мне более простым в освоении, имел всё нужное "из коробки", быстрее собирал проект и потреблял меньше ресурсов. В итоге за 2 недели я сделал кроссплатформенное приложение, которое стабильно работает и весит всего 18 МБ после установки.
Моя цель — не доказать, что Flutter лучше всех, а показать, что в определённых условиях — при наличии уже готового веб-продукта и ограниченного времени — WebView приложение может быть эффективным решением, а освоение мобильной разработки вовсе не требует глубоких знаний с первого дня. В данном случае практичный результат важнее "идеального" подхода.
На c# вполне пишется кросплатформено. Раньше ксамарин был, но его Майкрософт купил вроде. Давно не занимался мобильной разработкой. Но для вебвью и навигации использовать какие то сторонние библиотеки с кучей лишнего - такое себе. Стандартные средства уже не работают что ли?
Спасибо за комментарий! Моя статья — это субъективный опыт новичка, который успешно справился с задачей: быстро создать производительное кроссплатформенное приложение с WebView и нативной навигацией для уже существующего веб-сайта. Выбор Flutter был обусловлен не только его популярностью, но и тем, что он позволил достичь поставленных целей в сжатые сроки, сэкономить на оборудовании (не нужен Mac для iOS-разработки) и получить легкое приложение (18 МБ). Альтернативы вроде Xamarin (сегодня известный как .NET MAUI) или Ionic/Cordova не попали в моё поле зрения при поиске наиболее эффективных инструментов для быстрого старта новичка, а уж тем более не решали бы мою задачу кроссплатформенности без глубокого погружения в две нативные экосистемы. Результат налицо: приложение есть и работает, а это главное.
Можно в машине элементы кузова не сварить, а на клей посадить, и тоже будет работать... Какое-то время.
Задачи "чтоб заработало" стоит оставлять на работе или в личных одноразовых утилитах.
Здесь на Хабре читатели с большего это инженеры, а инженеры хотят анализа: контекст такой, опции такие и такие, решил сравнить. Вариант 1 оказался самым быстрым с точки зрения разработки MVP, но вариант 2 более гибкий и предоставляет больше кастомизации в долгосрочной перспективе. Вывод: для своего кейса я пошел с вариантом 1.
Тогда инженер захочет задать дополнительные вопросы, поделиться своим опытом, указать на неточности. А так получается в последнее время инженер только что и делает, как указывает на неточности, какой-то байт на комментарии)
Скажем честно, что использование Flutter на том же макбуке значительно съедает места на диске, особенно если использовать эмуляторы андроид и ios устройств. Даже сама установка всего нужного занимает часа два, если всё гладко. Гигабайт 50, наверное нужно иметь, хотя сами приложения не превышают 10 мегабайт)). На Windows примерно также.
Как сделать мобильное приложение в 2025 году за 2 недели