Мне кажется у читателей сложилось впечатление, что Flutter гонят саной тряпкой. Но это не так, цель нашей компании просто перейти на другой стек. И причины, которые тут изложены, ясное дело не всем нравятся, с чего они должны быть объективными?
Я всегда за развитие OpenSource и за то чтобы разработчики развивали комьюнити разных технологий. Но мне кажется это непосильная ноша для компании, которая к тому же избрала другой курс. Если бы мы нашли достаточное количество лидов под Flutter, то возможно так бы и вышло, но получилось все как раз наоборот. К тому же обрачу ваше внимание, что есть крупные компании как Google и Apple, которые создали операционные системы и развивает их постоянно. И есть Flutter, который должен постоянно нагонять 2-х гигантов, представляете сколько туда средств требуется вложить?
Имеется в виду использование Native SDK от создателей операционных систем Android, iOS. Под iOS это Swift, под Android это Kotlin языки. Там где то еще деклаймер есть с мелким шрифтом.
На старте проекта серчил в основном зарубежные статьи, и даже на английском не смог найти. Зато известна практика, когда MVVM + Rx + Clean architecture на проект с iOS и Android затаскивают (статьи отдельно под платформы вы легко найдете) и примерно одинаково развивают под бдением архитектора оби платформы. Так что вы мне подали отличную идею написать такую статью на стыке двух платформ в будущем. Спасибо за идею.
Вы угадали, я пользовался ей в последний раз в 2006, на мой вгляд тогда в нее внесли значительные улучшения. Периодически меня удивляли и оптимизации компиляторов и nullsafe, но я не критикую его синтаксис, это был собирательный образ от пользователей Dart) Простите, если задел) мне в Java очень нравится система коллекций, очень продуманная.
Объективные доводы это и есть численные метрики, растет число вакансий и на нетиве пропорционально Flutter, я точно так же могу перевернуть в свою сторону объективные метрики объяснив все с другой стороны, как вы делаете со статистикой issues. Закроют или нет Flutter вам никто не скажет, но есть риск. Есть исторические факты, например аналогия с ReactNative или закрытие гуглпроектов. История как мы знаем повторяется, не исключено что Flutter разовьется и KMM его не опередит, в будущем возможно все что угодно, но есть тренд. Я о нем рассказал, если он вас напугал, то это не значит, что статья эмоциональная и в Озоне сидят дураки которые боятся что Flutter придется поддерживать самим, просто этот риск нам не нужен, у нас есть большое комьюнити нативных разработчиков и лучше в него вкладываться, чем вкладываться в рисковые технологии превращая проект в монстра. Jetpack Compose имеет меньше рисков на мой взгляд, потому что есть в компании опыт и практика его использования, она более позитивная, но я сейчас не буду расписывать их, статья не об этом
В вашем случае выбор оправдан, запуск стартапа, ограниченный бюджет, ничего лучше кроме Flutter не придумаешь и об этом я тоже писал.
Swift как язык не образец, но тем не менее я его выбрал, например, для своих стартапов чтобы писать Backend, в выборке были C# и Go еще. Первый слишком тормознутый, второй слишком замороченный, а Swift как-то балансирует, за 4 года не пожалел. Я вообще Swift евангелист. Что до Dart, признаюсь я на нем не писал, поэтому мне пришлось представить в статье мнение 5 коллег, никто из них не является настроенным против Flutter. Один из них кстати тоже выпустил приложение, как и вы на iOS, будучи Android native разработчиком. Первые его впечатления: блин круто, декларативный UI - это будущее, единственное язык древнючий какой-то ну и артефакты в графике
Я бы не сказал, что все перешли прям целиком со сканеров, на данный момент мобилками чаще пользуются как бекапом, то есть свет вырубили или вайфай сдох - тогда достают телефон. Одной из главных задач у нас сейчас повысить качество приложения чтобы им чаще пользовались.
они удваиваются сейчас и на нативе и на Flutter, и ЗП растет у всех тоже. Это показатель роста самого IT в целом, причем Flutter скорее за взрывной рост новых стартапов.
отличный образ, только с учетом возможностей натива (кажется, в статье упоминал, что они шире) перелив из стаканчика в вазу с цветами. А с учетом пропорции в компании Flutter:Native то стаканчик уже давно пора списать как музейный реквизит.
Выше в коментариях я расшифровывал смысл строк "стал невольным сместителем", это означает, что решение было принято до того как автор стал руководителем, и смысл автору вникать в технологии, от которых в компания отказываются и без него? А вот причины разумеется изучены и изложены в этой статье, вы кстати ее читали?
Если бизнес уже согласился, значит ему это выгодно, я кажется упоминал в статье какую выгоду получит бизнес.
Довольно смело пишите за автора, готов взять секретарем)
Возможно вы и правы, ТСД, которые мы кстати использем для Web версии пунков выдачи заказов, стоит адаптировать и под мобилки, уверен мы еще вернемся к этой теме, могу только сказать что мобильный телефон удобен как раз своей мобильностью, а приделывать к нему еще и сканер, да еще который может привести к потери автономности мобилки - все это уменьшит преимущества, ну мы просто спрашивали наших сотрудников, которые пользуются приложением. Тем не менее спасибо за идею, возможно сотрудники ПВЗ изменят свое мнение и мы вернемся к теме ТСД.
Я бы сказал что это было рациональное обоснование того выбора, который был сделан в пользу Flutter в самом начале, ведь он более чем оправдан. Сейчас это уже не обоснование, а констатация фактов пройденого опыта, эксперемент завершен, проект продолжается с новыми силами.
Про плагин камеры согласен, еслиб это была одна проблема и было в компании куча энтузиастов ее решить никто бы не парился, и учитывая что плагинов пришлось бы еще немало написать, тут я планы не могу рассекречивать, но они правда есть, смысл во Flutter потеряется бы довольно быстро
народу стало меньше, я не стал этим козырять ибо сравнивать с Flutter проектом некорректно, он шел не по роудмапу, а по иттерационным изменениям, нам проще так как знаем точку, в которую должны придти.
Я бы сказал что выбор не странноватый, а спорный. Мне тоже показалось так, пока все не взвесили и со стороны бизнеса тоже.
вижу кажется 2 вопроса: - Почему вас только камера беспокоит, там по тексту много разных компонент и инфраструктурных вопросов поднималось, не хочется перестраивать процессы по автотестам ни библиотеки аналитики через плагин тащить, ни гайды дизайнеров расшаренные на натив, не хочется при редизайне заного рисовать компоненты визуальные, которые шарятся по командам на натив. - Бизнеслогика есть во всех приложения, много ли, мало ли ее - в этом вся разница. На мой взгляд ее не достаточно в нашем приложении для того чтобы скрещивать Native и еще что то, ну например KMM. Бизнеслогику можно вынести на сторону сервисов. Если тащить все таки в клиенты, то получим франкинштейн, до такой необходимости и неизбежности опять же недотягиваем
"Ну и замечание про "экс-бэкенд" не понял –" Это был сарказм адресованный async await. Ведь в Native он появился позже, чем в Dart, ИМХО полезность фичи прям очевидна, но увы больше в бэкенд разработке.
"Невольно став сместителем существующего..." видимо необходимо расшифровать. Решение уже было принято до меня, а я лишь был назначен на это место, чтобы данное решение грамотно воплотить в жизнь. Это не первый опыт, когда меня нанимали для того чтобы драйвить команду переходить на Native
Разумеется не только, был упомянут функционал только уже реализованный на Flutter и довольно общий, в будующем надо было бы подключать собственную аналитику и многие другие платформенные компоненты, характерные для нашей компании и реализованные на Native.
Мне кажется у читателей сложилось впечатление, что Flutter гонят саной тряпкой. Но это не так, цель нашей компании просто перейти на другой стек. И причины, которые тут изложены, ясное дело не всем нравятся, с чего они должны быть объективными?
Я всегда за развитие OpenSource и за то чтобы разработчики развивали комьюнити разных технологий. Но мне кажется это непосильная ноша для компании, которая к тому же избрала другой курс. Если бы мы нашли достаточное количество лидов под Flutter, то возможно так бы и вышло, но получилось все как раз наоборот. К тому же обрачу ваше внимание, что есть крупные компании как Google и Apple, которые создали операционные системы и развивает их постоянно. И есть Flutter, который должен постоянно нагонять 2-х гигантов, представляете сколько туда средств требуется вложить?
Имеется в виду использование Native SDK от создателей операционных систем Android, iOS. Под iOS это Swift, под Android это Kotlin языки. Там где то еще деклаймер есть с мелким шрифтом.
Спасибо, думаю нужно больше времени, чтобы сказать: да мы это сделали не зря, но акцент уже будет тогда на стороне нетива
На старте проекта серчил в основном зарубежные статьи, и даже на английском не смог найти. Зато известна практика, когда MVVM + Rx + Clean architecture на проект с iOS и Android затаскивают (статьи отдельно под платформы вы легко найдете) и примерно одинаково развивают под бдением архитектора оби платформы. Так что вы мне подали отличную идею написать такую статью на стыке двух платформ в будущем. Спасибо за идею.
Вы угадали, я пользовался ей в последний раз в 2006, на мой вгляд тогда в нее внесли значительные улучшения. Периодически меня удивляли и оптимизации компиляторов и nullsafe, но я не критикую его синтаксис, это был собирательный образ от пользователей Dart) Простите, если задел) мне в Java очень нравится система коллекций, очень продуманная.
Объективные доводы это и есть численные метрики, растет число вакансий и на нетиве пропорционально Flutter, я точно так же могу перевернуть в свою сторону объективные метрики объяснив все с другой стороны, как вы делаете со статистикой issues. Закроют или нет Flutter вам никто не скажет, но есть риск. Есть исторические факты, например аналогия с ReactNative или закрытие гуглпроектов. История как мы знаем повторяется, не исключено что Flutter разовьется и KMM его не опередит, в будущем возможно все что угодно, но есть тренд. Я о нем рассказал, если он вас напугал, то это не значит, что статья эмоциональная и в Озоне сидят дураки которые боятся что Flutter придется поддерживать самим, просто этот риск нам не нужен, у нас есть большое комьюнити нативных разработчиков и лучше в него вкладываться, чем вкладываться в рисковые технологии превращая проект в монстра. Jetpack Compose имеет меньше рисков на мой взгляд, потому что есть в компании опыт и практика его использования, она более позитивная, но я сейчас не буду расписывать их, статья не об этом
В вашем случае выбор оправдан, запуск стартапа, ограниченный бюджет, ничего лучше кроме Flutter не придумаешь и об этом я тоже писал.
Swift как язык не образец, но тем не менее я его выбрал, например, для своих стартапов чтобы писать Backend, в выборке были C# и Go еще. Первый слишком тормознутый, второй слишком замороченный, а Swift как-то балансирует, за 4 года не пожалел. Я вообще Swift евангелист. Что до Dart, признаюсь я на нем не писал, поэтому мне пришлось представить в статье мнение 5 коллег, никто из них не является настроенным против Flutter. Один из них кстати тоже выпустил приложение, как и вы на iOS, будучи Android native разработчиком. Первые его впечатления: блин круто, декларативный UI - это будущее, единственное язык древнючий какой-то ну и артефакты в графике
так вам ответили не в менее мягкой форме, что нативщиков сейчас с огнем не сыщешь, они скорее боятся почту открывать, как бы кто не схантил.
Я бы не сказал, что все перешли прям целиком со сканеров, на данный момент мобилками чаще пользуются как бекапом, то есть свет вырубили или вайфай сдох - тогда достают телефон. Одной из главных задач у нас сейчас повысить качество приложения чтобы им чаще пользовались.
они удваиваются сейчас и на нативе и на Flutter, и ЗП растет у всех тоже. Это показатель роста самого IT в целом, причем Flutter скорее за взрывной рост новых стартапов.
отличный образ, только с учетом возможностей натива (кажется, в статье упоминал, что они шире) перелив из стаканчика в вазу с цветами. А с учетом пропорции в компании Flutter:Native то стаканчик уже давно пора списать как музейный реквизит.
дык разные Java были. Google чудь не засудили за то что она взяла проваславную Java
Выше в коментариях я расшифровывал смысл строк "стал невольным сместителем", это означает, что решение было принято до того как автор стал руководителем, и смысл автору вникать в технологии, от которых в компания отказываются и без него? А вот причины разумеется изучены и изложены в этой статье, вы кстати ее читали?
Если бизнес уже согласился, значит ему это выгодно, я кажется упоминал в статье какую выгоду получит бизнес.
Довольно смело пишите за автора, готов взять секретарем)
Возможно вы и правы, ТСД, которые мы кстати использем для Web версии пунков выдачи заказов, стоит адаптировать и под мобилки, уверен мы еще вернемся к этой теме, могу только сказать что мобильный телефон удобен как раз своей мобильностью, а приделывать к нему еще и сканер, да еще который может привести к потери автономности мобилки - все это уменьшит преимущества, ну мы просто спрашивали наших сотрудников, которые пользуются приложением. Тем не менее спасибо за идею, возможно сотрудники ПВЗ изменят свое мнение и мы вернемся к теме ТСД.
Я бы сказал что это было рациональное обоснование того выбора, который был сделан в пользу Flutter в самом начале, ведь он более чем оправдан. Сейчас это уже не обоснование, а констатация фактов пройденого опыта, эксперемент завершен, проект продолжается с новыми силами.
Про плагин камеры согласен, еслиб это была одна проблема и было в компании куча энтузиастов ее решить никто бы не парился, и учитывая что плагинов пришлось бы еще немало написать, тут я планы не могу рассекречивать, но они правда есть, смысл во Flutter потеряется бы довольно быстро
народу стало меньше, я не стал этим козырять ибо сравнивать с Flutter проектом некорректно, он шел не по роудмапу, а по иттерационным изменениям, нам проще так как знаем точку, в которую должны придти.
Я бы сказал что выбор не странноватый, а спорный. Мне тоже показалось так, пока все не взвесили и со стороны бизнеса тоже.
вижу кажется 2 вопроса:
- Почему вас только камера беспокоит, там по тексту много разных компонент и инфраструктурных вопросов поднималось, не хочется перестраивать процессы по автотестам ни библиотеки аналитики через плагин тащить, ни гайды дизайнеров расшаренные на натив, не хочется при редизайне заного рисовать компоненты визуальные, которые шарятся по командам на натив.
- Бизнеслогика есть во всех приложения, много ли, мало ли ее - в этом вся разница. На мой взгляд ее не достаточно в нашем приложении для того чтобы скрещивать Native и еще что то, ну например KMM. Бизнеслогику можно вынести на сторону сервисов. Если тащить все таки в клиенты, то получим франкинштейн, до такой необходимости и неизбежности опять же недотягиваем
"Ну и замечание про "экс-бэкенд" не понял –"
Это был сарказм адресованный async await. Ведь в Native он появился позже, чем в Dart, ИМХО полезность фичи прям очевидна, но увы больше в бэкенд разработке.
"Невольно став сместителем существующего..." видимо необходимо расшифровать. Решение уже было принято до меня, а я лишь был назначен на это место, чтобы данное решение грамотно воплотить в жизнь. Это не первый опыт, когда меня нанимали для того чтобы драйвить команду переходить на Native
Разумеется не только, был упомянут функционал только уже реализованный на Flutter и довольно общий, в будующем надо было бы подключать собственную аналитику и многие другие платформенные компоненты, характерные для нашей компании и реализованные на Native.