Pull to refresh

Comments 44

Самая популярная (и хайповая) функция Flutter — это горячая перезагрузка с сохранением состояния.

Еще в 2015 году это сделал Kivy! Поскольку он написан на Python и использует его в качестве языка разработки, о компиляции приложения для его запуска на мобилке вообще речи не велось, так как Python запускается из исходников — внес правки в код, нажал "Run" — видишь результат.


Рекордные сроки

О каких рекордных сроках идет речь, если код на Flutter — это дремучие не структурированные трехэтажные конструкции кода, длиннющая лапша, в которой потом вообще никто не разберется даже тот, кто это написал.


Единственное в чем я увидел преимущество — скорость запуска приложения действительно поражает. И это все.

о компиляции приложения для его запуска на мобилке вообще речи не велось, так как Python запускается из исходников — внес правки в код, нажал "Run" — видишь результат

Как запуск из исходников связан с восстановлением состояния интерфейса?

Кстати, скорость запуска такая же как и с нативными проектами. Если, кончено, проект делают люди с прямыми руками и следят за своими машинами.
А вот и нет. Код во Flutter структурирован и логичен, а для того, чтобы не было проблем в распознавании код нужно писать не в одном файле)))
А вот и нет. Код во Flutter структурирован и логичен

Покажите код простого "структурированного" экрана с одним изображение и двумя кнопками...

Полностью согласен с предсказанием насчет этой платформы.
Гугл последнее время очень активно форсят Flutter, и есть за что.
Мне как после полу-года работы с React-Native, сперва Flutter показался многословным, но пописав ещё немного на нем, я понял, что описывать View на Flutter гораздо проще и приятнее чем в React-Native, а hot-relead с сохранением состояния просто ввел меня в экстаз.
Конечно же и есть свои минусы в виде нового языка и размера бандла.
Но я не считаю, их уж совсем критичными. Для такого отличного инструмента как Flutter, можно и выучить Dart. Когда к нему привыкнешь, уже не хочеться возвращаться к тому же Typescript и VanillaJS.
А Автору, спасибо за перевод!
а вы любите копировать свои коменты из статьи в статью? или так форсите за это вот?

ну и по делу, я как iOS разработчик использующий Swift и отказавшийся от Objective C не перейду на поделку от гугл, и причин очень много — от визуала до невозможности это все контролировать и оптимизировать как мне надо, с этой поделкой нет разговора о custom transitions для вью внутри контролеров таких как UITabBarCotroller UINavigationController UIViewController.
Нет возможности отрабатывать паралельно несколько gestures.
Так как это написано гуглом — значит забагованность и краши будут на ура и много.
Чтоб работать с такими вещами как MapsKit CoreData SpriteKit SceneKit, custom notification content, deep links это штуковина не годится совсем!
Как вы будите спользовать при больших UITableView UICollectionView асинхронную загрузку и префетчинг и отмену операции ( чтоб не сьедались фреймы) изображений например из инета?
Крос платворменость возможна и сейчас просто используя сайт для мобильных устройств.
Гугл просто хочет сильно снизить планку входа в appstore и запустить стаи веб манки кодеров, и через усаженных на свою технологию рулить разработчиками на чужой системе и влиять через них на apple inc, ну и конечно же как сильнее apple ограничивает гугул в сборе инфы тем сильнее гугул лезет на платформу в обход за этой датой.

UFO just landed and posted this here
Но кроссплатформ это миф который постоянно используют чтоб продвигать какой-то фреймворк, так как всегда будет, что нужно писать только под одну из систем, ну или ничего не использовать, что позволяет сделать система.
Ну вот из последнего ( такая открытая такая опенс сорц android os ) но в ней нереально сделать свой кастомный пуш нотификейшен, а в iOS без проблем.
Задача была сделать пуш о брошенной корзине и вывести все айтемы которые были в корзине в горизонтальном скролировании
Так вот в iOS это было сделано и быстро а вот в android пришлось клеить имеджи на бекенде и максимум 4 в один (как делает пинтерест).
и в iOS очень много таких штук которые делаются и быстро, а в android это анрил а значит в подобных флатеру анрил
UFO just landed and posted this here
Конечно это всегда разные приложения не только по количувству функционала но и по интерфейс идиомах и привычках пользователей.
На самом деле пользователь iOS не видит и не знает что и как на android и это так же и обратную сторону.
ну и чтоб писать круто для какойто из систем нужно от этого получать удовольствие, я получаю удовольствие от ios потому даже и не смотрю на android, но я вынимаю максимум из ios под мои задачи
И это круто когда два нативынх приложения под две платформы нативны и привычны для своих пользователей.
Ну и контроль разработчиком приложения и своя архитектура дает возможность быстрых добавлений функционала и держать краш фри 99.9% (swift)
ох уже этот яваскрипт мир)) так что учить в итоге? Dart или Typescript?)
хорошая статья, вроде как Dart особо не поддерживался Google, только сообществом, а теперь утверждается что Google поддерживает Flutter, хотя была новость что Google начала поддерживать Kotlin для разработки приложений для Android. Как-то все быстро развивается…
так что учить в итоге? Dart или Typescript?)
Kotlin.js! Шучу. Я C++ разработчик и недавно увлекся web'ом. Для себя выбрал Typescript. Dart рассматривал, но он совсем не понравился, намешали туда всего понемногу, а сами использовали TS в новом Angular'e.
UFO just landed and posted this here
Пункт про нативность порадовал. Как по мне, мобильное приложение не может нативным, если оно не использует интерфейс из ОС. А тут начинается какая-то подмена понятий, типа а давайте разберемся, что же такое нативность. Недавно была статейка про Electron, которая вызвала много споров, так вот Flutter — абсолютно то же самое.
Не совсем то же самое. В Electron и React Native существует дополнительная прослойка в виде Javascript движка, исполняющего код вашего приложения. Flutter же умеет компилировать код приложения непосредственно в машинный код процессора смартфона.
Я не про техническую реализацию, а про идею. И там и там кладется прибор на нативные контролы и интерфейс, и приведенная статья в основном об этом. Только в Electron использует вебовские контролы и инструментарий, а flutter свой самописный.
Это всё, конечно, хорошо. Но давайте смотреть реально на вещи.
Сразу скажу что я- Android-нативщик и мне тоже пришлось изучать Flutter.
7 mb для hello world release, на мой взгляд, многовато.
Модули для flutter сейчас- тихий ужас. Для сколь либо вменяемого функционала придется писать свои, что требует знаний iOS и Android в идеале двумя разными людьми, поскольку «универсальщик» не способен выдать качественного решения.
Полноценная работа с гуглокартами- забудьте. В готовых модулях нет ничего похожего.
ORM, OODB- забудьте. в Dart нет рефлексии, полноценных кодогенераторов тоже.
json-маппинг- забудьте. причина выше.
REST? пиши руками! нет аналогов ретрофиту.
В конце концов, у пользователей обеих платформ разный UX и ходить на iOS с material design нехорошо.
В итоге- утверждение, что сейчас можно делать на flutter быстро и дешево применимо, разве что, к штампованным приложениям-витринам. Для сколь либо серьезных проектов это утверждение смехотворно. Да, красиво. Но жирно, долго и неправильно.
Может быть когда нибудь (например с приходом фуксии) flutter обзаведется приличными инструментами, но сейчас этого нет.
> 7 mb для hello world release, на мой взгляд, многовато.
Как часто вы пишите приложения уровня hello world?
Если обычное приложение в итоге все равно занимает под 100 мегабайт, какая разница, что оно чуть больше?
В случае iOS вы, возможно, правы. Но я говорил об Android:
Сhrome Beta: 53mb
Adobe Photoshop Express: 61mb
Это из тяжелого. А если смотреть оптимизированные:
Клиент хабра: 12mb
Твиттер: 19mb
WhatsApp: 20mb
Telegram: 15mb
Даже 2gis на увесистом QT- 36mb
Потому 7mb, внезапно, становятся половиной\третью\четвертью от хорошего коммерческого приложения и такая цифра может быть критична. А с развитием flutter эта цифра будет только расти
У меня другие цифры: 2gis — 123мб, Хром — 80мб, Телеграм — 43мб, вк — 123мб.

Как вы смотрите размер?

Ибо с моими цифрами 7мб становятся десятой частью приложения, что уже совершенно не критично.

Скрин

Вы, наверно, смотрите через настройки. Там указывается размер с рабочим кэшем и данными. Речь шла об apk дистрибутиве. То есть ровно то, что скачивается с Google Play. Откройте страницы в GP этих приложений с устройства- там будет указан размер.
Посмотрите скрин в исходном комментарии — указан размер без данных и кэша.

В случае с 2гисом стоит рассматривать и саму карту, прибавив к 38мб еще сотню.
Простите, но считать размер 2gis вместе с картами- это как считать размер приложения «Фотографии» вместе с самими фотографиями.

При установке apk на устройство ART генерит всякие данные оптимизации(например, компиляция dex-байткода в платформозависимый odex). Потому после установки размер приложения значится больше- эти данные ОС считает частью приложения.

Но это не отменяет того, что с Google Play 2gis скачивается в размере 36мб на данный момент. Это же и размер файла .apk. А после установки размер приложения в настройках у меня значится 125MБ (apk + данные оптимизации).
Если обычное приложение в итоге все равно занимает под 100 мегабайт, какая разница, что оно чуть больше?

Помнится, на Kivy кричали, что его Hello World весит 7.5 Мб. и поэтому фу-фу-фу.

UFO just landed and posted this here
По поводу 7mb ответил выше. Даже в сравнении 2gis на qt цифра внушительная.

По поводу модулей- да, они появятся. Но речь шла о том, что можно разрабатывать под flutter быстро сегодня. Но нет достаточного количества дошедших до первой версии модулей для этого. И потом- многих инструментов просто не будет из-за текущих ограничений Dart и механизма сборки flutter. В общем бонусы по скорости сомнительны.

Официальный google maps в стадии Developers Preview версии 0.0.3. В здравом уме в продакшен такое не возьмут.

Да, можно разработать два лейаута для android и iOS, а из-за разных UX-парадигм еще и разную presentation и business-логику. Тогда на кой нужен flutter если 70 и больше процентов кода будут платформозависимы? Две команды нативщиков справятся с этим качественнее и быстрее

И это я не упомянул про то, что в Dart, в плане потокобезопасности (да и не только), гораздо проще выстрелить себе в ногу, чем в kotlin\java, что ведет к дополнительным отладкам и спящим багам. В нативе с этим куда проще
Это не очень дорогая цена кроссплатформенности и скорости разработки.
7 mb для hello world release, на мой взгляд, многовато.


В чем ужас — если не секрет?
Модули для flutter сейчас- тихий ужас. Для сколь либо вменяемого функционала придется писать свои, что требует знаний iOS и Android в идеале двумя разными людьми, поскольку «универсальщик» не способен выдать качественного решения.


Несомненно, в каждом приложении должны быть карты гугла.
Полноценная работа с гуглокартами- забудьте. В готовых модулях нет ничего похожего.


А это что?
ORM, OODB- забудьте. в Dart нет рефлексии, полноценных кодогенераторов тоже.

И это?
json-маппинг- забудьте. причина выше.


Конечно же для дарта нет http-клиентов, ога.
REST? пиши руками! нет аналогов ретрофиту.


Куча приложений гугла (да и не только) для айфона в материал-дизайне говорят об обратном. Да и вообще флаттер не диктует делать именно material-design.
В конце концов, у пользователей обеих платформ разный UX и ходить на iOS с material design нехорошо.


Зато на Java быстро, плюс на java одни приложения-не-витрины, да и говнокодеров нет, ага.
В итоге- утверждение, что сейчас можно делать на flutter быстро и дешево применимо, разве что, к штампованным приложениям-витринам. Для сколь либо серьезных проектов это утверждение смехотворно. Да, красиво. Но жирно, долго и неправильно.


В следующий раз, прежде чем вбрасывать, постарайтесь как-то подтвердить свои доводы банальным поиском в Google.
Это не очень дорогая цена кроссплатформенности и скорости разработки.
Я уже объяснял выше, почему там (по крайней мере сейчас) не может быть той скорости разработки, что у двух команд нативщиков.

В чем ужас — если не секрет?
Ужас в том, что крайне много востребованных модулей, не дошедших до версии 1.0. А так же большинство не предоставляют нужного функционала. Например, в модулях, которые работают с местоположением, все поголовно забывают о settings dialog (который крайне необходим для качественной работы местоположения). Тут можно долго продолжать, но соль в том, что модули либо не доработаны либо их возможностей не хватает для коммерческого применения.

Несомненно, в каждом приложении должны быть карты гугла.
Очень часто требуется. И сейчас, просто ради кластеризации, придется писать собственный модуль.

А это что? И это?
Напомню, что указанное Вами решение не релизное и нестабильно. И, насколько я понял, не совместимо с Flutter (посмотрите dartson). Вот что написано в доках:
Is there a GSON/Jackson/Moshi equivalent in Flutter?
The simple answer is no.
Such a library would require using runtime reflection, which is disabled in Flutter.


Конечно же для дарта нет http-клиентов, ога.
Не путайте http-клиенты и REST api-клиенты. Chopper, конечно, уже похож на retrofit, но сериализация и десериализация там предполагается ручная.

Куча приложений гугла (да и не только) для айфона в материал-дизайне говорят об обратном. Да и вообще флаттер не диктует делать именно material-design.
Да, но MD предлагается из коробки. Выходит, что писать только под MD или cocoa вредит UX, писать два варианта лейаутов- время и нет смысла, писать свой дизайн- разрабатывать UX и гайды\схемы что долго и дорого. То, что google на iOS с MD- так google сервисный гигант и может позволить себе консистентность. Сервисам по-меньше это вредит.

Зато на Java быстро, плюс на java одни приложения-не-витрины, да и говнокодеров нет, ага.
Относительно быстрее. Вас тормозит синтаксис- берите kotlin. Большинство известных коммерческих приложений- нативные. Копрокодеров везде хватает, но в Dart с его потокобезопасностью выстрелить себе в ногу проще.

В следующий раз, прежде чем вбрасывать
Простите, но скорее Вы не знаете инструмент, с которым работаете.

Я попробовал приложение под iOS. С использованием их cupertino компонентов. Они выглядят чуть чуть не так, как надо. Уже на этом этапе закрадывается сомнение об приложении. А уж когда дело доходит до переходов между экранами и другими transitions, то тут уж точно выбор не в пользу флаттера в сравнении с нативными компонентами. Во флаттере они либо другие, либо совсем отсутствуют. Переход между экранами использует другую кривую анимации, а во флаттере она как будто линейная. А вот эти мелочи, навроде менюшки, которая появляется снизу и предоставляет несколько пунктов на выбор, которую можно скрыть, стоит провести пальцем вниз? Во флаттере этот жест отсутствует. И как этим пользоваться?

Здесь эффект зловещей долины играет роль, имхо. Как будто iOS, но и не iOS в то же время.

Постоянно пытаться догнать интерфейс iOS можно, но какими усилиями? Лично для себя вынес, что флаттер очень хорош, если нужен «дизайнерский» интерфейс, который не будет реализовывать интерфейс той или иной платформы.
На Android под MD тоже складывается такое ощущение. Что поделать- свой рендер.

Но на самом деле это не критично. Посмотрите на huawei, meizu, xiaomi- их оболочки делают всё, чтобы пользователь не понимал чем пользуется. И прокатывает. Если большинству пользователей айфона дать huawei или meizu, предварительно заклеив задник- то те свято будут уверены что это- другая модель айфона. Большинство не видит разницы в упор.
Я вот попробовал Flutter чуть дальше hello word… Сделал приложение по уроку с GridView
Загрузить картинки и получить несколько столбцов с ними.
Понравилось вот что:
Одним движением руки меняется количество столбцов.
Меняется тема размер наполняемость рисунком контейнера
И еще больше понравилось… одним движением руки столбы превращаются в строки и я получаю «перевертыш» и горизонтальную прокрутку этих картинок.
(На java одним движением руки это не сделаешь)
Не понравилось.Хотел обернуть этот контейнер в GestureDetector чтоб он на нажатие на рисунок реагировал onTap И запутался в скобках. и довольно долго распутывался пока запустил.
На java одним движением руки это не сделаешь
Неправда Ваша. Сменить layout manager у recycler view- одна строчка кода. Ну может еще вызвать обновление списка- 2 строчки кода.
Дабы не быть голословным
я добавляю всего лишь
scrollDirection: Axis.horizontal,
И магия.
Приведите пример на java
LinearLayoutManager.setReverseLayout(true);//меняем направление
LinearLayoutManager.setStackFromEnd(true);//меняем начало компоновки (если надо точь в точь)

Да, две строчки, но и возможность менять край компоновки полезна. А можно и не менять и будет как начало переписки в старом вайбере. В любом случае- так же легко.
Прошу прощения, я Вас неправильно понял. Вы меняете не направление, а горизонтально\вертикально. Будет так:
LinearLayoutManager.setOrientation(LinearLayoutManager.HORIZONTAL)
Ну сильно спорить не буду… Тем более андроид разработка это всего лишь попутная разработка для большой ИС(Терминалы сбора данных-Инвентаризация, Торговый представитель-сбор заказов, мобильной место официанта и т.д) Т.е не является основной отраслевой деятельностью.Но я fluter попробовал и мне понравилось… Многоэтажные скобки я разбил на функции… выглядеть сразу начало симпатично… посмотрел примеры которые делаются более опытными разработчиками flutter… Там очень насыщенный красивый интерфейс… и именно мне там более всё понятно.(Возможно это просто психологически,-мне в java не нравится разбивка кода и xml экрана)…
Я так скажу… вот на java получить такой насыщенный интерфейс со всеми рюшечками у меня может не получиться… а на flutter есть основание предполагать что получится.
В Вашем случае- да, она не основная. Но в других бизнесах Android-приложение является основным продающим в силу распостраненности.

Но я fluter попробовал и мне понравилось…
Так это же хорошо. Мне на самом деле идеи flutter тоже нравятся. Просто не хватает инструментов для широкомасштабного продакшена.

Я пишу всё это не потому, чтобы «окунуть flutter», а чтобы показать последствия выбора для девелопера и компаний. Если конкретно Вам он подходит (судя по описанной Вами ситуации- да, вполне, закрытое использование)- это прекрасно! Делайте в своё удовольствие.

Просто конкретно я побоялся бы использовать flutter для серьезного коммерческого приложения. По крайней мере сейчас.

BTW. Посмотрите на Kotlin. На нем мы всей компанией пишем.
Вопрос не «как» а «зачем». Если будет реальный профит для бизнеса — тогда и убеждать никого не надо будет, аналитика скажет сама за себя.

А с точки зрения технаря флаттер вызывает лично у меня приступы фейспальмов и закатывания глаз…
вообще, прикольно, та же жава когда-то создавалась именно с прицелом на мультиплатформенность за счет подмены системных вызовов вызовами к виртуальной машине. И еще тогда мы знали, какой это гемор, компилять нативный С++ под разные платформы, даже безо всякого UI.
А тут, бац, оказывается, будущее мультиплатформенности — это именно нативные приложения.
Очень странно. У меня такое ощущение, что менеджмент (самый разнообразный) никак не может расстаться с мыслью, что мультиплатформенные приложения — это миф
Про 'нативный' интерфейс — тоже самое говорили ведь (и я не про React, я про Qt например) и получаем интерфейс, который ведет себя почти нативно.
При использовании текстового поля ввода логина в Flutter-приложении — я могу использовать LastPass для автозаполнения на Android/автозаполнялку из iOS12?
При выделении текста в TextView (или как там аналог называется) — будет стандартное системное меню со всем что в него интегрируется?(например, на Android, будет ли там пункт 'Перевести в Lingvo' если этот Lingvo стоит? Если нет — хотя бы штатное меню шаринга будет?). Как минимум в упомянутом Reflectly — ответ похоже 'разумеется нет'
Google Now (на Андроид) сможет через Assistant API 'читать' экран? (В обычных приложениях — может если приложение не мешает специально)
Интеграцию Spotlight и Google AppIndexing реализовать можно? А без написания платформенного кода?
Sign up to leave a comment.

Articles