Комментарии 141
А как насчет адаптивной верстки UI? Есть уже какие-то родные Flutter-решения?
нормально с ней все, есть кастомные пакеты с версткой в формате media — когда ты задаешь виджеты под каждый тип девайса, есть просто LayoutBuilder и deviceSize- когда ты можешь определить вручную необходимые параметры. Верстка кодом и css немного отличаются в подходе — но на мой взгляд все прекрасно и быстро. Колонки, строки, wrap и многое другое, конечно, тоже есть.
неплохой подход — SizeConfig, хорошо показал себя у нас на проектах
Спасибо, интересно. А как у Flutter с гейм-разработкой? Или все-таки не его/не предназначен?
Для специфических игр вроде визуальных новелл ещё можно рассматривать, но для всего остального flutter будет крайне неудобным инструментом.
Есть интеграция с Unity — что позволяет интерфейсы рисовать на flutter, а саму игру на unity. Как сказано в статье у игровых движков достаточно сложно делать многие вещи из «приложений». Кроме того есть интеграция с Rive(flare) и попытки создания своих игровых движков, но из-за достаточно раннего этапа — это не самый лучший выбор сейчас.
Ох уж и монстр получится flutter + unity, будем вспоминать, что когда-то приложения весили несколько мегабайт
Есть Flame, довольно популярный движок во Flutter сообществе.
Год назад, примерно когда я стал интересоваться флаттером, написал на нем игру-клон Flutter.Bird, было довольно интересно и надо сказать легко.
Примеры продакш ready игр на этом движке я не знаю, но знаю одну почти игру, написанную на этом движке и выложенную в сторы, можете поиграться:
apps.apple.com/us/app/darkness-dungeon/id1506675248
play.google.com/store/apps/details?id=com.rafaelbarbosatec.darkness_dungeon
github.com/RafaelBarbosatec/bonfire
Год назад, примерно когда я стал интересоваться флаттером, написал на нем игру-клон Flutter.Bird, было довольно интересно и надо сказать легко.
Примеры продакш ready игр на этом движке я не знаю, но знаю одну почти игру, написанную на этом движке и выложенную в сторы, можете поиграться:
apps.apple.com/us/app/darkness-dungeon/id1506675248
play.google.com/store/apps/details?id=com.rafaelbarbosatec.darkness_dungeon
github.com/RafaelBarbosatec/bonfire
Есть material, а есть cupertino. Как в результате получается "нативное" приложение для двух платформ? И там и там делают одинаково или
if platform == android window = MaterialWindow
if platform == ios window = CupertinoWindowЧаще всего делают усредненный дизайн, если нужен именно родной, то использую или обертки в которых уже зашита подстановка платформенных виджетов или пишут свою обертку — где if…, а в самом коде уже без if…
Flutter из коробки автоматически эмулирует многие аспекты платформы, например, физика скролла, типографика или иконки.
Поэтому, даже при использовании неродных виджетов приложение не будет вызывать отторжения и чувства чужеродности.
Но если требуется нативный вид для всех виджетов, то, действительно, нужно их явно указывать через if.
Поэтому, даже при использовании неродных виджетов приложение не будет вызывать отторжения и чувства чужеродности.
Но если требуется нативный вид для всех виджетов, то, действительно, нужно их явно указывать через if.
Я вот попытался опубликовать небольшое приложение для macOS — завернули за дизайн :D теперь сижу и думаю что делать)
Не по гайдлайнам?
совсем нет) там скорее material
github.com/doppio-dev/iXn
github.com/doppio-dev/iXn
Последний год я так или иначе пишу приложения на Flutter для iOS и Android. До этого у меня был и есть 5 летний опыт работы с Xamarin.
Так почему же флаттер побеждает, если такие статьи идут только от мобилоразработчиков?
Где статьи «Я, Вася, делал сайтики и десктоп на электроне, пересел на флаттер, и теперь меня не оторвать»?
То, что мобилоразработчики наконец-то перестали маяться дурью и писать отдельно под каждый из двух вендор-локов — это прекрасно, но это не «победа», это уже делал react native. Которым, кстати, продолжают пользоваться те, кто пришел имея сайтик и кому нужен апп. Несмотря на все его многочисленные недостатки.
Их, нет, потому что flutter не поддерживает десктоп. Они обещаяют её в будущем, пока есть только бета macOS.
Я писал на Qt, и для меня кроссплатформенный десктоп UI без С++ выглядит очень заманчивой идеей. Надеюсь на скорую поддежку.
Я писал на Qt, и для меня кроссплатформенный десктоп UI без С++ выглядит очень заманчивой идеей. Надеюсь на скорую поддежку.
Я не Вася, бэкенд разработчик. На новогодние прошёл курс по Flutter. На работе предложил написать приложение для внутреннего использования, на прошлой неделе выкатил альфу для тестирования. Это паралельно основной работе. Очень понравилось, приятно видеть результат работы. Буду уходить со временем на мобильную разработку.
А недостатки Xamarin какие по вашему мнению? И есть ли преимущество перед Flutter?
С моей колокольни (ксамарин 5+ лет и флаттер второй год)
минусы:
ксамарин натив — недружелюбная vs4mac для проектирования ui, приходилось переключаться в as и xcode; для подключения популярных андроидовских и иосных либ надо делать биндинги.
ксамарин формс — постоянный спуск к рендерерам, у меня не было проектов, чтобы в нем не было с десяток кастомных рендереров. стандартный набор контролов весьма куцый, по моему мнению для сложного дизайна формс абсолютно не подоходит, нам приходилось сильно изворачиваться, чтобы сделать что то нестандартное.
плюсы над флаттером:
ксамарин натив — честно, не знаю. разве что у вас какой то интерпрайз и вы подключите огромные дотнетовские либы, и не надо будет переводить код в дарт.
формс — мне очень нравятся возможности для mvvm из коробки от майков, что в uwp, wpf и xamforms.
минусы:
ксамарин натив — недружелюбная vs4mac для проектирования ui, приходилось переключаться в as и xcode; для подключения популярных андроидовских и иосных либ надо делать биндинги.
ксамарин формс — постоянный спуск к рендерерам, у меня не было проектов, чтобы в нем не было с десяток кастомных рендереров. стандартный набор контролов весьма куцый, по моему мнению для сложного дизайна формс абсолютно не подоходит, нам приходилось сильно изворачиваться, чтобы сделать что то нестандартное.
плюсы над флаттером:
ксамарин натив — честно, не знаю. разве что у вас какой то интерпрайз и вы подключите огромные дотнетовские либы, и не надо будет переводить код в дарт.
формс — мне очень нравятся возможности для mvvm из коробки от майков, что в uwp, wpf и xamforms.
недружелюбная vs4mac для проектирования ui
Есть же райдер.
стандартный набор контролов весьма куцый, по моему мнению для сложного дизайна формс абсолютно не подоходит
На xaml разве нельзя сделать кастомный контрол?
Можно, но это отнимает больше времени, чем хотелось бы…
Есть же райдер.
по vs4mac я говорил про нативный ui. для xf формочек для проектирования нет нигде.
На xaml разве нельзя сделать кастомный контрол?
Можно конечно, но он будет состоять из других контролов — которые абстракции над нативом, если вы имеете ввиду композицию в xaml. А сам набор очень ограничен.
Про один недостаток я написан, отсутствие дефолтного UI рендера (для кого-то это вовсе не минус). Все опирается на нативные контроллы. Хотя если использовать SkiaSharp, то жить можно.
Другой минус(ы), очень субъективный, который лично мне сложно выразить словами.
Почему, например, Xamarin так и не подвез Catalyst для Mac? Почему с покупкой Xamarin майкрософтом они все больше превращают ex-Xamarin Studio в IDE для работы с .Net Core, чем собственно с Xamarin? Я уже не говорю о том, что Xamarin.Forms за последние несколько лет превратился собственно в синоним Xamarin. Хотя, тут ответ наверное очевиден. Майкрософт всегда был бизнесом, ориентированным на корпоративный сегмент. Я хочу делать красивый UI и удобные приложения а не формочки для страховой компании.
Как минус Xamarin можно также занести отсутствие Hot Reload/Restart. Вроде как они что-то похожее сделали, но это работает только в Forms и даже (поправьте если ошибаюсь) только с iOS… В общем, так же как во Flutter у них не получится сделать просто потому что бессмысленно, все равно в итоге все упирается в нативный UI.
Другой минус(ы), очень субъективный, который лично мне сложно выразить словами.
Почему, например, Xamarin так и не подвез Catalyst для Mac? Почему с покупкой Xamarin майкрософтом они все больше превращают ex-Xamarin Studio в IDE для работы с .Net Core, чем собственно с Xamarin? Я уже не говорю о том, что Xamarin.Forms за последние несколько лет превратился собственно в синоним Xamarin. Хотя, тут ответ наверное очевиден. Майкрософт всегда был бизнесом, ориентированным на корпоративный сегмент. Я хочу делать красивый UI и удобные приложения а не формочки для страховой компании.
Как минус Xamarin можно также занести отсутствие Hot Reload/Restart. Вроде как они что-то похожее сделали, но это работает только в Forms и даже (поправьте если ошибаюсь) только с iOS… В общем, так же как во Flutter у них не получится сделать просто потому что бессмысленно, все равно в итоге все упирается в нативный UI.
Hot Reload в Xamarin.Forms есть с 2019 года, и для Android и для iOS, постоянно пользуюсь.
Насчет Xamarin.Native не скажу.
Насчет Xamarin.Native не скажу.
рефреш xaml работает в дебаге стабильно для ios-droid. Рестарт — вроде тоже, скорость старта, особенно андроида, в последних релизах сильно апали.
Основная проблема xf — медленный интерфейс, медленный старт приложения. Рендеры — то такое, можно списать на издержки технологии, но вот что делать с перформансом, когда у тебя простенький список лагает на среднем телефоне двухлетней давности?
Основная проблема xf — медленный интерфейс, медленный старт приложения. Рендеры — то такое, можно списать на издержки технологии, но вот что делать с перформансом, когда у тебя простенький список лагает на среднем телефоне двухлетней давности?
Да, раньше списки были действительно проблемой, но с появлением CollectionView списки шустрые и лагов не замечал. (Не успел протестировать на действительно сложных списках, но простые или 1 колонкой работают плавно даже с быстрой прокруткой).
А вот с более медленным стартом приложения придется мириться, но тут у всего кроме натива будут проблемы. Xamarin Forms мы используем в основном для внутренних приложений, там где это будет не так критично. Например, внутренний документооборот, управление складами, курьерские приложения.
А вот с более медленным стартом приложения придется мириться, но тут у всего кроме натива будут проблемы. Xamarin Forms мы используем в основном для внутренних приложений, там где это будет не так критично. Например, внутренний документооборот, управление складами, курьерские приложения.
А я вот не увидел особо преимуществ перед Xamarin.
На стороне Xamarin огромное количество библиотек, как минимум. Найдите достойные аналоги для того же Autofac, Automapper.
При использовании Native подхода, мы можем оптимизировать рендеринг по-максимуму, не теряя ни капли производительности в сравнении с Java или iOS, причем 100% знаем как это работает, с flutter такое не пройдет.
Изучая SDK Android и iOS мы будем это реально использовать в Xamarin приложениях, соответственно переход от Xamarin на swift, java, kotlin — не проблема, как и обратный подход.
Что плохо — это визуальное накидывание интерфейса на iOS, но мы его и не используем, в команде сториборды — это ад, мы создаем интерфейс программно.
Прототип на Xamarin Forms написать намного быстрее и проще, все-таки XAML — это мощь.
Производительность Xamarin Forms на списках, за что его много хейтили, стала намного лучше сейчас, когда добавили CollectionView и наши клиенты не замечают разницы c приложениями на iOS и Java.
Плюс идет развитие Blazor, значит и SPA приложения можно будет писать на C#. Blazor мы уже опробовали, есть проблемы с производительностью, но мы были вполне довольны используя его для админок.
На стороне Xamarin огромное количество библиотек, как минимум. Найдите достойные аналоги для того же Autofac, Automapper.
При использовании Native подхода, мы можем оптимизировать рендеринг по-максимуму, не теряя ни капли производительности в сравнении с Java или iOS, причем 100% знаем как это работает, с flutter такое не пройдет.
Изучая SDK Android и iOS мы будем это реально использовать в Xamarin приложениях, соответственно переход от Xamarin на swift, java, kotlin — не проблема, как и обратный подход.
Что плохо — это визуальное накидывание интерфейса на iOS, но мы его и не используем, в команде сториборды — это ад, мы создаем интерфейс программно.
Прототип на Xamarin Forms написать намного быстрее и проще, все-таки XAML — это мощь.
Производительность Xamarin Forms на списках, за что его много хейтили, стала намного лучше сейчас, когда добавили CollectionView и наши клиенты не замечают разницы c приложениями на iOS и Java.
Плюс идет развитие Blazor, значит и SPA приложения можно будет писать на C#. Blazor мы уже опробовали, есть проблемы с производительностью, но мы были вполне довольны используя его для админок.
Но главная проблема Qt не в сложности написания нативного UI, главная проблема — C++.Qt на мобильных платформах — это QML, а там можно вообще всю логику писать на JS.
Ну и потом, C++ в Qt это по сути Си с классами. Вы, конечно, можете принести туда любую магию из новых стандартов, но это скорее противоречит духу библиотеки, чем требуется для работы. А фишки типа системы сигналов-слотов и обилие готовых подсистем на все случаи жизни ещё уменьшают сложность, даже для многопоточных приложений.
«Настоящая» главная проблема там в багах типа такого, вечных проблем с текстовыми полями, сложности в получении некоторых действительно нативных контролов и эффектов, например лупы из iOS. Но это относительно нативных приложений, у других кросс-платформенных фреймворков многое из этого тоже не решено.
Но главная проблема Qt не в сложности написания нативного UI, главная проблема — C++
Qt на мобильных платформах — это QML,
Ну если хочется кросплатформенности, то и на Desktop QML неплохо работает,
и во многом уже лучше Qt/Widgets к сожалению.
Так что я бы C++ назвал преимуществом, вряд ли ffi Dart также просто сделать
как интеграцию C++ и QML/JavsScript.
У Qt на мой взгляд другие проблемы:
- Намного слабее маркетинг
- Типизация, здесь Dart выигрывает по сравнению с QML, но вроде в Qt 6.x собираются поправить
- Направленность на "Embedded Linux", такое чувство что остальные платформы тестируются
намного меньше
Flutter, WPF/UWP/Avalonia, Qt (и, быть может, другие тулкиты, которы отрисовывают контроллы сами) имееют ряд преимуществ и недостатков. Преимущества расписаны, а к недостаткам я бы отнес тот факт, что им приходится мимикрировать под нативные. Разработчикам тулкитов требуется создавать разные наборы контроллов/темы под разные ОС (или, может, даже версии). И, видимо, это придется поддерживать в актуальном состоянии.
Также, замечу некую "философскую" проблему, которая, может, и не проблема для промышленного применения, но немного меня расстраивает. По-сути, выполняется двойная работа, разработчиками ОС и разработчиками тулкита по созданию контролов. А приложения раздуваются в размере засчет кода, аналог которому уже есть в ОС.
А можете поделиться ссылочкой на какое-нибудь приложение в сторе, которое хорошо сделано на flutter и совсем неотличимо от нативного UX?
Как я написал в статье, я периодически пользуюсь приложением от Realtor.com, и к моему удивлению я узнал что оно написано на Flutter. Оно наверное больше тяготит к Material Design но у меня и мысли не было, что это не нативное iOS приложение.
apps.apple.com/US/app/id336698281?mt=8
play.google.com/store/apps/details?id=com.move.realtor&hl=en_US
apps.apple.com/US/app/id336698281?mt=8
play.google.com/store/apps/details?id=com.move.realtor&hl=en_US
НЛО прилетело и опубликовало эту надпись здесь
Oops, извиняюсь, я опирался на эту ссылку — flutter.dev/showcase
НЛО прилетело и опубликовало эту надпись здесь
Надеюсь, кто-нибудь из realtor появится в комментариях)
было бы интересно почитать их ответ конечно))
Будет забавно если это какая-то внутренняя договорённость с Гуглами в обмен на какие-то вкусные коврижки.
К сожалению, но нет. Возможно, какие-то некритичные приложения и будут писать на флаттере. Но опыт, хамарина, киви, react native показал, что это верный путь получить ряд проблемных клиентов, которые опустят рейтинг твоих апок в маркете, и ты не сможешь достичь коммерческие цели.
react native даже рядом не стоит к Flutter) Может сейчас и не все идеально, но в базе зашита возможность развития и приведения к идеалу.
+ весь корпоративный софт на мой взгляд перейдет на Flutter)
+ весь корпоративный софт на мой взгляд перейдет на Flutter)
НЛО прилетело и опубликовало эту надпись здесь
Java 8 не сокращает затраты на разработку и time to market, не упрощает процессы и менеджмент. Я не говорю про старые проекты, я про начало новых, особенно в условиях кризиса и уменьшения финансирования. Flutter эффективнее от 2 до 6 раз с точки зрения затрат на несколько платформ.
НЛО прилетело и опубликовало эту надпись здесь
Dart публично разрабатывается с 2011. Dart как замена JS — провал, начиная с 2015, следуя вашей логике гугл давно должен был закрыть проект.
Гугл не вкладывался в Kotlin до момента пока JetBrains не довели его до стабильного состояния. Да и вообще Kotlin не продукт Гугла, это самостоятельный продукт. Просто «повезло», так сказать.
Flutter не разменная монета. Flutter доказал что как продукт имеет очень существенный преимущества перед конкурентами. И если статья не убеждает в этом, то есть не-Васи, непредвзятые бэкенд разработчики (Phoenix_free), которым зашло.
Гугл не вкладывался в Kotlin до момента пока JetBrains не довели его до стабильного состояния. Да и вообще Kotlin не продукт Гугла, это самостоятельный продукт. Просто «повезло», так сказать.
Flutter не разменная монета. Flutter доказал что как продукт имеет очень существенный преимущества перед конкурентами. И если статья не убеждает в этом, то есть не-Васи, непредвзятые бэкенд разработчики (Phoenix_free), которым зашло.
Flutter доказал что как продукт имеет очень существенный преимущества перед конкурентами.Сколько продуктов отсюда этого не доказали?
killedbygoogle.com
Выбросят вместе Fuchsia? «Fuchsia будет принципиально отличаться от Android. При этом ОС должна получить поддержку приложений Android. Ее интерфейс и ПО пишутся с применением Flutter SDK, позволяющего создавать кроссплатформенный код с возможностью запуска и на Android, и на iOS. Кроме того, в Fuchsia поддерживается язык Dart „
Первая часть чуть ли не способствовала «бросить все» и перейти на Flutter, вторая же часть статьи (про минусы Dart) быстро опустило на землю и фантазия захлопнулась… Все таки, как по мне, пока Avalonia на первом месте для проб и ошибок. Там тоже Skia, да и по первому опыту нареканий пока нет.
Flutter просто замечательный фреймворк, но очень не хватает возможности построения UI в стиле Vue. Когда описание внешнего вида компонента идет отдельно от кода. Я слышал, что это сделано для повышения производительности, но мне кажется вряд ли там прям все так серьезно бы просело.
Когда описание внешнего вида компонента идет отдельно от кода.
Что именно вы имеете в виду? Описание внешнего вида компонента – это в любом случае код. Он может быть написан на языке разметки, типа HTML/XML, а может на том же языке, что и остальной код приложения (и, как по мне, это гораздо удобнее и гибче).
А отделять бизнес-логику от UI – это всегда хорошая практика. И Flutter никак в этом не мешает.
Как и в любом другом фреймворке, здесь тоже не все так радужно. На моем Android 7.0 некоторые приложения, скачанные из Google Play нещадно тормозят. Это касается не всего приложения в целом, а отдельных его элементов, что еще страннее:
Есть такой грех за Flutter. Фреймворк не прощает, или прощает меньше, если вы пихаете все подряд в UI тред, например. Любая операция не должна превышать 16 миллисекунд. Работа со списками тоже имеет свои особенности, как и везде. Но если знать некоторые основы, с производительностью не будет проблем. Сейчас я работаю над приложением, в котором просто уйма анимация и списки виджетов с более 500 елементов в нем. Пока критичных проблем с производительность нет.
В том-то и дело, что 500 + элементов в списке работают без тормозов как, например, в Kivy или ReactNative, а простой шейдер типа FadeTransition экранного менеджера в любом приложении Flutter безбожно тормозит! И ладно… И пусть… Пусть есть какие-то проблемы, которых в любом фреймворке с головой… Но я не понимаю, почему тогда Flutter позиционируют как самый быстрый, самый крутой, который рендерит анимации как покурить и в таком духе… Объясните…
Какое-то приложение, скачанное с Google Play тормозит… эка невидаль. Какая разница, на чем оно написано, без исходников "объяснить" почему кто-то написал тормозное приложение – ну так себе просьба.
А я вас помню – вы как-то обещали в следующей статье показать, какой Flutter тормоз. Будет статья с кодом?
P.S. мультиаккаунты же вроде были запрещены на хабре?
Вам этого мало? Любое приложение Flutter нещадно тормозит при использовании списков и анимации типа Transition в менеджере экранов! Это касается и официальных приложений и не официальных. Также (не хотел снова поднимать этот вопрос) существует только пара-тройка виджетов типа «Cupertino» для iOS во Flutter. Почему-то это гордо называется «Поддержка iOS/Кроссплатфора». Почему замалчивают тот факт, что поддержки iOS виджетов во Flutter просто не существует? Расскажите это человеку, который оставил здесь комментарий на тему, как отклонили его приложение в Apple за не соответствие UI!
Не думал, что когда-нибудь придется объяснять такие вещи разработчику, но:
∃ ≠ ∀Также (не хотел снова поднимать этот вопрос) существует только пара-тройка виджетов типа «Cupertino» для iOS во Flutter.
Вы хотели сказать пара десятков?
Почему замалчивают тот факт, что поддержки iOS виджетов во Flutter просто не существует?
Да вроде английским по белому написано, как работает система виджетов.
Расскажите это человеку, который оставил здесь комментарий на тему, как отклонили его приложение в Apple за не соответствие UI!
А где он писал, что его приложение отклонили? Есть какие-то пруфы? Зато есть вот такая официальная информация.
Ну и мой вопрос про статью вы проигнорировали. Ок. А, я так понял, что скрин какого-то приложения из Google Play – это и есть доказательство тормознутости.
Вы хотели сказать пара десятков?
Если быть точным — 11. А если отбросить элементы «Переключатель», который ничем не отличается от того же на Android, «Navigation bar», который на самом деле просто обычный список (не понятно, зачем его включили в раздел Cupertino), «Кнопки» (две), которые оказываются на самом деле просто RaisedButton и FlatButton из Android, «Activity indicator», который просто обычный спиннер, страшнючие текстовые поля (два), которые нормальный человек никогда не будет использовать в своем приложении, «Pull to refresh», который идентичен элементу в Android (опять же, не понятно, зачем его включали в раздел Cupertino), — то можете сами посчитать, сколько там виджетов для iOS. Я написал то, что увидел в официальном демо приложении от 2020 года.
если вы про меня — то у меня отклонили приложение для macOS =). Flutter прекрасен. есть соотношение затраты-качество, у Flutter оно прекрасное, никто не говорит что тормозов никогда не будет, но их меньше чем по многих других решениях и обычно можно сделать хорошо. Мне виджетов хватает. С дизайном мобилок проблем нет.
Мне Flutter тоже зашел, но что касается производительности, я взял стандартное демо приложение с каунтером, добавил туда Drawer с картинкой в шапке и когда пытаюсь его открыть через кнопку в аппбаре, то когда он выезжает первый раз он заметно лагает.
С исходниками, я бы подсказал где собака зарыта
Стандартная аппликуха, которая делается при create myapp плюс в ней Drawer виджет с ListView, у которого в шапке картинка (через BoxDecoration и DecorationImage виджеты) и пару Row(children:[Text("lala")]. Т.е. косячить там негде, все сделано, как описано в доках.
Там, возможно, в кишках нет прелоада ресурсов и он картинку с диска читает и декодит в момент первого открытия drawer-а, я хз. Лагает только при первом открытии, дальше все ок.
github.com/g0rdan/drawer_perf_test
Результат (iPhone XR):
Причем картинка 3.8 мб, специально
flutter run --releaseРезультат (iPhone XR):
Причем картинка 3.8 мб, специально
Скажите пожалуйста, на сколько перспективна разработка с использованием Flutter для UI и Kotlin для всего остального? Год назад была одна статья на эту тему, с тех пор особо материалов не видел. Имеет ли вообще эта связка смысл.
Смысл есть только если часть вашего приложения имеет, допустим, сложный UI с анимацией, и вам проще это реализовать на Flutter и интегрировать это на 2 платформы, чем пытаться сделать это нативно 2 раза. Но это довольно редкий кейс, где у вас/в компании уже есть нативные приложения, есть желание/опыт работы с Flutter и т.д.
Осталось только пофиксать 5000+ issues (на GitHub) и можно побеждать )))
А пока… побеждает React Native )
А пока… побеждает React Native )
Количество issues, как и количество stars (где Flutter обошел React.Native) ни о чем не говорят. Потребности бизнеса говорят. Я вижу как бизнес, по крайней мере в Штатах, очень заинтересован во Flutter и часто выбирает Flutter вместо React.Native/Xamarin/etc. Бизнес хочет сэкономить и при этом не наступать на «грабли» кроссплатфоменной мобильной разработки.
Вы сейчас о каком бизнесе говорите? Стартапы, мелкие предприятия да, но не крупные. Для крупных важна стабильность, а не хайповость
Согласен, где стоимость разработки дело десятое — нативная разработка всегда будет в приоритете. Хотя это не отменяет проблему вендор-лока, уменьшение сложности продукта за счет единой кодовой базы и т.п.
Плюс, надо отметить, что в Штатах все-таки бизнес в срезе это малые и средние предприятия, в отличии от России, поэтому стоимость разработки важна.
Плюс, надо отметить, что в Штатах все-таки бизнес в срезе это малые и средние предприятия, в отличии от России, поэтому стоимость разработки важна.
Flutter уж точно стабильнее React Native (знаю по личному опыту), плюс у него гораздо «взрослее» инфраструктура.
А по поводу того, кто выбирает — посмотрите здесь, есть ли там достаточно крупный бизнес?
А по поводу того, кто выбирает — посмотрите здесь, есть ли там достаточно крупный бизнес?
В чём сегодня измеряется стабильность? Не прикапываюсь, просто интересно.
Я измерял в количестве багов фреймворка, с которыми встретился, за единицу времени.
Мне кажется, что это не особо показательный критерий. Баги бывают очень разные. Один баг может стоить десять других.
Например, количество мелких багов скорее будут отражать популярность, а не стабильность.
Например, количество мелких багов скорее будут отражать популярность, а не стабильность.
Речь шла о багах, с которыми я лично сталкивался при работе. Популярность тут не причём.
Я согласен, одного моего мнения недостаточно для статистики, однако есть стойкое ощущение, что это именно так — флаттер стабильнее реакт нейтив.
Несогласным предлагаю попробовать оба фреймворка лично — возможно, вам повезёт больше.
Если же говорить об инфраструктуре — качество плагинов для IDE, отладчика и т.д., то тут даже опираться на ощущения не надо — у флаттера они объективно лучше.
Я согласен, одного моего мнения недостаточно для статистики, однако есть стойкое ощущение, что это именно так — флаттер стабильнее реакт нейтив.
Несогласным предлагаю попробовать оба фреймворка лично — возможно, вам повезёт больше.
Если же говорить об инфраструктуре — качество плагинов для IDE, отладчика и т.д., то тут даже опираться на ощущения не надо — у флаттера они объективно лучше.
Я измерял в количестве багов фреймворка, с которыми встретился, за единицу времени
Это как в англоязычном высказывании — «plural of anecdote is not data». Измерять стабильность фреймворка только по себе — это совсем неправильно.
Наверное стоит прояснить — я не проводил исследования качества этих двух фреймворков, не было такой цели.
Однако я занимался разработкой мобильных приложений с использованием обоих фреймворков достаточно длительное время и за это время у меня сложилось чёткое ощущение, что флаттер стабильнее, разрабатывать с ним удобнее, а результат, в среднем, получается лучше.
Я могу долго (и нудно) рассказывать, почему это так, но делать этого не буду, потому что личный опыт гораздо важнее — попробуйте их сами и сделайте выводы.
Однако я занимался разработкой мобильных приложений с использованием обоих фреймворков достаточно длительное время и за это время у меня сложилось чёткое ощущение, что флаттер стабильнее, разрабатывать с ним удобнее, а результат, в среднем, получается лучше.
Я могу долго (и нудно) рассказывать, почему это так, но делать этого не буду, потому что личный опыт гораздо важнее — попробуйте их сами и сделайте выводы.
Все этого хотят но это не говорит о том, что технология готова для продакшна. Flutter сейчас — очень сырой продукт. В теории все классно, на практике — постоянно проблемы.
Иногда Apple не пропускает Flutter приложения в стор — пишут что приложение не использует нативные элементы управления.
Иногда Apple не пропускает Flutter приложения в стор — пишут что приложение не использует нативные элементы управления.
Иногда Apple не пропускает Flutter приложения в стор — пишут что приложение не использует нативные элементы управления.Это довольно голословно. Хотелось бы увидеть пруфы.
Flutter сейчас — очень сырой продукт. В теории все классно, на практике — постоянно проблемы.Опять же, хотелось бы больше специфики. В моей практике все с точностью да наоборот.
Смотря что считать "готовым для продакшна". У нас приложение уже полгода в продакшне, Apple ни разу не отклонила по этой причине.
Очень громкое название.
Flutter побеждает ровно до тех пор, пока не требуется сделать что-то, что использует что-то более сложное, чем список товаров в приложении, подтянутый с API. Не говоря уже о том, насколько сильно Flutter отличается от нативных приложений в плане look-and-feel. За Андроид говорить не берусь, использую телефон на Android'е только как тестовое устройство, но на iOS Flutter ощущается, будто кто-то очень и очень удачно замаскировал WebView под нативное приложение, и это очень неприятно. Но буду честен, я видел множество нативных приложений, от которых у меня были похожие ощущения, и над парой из них мне даже удалось поработать.
Не говоря уже о том, что у всех подобных кроссплатформенных библиотек всегда есть три фундаментальные проблемы:
1. Они всегда играют в догонялки с платформой, которую они пытаются абстрагировать
2. Они добавляют еще один весьма крупный слой, на котором может пойти что-то не так.
3. Ограниченный выбор библиотек — некоторые находятся на очень ранней стадии развития, некоторые просто отсутствуют в силу особенностей платформы, некоторые приходится адаптировать самому, прописывая платформоспецифичный код для каждой из них (уменьшая выгоду по времени от кроссплатформенности и добавляя еще один слой, на котором может что-то пойти не так)
Да, какому-то бизнесу Flutter подходит идеально — у них нет нужды строить хорошее приложение, и «подешевле-побыстрее» является основным критерием. Но называть бы это победой я не стал.
Flutter побеждает ровно до тех пор, пока не требуется сделать что-то, что использует что-то более сложное, чем список товаров в приложении, подтянутый с API. Не говоря уже о том, насколько сильно Flutter отличается от нативных приложений в плане look-and-feel. За Андроид говорить не берусь, использую телефон на Android'е только как тестовое устройство, но на iOS Flutter ощущается, будто кто-то очень и очень удачно замаскировал WebView под нативное приложение, и это очень неприятно. Но буду честен, я видел множество нативных приложений, от которых у меня были похожие ощущения, и над парой из них мне даже удалось поработать.
Не говоря уже о том, что у всех подобных кроссплатформенных библиотек всегда есть три фундаментальные проблемы:
1. Они всегда играют в догонялки с платформой, которую они пытаются абстрагировать
2. Они добавляют еще один весьма крупный слой, на котором может пойти что-то не так.
3. Ограниченный выбор библиотек — некоторые находятся на очень ранней стадии развития, некоторые просто отсутствуют в силу особенностей платформы, некоторые приходится адаптировать самому, прописывая платформоспецифичный код для каждой из них (уменьшая выгоду по времени от кроссплатформенности и добавляя еще один слой, на котором может что-то пойти не так)
Да, какому-то бизнесу Flutter подходит идеально — у них нет нужды строить хорошее приложение, и «подешевле-побыстрее» является основным критерием. Но называть бы это победой я не стал.
Но буду честен, я видел множество нативных приложений, от которых у меня были похожие ощущения, и над парой из них мне даже удалось поработать.
Т.е. это не проблема флаттера.
Они добавляют еще один весьма крупный слой, на котором может пойти что-то не так.
Один добавляют, другой могут и убрать. Например, учитывая, что Flutter, грубо говоря, берет от системы только канвас и рисует весь интерфейс на нем, приложение будет одинаково выглядеть и вести себя и на 10, и на 5 андроиде. И посколько UI слой от системы не зависит, как только новый компонент добавляется во Flutter, он становится доступным на всех версиях системы автоматически.
Вообще, имхо, отделить UI слой от OS – это здравая идея.
некоторые приходится адаптировать самому, прописывая платформоспецифичный код для каждой из них
Ну так этот код все равно бы пришлось писать.
Да, какому-то бизнесу Flutter подходит идеально — у них нет нужды строить хорошее приложение, и «подешевле-побыстрее» является основным критерием.
Нативное != хорошее, подешевле-побыстрее != хуже.
Они всегда играют в догонялки с платформой, которую они пытаются абстрагировать
Да, здесь согласен. Это надо учитывать и решать, насколько это критично. Потому что может оказаться, что этот супер-новый компонент нативно доступен только в условном Андроиде 31, до которого в ближайшие пару лет обновятся только 5% ваших пользователей, и без костылей на предыдущих версиях его все равно не сделать.
Т.е. это не проблема флаттера.
Да нет, это все еще проблема флаттера. Чтобы нативное приложение выглядело ненативно и ощущалось так же, разработчикам приходится стараться, чтобы сделать плохо (в основном с подачи менеджеров и дизайнеров, которые не понимают/не хотят понимать разницы между платформами и не хотят читать гайдлайны по UI для этих платформ). В случае с флаттером же приходится стараться, чтобы оно выглядело и ощущалось как нативное.
Например, учитывая, что Flutter, грубо говоря, берет от системы только канвас и рисует весь интерфейс на нем, приложение будет одинаково выглядеть и вести себя и на 10, и на 5 андроиде.
С этим прекрасно справляется AndroidX. В случае же с iOS, напротив, нежелательно, чтобы системные компоненты на разных версиях iOS — как минимум выглядит неопрятно, как максимум — запутывает пользователя. Так что в данном случае Флаттер вряд ли «может и убрать».
Нативное != хорошее, подешевле-побыстрее != хуже.
Абсолютно верно! В теории это не так. На практике же зачастую именно так и выходит. И, опять же, на хорошо сделанное ненативное приложение может быть потрачено намного больше человекочасов, чем могло бы быть потрачено на две платформы просто потому, что помимо проблем платформы приходилось решать еще и проблемы кроссплатформенного фреймворка.
Ну так этот код все равно бы пришлось писать.
Конечно. Вот только к этому коду еще и плагин писать, и этот код можно было бы писать без оглядки на:
а) вторую платформу
б) объединяющего их интерфейса/плагина
Потому что может оказаться, что этот супер-новый компонент нативно доступен только в условном Андроиде 31, до которого в ближайшие пару лет обновятся только 5% ваших пользователей, и без костылей на предыдущих версиях его все равно не сделать.
Я немного не про то. Скажем, в новой версии iOS поменяли то, как выглядит диалоговое окно — например, теперь оно стало шириной с весь экран, и кнопка, означающая «разрушительное» действие всегда будет помещена системой в самый конец списка кнопок. В предыдущей версии, например, было наоборот. Если вдруг разработчики флаттера сделали самописный диалог, а не просто вызов UIAlertController, я получу неконсистентное поведение — во всей системе «разрушительная кнопка» внизу, а во флаттере до обновления она все еще вверху. Чтобы это исправить, мне придется обновлять версию флаттера, и заново выпускать новую версию. А с этим обновлением я получу корректное поведение для пользователей более новой системы, но некорректное — для пользователей более старой. Не говоря уже о том, что обновление версии флаттера может нести в себе множество других сюрпризов — например, сломается другая критическая часть приложения.
В случае с флаттером же приходится стараться, чтобы оно выглядело и ощущалось как нативное.
Я бы так не сказал. Т.е. он, конечно, подталкивает к тому, чтобы использовать везде Material Design, но база Cupertino компонентов вполне себе неплохая, и можно сделать iOS версию только с ними, и будет смотреться вполне себе нативно без всяких дополнительных усилий со стороны разработчика.
С этим прекрасно справляется AndroidX
Ну я бы не сказал, что прекрасно. В плане Material Design – может быть, в плане сильно кастомного UI – помощи не так уж много. Да что там говорить, за все эти годы поддержку нормальных теней в Андроид так и не завезли.
И, опять же, на хорошо сделанное ненативное приложение может быть потрачено намного больше человекочасов, чем могло бы быть потрачено на две платформы просто потому, что помимо проблем платформы приходилось решать еще и проблемы кроссплатформенного фреймворка.
А может быть и не потрачено? У нас приложение на флаттере уже полгода в production. Ничего сложного, обычное бизнес-приложение, но:
- Качество при переходе от 2 нативных к одному кросс-платформенному не пострадало (в большинстве случаев улучшилось).
- Времени мы тратим гораздо меньше.
Конечно. Вот только к этому коду еще и плагин писать, и этот код можно было бы писать без оглядки на:
а) вторую платформу
б) объединяющего их интерфейса/плагина
Так если вам на второй платформе эта функциональность не нужна, и не пишите. Плагин – да, какой-то оверхед принесет. Но при хорошей модульной архитектуре оверхед не будет большим. Понятно, что если у вас 90% приложения завязано на специфичные для платформы вещи, то от флаттера толку, скорее всего, не будет.
Скажем, в новой версии iOS поменяли то, как выглядит диалоговое окно
It depends. В некоторых случаях возможность контролировать, как у меня выглядит интерфейс – это плюс.
Я бы так не сказал. Т.е. он, конечно, подталкивает к тому, чтобы использовать везде Material Design,
Я бы на месте эппл разворачивал МП с material из AppStore.
Что тут можно сказать, хорошо, что вы не на месте эппл.
Что не отменяет того факта, что Material Design на iPhone выглядит уродливо и абсолютно не к месту.
На вкус и цвет фломастеры разные. Я не фанат MD, но и отвращения он у меня не вызывает.
Есть вкус, а есть Human Interface Guidelines.
Среди которых есть следующее:
Material Design на iOS это нарушает.
Среди которых есть следующее:
Consistency
A consistent app implements familiar standards and paradigms by using system-provided interface elements, well-known icons, standard text styles, and uniform terminology. The app incorporates features and behaviors in ways people expect.
Material Design на iOS это нарушает.
"keep the following principles in mind" != "strictly follow principles"
Да, MD не использует "system-provided interface elements", но много вы знаете приложений, которые используют только "system-provided interface elements"? Блокировать их?
Что делать с нативным будильником? Почему он использует какие-то нестандартные кнопки вместо system-provided interface elements?
При этом, заметьте, флаттер предоставляет возможность использовать элементы, соответствующие HIG.
Так что, "не к месту" – отчасти, да, "уродливо" – вкусовщина.
В статье много раз упомянута Dart VM в смысле, что она имеет какое то оношение к тому приложению, что исполняется у пользователя.
Но Flutter работает иначе.
Виртуальная машина используется в Flutter только для отладки.
Благодаря ей вы можете менять код на лету и видеть результат.
При окончательной компиляции всё компилируется в native. И никакой виртуальной машины Dart и её тормозов нет у конечного пользователя.
Но Flutter работает иначе.
Виртуальная машина используется в Flutter только для отладки.
Благодаря ей вы можете менять код на лету и видеть результат.
При окончательной компиляции всё компилируется в native. И никакой виртуальной машины Dart и её тормозов нет у конечного пользователя.
Dart VM is a virtual machine in a sense that it provides an execution environment for a high-level programming language
Dart code can be compiled into machine code using Dart VM AOT pipeline and then executed within a stripped version of the Dart VM, called precompiled runtime
Именно так. Вообще есть замечательная картинка:
Которая показывает что подразумевают, когда говорят о Dart VM. При этом, как написано выше, даже с AOT все равно загружается stripped precompiled runtime, в котором все равно есть GC.
Заголовок спойлера
Которая показывает что подразумевают, когда говорят о Dart VM. При этом, как написано выше, даже с AOT все равно загружается stripped precompiled runtime, в котором все равно есть GC.
Aot не отменяет рантайм. Вся разница только в прекомпайле кода приложения. А JIT не значит медленно. Есть ряд оптимизаций, которые можно производить только в рантайме. Jitовая джава быстрее аот'а. Но это лечится профайлами
как и все GC, GC в Dart VM имеет поколения
Не все. Только, внезапно, generational gc имеют поколения.
Go, например, не имеет поколений в своём GC.
Android Runtime, хоть и generational, но не выделяет новые объекты в отдельной области памяти, а просто хранит их на стеке.
В том-то и дело, что 500 + элементов в списке работают без тормозов как, например, в Kivy или ReactNative, а простой шейдер типа FadeTransition экранного менеджера в любом приложении Flutter безбожно тормозит! И ладно… И пусть… Пусть есть какие-то проблемы, которых в любом фреймворке с головой… Но я не понимаю, почему тогда Flutter позиционируют как самый быстрый, самый крутой, который рендерит анимации, как покурить, и в таком духе, но который не справляется с самой простой анимацией списка в пять элементов, гифку которой я привел в предыдущем сообщении, и не справляется с обычной анимацией перехода между экранами типа FadeTransition? Объясните людям…
А про веб то почему никто не спрашивает? Как там веб поживает? Можно и для сайтика и для аппы примерно одну кодовую базу для интерфейса держать?
Рано. Для веба пока – только поиграться. Но прогресс есть.
Я не знаю каких-либо ограничений по виджетам, т.е. весь сет виджетов должен работать и на мобилках и вебе, но производительность в вебе далека от идеала. Хотя в этом направлении ведуться работы
Интерфейс делать сложно. А вот использовать Dart-овую общую прослойку для state managment/api managment для Web и Mobile — вполне реально, мы так делаем. Есть и плюсы и минусы, конечно.
Зашёл в Купертино библиотеку элементов и мгновенны вижу разницу между нативными элементами и вариантами от Флаттер. Даже не помня некоторые элементы, сразу видны огрехи: межстрочные интервалы, отступы, цвета, паддинги, маржины, толщина шрифта, его отображение. Да, это всего-то px туда, px сюда, но из этих мелочей складывается общий привычный платформе UX. Пока ниразу не видел приложений, про которые я бы сказал «Ну все, Нейтив больше не нужен».
Количество вакансий на xx:
flutter разработчик — 58
react native разработчик — 303
android разработчик — 1 621
ios разработчик — 1 488
Если и побеждает, то не на территориии РФ.
flutter разработчик — 58
react native разработчик — 303
android разработчик — 1 621
ios разработчик — 1 488
Если и побеждает, то не на территориии РФ.
Так вопрос не в чистом количество вакансий а в приросте, я например тоже заметил что количество растет очень быстро
Количество вакансий на xx:
flutter разработчик — 58
react native разработчик — 303
android разработчик — 1 621
ios разработчик — 1 488
Если и побеждает, то не на территориии РФ.
Знать именно конкретную технологию — это важно разве что в самом-пресамом начале карьеры. Ибо желающих возиться с тобой и тянуть твое развитие очень мало. Нужно чтобы ты сразу пришёл и смог вписаться работу.
А вот потом, когда тебе доверяют полностью самостоятельную разработку или, тем паче, руководство разработкой — всё меняется.
Ну я вот уже лет 20 как делаю на тех технологиях что лично мне удобнее для работы.
По сути, заказчика интересует конечный продукт, а не способ реализации.
И если Flutter мне позволяет повысить производительность (особенно при кросс-платформенной разработке; да и при разработке на одну платформу), то цифры вакансий значения не имеют.
Что до нанимаемых мною людей… Мне всегда важно было какой ты программист, а не насколько ты хорошо знаком с конкретной платформой. Разработка она, по сути, одинакова в смежных технологиях. Хороший разработчик осваивает азы Dart и Flutter за неделю после чего производоительность только растет. И уже ко второму месяцу он уже продуктивен неотличимо от того, кто работает год на этой технологии. Если это хороший разработчик, конечно.
Впрочем, и нулевых людей «со школы и универа» тоже брал и достаточно быстро подтягивал до минимально приемлимого уровня, чтобы уже они начинали окупаться.
Конечно, если проект ограничен жесткими сроками этого делать не получится. Но если имеются постоянно-повседневные работы, если у предприятия достаточный стабильный объем заказов, то предприятие нисколько не напрягает взять разработчика без знания стека.
Жесткие требования к стеку важны при следующих условиях: или очень мелкое предприятие или очень ответственный или очень срочный заказ или откровенно бодишопная соковыжималка или ты сразу хочешь много денег и не согласен получать как ученик первый месяц.
Ну и, разумеется, в самом начале карьеры выбора у тебя меньше.
Однако, повторюсь, большой опыт разработки на других стеках я ставлю выше, чем маленький опыт, но на нужной мне платформе. В применении к Flutter'у: конкретно Dart+Flutter — это вовсе никакой не Хаскель — и освоить Flutter человеку с опытом совсем не сложно.
Интересно выяснить ответ на такой вопрос — это правда, что для сборки приложения Flutter нужно устройство с MacOs и сам Iphone?
Разрабатывать можно на любом – используя эмулятор Андроида. Для сборки под iOS – да, в любом случае нужен mac (iPhone не особо нужен, можно обойтись симулятором в большинстве случаев), хотя можно воспользоваться облачным решением для сборки, например, https://codemagic.io/
В общем, с маком будет удобнее, но в теории можно обойтись и без него.
Если вы хотите разрабатывать для iOS, то на любом инструменте вам понадобится Mac для сборки (либо облачные сервисы для сборки), iPhone не обязателен. Хотя те же пуши без iPhone не оттестишь, на симулятор они не приходят. Если вы хотите разрабатывать под iOS как-то несерьезно не иметь Mac и iPhone.
В одном из последних обновлений симулятора завезли что-то вроде поддержки пушей :) Правда, не полноценных: можно перетащить на симулятор специальным образом составленный JSON-файлик, и он преобразуется в пуш, который будет проброшен вашему приложению, как будто он пришёл с сервера. Но, конечно, к сожалению, подписаться на настоящие пуши и проверить, что всё работает end-to-end без устройства не получится.
Бредовая философия от которой выигрывает только одно, и то в краткосрочной перспективе — кошелёк заказчика, а дальше страдают все — пользователи, заказчик, разработчики приложений.
Посмотрите про флаттер недавний пост от медузы и почитайте комменты.
Посмотрите про флаттер недавний пост от медузы и почитайте комменты.
Ребят, вопрос к Xamarin-щикам или Flutter и т.д. А как у вас обстоит дело в крашлитикой и другими аналогичными крашами? Лично у меня волосы на дыбы встают после китайских мутантов. А вы как фиксаете, получается?
В простом сравнении выглядит, что flutter заменил webView на canvas для рендера элементов, которые будут лишь мимикрировать под нативные. Как по мне, такой подход не сильно отличается от рендера элементов под webView, который в статье критикуется за ненативность, разница лишь в производительности. Недавно на хабре была статья о приложении Meduza написанном на flutter. Так вот в нём, на моём LG Q6, скроллинг очень сильно лагает и сама прокрутка выглядит ненативно, несмотря на заверения команды flutter о нативности и производительности.
говори что он побеждает, чтобы другие поверили.
Недавно отписался от какой то группы в телеграме, которая приводила типа статистику, поднялись продажи на такие то товары, типа на одежду. Потом читаю новости продажи по одежде просели максимально сильно. В общем тут кто-то врет, я подумал что все таки маркетологи из этого телеграм канала, ну они писали типа на wildberries выросли продажи на 600% одежды и т.п. в общем тут из той же серии. Почему Flatter побеждает. Ну вот не знаю. Тоже к нему присматриваюсь, присматриваюсь. Но вот схожесть с React меня почему то от него отталкивает. Простите меня любители react. Я просто сторонник Ractive,Vue, и вот это вот все.
Так вот, тут недавно была статья про медузу, что на флаттер написана, ну я скачал, упс, оказывается скачал старое приложение нативное, якобы. Но нативное там скорее всего только WebView остальное уже HTML, потому что тормозит оно ужасно ( ну там сверху значит, у нас вышло новое приложение, нажми чтобы скачать, ну я скачал, да, поновее. И тем самым я смог сравнить то и другое. Первое жутчайше тормозит при скролле вверх вниз. Второе на Flatter при скролле как то странно скроллится, не естественно и тоже подергиваясь, но как то более линейно чем «нативное». анимация открыти окон вроде ничего, нормально все отрабатывала, шрифты красиво, в целом все хорошо, но вот скролл какой то странный все же. Может быть конечно у них только так, но я когда первые Hello world'ы собирал, тоже не особо скоростью радовало, особенно вначале.
Недавно отписался от какой то группы в телеграме, которая приводила типа статистику, поднялись продажи на такие то товары, типа на одежду. Потом читаю новости продажи по одежде просели максимально сильно. В общем тут кто-то врет, я подумал что все таки маркетологи из этого телеграм канала, ну они писали типа на wildberries выросли продажи на 600% одежды и т.п. в общем тут из той же серии. Почему Flatter побеждает. Ну вот не знаю. Тоже к нему присматриваюсь, присматриваюсь. Но вот схожесть с React меня почему то от него отталкивает. Простите меня любители react. Я просто сторонник Ractive,Vue, и вот это вот все.
Так вот, тут недавно была статья про медузу, что на флаттер написана, ну я скачал, упс, оказывается скачал старое приложение нативное, якобы. Но нативное там скорее всего только WebView остальное уже HTML, потому что тормозит оно ужасно ( ну там сверху значит, у нас вышло новое приложение, нажми чтобы скачать, ну я скачал, да, поновее. И тем самым я смог сравнить то и другое. Первое жутчайше тормозит при скролле вверх вниз. Второе на Flatter при скролле как то странно скроллится, не естественно и тоже подергиваясь, но как то более линейно чем «нативное». анимация открыти окон вроде ничего, нормально все отрабатывала, шрифты красиво, в целом все хорошо, но вот скролл какой то странный все же. Может быть конечно у них только так, но я когда первые Hello world'ы собирал, тоже не особо скоростью радовало, особенно вначале.
Еще во Flutter какой-то ад с темами. К примеру, для слайдера можно в общей теме переопределить sliderTheme, а когда это делаешь для buttonTheme, то часть работает (height), а часть нет (цвета, отступы). При этом документация на голубом глазу говорит, что можно переопределять что хочешь. И только в issue tracker-е расскажут, что есть такая давняя проблема, разрабы о ней знают, обещают большой рефакторинг, который исправит ситуацию, но в документации почему-то об этом молчат.
А чем плох кроме «тормозов» и ненативности PhoneGap? У меня два приложения на PhoneGap. Оба не тормозят вообще, одно из них карта с кэшом на Leaflet с наложенными poi и векторным слоем. Скачиваний не много: у одного чуть больше 10.000, у другого 5.000, на ненативность никто не жаловался. Всё время читаю, что надо срочно убегать с PhoneGap, но мне бы понять зачем…
Попробуйте отобразить список из 500 элементов хотя бы, чтобы не было тормозов при скроллинге, а теперь 1000, несколько тысяч. А теперь множество горизонтальных списков на одном экране, так чтобы каждый из них переиспользовал элементы друг друга (как сделано в гугл плей). Да, вы можете применить ту же технологию, что и в нативе (переиспользование элементов списка, но я думаю это уже довольно сложная задача и не факт, что будет значительно лучше).
Пример с картами — это как раз та ниша, где phoneGap уместен.
Для каждого инструмента своя ниша. Для приложения где оптимизация не важна эта технология вполне подходит, но для серьезного проекта есть куда лучшие варианты (Натив, Xamarin, Flutter, React Native).
Извиняюсь, что пишу про тормоза, но просто это решающий момент, почему разработчикам все еще приходится писать нативно.
Пример с картами — это как раз та ниша, где phoneGap уместен.
Для каждого инструмента своя ниша. Для приложения где оптимизация не важна эта технология вполне подходит, но для серьезного проекта есть куда лучшие варианты (Натив, Xamarin, Flutter, React Native).
Извиняюсь, что пишу про тормоза, но просто это решающий момент, почему разработчикам все еще приходится писать нативно.
А во flutter работает нативное поведение платформы? Например мастер-паролей на ios при вводе логина-пароля?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Flutter побеждает?