Comments 48
С учетом того, что Google позиционирует данную операционную систему как замену Android— другими словами это нужно удалить из статьи? Мне тоже было бы интересно чем вы это подтверждаете, ведь это меняет отношение к статье. Лично я не нашел подтверждений этому высказыванию, напротив, Google говорят что это они «для поиграться»:
Fuchsia дает нам возможность по-новому взглянуть на то, какой может быть операционная система. Я знаю, что многие очень возбуждаются, когда что-то про нее слышат. «О, это замена Android» или «О, это же новая Chrome OS», но это не так. На самом деле Fuchsia для нас – это возможность изучать операционную систему, а впоследствии применять полученные знания при работе с другими нашими продуктами.
- Общее впечатление разработчиков — понравилось ли писать на Flutter? Подход-тулинг-язык?
- Насколько удобно было писать (по сравнению с нативом)?
- Насколько сильно приходилось if-ами прописывать разные виджеты для разных платформ?
- С какими проблемами производительности-стабильности столкнулись?
- Планируете ли использовать дальше на более крупных проекта?
2. Я лично до этого вообще не писал для моб, но со слов остальных членов команды Флаттер по удобности переплевывает натив.
3. if нужны только если хочется отдельные дизайны для разных платформ. Если дизайн одинаковый, то кодовая база одна и никаких if.
4. Скорее да.
Как-то все слишком позитивно получилось, но нет, я не продвигаю Flutter если что:). Трудности были, но все они больше связаны с отстутствием опыта, периодической несовместимостью различных библиотек между собой, но это все есть и в других фреймворках
Конечный установочный пакет больше, так как в него добавляется виртуальная машина Dart.
Вы наверное хотели сказать не виртуальная машина а рантайм? Это очень разные вещи.
— Конечный установочный пакет больше, так как в него добавляется виртуальная машина Dart.
Но это в режиме debug, а когда собирается конечный продукт (release) в нем отсутствует «виртуальная машина» и…
добавляется просто библиотека графического движка для отрисовки виджетов
А также приложение весит всего 4-5(mb) Android и 2-3(mb) IOS, и ещё в конечном результате приложение собирается в native версию.
Почему тогда это относиться к минусу?
ВМ, для разработки это большой плюс.
Так там на выходе собирается apk-файл.
Конечный установочный пакет больше, так как в него добавляется виртуальная машина Dartопять, уже столько написано про это, вы пробовали собирать release версию, а не debug. В debug еще и тормозит бывает, а в release все летает.
А почему используется такое решение с навигацией, а не роутинг с поддержкой Back Button?
Navigator.push / pushNamed etc.
А приходилось ли Вам уже писать Native модули, и если да, то на какие задачи?
Или пока библиотек хватало с головой?
Спасибо за ответы
Чувствую заминусуют меня за этот коммент но… Вы пробовали использовать QT? Если да, то чем для вас он хуже флаттера? Мы, например, в команде попробовали флаттер и поняли, что на данном этапе это слишком сыро. Производительность заметно хуже, чем на QT, хотя и там и там отрисовка на том же вулкане. Плюс QT охватывает гораздо больше платформ, плюс это всё-таки C++, и с точки зрения оптимизации там все гораздо лучше и нет лишних виртуальных машин и тд. Да и библиотек под плюсы просто не пересчитать. При наличии хорошего дизайнера вполне можно получить красивое приложение и на кьюте. Ну и заодно я бы посмотрел, как вы будете подключать какую-нибудь библиотеку написанную на сях или плюсах к проекту на флаттере (например тот же linphone). В будущем может из флаттера и выйдет что-то интересное, но в данный момент для коммерческой разработки это слишком сыро и просто опасно использовать, особенно когда на кону серьезные деньги. имхо.
П.С. жду флаттер на базе го :) вот это было бы интересно :)
На счёт сложности — а в чем сложность? Как по мне скакание вокруг сырости и багов гораздо сложнее, чем у более менее стабильного решения. Сложность в языке, то что там c++? Да, во флаттере есть готовые визуальные составляющие, которые смотрятся симпатично, но если нужно делать под конкретный дизайн, то там тоже начинается веселье. И как писал выше — использование любой сторонней библиотеки это боль и страдания. И не сказал бы, что это прям совсем другая ниша, скорее QT умеет в разы больше, но никто не заставляет всем этим пользоваться, можно пользоваться только теми инструментами которые нужны, а потом мучительно не переписывать на другой язык если проект вырастает. Да и комьюнити у кьюта огромно, есть форумы где можно найти и баги, и воркэраунды для их обхода, да и обновления выходят довольно часто. :)
Кстати тоже отличный вариант :) Но в нашем случае приложение полностью на 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 нормально работает, но я лично не пробовал.
Я разрабатываю некоторое приложение с 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?
Или более простой вариант (без смены архитектуры):
stackoverflow.com/questions/48481590/how-to-set-update-sate-of-statefulwidget-from-other-statefulwidget-in-flutter
В State можно создавать обычные — не final — переменные и геттеры, сеттеры к ним (без предупреждений от Android Studio)
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 и передав ему в конструктор новый экземпляр вложенного виджета. Скорее всего мне нужно пересматривать архитектуру, но ничего внятного пока в голову не лезет
рано или поздно Flutter вытеснит нативную разработку под Android
Однозначно не «рано». Может когда-нибудь. но сейчас явных предпосылок к этому нет. Fuchsia еще в очень начальном состоянии и пока неясно что будет в итоге. А касательно самого Flutter — есть много готовых пакетов на pub.dartlang.org, которые мы можем подтягивать и использовать, работая только на Dart. Но, если глянуть их исходники, то там будет 1 враппер, написанный на дарте, а вся логика прописана на Java и Objective.
Я вижу во Flutter очень мощный и интересный инструмент для создания UI. Но предпосылок для полного вытеснения нативки пока не вижу совершенно.
Flutter. Плюсы и минусы