Рассматривали, но посчитали трудозатраты и поняли, что написать свое проще, с учетом дальнейшего сопровождения и расширения. Нам нужна интеграция со многими другими сервисами компании, а это всегда трудоемкая работа, особенно когда система внешняя.
Кроме того, учитывались наши предпочтения по технологическому стеку (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 добавляется просто библиотека графического движка для отрисовки виджетов.
Представители Google осторожны в высказываниях, и официальных планов по развитию Fuchsia пока нет. «Google смотрит на эти эксперименты с открытым кодом как на инвестиции в инновации», — например, так ответили журналистам Bloomberg. По данным других источников Bloomberg, однажды Fuchsia заменит Android, но это вряд ли произойдёт раньше, чем через пять лет.
Перед тем как ответить, сразу оговоримся, в этой статье мы лишь описали наш ход мыслей при поиске решения в условиях ограниченного времени. Нам хотелось привлечь внимание к данной проблеме и отсутствию легкодоступных однозначных и простых решений. Ресурсов, где описана эта проблема и варианты ее решения по пальцам перечесть. И статей как-то тоже не видно…
1. Да, действительно robot на CI видимо не вариант. До реализации в CI этого решения у нас не дошло, по озвученным в статье причинам.
2. Найти нативное решение все же не так просто. А уж написать самому тем более. Согласны, оно выглядит попроще и читабельнее. Однако если память нам не изменяет, запустить его с ходу у нас не вышло. Поэтому выбрали другое решение.
3. Про данную возможность было известно, но в условиях ограниченного времени лезть в JQuery и изменять что-то в найденном нами решении не хотелось.
Если применить предложенное выше нативное решение, то, пожалуй, благоразумно будет использовать и передачу WebElement.
4. В том то и дело, что проблема, как ни странно, не особо частая. И давать частные случаи при подготовке специалиста возможно только тогда, когда всеми основными знаниями он уже владеет в совершенстве. Увы, такое, на наш взгляд, может себе позволить не каждый.
Спасибо за комментарий. Хотя идеальным решением было бы исправление WebDriver.
Massive view controller упоминался в качестве примера того, что бывает если написание кода на проекте вообще ничем не ограничивать.
Цель примера с UITableView иная — показать императивность UIKit'а, он упрощен для наглядности. Сырые данные или dataSource, в любом случае, придется заводить свойство, доступ к которому получают все единицы класса в пределах исходника.
Все зависит от степени вовлеченности разработчиков в проект и в Rx в частности. Если большая текучка, то стоит подумать о времени, которое новые люди потратят на преодоление порога вхождения, который у библиотеки достаточно высокий, особенно при работе с UI.
А если с кадрами проблем нет, то полный вперед)
Кроме того, учитывались наши предпочтения по технологическому стеку (Node.js, React)
Или более простой вариант (без смены архитектуры):
stackoverflow.com/questions/48481590/how-to-set-update-sate-of-statefulwidget-from-other-statefulwidget-in-flutter
В State можно создавать обычные — не final — переменные и геттеры, сеттеры к ним (без предупреждений от Android Studio)
1. Да, действительно robot на CI видимо не вариант. До реализации в CI этого решения у нас не дошло, по озвученным в статье причинам.
2. Найти нативное решение все же не так просто. А уж написать самому тем более. Согласны, оно выглядит попроще и читабельнее. Однако если память нам не изменяет, запустить его с ходу у нас не вышло. Поэтому выбрали другое решение.
3. Про данную возможность было известно, но в условиях ограниченного времени лезть в JQuery и изменять что-то в найденном нами решении не хотелось.
Если применить предложенное выше нативное решение, то, пожалуй, благоразумно будет использовать и передачу WebElement.
4. В том то и дело, что проблема, как ни странно, не особо частая. И давать частные случаи при подготовке специалиста возможно только тогда, когда всеми основными знаниями он уже владеет в совершенстве. Увы, такое, на наш взгляд, может себе позволить не каждый.
Спасибо за комментарий. Хотя идеальным решением было бы исправление WebDriver.
Цель примера с UITableView иная — показать императивность UIKit'а, он упрощен для наглядности. Сырые данные или dataSource, в любом случае, придется заводить свойство, доступ к которому получают все единицы класса в пределах исходника.
А если с кадрами проблем нет, то полный вперед)