Комментарии 48
НЛО прилетело и опубликовало эту надпись здесь
Представители Google осторожны в высказываниях, и официальных планов по развитию Fuchsia пока нет. «Google смотрит на эти эксперименты с открытым кодом как на инвестиции в инновации», — например, так ответили журналистам Bloomberg. По данным других источников Bloomberg, однажды Fuchsia заменит Android, но это вряд ли произойдёт раньше, чем через пять лет.
НЛО прилетело и опубликовало эту надпись здесь
С учетом того, что Google позиционирует данную операционную систему как замену Android— другими словами это нужно удалить из статьи? Мне тоже было бы интересно чем вы это подтверждаете, ведь это меняет отношение к статье. Лично я не нашел подтверждений этому высказыванию, напротив, Google говорят что это они «для поиграться»:
Fuchsia дает нам возможность по-новому взглянуть на то, какой может быть операционная система. Я знаю, что многие очень возбуждаются, когда что-то про нее слышат. «О, это замена Android» или «О, это же новая Chrome OS», но это не так. На самом деле Fuchsia для нас – это возможность изучать операционную систему, а впоследствии применять полученные знания при работе с другими нашими продуктами.
Добрый день! Действительно, хотя заявления о том, что Fuchsia — возможная замена Android, звучат уже достаточно давно, они всегда носят неофициальный характер (пример в Bloomberg). По этой причине в комьюнити нередко прислушиваются даже к личным комментариям от разработчиков Google, в частности, Travis Geiselbrecht подчеркивает, что Fuchsia «не игрушка». При этом в 2019 году Google подтвердил, что в ближайшие годы полный отказ от Android не планируется, а Fuchsia будет использоваться на различных устройствах, в том числе IoT. У Android огромная экосистема приложений, и единомоментно свернуть ее просто невозможно. Однако, в свое время тоже существовали легендарные ОС, которые сейчас уже не используются. Если эксперименты с новыми ОС окажутся удачными, они могут вытеснить Android постепенно, но этот процесс займет как минимум несколько лет.
Спасибо за статью, сам сейчас рассматриваю Flutter для коммерческой разработки. Вы его только смотрели, или попробовали в бою? Если да, хотелось бы послушать про реальный опыт.
Мы рады, что статья вам полезна! Да, мы пробовали Flutter на одном небольшом проекте.
Тогда я готов завалить расспросами :)
- Общее впечатление разработчиков — понравилось ли писать на Flutter? Подход-тулинг-язык?
- Насколько удобно было писать (по сравнению с нативом)?
- Насколько сильно приходилось if-ами прописывать разные виджеты для разных платформ?
- С какими проблемами производительности-стабильности столкнулись?
- Планируете ли использовать дальше на более крупных проекта?
1. Общее впечатление отличное. Как по мне, то порог входа достаточно низок, все интуитивно понятно, документация по самому фреймворку на достаточном уровне.
2. Я лично до этого вообще не писал для моб, но со слов остальных членов команды Флаттер по удобности переплевывает натив.
3. if нужны только если хочется отдельные дизайны для разных платформ. Если дизайн одинаковый, то кодовая база одна и никаких if.
4. Скорее да.
Как-то все слишком позитивно получилось, но нет, я не продвигаю Flutter если что:). Трудности были, но все они больше связаны с отстутствием опыта, периодической несовместимостью различных библиотек между собой, но это все есть и в других фреймворках
2. Я лично до этого вообще не писал для моб, но со слов остальных членов команды Флаттер по удобности переплевывает натив.
3. if нужны только если хочется отдельные дизайны для разных платформ. Если дизайн одинаковый, то кодовая база одна и никаких if.
4. Скорее да.
Как-то все слишком позитивно получилось, но нет, я не продвигаю Flutter если что:). Трудности были, но все они больше связаны с отстутствием опыта, периодической несовместимостью различных библиотек между собой, но это все есть и в других фреймворках
Да, понравилось, особенно легкость, с которой интегрируется Flutter в AndroidStudio. Сам подход и язык тоже были признаны достаточно удобными, хотя и несколько непривычными после длительной нативной разработки. У Flutter отличается концепция верстки, но уже в течение первой недели разработки мы втянулись. В нашем случае мы переносили уже существующее приложение с Android на Flutter, оно выглядело идентично на Android и iOS. По производительности особых замечаний не было, по стабильности были вопросы, когда обновляли Flutter или какую-либо из сторонних библиотек (но это лечилось тщательной чисткой проекта). С крупными проектами – посмотрим, но сейчас у нас в работе еще один проект среднего масштаба на Flutter.
Попробовали Flutter на двух небольших проектах: один на хакатоне, второй коммерческий. Остались очень довольны выбором, т.к. в коммерческом проекте нужно было реализовать уникальный дизайн, который был бы одинаков на двух платформах и Flutter как раз в это умеет. К Dart быстро привыкаешь, библиотек уже хватает, hotreload is amasing ты мгновенно видешь все внесенные изменения с сохранением состояния, и прочие плюшки
А можно тогда и вас чуть подробнее расписать по списку вопросов из моего предыдущего коммента? habr.com/ru/company/simbirsoft/blog/441766/#comment_19812380
Конечный установочный пакет больше, так как в него добавляется виртуальная машина Dart.
Вы наверное хотели сказать не виртуальная машина а рантайм? Это очень разные вещи.
Реальная виртуальная машина там тоже есть, но добавляется только в debug сборку. А в release добавляется просто библиотека графического движка для отрисовки виджетов.
— Конечный установочный пакет больше, так как в него добавляется виртуальная машина Dart.
Но это в режиме debug, а когда собирается конечный продукт (release) в нем отсутствует «виртуальная машина» и…
добавляется просто библиотека графического движка для отрисовки виджетов
А также приложение весит всего 4-5(mb) Android и 2-3(mb) IOS, и ещё в конечном результате приложение собирается в native версию.
Почему тогда это относиться к минусу?
ВМ, для разработки это большой плюс.
Вспоминаю электрон и не нахожу ответа на самый главный вопрос: как обстоят дела с потреблением памяти и ресурсов процессора?
Спасибо за статью, можно вопрос «от чайника»? Вот и Вашей статье, и в других статьях по Flutter всегда подчеркивают, что исходный код Dart компилируется в нативное приложение. Для iOS понятно. А что есть «нативное» для Андроида? Это действительно исполняемый файл Линукса или все-таки байт-код для виртуальной машины Андроида? Если это исполняемый файл Линукса, то как реализована платформенная зависимость х86/х86_64/arm и есть ли возможность прицепить сторонние динамические библиотеки (*.so)? Как реализованы права доступа к аппаратным ресурсам? Если я запустил такое приложение из под root, у приложения автоматически полный доступ по всему? Я всегда считал, что виртуальная машина — это есть одновременно и сердце и главное преимущество Андроида, а тут выглядит как шаг назад обратно к машинному коду. Или я ошибаюсь?
Вопрос о прогрессивности Flutter вызвал у наших разработчиков оживленную дискуссию, поэтому, полагаем, на этот вопрос трудно ответить однозначно) Что касается исходного кода Dart, он компилируется в нативные библиотеки для ARM и x86 и подключается к Android проекту. Скорее всего, такой подход продиктован стремлением увеличить производительность и снизить зависимость от Android для возможного перехода на Fuchsia.
Так там на выходе собирается apk-файл.
В Android любые пользовательские приложения выполняются каждое в своей «песочнице», при этом неважно, скомпилировано ли приложение в платформенный машинный код или в платформонезависимый байткод типа Dalvik. Более того, со времен ART то, что вы называете «виртуальной машиной» практически отсутствует, потому что ART автоматически перекомпилирует байткод из APK в нативный платформенный код («исполняемый файл Линукса», если угодно) заранее после установки приложения либо во время первого запуска, а не занимается постоянной JIT компиляцией байткода во время его выполнения как Dalvik VM. Более того, никто не мешал и не мешает прицепить .so даже к байткоду в Dalvik VM — через JNI. Так что ваши представления о реализации механизмов защиты приложений в Android несколько… хм. Ну и Android NDK был с нами с первых версий Android и никуда пропадать не планирует, на его основе вполне себе пишутся и работают приложения в нативном коде под Android, я лично делаю это на Qt, вот сейчас и Flutter появился примерно с той же парадигмой. Это вовсе не «шаг назад», а скорее «шаг вперед», особенно в плане производительности.
Спасибо, развернуто и понятно написали. Так уж получилось, что все свои приложения я писал на Джаве, Котлин никогда серьёзно не рассматривал, так как по сути это та же самая VM, только синтаксис птичий. Поэтому фраза «компилируется в нативный код» меня и заинтриговала. Вот и пытаюсь разобраться. И, вроде, действительно привлекательно выглядит, чтобы на эту технологию переходить. Я автор микро-Математики (https://github.com/mkulesh/microMathematics) и просто пытаюсь понять, стоит ли её портировать на Flutter и насколько это сложно. Явные плюсы — производительность и iOS, но трудозатраты большие, что пугает.
Ну если вы хотите iOS, то придется по-любому ваш продукт на чем-то переписывать — либо на ObjC/Swift (но тогда вам придется параллельно поддерживать обе, мягко говоря, не пересекающиеся кодовые базы), либо на чем-то кроссплатформенном, второе, по-моему, предпочтительнее. Правда, лично я все больше с Qt/QML имею опыт, Flutter не пробовал. Кстати, забавно, раньше при виде фразы «cross-platform mobile toolkit» в статье модно было плеваться в комментариях в стиле «фи, не нативно» (в том смысле, что контролы в UI выглядят не «родными»). Но в последнее время эта тенденция как-то затихает, и «собственный графический движок» у таких тулкитов и «единообразие внешнего вида приложения на всех платформах» уже начинает постепенно выставляться как плюс.
Конечный установочный пакет больше, так как в него добавляется виртуальная машина Dartопять, уже столько написано про это, вы пробовали собирать release версию, а не debug. В debug еще и тормозит бывает, а в release все летает.
А почему используется такое решение с навигацией, а не роутинг с поддержкой Back Button?
Navigator.push / pushNamed etc.Этот фрагмент кода приведен в качестве примера. Мы решили не загромождать код объявлением routes.
Чувствую заминусуют меня за этот коммент но… Вы пробовали использовать QT? Если да, то чем для вас он хуже флаттера? Мы, например, в команде попробовали флаттер и поняли, что на данном этапе это слишком сыро. Производительность заметно хуже, чем на QT, хотя и там и там отрисовка на том же вулкане. Плюс QT охватывает гораздо больше платформ, плюс это всё-таки C++, и с точки зрения оптимизации там все гораздо лучше и нет лишних виртуальных машин и тд. Да и библиотек под плюсы просто не пересчитать. При наличии хорошего дизайнера вполне можно получить красивое приложение и на кьюте. Ну и заодно я бы посмотрел, как вы будете подключать какую-нибудь библиотеку написанную на сях или плюсах к проекту на флаттере (например тот же linphone). В будущем может из флаттера и выйдет что-то интересное, но в данный момент для коммерческой разработки это слишком сыро и просто опасно использовать, особенно когда на кону серьезные деньги. имхо.
П.С. жду флаттер на базе го :) вот это было бы интересно :)
Нет, это другая ниша. Flutter позволяет писать кросс-платформенные приложения легко, но при этом не выжимая максимальную производительность. На QT процесс разработки усложняется, зато мы можем добиться большей производительности. Поэтому Flutter выгоднее использовать на небольших и средних проектах.
На счёт сложности — а в чем сложность? Как по мне скакание вокруг сырости и багов гораздо сложнее, чем у более менее стабильного решения. Сложность в языке, то что там c++? Да, во флаттере есть готовые визуальные составляющие, которые смотрятся симпатично, но если нужно делать под конкретный дизайн, то там тоже начинается веселье. И как писал выше — использование любой сторонней библиотеки это боль и страдания. И не сказал бы, что это прям совсем другая ниша, скорее QT умеет в разы больше, но никто не заставляет всем этим пользоваться, можно пользоваться только теми инструментами которые нужны, а потом мучительно не переписывать на другой язык если проект вырастает. Да и комьюнити у кьюта огромно, есть форумы где можно найти и баги, и воркэраунды для их обхода, да и обновления выходят довольно часто. :)
В Qt приложение зачастую можно написать так, что от C++ там будет только штампованный main.cpp из десятка строчек, инициализирующий декларативную машинерию и подгружающий локализацию, и все. Интерфейс при этом будет написан на QML, который вполне по силам освоить даже дизайнеру (он для этого и разработан), а бизнес-логика — на JS. При этом все будет летать, потому что QML-файлы инстанцируются в Qt'шные классы, у которых все внутренности (кроме пользовательских обработчиков событий, пожалуй, которые в данном случае будут на JS) написаны на C++. Причём даже все это можно ускорить ещё больше, перенеся момент парсинга/инстанцирования с момента подгрузки QML-файла на момент сборки приложения с помощью Qt Quick Compiler.
Кстати тоже отличный вариант :) Но в нашем случае приложение полностью на c++ без JS, архитектура viper, используется довольно много c++ библиотек (в том числе openssl), и отказались от qt quick. Тем не менее приложение работает очень шустро и выглядит вполне прилично, с анимашками и прочими финтифлюшками :) но согласен полностью, что можно пойти более простым путем и не усложнять себе жизнь, если того не требуют обстоятельства.
Подскажите новичку в мире мобилок. Нужно мне написать софт, наверное сначала под Андроид, потом и под iOS. Айфона и макбука нет. Лет 5 работал на c++, последние 10 лет больше c#. Немного смотрел Xamarin. Вот есть Flutter. С Qt немного работал. А ещё все эти react native и пр. Учить Java/Swift не считаю целесообразным. Что взять? У Qt есть эмулятор, или для iOS придется макбук+айфон покупать? Спасибо.
Ну, Qt существует, естественно, не в вакууме, как для сборки под Android ему нужны Android SDK и NDK, так и для сборки под iOS, соответственно, нужен Xcode. Эмуляторы есть в составе Xcode, но, чтобы его поставить, нужно устройство с MacOS. Говорят, на Хакинтоше Xcode нормально работает, но я лично не пробовал.
Касались ли вы вопроса использования C++ в приложении, написанном на Flutter?
Хотел бы задать вопрос касательно архитектуры Flutter-приложений.
Я разрабатываю некоторое приложение с Drawer, где в пределах одного Scaffold хочу обновлять body
Каждый body — отдельный класс. У меня имеется необходимость менять appBar в Scaffold из body после завершения какого-либо действия, например загрузки данных из сети. Я решил проблему следующим образом:
Создал абстрактный класс IPagedScaffold, в котором объявил метод updateTitle(String title) и реализовал его в State-классе своего Scaffold
Создал абстрактный класс MaterialFragment extends StatefullWidget, от которого будут наследоваться body, устанавливаемые в Scaffold
В классе MaterialFragment создал поле IPagesScaffold _scaffold и сделал для него геттер и сеттер. Сеттер я использовал в конструкторе State-класса моего Scaffold, вызывая в конструкторе метод body.setPagedScaffold(this);
В классах State я мог установить заголовок через widget.getPagedScaffold().updateTitle('Some title') и все было хорошо.
Но, заметив, что Android Studio подчеркивает MaterialFragment увидел сообщение, что классы Widget помечены как immutable и соответственно все поля должны быть объявлены как final. Это испортило все.
Получается, что я могу установить Scaffold только в конструкторе, однако в момент инициализации body, Scaffold может быть еще не создан, например в случае если я добавляю на экран сразу Scaffold вместе с body: new MyPagedScaffold(new MyMaterialScreen());
Попытался внутри класса State моего body сделать (Scaffold.of(context) as IPagedScaffold).updateTitle(«My title»), но получил сообщение об ошибке, что Scaffold не является экземпляром класса IPagedScaffold
Пока вижу два решения:
1) Оставить все как есть и не обращать внимания на предупреждение об иммутабельности Widget (мне видится это неправильным)
2) Создать класс-хранилище, который будет хранить в статичном поле экземпляр моего IPagedScaffold (вижу это решение очень грязным)
Скажите, пожалуйста, как можно решить мою проблему? Или я вообще изначально неправильно воспринимаю архитектуру приложений для Flutter?
Я разрабатываю некоторое приложение с Drawer, где в пределах одного Scaffold хочу обновлять body
Каждый body — отдельный класс. У меня имеется необходимость менять appBar в Scaffold из body после завершения какого-либо действия, например загрузки данных из сети. Я решил проблему следующим образом:
Создал абстрактный класс IPagedScaffold, в котором объявил метод updateTitle(String title) и реализовал его в State-классе своего Scaffold
Создал абстрактный класс MaterialFragment extends StatefullWidget, от которого будут наследоваться body, устанавливаемые в Scaffold
В классе MaterialFragment создал поле IPagesScaffold _scaffold и сделал для него геттер и сеттер. Сеттер я использовал в конструкторе State-класса моего Scaffold, вызывая в конструкторе метод body.setPagedScaffold(this);
В классах State я мог установить заголовок через widget.getPagedScaffold().updateTitle('Some title') и все было хорошо.
Но, заметив, что Android Studio подчеркивает MaterialFragment увидел сообщение, что классы Widget помечены как immutable и соответственно все поля должны быть объявлены как final. Это испортило все.
Получается, что я могу установить Scaffold только в конструкторе, однако в момент инициализации body, Scaffold может быть еще не создан, например в случае если я добавляю на экран сразу Scaffold вместе с body: new MyPagedScaffold(new MyMaterialScreen());
Попытался внутри класса State моего body сделать (Scaffold.of(context) as IPagedScaffold).updateTitle(«My title»), но получил сообщение об ошибке, что Scaffold не является экземпляром класса IPagedScaffold
Пока вижу два решения:
1) Оставить все как есть и не обращать внимания на предупреждение об иммутабельности Widget (мне видится это неправильным)
2) Создать класс-хранилище, который будет хранить в статичном поле экземпляр моего IPagedScaffold (вижу это решение очень грязным)
Скажите, пожалуйста, как можно решить мою проблему? Или я вообще изначально неправильно воспринимаю архитектуру приложений для Flutter?
Обычно на проектах мы используем архитектуру redux, где для решения подобной проблемы можно создать событие на обновление title bar определенного экрана.
Или более простой вариант (без смены архитектуры):
stackoverflow.com/questions/48481590/how-to-set-update-sate-of-statefulwidget-from-other-statefulwidget-in-flutter
В State можно создавать обычные — не final — переменные и геттеры, сеттеры к ним (без предупреждений от Android Studio)
Или более простой вариант (без смены архитектуры):
stackoverflow.com/questions/48481590/how-to-set-update-sate-of-statefulwidget-from-other-statefulwidget-in-flutter
В State можно создавать обычные — не final — переменные и геттеры, сеттеры к ним (без предупреждений от Android Studio)
Да, то что в State можно создавать обычные поля я знаю. В варианте по ссылке в актуальном варианте решения предлагают передавать ссылку на State в конструктор виджета, откуда она записывается в собственное поле виджета _MyHomePageState parent:
стоит отметить, что в этом примере они также не указали _MyHomePageState parent как final, на что будет жаловаться Idea (что не будет при этом мешать коду корректно(?) работать). Если подразумевается, что виджет, получивший ссылку на _MyHomePageState является StatefulWidget виджетом, то эту ссылку можно будет передать в State и там уже делать с ней что заблагорассудится
Моя проблема немного в другом: на момент создания как Parent-виджета так и Sub-виджета их State не определены, так как я в конструктор Parent-виджета пытаюсь передать Sub-виджет. Я пытался так сделать, чтобы один и тот-же класс MyScaffold можно было использовать как для фрагментов (замены содержимого Scaffold), так и для новых Route, просто создав экземпляр класса MyScaffold и передав ему в конструктор новый экземпляр вложенного виджета. Скорее всего мне нужно пересматривать архитектуру, но ничего внятного пока в голову не лезет
class Sub extends StatelessWidget {
_MyHomePageState parent;
Sub(this.parent);
@override
Widget build(BuildContext context) {
return new InkResponse(
child: new Container(
margin: globalMargin,
color: Colors.red,
child: new Center(
child: new Text(
"-",
style: textStyle,
),
)),
onTap: () {
this.parent.setState(() {
this.parent.number --;
});
},
);
}
}
стоит отметить, что в этом примере они также не указали _MyHomePageState parent как final, на что будет жаловаться Idea (что не будет при этом мешать коду корректно(?) работать). Если подразумевается, что виджет, получивший ссылку на _MyHomePageState является StatefulWidget виджетом, то эту ссылку можно будет передать в State и там уже делать с ней что заблагорассудится
Моя проблема немного в другом: на момент создания как Parent-виджета так и Sub-виджета их State не определены, так как я в конструктор Parent-виджета пытаюсь передать Sub-виджет. Я пытался так сделать, чтобы один и тот-же класс MyScaffold можно было использовать как для фрагментов (замены содержимого Scaffold), так и для новых Route, просто создав экземпляр класса MyScaffold и передав ему в конструктор новый экземпляр вложенного виджета. Скорее всего мне нужно пересматривать архитектуру, но ничего внятного пока в голову не лезет
Есть ли у кого-то опыт перехода с React Native на Flutter? Интересно услышать, что послужило причиной, с какими проблемами/ограничениями столкнулись и к какому выводу пришли.
Начал изучение Flutter с HelloWorld. Собрал проект, сделал релизную сборку, залил на iPhone и запустил — работает. Спустя неделю пытаюсь запустить залитую на девайс программу — получаю вылет сразу после запуска. Flutter выглядит уж совсем сырым.
рано или поздно Flutter вытеснит нативную разработку под Android
Однозначно не «рано». Может когда-нибудь. но сейчас явных предпосылок к этому нет. Fuchsia еще в очень начальном состоянии и пока неясно что будет в итоге. А касательно самого Flutter — есть много готовых пакетов на pub.dartlang.org, которые мы можем подтягивать и использовать, работая только на Dart. Но, если глянуть их исходники, то там будет 1 враппер, написанный на дарте, а вся логика прописана на Java и Objective.
Я вижу во Flutter очень мощный и интересный инструмент для создания UI. Но предпосылок для полного вытеснения нативки пока не вижу совершенно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Flutter. Плюсы и минусы