Рассматривали, но посчитали трудозатраты и поняли, что написать свое проще, с учетом дальнейшего сопровождения и расширения. Нам нужна интеграция со многими другими сервисами компании, а это всегда трудоемкая работа, особенно когда система внешняя.
Кроме того, учитывались наши предпочтения по технологическому стеку (Node.js, React)
Для нас Jira обладает избыточной функциональностью и не обладает требуемой. За годы работы мы выработали свои правила и процессы и хотели, чтобы наш таск-трекер помогал в этом, а не мешал)
Нет, это другая ниша. Flutter позволяет писать кросс-платформенные приложения легко, но при этом не выжимая максимальную производительность. На QT процесс разработки усложняется, зато мы можем добиться большей производительности. Поэтому Flutter выгоднее использовать на небольших и средних проектах.
Была ситуация, когда нам нужно было использовать веб-сокеты. Сейчас для этого уже есть библиотека, но на тот момент ее не было, поэтому мы обратились к Android и iOS библиотекам для передачи событий между нативной частью приложения и Flutter.
Вопрос о прогрессивности Flutter вызвал у наших разработчиков оживленную дискуссию, поэтому, полагаем, на этот вопрос трудно ответить однозначно) Что касается исходного кода Dart, он компилируется в нативные библиотеки для ARM и x86 и подключается к Android проекту. Скорее всего, такой подход продиктован стремлением увеличить производительность и снизить зависимость от Android для возможного перехода на Fuchsia.
Да, понравилось, особенно легкость, с которой интегрируется Flutter в AndroidStudio. Сам подход и язык тоже были признаны достаточно удобными, хотя и несколько непривычными после длительной нативной разработки. У Flutter отличается концепция верстки, но уже в течение первой недели разработки мы втянулись. В нашем случае мы переносили уже существующее приложение с Android на Flutter, оно выглядело идентично на Android и iOS. По производительности особых замечаний не было, по стабильности были вопросы, когда обновляли Flutter или какую-либо из сторонних библиотек (но это лечилось тщательной чисткой проекта). С крупными проектами – посмотрим, но сейчас у нас в работе еще один проект среднего масштаба на Flutter.
Release тоже пробовали, это можно заметить на скриншотах. Но даже в release версию добавляется библиотека графического движка, из-за чего размер apk все равно больше (хоть и не так критично, как в debug).
Реальная виртуальная машина там тоже есть, но добавляется только в debug сборку. А в release добавляется просто библиотека графического движка для отрисовки виджетов.
Кроме того, учитывались наши предпочтения по технологическому стеку (Node.js, React)
Или более простой вариант (без смены архитектуры):
stackoverflow.com/questions/48481590/how-to-set-update-sate-of-statefulwidget-from-other-statefulwidget-in-flutter
В State можно создавать обычные — не final — переменные и геттеры, сеттеры к ним (без предупреждений от Android Studio)