Как стать автором
Обновить

Комментарии 53

Очередной фреймворк «убийца ххх»… а тем временем, все серьезные приложения все равно пишут нативно, под каждую платформу отдельно. Потому как то произодительности не хватает, то возможностей, и все равно часть кода приходится писать нативно, что очень усложняет «кроссплатформенную» разработку, и в итоге люди задаются вопросом, если половина нативна, то почему же уж все нативно не написать? P.S. Был опыт разработки на Xamarin, знаю о чем говорю. Для простеньких приложений аля «визитка» — самое то. Для серьезных проектов- лучше даже не начитать.
С производительностью норм должно быть, ибо в нативный arm код компилится. В случае андроида даже накладных расходов на jni не должно быть.
Кстати, еще добавлю — до флаттера был дико скептически настроен к кроссплатформенным фреймворкам, собственно из за этого его проморгал в свое время, думал очередная фигня на веб технологиях или подобном. А потом где то месяц назад наткнулся на более подробное его описание, схему архитектуры и дико пожалел что такое пропустил.
А можете рассказать как раз о примерах, когда не хватает возможностей и частях, которые надо писать на нативе? Сам то я пишу только на нативе, но т.к. тема кроссплатформенных решений становится популярна, то интересуюсь этим чисто как инструментом для мелких проектиков/прототипов. Просто все вокруг говорят «не подходит для серьёзных проектов», а о конкретных моментах умалчивают.
Я тоже пишу на нативе под ios, одно время помогал проекту, написанному на xamarin'e, как раз писал нативные части, которых им не хватало. Ну, к примеру, когда вышел FaceID, работу с ним приходилось делать нативно, так как xamarin не поддерживал (это относится и ко многим другим новым фичам iOS, фреймворки начинают их поддерживать с сильным запозданием). Второй пример- работа с сервером через вебсокеты (передача real-time видео/audio), xamarin не тянул. Третий пример — компонент выбора фото/видео из библиотеки телефона (нужен был кастомный, со сложным поведением).

Эммм… FaceID из коробки в Xamarin работал в момент релиза нового айфона. Там же обратная совместимость от TouchID, тоже апи использовано.

Обратная совместимость была, да, но требовалось при использовании TouchID в дизайне это отобразить, а для этого нужно было отличать TouchID от FaceID.
Обратная совместимость была, да, но требовалось при использовании TouchID в дизайне это отобразить, а для этого нужно было отличать TouchID от FaceID.


Из-за этого «одного бита» вы делаете вывод, что все кросс-платформенные системы — говно?

Стоимость решения проблемы отличения TouchID/FaceID и рядом не стояла со стоимостью не кросс-платформенной разработки.

Вообще-то я не писал что «что все кросс-платформенные системы — говно», а наоборот, писал «Для простеньких приложений аля «визитка» — самое то». Если вы готовы постоянно идти на компромисы, мириться с производительностью и не использовать новейшие фичи платформ- то да, это неплохой выбор. Конкретная проблема отличить TouchID от FaceID на тот момент была не решаема через фреймворк, только натив, и не всегда заказчик хочет об этом слышать, ему нужен результат.
Ой ну не знаю…
Пока все поливают помоями очередных «убийц ххх», то эти самые убийцы медленно и верно завоёвывают рынок. Оглянуться не успеем как нативных разработчиков останется с гулькин нос, и основная численность будет вот таких flutter, kotlin и т.д. разработчиков.

Kotlin полностью нативный.

Я пишу нативно и пока безработица мне не грозит. Наоборот, моя стоимость только повысится, когда кругом будут сплошные фреймворк-кодеры, не способные делать хоть что-то серьезное и быстро работающее. Кстати, тоже самое писали про Ruby on Rails, что он захватит всю веб разработку. И где он сейчас?
Особенно весело станет когда флаттер будет нативным под фуксию и кроссплатформой для остальных)
20 лет слышу такие вещи! ;-)
А разве не так?) За 20 лет (господи, я в первый класс тогда пошел и даже о существовании компьютеров еще не подозревал) по моему все заполонил веб с js и всякие высокоуровневые языки.
Xamarin прекрасно себя показывает в серьёзных B2B проектах. Даже там, где UI свистелки-перделки нужны.
Все хорошо во flutter, мне очень понравился, прост в изучении и развертывании, но для продакшина не подходит, несколько раз приходилось чинить приложение потому как что то да менялось с каждым релизом. Сейчас вообще http client сломался и я плюнул на это дело, подожду официального релиза.
Отличная статья, спасибо, жду фуксию и пока повысится популярность), а до тех пор параллельно буду нативный андроид копать + флаттер.

Ищу на чем сделать пресловутый кросс-платформенный MVP, ранее немного работал с Xamarin. Вопрос: чем все-таки Flutter лучше? При этом, он должен быть сильно лучше, ибо +время на изучение Dart, более сырое решение (даже нет релизной версии), Андроид студия послабее VS.

Какие преимущества перед React Native? Из недостатков нужен новый язык — Dart который за пределами этого фреймворка нигде не нужен.
Натив. Ну т.е. компилится в нормальный бинарь и никаких прослоек между UI и кодом. Ну и статическая типизация конечно же)
Основной момент, в котором Flutter со старта имеет большое преимущество — производительность. Не нужно использовать JS Bridge при прямом обращении к платформе, а за счёт этого значительно проще выйти на 60 FPS при отрисовке UI.
Не называл бы изучение Dart минусом. Мне хватило одной секции на codeLabs от google, чтобы начать писать на нем. Очень понятный, легкий в изучении, лаконичный язык. По ходу разработки проекта уже появляются более конкретные вопросы касательно специфики языка, которые так же легко гуглятся. Если пришли не из JS, а из Java или C#, язык зайдет на ура.
Считаю Flutter отличным вариантом для создания MVP сразу на две платформы за максимально короткий срок. Проверка гипотезы, а потом написание нормального нативного приложения.

И еще момент. Я вот смотрю на Hamilton (это приложение на iOS и Android на Flutter) и мне очень-очень больно пользоваться подобным интерфейсом. Все-таки нативные элементы на каждой платформе должны быть обязательно.

P.S. На первой демо GIF вы поставили кнопку в Safe-зону. Так делать не стоит )
А оценка Hamilton-пользователей в 4.6 в GP как бы ни о чем? Прислушаемся же к вашему экспертному мнению?

Flutter не выглядит ли как попытка воскресить Dart?

Очень на то похоже. На тайпскрипте было бы лучше.

Согласен, непонимаю почему минус поставили.
Минус ставил не я, но что я думаю:
— typescript меньше типизирован да и не сказать что дико популярен, плюс хотят народ с нативной разработки переманивать, а на него с java и c# народ вроде как легко пересаживается.
— На дарт гораздо больше влияния гугл может оказывать.
— Возможно опасение повторения истории с java и oracle.
Как мне кажется если и выбирать — то логично было выбирать между go и dart.
Flutter не выглядит ли как попытка воскресить Dart?

Почему воскресить?
На Dart вполне себе актуальные вещи пишутся. Например, веб-морда основного источника дохода Google — их рекламной системы.
Думаю, на месте Dart вполне себе мог оказаться другой язык с сильной типизацией и трансляцией в JavaScript
и трансляцией в JavaScript

А это то тут причем?
Скорее никакого в отношении к JavaScript (хотя он такой, что все может быть :)
Но, в данном случае, сам факт возможности трансляции на другие языки очень важен
Кстати, поговорить о Dart и Flutter можно в русскоязычном сообществе в телеграм t.me/rudart

Вообще по ходу дела тут подход в итоге подобен тому что есть в Qt qml.

А какие-то инструменты для той самой визуальной верстки есть?

Никаких, как нет и визуальной вёрстки.

Всё дерево виджетов создаётся в коде, и единственный способ визуализировать его — в виде древовидной структуры в одной из вкладок плагина. Но есть утилиты, позволяющие эмулятор использовать в качестве интерактивного макета. Открываешь «Flutter Inspector», кликаешь на «Toggle Select Widget Mode», далее жмёшь на любой UI-элемент в запущенном приложении и инспектор тебя перебрасывает к нужному элементу в дереве виджетов.
Еще могу дополнить что часто hot reload спасает.
НЛО прилетело и опубликовало эту надпись здесь

Есть какое-либо взаимодействие с нативной средой? Т.е. если в фреймворка, что-то не хватает это нужно самим на Dart дописывать?

Разумеется, если для вашей ситуации что-то не предусмотрели — это нужно будет сделать вам самостоятельно или найти того кто вам сделает или найти вдруг это уже сделано.

Если расширение реализовано уже удобным способом, интегрированным с Dart и Flutter, то через plugin
flutter.io/developing-packages/#plugin

Нет, не на чистом Dart дописывать. А еще и на native под платформу.

Естъ какие-то примеры реальных приложений на флатере?

Вот, например, то, что предоставляет оф.сайт flutter.io/showcase.
Так же есть сэмпл в гугл плей — Flutter Gallery.

Да но это все еще шоукейсы, хоть мозехт и впечатлительные… Мэнеджеров гораздо легече убдеть реально взлетевшим приложением и это вполне понятно.

Хочу пригласить всех, кому интересен Dart и Flutter, на конференцию DartUP в Питере 1 декабря. Конференция бесплатная, но регистрироваться нужно. Программу будем публиковать со следующей недели dartup.ru
А после конференции видео будут для живущих далеко-далеко, которые точно не смогут приехать?
Да, видео будет у нас в блоге на хабре. Но тем, кто сможет, рекомендую приехать — можно будет лично пообщаться, задать вопросы спикерам, да и просто познакомиться.
Очень интересно, жду финальный релиз.
Есть несколько вопросов по теме:
1. Где можно искать библиотеки, созданные сообществом? В смысле есть какой-то аналог js.coach для Реакта и mvnrepository.com для Java?
2. Существует ли какой-то способ отправки пуш-уведомлений во Флаттер-приложение без использования Firebase? Имею ввиду из коробки, без написания своей нативной библиотеки.
3. Я, например, хочу сделать приложение, которое будет выглядеть нативно и на андроиде и на айфоне. Возможно ли на Флаттере это сделать в одной кодовой базе и без проверок типа «if(isOnAndroid){...}else{...}»?
1) pub.dartlang.org
3) Поищите недавнюю статью, там подход предложен был, но да, без проверок судя по всему не обойтись (хотя по мне это и к лучшему, не очень представляю как можно бы было сделать гибко и универсально одновременно)
2. Без использования Firebase не видел, но от Firebase есть для пушей плагин pub.dartlang.org/packages/firebase_messaging#-readme-tab-, так что писать нативную часть придется по минимому.
Кстати плагины у них есть не только для пушей.

А роутеры уже завезли?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий