Комментарии 48
На русском о flutter кроме Surf вообще кто-нибудь пишет? А то только их статьи подкасты и видео попадаются. Ну и Wrike немного, но у них больше по дарту)
А как же навигация во flutter в асинхронных экшнах того же MobX, когда у нас нет контекста?
Только GetX или есть другие решения?
Только GetX или есть другие решения?
С MobX плотно не работал, но в данной ситуации первое что приходит на ум:
Можно передать Navigator где-нибудь вверху дерева при инициализации. Так как под капотом он все-равно через of ищет экземпляр по дереву.
Другой момент что если навигаторов больше одного, то:
Создавать в DI ScaffoldKey и провайдить его до Scaffold и где нужно в логике через scaffolKey.currentContext брал навигатор.
Можно передать Navigator где-нибудь вверху дерева при инициализации. Так как под капотом он все-равно через of ищет экземпляр по дереву.
Другой момент что если навигаторов больше одного, то:
Создавать в DI ScaffoldKey и провайдить его до Scaffold и где нужно в логике через scaffolKey.currentContext брал навигатор.
Скажите, а у вас нет ощущения переусложненности флатеровской верстки? Я не могу отделаться от ощущения, что тот, кто это разрабатывал бы далек от понимания простоты html и css. Это же надо придумать, если у тебя вложенный один виджет, пиши child, если массив — children. Вот такая умная штука не умеет сама считать до двух?
Я, признаться, был несколько большего впечатления о flutter. Думал, он как-то вобрал в себя близкое из css и html — на деле волшебства с розовыми понями, приходиться воображать паралельно чтению документации самостоятельно.
Я, признаться, был несколько большего впечатления о flutter. Думал, он как-то вобрал в себя близкое из css и html — на деле волшебства с розовыми понями, приходиться воображать паралельно чтению документации самостоятельно.
По поводу ощущения: поначалу было, но потом понимаешь что это удобно и писать становится легко. Возможно, сила привычки.
По поводу child: библиотека виджетов Flutter написана на Dart, он строго типизирован и не умеет ставить варианты типов, как, например, в TypeScript:
И перегрузки тоже нет.
Получается чтобы он сам определял виджет это или список виджетов — нужно передавать dynamic и уже под капотом будет определяться тип, так как у Widget и List нет общего предка. А dynamic значит что мы можем туда пробросить хоть bool. При запуске у нас все, конечно, посыпется, но преимущество типизации в том что мы видим ошибку на этапе написания кода, а не в рантайме.
По поводу child: библиотека виджетов Flutter написана на Dart, он строго типизирован и не умеет ставить варианты типов, как, например, в TypeScript:
Widget | List<Widget>И перегрузки тоже нет.
Получается чтобы он сам определял виджет это или список виджетов — нужно передавать dynamic и уже под капотом будет определяться тип, так как у Widget и List нет общего предка. А dynamic значит что мы можем туда пробросить хоть bool. При запуске у нас все, конечно, посыпется, но преимущество типизации в том что мы видим ошибку на этапе написания кода, а не в рантайме.
Бррр, это же хорошо что он не похож на css и html. Эти две штуки одна из многих причин почему не люблю веб фронтенд.
Ну не знаю, сильно порезать html в рамках флаттера было бы возможно. Оставить хотя бы названия и объявление свойств. Не нужно было бы два раза слово паддинг писать если тебе нужен паддинг.
Одна фигня, иерархия блоков, да их свойства флексы падинги фонтсайзы все это и там и там.
Я надеюсь, что я чего то не догоняю ещё. Но модули в моей логике до флаттера то я уже видел. Не один я чувствую горошинку под матрасом.
То с непривычки.))
Сам начинал с веба. Не скажу что одно лучше другого, для меня и у того и у того есть преимущества.
Но я настолько прикипел к декларативной верстке Flutter, что делать как раньше уже не так нравится.
Но я настолько прикипел к декларативной верстке Flutter, что делать как раньше уже не так нравится.
Стокгольмский синдром эта непривычка называется.)
Сначала напишите большой коммерческий проект на Flutter потом посмотрим как захотите назад к html и css. Уверяю я был такого же мнения о верстке когда первый раз на него взглянул и пощупал на пет проекте. А написав полноценный коммерческий продукт понимаешь почему пришли именно к такому подходу а не какому нибудь другому. Сейчас в восторге от flutter и назад в Native не хочу.
Скажите, а зачем вообще нужен реакт или флуттер, если есть нативные жава/котлин/свифт?
Из-за кроссплатформенности? Тогда почему не xamarin?
Потому что иных резонов их использовать, я, честно говоря, не вижу.
Из-за кроссплатформенности? Тогда почему не xamarin?
Потому что иных резонов их использовать, я, честно говоря, не вижу.
Чем больше инструментов (особенно с разными концепциями и логикой) — тем лучше. До того же xamarin был qt например, это же не значит что только qt нужно было использовать и ничего не разрабатывать.
ну оно как бы очевидно, что разработка для webview как-то не очень в силу специфики платформы; js будет и медленнее, и вряд ли позволит доступаться к специфическим API андроида. Как с флуттером, я не знаю. Может, я и про RN ошибаюсь, но для нас доступ к упомянутым специфическим API (Telephony API, Wifi и прочая нетворк) критичен, поэтому, наверное, я эти альтернативы и не воспринимаю всерьез
Так у них разные точки входа.
Компании срочно нужна прилага, и у нее есть куча веб разработчиков. Учить C# + Xamarin или взять React Native? Даже не зная React — проще изучить RN, чем с нуля совершенно другую платформу. А если подходит для задачи PWA, то там вообще минимум усилий.
Теперь ситуация обратная — шарписту проще Xamarin.
Но у каждого из фреймворков и нативки есть плюсы и минусы. RN не такой производительный как хотелось бы, у Xamarin хватает проблем, нативка громоздкая во многих вещах (а анимации делать так вообще караул). Вот тут добавляется еще Flutter.
Чтобы разработчик имел не один инструмент и мирился с ним, а выбирал то что ближе по целям и меньшим влиянием на задачу минусов выбранной технологии.
Также на количество кросс-платформы влияет:
Компании срочно нужна прилага, и у нее есть куча веб разработчиков. Учить C# + Xamarin или взять React Native? Даже не зная React — проще изучить RN, чем с нуля совершенно другую платформу. А если подходит для задачи PWA, то там вообще минимум усилий.
Теперь ситуация обратная — шарписту проще Xamarin.
Но у каждого из фреймворков и нативки есть плюсы и минусы. RN не такой производительный как хотелось бы, у Xamarin хватает проблем, нативка громоздкая во многих вещах (а анимации делать так вообще караул). Вот тут добавляется еще Flutter.
Чтобы разработчик имел не один инструмент и мирился с ним, а выбирал то что ближе по целям и меньшим влиянием на задачу минусов выбранной технологии.
Также на количество кросс-платформы влияет:
- Производительность или простота решения. Были на базе WebView (Phonegap, например) — есть альтернатива в лице более производительного Xamarin, ему в альтерантиву выкатили более простой в написании кода (в идеале) RN.
- Также, на мой взгляд, это отчасти репутационный вопрос, если компания создаст крутую технологию, это ей в плюс.
- Каждая новая кросс-платформа старается быть лучше предыдущей. WevView лагает — вот вам RN с нативными OEM виджетами. У RN фризы из-за моста — вот вам Flutter без него и еще свой движок рендера с AOT компиляцией, что делает его еще быстрее.
Ну, я вообще скептичен к кросс-платформе
Сколько не сталкивался — оно работает более-менее если ничего серьезного на клиенте не делать. Ну и WevView по сути своей (имхо) есть такая кривая быстрая заплатка, не очень хорошо работающая в силу адского разнообразия дивайсов и размеров их экранов/разрешений
Flutter меня смущает тем, что он все еще такой… полуофициальный. Если с котлиным/жавой я могу просто установить а. студию, и все, я готов разрабатывать, то с Ф. придется попрыгать. Ну и с отладкой там тоже не все так просто, а у меня травма после ndk/c++
Сколько не сталкивался — оно работает более-менее если ничего серьезного на клиенте не делать. Ну и WevView по сути своей (имхо) есть такая кривая быстрая заплатка, не очень хорошо работающая в силу адского разнообразия дивайсов и размеров их экранов/разрешений
Flutter меня смущает тем, что он все еще такой… полуофициальный. Если с котлиным/жавой я могу просто установить а. студию, и все, я готов разрабатывать, то с Ф. придется попрыгать. Ну и с отладкой там тоже не все так просто, а у меня травма после ndk/c++
А что не так с отладкой? Помоему Dart Dev Tools просто превосходят нативную отладку. Чего полуоффициальній? Все оффициально и достаточно установить плагин и сдк(как и с Android SDK) для полной работі со студии. Причем на маке Андроид студия сразу превращается в кросс-платформенную студию с которой можно запускать как на іос так и на андроид.
Я не пробовал отладку флаттера
А с ndk+lldb все очень плохо — студия не всегда останавливается на брейкпойнтах, очень не всегда показывает значения переменных; если переменные это std::, то вообще их не замечает; если же код, не дай бог, мультипоточный — тушите свет
В конечном итоге отладка сводится к логгировани переменных и чтению логов
Если у дарта с этим лучше — это хорошо, но, честно говоря, как-то все равно сомнительно. Ну и усложненный доступ к андроидному фреймворку это несерьезно
А с ndk+lldb все очень плохо — студия не всегда останавливается на брейкпойнтах, очень не всегда показывает значения переменных; если переменные это std::, то вообще их не замечает; если же код, не дай бог, мультипоточный — тушите свет
В конечном итоге отладка сводится к логгировани переменных и чтению логов
Если у дарта с этим лучше — это хорошо, но, честно говоря, как-то все равно сомнительно. Ну и усложненный доступ к андроидному фреймворку это несерьезно
Отладка действительно хороша и информативна. А что с доступом к андроидному фреймворку не нравиться? Там все элементарно и просто. Вы ж работаете с мультиплатформенным решением, куда еще проще… Хотите чейннелы напишите там как два пальца об асфальт, а хотите ffi заюзайте и напрямую нативный код дергайте.
Это дешевле и проще в поддержке. Вместо пяти программистов под пять платформ — один. Ну или вместо изучения разных языков и средств — изучить одно.
Я вот, если честно, не упомню ни одного сколько нибудь успешного кроссплатформенного приложения (веб не в счет). Ну, чтоб одна и та же code base, под линукс и винду, например
А что вы имеете ввиду? Сходу назову: Chrome (Firefox, Opera и пр., даже Edge), KeePass CX, vsCode, Telegram, Slack, mpv, VLC, Skype, MS Teams, FileZilla, SmartGit. А если копнуть глубже, то выясняется, что практически всё что я использую, это кросс-платформенные приложения. Если брать консольные, то 90+%.
Или вы имеете ввиду именно на Dart?
разве там одна и та же code base? Не знаю насчет хрома, но огнелис написан на плюсах, и просто взять и скомпилировать один и тот же неизменный код на с++ вижуал студией под винду и gcc под линукс вряд ли получится.
Вы, возможно, имеете в виду порты программ на разные платформы, но это ж совсем не значит, что они кросс-платформенные.
Вы, возможно, имеете в виду порты программ на разные платформы, но это ж совсем не значит, что они кросс-платформенные.
Мне кажется у вас какое-то своё понимание слова кросс-платформенность. Если большая часть кода переиспользуется — приложение кроссплатформенное. Какие при этом задействованы компиляторы, с какими флагами, и какие бубны при этом бьются — не имеет значения.
In computing, cross-platform software (also multi-platform software or platform-independent software) is computer software that is implemented on multiple computing platforms.[2] Cross-platform software may be divided into two types; one requires individual building or compilation for each platform that it supports, and the other one can be directly run on any platform without special preparation, e.g., software written in an interpreted language or pre-compiled portable bytecode for which the interpreters or run-time packages are common or standard components of all platforms.[3]
Я могу ошибаться, но, имхо, умеренное количество IFDEF-ов не делают софт НЕ кроссплатформенным. Эти самые IFDEF есть даже в React native с его JS.
Обычное у меня понимание
Возьмем программу на жава — в большинстве случаев мне вообще ничего не надо делать, java.exe my.jar будет и на линуксе, и на винде
А если мне надо делать специальный билд под каждую платформу — это уже не кроссплатформанность. Элементарно, например — доступ к файлам в линуксе и винде описан по-разному, и на тех же плюсах вам надо будет иметь разную имплементацию
Далее, если вы используете (а вы используете) функции ядра, сиречь системный API, он тоже будет разный, и писать его надо будет по-разному. Например, многопоточность. И т.п., набором ifdef ов тут ограничиться не получится
А суть кросс-платформы как раз в том и заключается, что код будет бежать на разных платформах с минимальныму переделками. По крайней мере, менеджмант ее понимает именно так
Возьмем программу на жава — в большинстве случаев мне вообще ничего не надо делать, java.exe my.jar будет и на линуксе, и на винде
А если мне надо делать специальный билд под каждую платформу — это уже не кроссплатформанность. Элементарно, например — доступ к файлам в линуксе и винде описан по-разному, и на тех же плюсах вам надо будет иметь разную имплементацию
Далее, если вы используете (а вы используете) функции ядра, сиречь системный API, он тоже будет разный, и писать его надо будет по-разному. Например, многопоточность. И т.п., набором ifdef ов тут ограничиться не получится
А суть кросс-платформы как раз в том и заключается, что код будет бежать на разных платформах с минимальныму переделками. По крайней мере, менеджмант ее понимает именно так
в большинстве случаев мне вообще ничего не надо делать, java.exe my.jar будет и на линуксе, и на винде
Это никак не связано с кросс-платформенностью.
и на тех же плюсах вам надо будет иметь разную имплементацию
До тех пор пока она
- скрыта от ваших глаз (например: готовая или стандартная библиотека)
- либо этот код не занимает существенную часть вашего приложения
это всё не имеет никакого отношения к обсуждаемому вопросу. Я повторюсь — даже на React Native с его JavaScript у вас будут флаги isIOS и isAndroid, и часть кода будет скрыта за IF-ми. НИКАКОЙ принципиальной разницы с доступом к файловой системе из под c++.
А суть кросс-платформы как раз в том и заключается, что код будет бежать на разных платформах с минимальныму переделками
Так и есть. И вышеописанный софт как раз такой. Тот самый менеджер нанимает очередного погроммиста, и тот 95%+ времени пишет код, который будет исполняться на всех поддерживаемых платформах разом.
Так и есть. И вышеописанный софт как раз такой. Тот самый менеджер нанимает очередного погроммиста, и тот 95%+ времени пишет код, который будет исполняться на всех поддерживаемых платформах разом.
За 20+ лет разработки я не встречал ни одного более-менее сложного софтваря, которое бы без проблем работало по описанным выше принципам. Возможно, какая-то часть кода м.б. кросс-платформенной — алгоритмы там, или бизнес-логика, но далеко не весь код, и совсем не ифдефами это все решается. Посмотрите, например, на процедуру билда того же фаерфокса на винде и убунту, насколько они сложные и разные. Если бы все было как вы говорите, у нас было бы одно описание для билдов под все платформы, а это не так.
Кроме того, программер, который пишет кросс-платформу, должен быть ээ skilled в этих самых платформах. Т.е., его уровень д.б. выше
Вот потому чистая кросс-платформеннось никуда и не взлетела, это тупо дорого
За 20+ лет разработки я не встречал ни одного более-менее сложного софтваря, которое бы без проблем работало
Я за примерно такой же срок тоже не видел ни одного сложного приложения, которое бы хорошо работало. Вне зависимости от его кросс-платформенности. Весь крупный софт написанный в этом мире кривой. Печальный факт.
Мы занимаемся ерундой. Вы не читаете то что я пишу. Не открываете мои ссылки и разговариваете сами с собой, доказывая мне, что вашему пониманию кросс-платформенности не соответствуют то, что другие разработчики называют кросс-платформенными приложениями. Не вижу смысла продолжать, уж извините.
Мы занимаемся ерундой. Вы не читаете то что я пишу. Не открываете мои ссылки и разговариваете сами с собой, доказывая мне, что вашему пониманию кросс-платформенности не соответствуют то, что другие разработчики называют кросс-платформенными приложениями
да читаю, читаю
Просто для 80% менеджмента кроссплатформа это один код, который работает везде, без изменений
Разработчики могут что угодно думать, решения принимают не они
Некоторые фичи требуют вызова API операционки. В Flatter это реализуется «федеративными плагинами», содержащими код на java, swift, kotlin или C++ (https://flutter.dev/docs/development/packages-and-plugins/developing-packages#step-2b-add-android-platform-code-ktjava). Ну а для сферического приложения доставки еды в вакууме самому ничего платформозависимого писать не нужно. Плюс готовых решений очень много на pub.dev. Мне такое изобилие чем-то Delphi напоминает.
ага, спасибо.
т.е., получается, что если я хочу Android SDK, мне надо иметь проект на жаве/кт. Не совсем понятно тогда, зачем мне вообще флаттер/реакт, если мне все время нужен доступ к сдк. Тем более что в последнее время у нас появился котлин, корутины, рум, джетпак, сейчас вот еще compose вовсю пилят…
Хотя, возможно, это специфика наших проектов, я просто не сталкивался с таким, что у меня логика не трогает фреймворк, или на сервере
т.е., получается, что если я хочу Android SDK, мне надо иметь проект на жаве/кт. Не совсем понятно тогда, зачем мне вообще флаттер/реакт, если мне все время нужен доступ к сдк. Тем более что в последнее время у нас появился котлин, корутины, рум, джетпак, сейчас вот еще compose вовсю пилят…
Хотя, возможно, это специфика наших проектов, я просто не сталкивался с таким, что у меня логика не трогает фреймворк, или на сервере
Не, почти все сделано до Вас, и позволяет не вникать в SDK каждой платформы. По сути флаттер — это некий макрос-кодогенератор, на выходе Вы получите компилируемый код на swift, kotlin и т.д., который уже не нужно править. Плагины собственно и описывают правила, как собирать нативный код. Для экзотики всякой, работы со своим железом придётся писать свой, но самые частые потребности уже перекрыты собственным SDK и pub.dev. Никто не говорит, что единственный и правильный путь. Но самый быстрый и дешёвый — точно.
Насколько я помнимаю, флаттер компилит приложение в нативный код, а не в свиф, котлин и прочее. Не знаю насчет свифта, а котлин так уж совершенно точно не компилится в нативный
Ну и если мне так или иначе надо писать на жаве/котлине плагины и прочее, зачем мне вносить доп. сложность в систему, и использовать еще и флаттер? Только для кроссплатформенного UI? Я не верю, что под ios UI написанный на флаттере, будет совершенно какой же, как и нативный на свифте. Новое обновление ios — и весь мой flutter UI становится некрасивой тыквой
Собссно, в большинстве мультиплатформенных проектов как раз таки UI разный, core одинаковый. А тут, вишь, новый подход
Ну и если мне так или иначе надо писать на жаве/котлине плагины и прочее, зачем мне вносить доп. сложность в систему, и использовать еще и флаттер? Только для кроссплатформенного UI? Я не верю, что под ios UI написанный на флаттере, будет совершенно какой же, как и нативный на свифте. Новое обновление ios — и весь мой flutter UI становится некрасивой тыквой
Собссно, в большинстве мультиплатформенных проектов как раз таки UI разный, core одинаковый. А тут, вишь, новый подход
Лучше писать сразу в машинном коде под каждую систему. Зачем вообще языки программирования? По сути, лишняя абстракция.
какой-то, извините, глупый комментарий
Смысл в том, что UI флаттера вообще не нативный. Он такой, каким вы его напишете. Может быть похожим на android, на windows или вообще свой собственный.
Что касается нативного кода, у него к каждой платформе свой подход. Для будущей Fuchsia он вообще единственное средство разработки, для android — виртуальная машина, для Mac есть AOT компилятор, для веб — вообще транспиляция в JS. UI у всех будет идентичным. Здесь core разный, UI одинаковый. Даже существует возможность внедрения флаттера в нативные существующие приложения с целью унифицировать и упростить именно разработку интерфейса.
Возможно, я несколько коряво излагаю, вот обзор архитектуры: https://flutter.dev/docs/resources/architectural-overview
Что касается нативного кода, у него к каждой платформе свой подход. Для будущей Fuchsia он вообще единственное средство разработки, для android — виртуальная машина, для Mac есть AOT компилятор, для веб — вообще транспиляция в JS. UI у всех будет идентичным. Здесь core разный, UI одинаковый. Даже существует возможность внедрения флаттера в нативные существующие приложения с целью унифицировать и упростить именно разработку интерфейса.
Возможно, я несколько коряво излагаю, вот обзор архитектуры: https://flutter.dev/docs/resources/architectural-overview
да я понимаю, тоже читал:)
У меня просто сомнения, что оно получит развитие — слишком уж много всего уже написано на андроиде. Мне даже интересно, как гугл вот так вот возьмет, и переползет целиком на фуксию?
У меня просто сомнения, что оно получит развитие — слишком уж много всего уже написано на андроиде. Мне даже интересно, как гугл вот так вот возьмет, и переползет целиком на фуксию?
для android — виртуальная машина
Эм, нет, он в .so компилит нативный под arm, виртуальная машина только для дебаг сборок используется.
А Kotlin Multiplatform рассматривали? Если да, какие впечатления по сравнению с RN и Flatter?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему я ушёл с React Native и перешёл во Flutter: Часть 2