У вас будет виджет (от балды, назовем его NancListView), способный отрисовать что угодно (написанное на XML), на данный момент, минимальный размер этого виджета в рамках приложения - скроллящийся список. То есть вы можете встроить этот виджет в ваш существующий экран, или сделать отдельный экран из такого виджета и управлять им через CMS.
Ведется работа и по более маленькому размеру - атомарным виджетам. Работать это будет примерно так: Вы полностью создаете виджет через CMS, скажем - некую продуктовую карточку. Используете, условный NancWidget, передавая в него требуемые параметры, которые, по аналогии с {{ page.something }}, можно будет получать и в таком виджете. И теперь вы можете управлять через CMS тем, как выглядит этот виджет, полностью менять его, а через приложение, классическим путем - наполнять его данными. Фактически сохраняя классический способ разработки приложения и получая возможность изменять вид любого компонента через CMS.
Которая может быть использована с вашей текущей инфрой
И которая позволяет (дополнительно к основному CMS-функционалу) создавать UI с (пока небольшой) логикой, используя для этого XML с наименованием тегов, аналогичным наименованию виджетов во Flutter
Flutter-код из XML не генерится в прямом смысле слова. XML парсится в реальном времени, весь "экран", назовем его так, асинхронно преобразуется в виджеты, и затем используются только они.
Чтобы начать использовать достаточно всего одной потребности - "хочу править контент", затем, если "хочу иметь возможность создавать и обновлять экраны Flutter-апок динамически" - то в ход идет UI Builder (назовем его так).
Есть "из коробки", работающие хорошо. Плюс появляются интересные сторонние решения (первое попавшееся).
Воспользуюсь аргументом автора оригинальной статьи: "Вот impeller зарелизится, тогда заживем! 🙂". Если по существу - да, бывают "какие-то баги", которые визуально выглядят как лаги, к сожалению у меня нет iOS устройства под рукой, чтобы как-то погрузиться в причину там происходящего и оправдать Flutter более аргументированно, поэтому просто отвечу - ну ок, есть вот такой вот лаг при такой вот анимации на iOS
Вот у меня тоже есть ощущение (по крайней мере мой опыт именно такой) что почти все делают все кастомное, и это и есть стихия Flutter - на нем не нужно прикладывать усилий, чтобы все выглядело везде одинаково (кастомно), на RN я пока не писал, но есть ощущение, что на нем придется прикладывать дополнительные усилия, чтобы все выглядело одинаково.
Как я и упомянул, единственный (по моему мнению) объективный плюс RN - CodePush. Этот плюс у него есть и относительно нативных способов разработки, но значит ли это, что из-за этого плюса нативная разработка более не применима? Если нет - то это не значит того же и относительно Flutter. Потом, процесс тестирования (именно во время разработки) в случае с Flutter не является сколь бы то ни было сложным или долгим (с любых точек зрения) - если есть CI, то на любой чих можно сделать билды сборок, автоматически доставляемые в интересующий вас канал (например - Firebase Distribution), которые доступны для тестировщиков в течение нескольких минут. Поэтому разница в этом аспекте по сравнению с RN будет заключаться только в том, что тестировщику RN-приложения достаточно будет лишь открыть уже установленное приложение для тестов, а тестировщику Flutter-приложения - установить новую версию поверх старой (~ 1 минута - максимум).
Относительно публикации обновлений приложения "без сторов" - круто, все так, но зыбко. И я, с точки зрения бизнеса, не стал бы делать ставку на какую угодно технологию, полагаясь на серую зону и то, что она никогда не станет черной.
Не ко мне вопрос, но, предположу, что фикс конкретной проблемы (как я понял, проблема не в производительности как таковой, а в сочетании скорости обновления экрана и анимаций или отправке дебаг-эвента) - еще не влит в stable / не протестирован / еще что-то.
Добавленный сюда Xamarin - это стёб. Опять же, ничего не имею против, и это может быть тем, что когда-то выстрелит, но сейчас это совершенно не конкурент ни для Flutter, ни для React Native.
А вот с "невозможностью" переиспользования кода во Flutter - интересно. Какие у вас кейсы, что для веба Flutter не пригоден? И какие именно нативные плюшки вам нужны?
Приходится, иногда, работать в офлайне, но при этом все окружение и все зависимости были установлены при наличии интернета.
Мне кажется, самым простым будет получить, каким-нибудь образом, интернет на рабочей машине, установить окружение, запустить hello-world приложение, и после этого можно будет работать офлайн (но без новых зависимостей).
Либо повторить все это на машине с интернетом и перенести все это на машину без интернета.
Либо завести внешний жесткий, на котором вести всю разработку (пожалуй, последний вариант будет наименее болезненным).
Нет каких-то особых причин, кроме желания написать велосипед. Хотя можно было бы и обосновать это тем, что написав 50 строк кода я избавился от одной зависимости.
Авто-генерируемый фронт подойдёт для очень стандартных админок, сделать кастомный продукт таким образом не получится, а посему - генерация фронта решает очень малую выборку задач.
А по поводу унылости - интересное мнение) я последний год использую gRPC и он мне очень нравится.
Плагинов для работы с камерой есть достаточно, но вот чтобы работать сразу с распознаванием — что-то тоже есть (типа firebase ml), но для VR — скорее всего придется писать самостоятельно
У вас будет виджет (от балды, назовем его
NancListView), способный отрисовать что угодно (написанное на XML), на данный момент, минимальный размер этого виджета в рамках приложения - скроллящийся список. То есть вы можете встроить этот виджет в ваш существующий экран, или сделать отдельный экран из такого виджета и управлять им через CMS.Ведется работа и по более маленькому размеру - атомарным виджетам. Работать это будет примерно так:
Вы полностью создаете виджет через CMS, скажем - некую продуктовую карточку. Используете, условный
NancWidget, передавая в него требуемые параметры, которые, по аналогии с{{ page.something }}, можно будет получать и в таком виджете. И теперь вы можете управлять через CMS тем, как выглядит этот виджет, полностью менять его, а через приложение, классическим путем - наполнять его данными. Фактически сохраняя классический способ разработки приложения и получая возможность изменять вид любого компонента через CMS.Спасибо!
Это стоит рассматривать как:
CMS
Которая может быть использована с вашей текущей инфрой
И которая позволяет (дополнительно к основному CMS-функционалу) создавать UI с (пока небольшой) логикой, используя для этого XML с наименованием тегов, аналогичным наименованию виджетов во Flutter
Flutter-код из XML не генерится в прямом смысле слова. XML парсится в реальном времени, весь "экран", назовем его так, асинхронно преобразуется в виджеты, и затем используются только они.
Чтобы начать использовать достаточно всего одной потребности - "хочу править контент", затем, если "хочу иметь возможность создавать и обновлять экраны Flutter-апок динамически" - то в ход идет UI Builder (назовем его так).
Есть "из коробки", работающие хорошо. Плюс появляются интересные сторонние решения (первое попавшееся).
Воспользуюсь аргументом автора оригинальной статьи: "Вот impeller зарелизится, тогда заживем! 🙂". Если по существу - да, бывают "какие-то баги", которые визуально выглядят как лаги, к сожалению у меня нет iOS устройства под рукой, чтобы как-то погрузиться в причину там происходящего и оправдать Flutter более аргументированно, поэтому просто отвечу - ну ок, есть вот такой вот лаг при такой вот анимации на iOS
Вот у меня тоже есть ощущение (по крайней мере мой опыт именно такой) что почти все делают все кастомное, и это и есть стихия Flutter - на нем не нужно прикладывать усилий, чтобы все выглядело везде одинаково (кастомно), на RN я пока не писал, но есть ощущение, что на нем придется прикладывать дополнительные усилия, чтобы все выглядело одинаково.
Как я и упомянул, единственный (по моему мнению) объективный плюс RN - CodePush. Этот плюс у него есть и относительно нативных способов разработки, но значит ли это, что из-за этого плюса нативная разработка более не применима? Если нет - то это не значит того же и относительно Flutter. Потом, процесс тестирования (именно во время разработки) в случае с Flutter не является сколь бы то ни было сложным или долгим (с любых точек зрения) - если есть CI, то на любой чих можно сделать билды сборок, автоматически доставляемые в интересующий вас канал (например - Firebase Distribution), которые доступны для тестировщиков в течение нескольких минут. Поэтому разница в этом аспекте по сравнению с RN будет заключаться только в том, что тестировщику RN-приложения достаточно будет лишь открыть уже установленное приложение для тестов, а тестировщику Flutter-приложения - установить новую версию поверх старой (~ 1 минута - максимум).
Относительно публикации обновлений приложения "без сторов" - круто, все так, но зыбко. И я, с точки зрения бизнеса, не стал бы делать ставку на какую угодно технологию, полагаясь на серую зону и то, что она никогда не станет черной.
Не ко мне вопрос, но, предположу, что фикс конкретной проблемы (как я понял, проблема не в производительности как таковой, а в сочетании скорости обновления экрана и анимаций или отправке дебаг-эвента) - еще не влит в stable / не протестирован / еще что-то.
В том же issue есть по меньшей мере две отсылки к тому, что проблема решена
Добавленный сюда Xamarin - это стёб. Опять же, ничего не имею против, и это может быть тем, что когда-то выстрелит, но сейчас это совершенно не конкурент ни для Flutter, ни для React Native.
А вот с "невозможностью" переиспользования кода во Flutter - интересно. Какие у вас кейсы, что для веба Flutter не пригоден? И какие именно нативные плюшки вам нужны?
https://docs.flutter.dev/perf/shader
device_preview
Зато работает состояние, когда не работает веб)
Мне кажется, самым простым будет получить, каким-нибудь образом, интернет на рабочей машине, установить окружение, запустить hello-world приложение, и после этого можно будет работать офлайн (но без новых зависимостей).
Либо повторить все это на машине с интернетом и перенести все это на машину без интернета.
Либо завести внешний жесткий, на котором вести всю разработку (пожалуй, последний вариант будет наименее болезненным).
Нет каких-то особых причин, кроме желания написать велосипед. Хотя можно было бы и обосновать это тем, что написав 50 строк кода я избавился от одной зависимости.
Я думаю, он дойдет до публикации в стопах, пока все ещё в процессе написания
Можете ли поделиться тестовыми проектами (1. 2. 3)? Особенно интересен 3.
adb rootтоже работает, то получится ли через adb сделать unpinning (чтобы не пересобирать apk - большой вопрос)Спасибо, буду ковырять
Авто-генерируемый фронт подойдёт для очень стандартных админок, сделать кастомный продукт таким образом не получится, а посему - генерация фронта решает очень малую выборку задач.
А по поводу унылости - интересное мнение) я последний год использую gRPC и он мне очень нравится.
В TS прям эта же схема работает просто как сказка, вообще без лишних телодвижений