Комментарии 117
Всего лишь камера - и переходить на Native?
Почему не подошел вариант работы с камерой вывести в Native, а остальное на Flutter?
Разумеется не только, был упомянут функционал только уже реализованный на Flutter и довольно общий, в будующем надо было бы подключать собственную аналитику и многие другие платформенные компоненты, характерные для нашей компании и реализованные на Native.
Ну, потому что "недавно стал руководителем разработки" и надо же что-то делать, что-то внедрять, как-то засветиться.
"Невольно став сместителем существующего..." видимо необходимо расшифровать. Решение уже было принято до меня, а я лишь был назначен на это место, чтобы данное решение грамотно воплотить в жизнь. Это не первый опыт, когда меня нанимали для того чтобы драйвить команду переходить на Native
Руковожу в общей сложности с 2013, когда твой отдел достигает 25 людей, то ваще не до признания, и честно говоря, не помню чтобы возникало желание засветиться еще до внедрения, после внедрения и получения профита было дело, хочется делиться своими наработками, скоро про это напишу, кстати. Если бы следующее предложение прочитали после первого, то получили внятный ответ о моем участии в выборе стеков, так то надо мной руководитель тоже есть.
Наконец-то тайна почему в Озоне ушел флаттер - теперь раскрыта. Спасибо за статью)
Вот эти все качели: "А давайте всё перепишем на Flutter", "А давайте всё вернем обратно на натив" – вызывают подозрение, что анализа на предмет: "А нужен ли здесь Flutter?" не проводилось.
Google killed. Это можно сказать про любую технологию. Какая компания будет годами поддерживать и развивать продукт, который ей больше не нужен?
Dart так себе язык. А с самого начала не видно было, какой это язык? Тем более, что раньше он был хуже – все-таки он достаточно активно развивается. Ну и замечание про "экс-бэкенд" не понял – он же как раз был представлен изначально, как "более лучший яваскрипт", при чем тут бэкенд?
Сообщество платформы. А сколько этих issue в других фреймворках?
Собственный UI. Ну так для каких-то проектов это наоборот преимущество. Опять же, это было известно с самого начала, или это "вдруг" выяснилось через полгода разработки?
Касательно комикса про ожидание от одного Flutter-разработчика. Так это никогда так не работает. Я писал про это 3 года назад:
So this equation:
2 Flutter guys = 2 Android guys + 2 iOS guysis totally wrong, but this one:
1 Flutter guy + 1 Android guy + 1 iOS guy = 2 Android guys + 2 iOS guyslooks more like a truth for me.
Практика показала, что где-то так оно и есть.
Мне показалось, что все описанные проблемы Флаттера зауши притянуты
А я наоборот полностью с автором статьи согласен - тоже пробовали флаттер в одно время, и все хорошо, но только до тех пор, пока ты не не отклоняешься от рамок фреймворка ни на шаг - как только тебе нужно какие-то более хардварные фишки (та-же камера) - сразу становится очень больно.
И остальные описанные проблемы тоже имеют место быть и сильно замедляют разработку - будь то сырые фреймворки или необходимость писать два раздельных ui если хочешь выглядить хотя-бы более менее нативно.
Но в те времена когда мы пытались - самая большая проблема была в межслойных багах - когда делаешь что-то несколько нестанадртное и получаешь неопределенное поведение, которое непонятно на какой стороне неопределенное - сломался флаттер, платформа, их взаимодействие друг с другом или код который ты написал неправильный - и если он неправильный то почему (взаимодействие native -> flatter -> native может быть крайне неочевидным)
сейчас с камерой на flutter все хорошо, довольно стабильно работает, плюс дописали плагины для web и windows (пр на днях вмержится в мастер) для использования web-камер
Верю, но кажется что flutter как и например web в мобилках пока находится в ситуации вечно отстающего, и эта пробелма, которую можно решить только сделав его нативом для платформы.
В нативе постоянно появляются новые фишки и api, поддержка формфакторов девайсов. Зачастую они дают какие-то конкурентные преимущества (та-же camera2api которая позволяет получать лучше обрабатывать снимки и проще их получать), их имеет смысл сразу внеднять в приложение (но не во все конечно, есть те в которые вообще ничего не надо никогда), а в флаттере/web эта штука появляется с большим опозданием (коробочное решение уровня api которое можно использовать без влезания в натив), и это может сделать приложение неконкурентным с нативом.
Пуши, геолокация, камера - это сейчас все и в веб приложении провернуть можно, но оно появилось в поддержке в вебе сильно позже чем в нативе на мобилках, и как итог - те кому нужны были стабильные пуши - сделали приложение.
С другой стороны те, кому не нужны эти фишки, вообще могут не делать приложение а обойтись мобильной веб версией.
Получается флаттер перспективно выглдяит если на нем делать веб + ios + android (с windows 11 в подарок) например - скорее как альтернатива мобильной веб версии с плюсами приложения, чем как замена нативных приложений.
А вот с камерой поясните..Почему вы не используете ТСД (Терминалы сбора данных)...Специально обученное устройство для складов ,чтения (мгновенного) QR кодов различного типа и штрих кодов различного типа...Это устройство в котором есть сканер штрихкодов(с аппаратным декодированием ) и специальная камера с SDK для декодирования этикеты как у Вас на фото(Типа отделить тект от цены от штрихкода)...(Отказ от ТСД ведь не из-за экономии?) В этом случае всё делаеться нативным sdk производителя,а вам отправляется broadcust ,который легко плагином отлавить во flutter.И если чтение штрихкода (разбор этикетки)является камнем преткновения,то в этом случае(ТСД) и проблемы то нет.
Возможно вы и правы, ТСД, которые мы кстати использем для Web версии пунков выдачи заказов, стоит адаптировать и под мобилки, уверен мы еще вернемся к этой теме, могу только сказать что мобильный телефон удобен как раз своей мобильностью, а приделывать к нему еще и сканер, да еще который может привести к потери автономности мобилки - все это уменьшит преимущества, ну мы просто спрашивали наших сотрудников, которые пользуются приложением. Тем не менее спасибо за идею, возможно сотрудники ПВЗ изменят свое мнение и мы вернемся к теме ТСД.
Что характерно, одно время ваши сотрудники всё-таки пользовались сканером, потом перешли на мобилки.
Я бы не сказал, что все перешли прям целиком со сканеров, на данный момент мобилками чаще пользуются как бекапом, то есть свет вырубили или вайфай сдох - тогда достают телефон. Одной из главных задач у нас сейчас повысить качество приложения чтобы им чаще пользовались.
Сканером пользуются, т.к. функционала в самом веб-приложении существенно больше
Пикнуть сканером посылку - все равно удобнее и быстрее, особенно когда их проходит 200-300 штук, а надо за час все обработать.
Как Сергей написал выше, приложение самый незаменимый вариант, если вдруг отключился свет или основная линия интернета упала. Приемка и выдача идут без перебоев
А варианты мобмльных терминалов не рассматривали?
как пример:
https://www.zebra.com/us/en/products/mobile-computers/handheld.html
да и на али тоже много разных, и весьма продвинутых
хотя и зебра не так уж и дорогая, в рамках средних мобил
заодно и куар коды считывает от ковида :) )
Можно использовать специализированный промышленный/корпоративный браузер и получить одинаковую по функционалу с точки зрения веб страниц платформу и на ТСД и на обычных мобилках.
Веб клиенты обычно гибче и универсальнее, особенно там где не нужны свистелки и тп (что нужно для b2c)
фейсайди, пушнотификации, фоновые вычисления, кеширование состояния приложения это неполный список фич нашего ПВЗ и даже свистелка есть, в общем не так легко затащить через Web. А так согласен, для приложения аля стартап бери и пиши на чем хочешь
Для гибридных решений конечно надо писать екстеншены (если их еще не написали) для требуемого функционала. В качестве саморекламы могу обратить внимание на полностью бесплатное с открытым исходным кодом гибридное решение https://github.com/rhomobile/rhodes
Подробнее - https://files.tau-platform.com/Tau_Rhodes.pdf
Поддерживаем отечественные ОС, включая Аврору.
Возможно, забыли упомянуть аргумент против Flutter, что он отнимает рабочие места у native разработчиков, которые много лет инвестировали в native платформы.
В наше время ли говорить о недостатке рабочих мест, когда на одного соискателя сотня вакансий).
отнимает рабочие места у native разработчиков, которые много лет инвестировали в native платформы
Ну-да, ну-да, это все заговор злых нативных разработчиков, а вовсе не корявоватый фреймворк, в котором для полноценной разработки все равно нужны эти проклятые нативные разработчики :)
Разумеется, это нарочито слабый аргумент и его задача лишь подчеркнуть слабость и притянутость аргументов из статьи.
А, а я дурак старый, не разглядел. Прошу прощения за ерничание.
В свою защиту могу сказать только то, что такой аргумент я действительно встречал на просторах интернета...
Хотя, если честно, пункты 4 и 5 вполне себе важны. Переизобретенный UI вполне себе может отталкивать пользователя (сам столкнулся со странным скроллингом в Jetpack Compose). Ну а разрабатывать, когда у тебя постоянно что-то отваливается - удовольствия мало, так что пункт 5 тоже вполне себе верен.
Странная статья, и странные намёки на KMM. Kotlin тоже так себе язык, и Java до сих пор вполне себе жива, да и со звездами на github не очень против Flutter например.
к тому же уже можно писать приличную кросс-платформу на JavaFX
Тем не менее, судя по результатам опроса в конце статьи, большинство согласно с автором, и большинство считают Kotlin лучшим языком.
Ну да, 23% vs 20% - это убедительная победа Kotlin :-) Учитывая число открытых Flutter багов на github, KMM ждёт впереди долгий и трудный путь, и не факт что JetBrain сможет его осилить.
Ну так и джаве сколько лет по сравнению с котлин, а котлин, хоть и моложе, но уже где-то опережает джаву. Меня самого долго ломало переходить на котлин, я считал этот язык каким-то несерьезным что ли. Но когда перешел, на джаву без боли смотреть не могу, хотя считаю, что она наконец поднажала и старается догнать котлин в удобстве и новом функционале. Я может быть когда-нибудь и вернусь на джаву, ибо котлин, в стремлении закрыть недостатки джавы, их закрыл, но при этом добавил свои недостатки и костыли. Но при этом взросление котлина, я считаю, пока более динамичное, и недостатки и баги исправляются быстрее.
Вообще-то Java8 and Java17 не одно и тоже - на какую после Kotlin "смотреть не могу" ? А на Dart после Kotlin как смотрится?
Я расматриваю эти два языка вне версий, так как от версии к версии в них меняется не сильно. Хотя в джаве конечно больше функционала завозят в последние годы, то что в котлине завезли с самого начала. Тем не менее, я не думаю что в Java17 добавили/когда либо добавят то, что я люблю в котлине. Null safety, от которого я в самом начале работы с котлином просто плевался, а сейчас жить не могу. Optional очень слабый конкурент удоству null safety. Максимально удобная функциональщина, и то, как это сделано в джаве - у меня просто кровь из глаз. Функции расширения и многое другое.
На dart я пока никак не смотрю, я бекенд разработчик. Но в планах есть пойтив мобильные разработчики, но я любо перейду на нейтив-андроид, либо на KMM, потому как мысли, выраженные автором я читал много где. Ну и поэтому я думаю, что Flutter я все же пропущу.
Напрасно,попробуй Flutter - он простой, плюс внятная документация. И null safety в Dart есть.
И правда интересно было посмотреть результаты опроса. Наверное, каждый голосовал за свой язык, на котором он пишет, плюс еще те, кто работал с несколькими. Поэтому, может быть, опрос показывает сколько зашло в опрос Swift / Dart / Kotlin разработчиков)
Но все равно интересно посмотреть распределение
Из-за «Native» вместо «натив» в заголовке подумал, что вы перешли на React Native в итоге, а не на нативщину
Для конкретной задачи - объяснено, но не исчерпывающе. Есть ли в двух версиях, для iOS для Андроид, общий код, пресловутая "бизнес логика"? Если нет и всё приложение в основном интерфейс и специфика платформ, подозрительно прозвучала камера, тогда вопрос только в том, что перевешивает - специфика платформ или готовность пользователей, а кто сотрудников то спрашивал, терпеть странноватый интерфейс. Если, типа, перевесило нежелание подгонять камеру под Флаттер, то не изволит ли автор сиё подтвердить?
Если есть, то неужели её пишут дважды? Или трижды ибо бэкенд. Может быть на Котлин, раз уж КММ так воспета? Не будет ли у автора, не достигая границ нарушения корпоративной этики путём разглашения ноу-хау разумеется, возможности уточнить?
Как КММ потеснит Флаттер я не понял. На сейчас тенденция - сливаться в экстазе. Мак с iPad, Андроид с Windows. Флаттер практически достиг полной кросс-платформенности, Эппл + Гугол + Микрософт + Интернет, а Kotlin Native пока (всё ещё) в альфе. И за оставшиеся пол года до WWDC и сопутствующего ему указания каждому его места - из неё не выйдет. Отсюда и КММ - то самое Мобайл актуальность которого уходит в прошлое.
Соответственно, Гугол пока не может убить Флаттер поскольку тогда полностью кросс-платформенное противостояние с Эппл, которое будет по любому, окажется без его участия и вне его контроля. Микрософт ведь тоже шевелится...
вижу кажется 2 вопроса:
- Почему вас только камера беспокоит, там по тексту много разных компонент и инфраструктурных вопросов поднималось, не хочется перестраивать процессы по автотестам ни библиотеки аналитики через плагин тащить, ни гайды дизайнеров расшаренные на натив, не хочется при редизайне заного рисовать компоненты визуальные, которые шарятся по командам на натив.
- Бизнеслогика есть во всех приложения, много ли, мало ли ее - в этом вся разница. На мой взгляд ее не достаточно в нашем приложении для того чтобы скрещивать Native и еще что то, ну например KMM. Бизнеслогику можно вынести на сторону сервисов. Если тащить все таки в клиенты, то получим франкинштейн, до такой необходимости и неизбежности опять же недотягиваем
Кажется что это рациональное обоснование эмоционального выбора.
На go же все пишут и не парятся про то что гугл убъет проект. Кажется что на Flutter слишком сильная ставка для того чтобы его убить.
Dart да - так себе. Зато хот релоад хорош. Хотя мне после TypeScript / React Native эстетически не заходит.
Kotlin разрабатывается JetBrains, и пытаются с JetPack Compose догнать Flutter. Но точно также может быть разорван контракт с JetBrains
Если для камеры нужно писать нативный код, зачем весь остальной делать нативным. Можно написать свой плагин просто.
По поводу опережения графика - а народу то в сумме больше или меньше фигачит?
Ну то есть с точки зрения трат мне кажется выбор странноватым. Вот клиентское приложение точно должно быть нативным, тут вопросов нет.
Я бы сказал что это было рациональное обоснование того выбора, который был сделан в пользу Flutter в самом начале, ведь он более чем оправдан. Сейчас это уже не обоснование, а констатация фактов пройденого опыта, эксперемент завершен, проект продолжается с новыми силами.
Про плагин камеры согласен, еслиб это была одна проблема и было в компании куча энтузиастов ее решить никто бы не парился, и учитывая что плагинов пришлось бы еще немало написать, тут я планы не могу рассекречивать, но они правда есть, смысл во Flutter потеряется бы довольно быстро
народу стало меньше, я не стал этим козырять ибо сравнивать с Flutter проектом некорректно, он шел не по роудмапу, а по иттерационным изменениям, нам проще так как знаем точку, в которую должны придти.
Я бы сказал что выбор не странноватый, а спорный. Мне тоже показалось так, пока все не взвесили и со стороны бизнеса тоже.
Просто чтобы подытожить:
- автор стал руководителем какого-то отдела не ознакомившись с технологией, которая используется на проекте
- автор решил просто отказаться от годовых наработок, потому-что ему так удобнее
- бизнесу это встанет в ушедших сотрудников (кто после флаттера станет писать на нативе ? Никто)
- бизнесу это встанет в ожидание разработки нативных приложений
- бизнесу это встанет в просранный HR- бренд, потому-что когда отдел разработки переводят на другие технологии насильно, это очень быстро расходится и вызывает негативные оценки компании
Либо руководство озона крайне наплевательски относятся к инструментам, которые обеспечивают из базовую деятельность, либо какая-то внутренняя политика пошла по известному месту.
Выше в коментариях я расшифровывал смысл строк "стал невольным сместителем", это означает, что решение было принято до того как автор стал руководителем, и смысл автору вникать в технологии, от которых в компания отказываются и без него? А вот причины разумеется изучены и изложены в этой статье, вы кстати ее читали?
Если бизнес уже согласился, значит ему это выгодно, я кажется упоминал в статье какую выгоду получит бизнес.
Довольно смело пишите за автора, готов взять секретарем)
Я как-раз кстати прочитал статью. И вы знаете, я не увидел ни одного пункта, в котором были бы описаны причины переходит на натив с точки зрения бизнеса кроме
"захотелось перейти от количественного к качественному: более нативного поведения и вообще, чтобы ставили только пять звёзд"
Это предложение смысловую нагрузку потеряло на вычитке редакторами.
Вы инженер и руководитель, вы в отличии от бизнеса, который почему-то решил перейти на удвоенную трату бюджета и замедление разработки, которое произойдет через полгода, должны понимать что делаете, разбираться в том, что именно нужно переписывать. Бизнесу глубоко неважно, какое поведение у приложения их работников, бизнесу важно, получить заказанную фичу в четкий срок с понятным бюджетом.
Я вообще крайне смелый человек, особенно, когда вижу очевидно ошибочные решения. 90k$/y и поехали
Думаю, картинка с сарказмом "Imagine a world where you write code once" не совсем уместна, тот же Java, который стал языком разработки Android, шёл под лозунгом "Write once, run everywhere", не знаю, шутили ли по этому поводу 20 лет назад.
Привет коллега! Абсолютно с тобой согласен, мой опыт сгенерировал аналогичную статью с анаогичными выводами только на vc )
Нативщик переписывает с кросплатформы на натив. Сначала с RN потом с Flutter. Похоже на то, что кто-то переливает чай из казенной чашки в ту, которую из дома принес, с любимыми цветочками. Мне тоже флаттер не оч, но чет веских причин 'все переписать нах' в описанном кейсе я особо не увидел.
Я, делающий на Ionic + Capacitor + Angular, be like:
Для меня Flutter был как глоток свежего воздуха. Без него я бы никогда не выпустил версию своего приложения под iOS. Я столько замучался с этими хакинтошами - это просто жесть.
С флутером можно разрабатывать вообще без эмуляторов - компилим виндус версию и запускаем. Хот-релоад неплохо работает.
Получилось обойтись без нативного кода совсем, работает быстро. Разрабатывать на удивление легко (особенно по сравнению с iOS).
Значит дарт - плохой, а swift-образец удобства? С чего вы решили, что разработчики предпочтут Swift?
В вашем случае выбор оправдан, запуск стартапа, ограниченный бюджет, ничего лучше кроме Flutter не придумаешь и об этом я тоже писал.
Swift как язык не образец, но тем не менее я его выбрал, например, для своих стартапов чтобы писать Backend, в выборке были C# и Go еще. Первый слишком тормознутый, второй слишком замороченный, а Swift как-то балансирует, за 4 года не пожалел. Я вообще Swift евангелист. Что до Dart, признаюсь я на нем не писал, поэтому мне пришлось представить в статье мнение 5 коллег, никто из них не является настроенным против Flutter. Один из них кстати тоже выпустил приложение, как и вы на iOS, будучи Android native разработчиком. Первые его впечатления: блин круто, декларативный UI - это будущее, единственное язык древнючий какой-то ну и артефакты в графике
Вот когда удаётся обойтись совсем без нативного кода - все прекрасно в флаттере, но насколько я помню - карты, геолокацию, камеру и остальные хардварные фишки не применить
Google Killed
Так Android и Jetpack Compose, который упоминается в статье, тоже made by Google и по той же логике точно также могут быть закрыты. Можно, конечно, допустить, что неожиданно Flutter решат закрыть через какое-то время, но объективных причин для этого нет. Сам SDK развивается, количество вакансий и разработчиков растет, есть поддержка Fuchsia (если она когда-нибудь разовьётся во что-нибудь для мобилок).
Вот, например, давайте посмотрим на Dart: когда в него завезли null safety? Правильно, только весной 2021 года, а ведь это базовый механизм статической типизации.
Нет такого общепринятого понятия, как "базовый механизм статической типизации" для null safety. Просто в Kotlin/Swift это появилось уже после того, как вышел Dart. Да и сама фича достаточно сложная для добавления, потому что требует правки всей системы типов, миграции кода библиотек/приложений. Если сравнивать с Kotlin, то в итоге получилось даже лучше, потому что компилятор Dart может использовать информацию о типах и вырезать проверки на null в нативном коде, что повышает производительность и уменьшает размер сборки, а в Kotlin это все остается на границах публичных методов, потому что рантайм ничего не знает об этом. В Dart'e действительно нет многих фишек современных языков, но если смотреть не в моменте, а за период с релиза Flutter то развивается он достаточно бодро и разрабы прислушиваются к коммьюнити. Плюс у Dart'a тут есть возможность насобирать шишек за чужой счет и добавлять фичи более обдуманно. Да, конечно, хочется все и сразу, но развитие есть.
Конечно, прекрасно, что Flutter можно посмотреть в исходниках, как и увидеть, сколько issues сейчас открыто в официальном репозитории: их количество только растёт — это говорит о том, что команда пока не справляется с потоком ошибок. Например, только совсем недавно сделали, чтобы анимации не тормозили на iOS ¯_(ツ)_/¯
Количество isssues не равно количеству ошибок, потому что это могут быть фича реквесты, вопросы по использованию SDK, инфраструктурные проблемы, ошибки в desktop платформах (которые еще не в релизе), да и вообще что угодно. Количество тасок скорее говорит о том, что само сообщество вокруг Flutter большое и растет.
По поводу проблем с анимациями на iOS: такая проблема действительно была, но по статье не понятно, аффектило ли это вас или это просто пример. Когда мы выпускали приложение (которое уже было в сторе на Android) на iOS то таких проблем не было.
Собственный UI, характерный для обеих мобильных платформ
Поведение на разных платформах можно кастомизировать, часть из этого работает уже по умолчанию. В примерах есть приложение, которое на разных платформах выглядит нативно при этом максимально переиспользует общие части. Могут быть и другие варианты как это решить, все зависит от дизайна и требований. Тут действительно можно упрекнуть Flutter в том, что он не может как-то автоматически менять UI на разных платформах, чтобы приложение выглядело нативно, но UI паттерны могут отличаться слишком сильно.
В целом доводы в статье субъективные и эмоциональные, а при таком серьезом решении о миграции всего приложения на другой стек, выглядит как раз необдуманно, но, с другой стороны, дает понимание о подходах в компании к таким вопросам.
Объективные доводы это и есть численные метрики, растет число вакансий и на нетиве пропорционально Flutter, я точно так же могу перевернуть в свою сторону объективные метрики объяснив все с другой стороны, как вы делаете со статистикой issues. Закроют или нет Flutter вам никто не скажет, но есть риск. Есть исторические факты, например аналогия с ReactNative или закрытие гуглпроектов. История как мы знаем повторяется, не исключено что Flutter разовьется и KMM его не опередит, в будущем возможно все что угодно, но есть тренд. Я о нем рассказал, если он вас напугал, то это не значит, что статья эмоциональная и в Озоне сидят дураки которые боятся что Flutter придется поддерживать самим, просто этот риск нам не нужен, у нас есть большое комьюнити нативных разработчиков и лучше в него вкладываться, чем вкладываться в рисковые технологии превращая проект в монстра. Jetpack Compose имеет меньше рисков на мой взгляд, потому что есть в компании опыт и практика его использования, она более позитивная, но я сейчас не буду расписывать их, статья не об этом
какой то внук Ванги, КММ сдвинет флаттер, гугл может убить флаттер, чувак бегает по проектам и все что делает везде переписывает все на натив, статья херня галимая, натив головного мозга
Автор так критикует синтаксис Java, как будто пользовался ей лет 10 назад.
Ок, пусть даже современная джава немного более громоздкая, но на дворе 2022 и никто не запрещает юзать IDE для автодополнения и быстрой генерации типичных конструкций.
Вы угадали, я пользовался ей в последний раз в 2006, на мой вгляд тогда в нее внесли значительные улучшения. Периодически меня удивляли и оптимизации компиляторов и nullsafe, но я не критикую его синтаксис, это был собирательный образ от пользователей Dart) Простите, если задел) мне в Java очень нравится система коллекций, очень продуманная.
она даже с lombok громоздкая в сравнении с Kotlin
Кроме того, было принято решение использовать единую архитектуру в мобильном приложении для обеих платформ, делать перекрёстное и межплатформенное ревью, чтобы идти в одном направлении.
Можно где то подробнее прочитать про единую архитектуру приложений? Есть статьи какие-то или доклады?
На старте проекта серчил в основном зарубежные статьи, и даже на английском не смог найти. Зато известна практика, когда MVVM + Rx + Clean architecture на проект с iOS и Android затаскивают (статьи отдельно под платформы вы легко найдете) и примерно одинаково развивают под бдением архитектора оби платформы. Так что вы мне подали отличную идею написать такую статью на стыке двух платформ в будущем. Спасибо за идею.
Писать статьи не очень просто, а комменатриев тут очень много и большая часть с критикой. Понимаю, что есть вероятность, что автор мог не донести мысль из-за чего его аргументы могли быть не в лучшем свете. Но я, все же, думаю, за статьей есть большой смысл и буду ждать новую статью с более подробным разбором, чтобы она могла обьяснить каждому причины отказа от технологии
А вы под Native что имеете в виду? Kotlin Native, или просто разработку под андроид на Kotlin/Java?
Вся аргументация притянута "за уши". SwiftUI и Jetpack Compose тоже что и Flutter. Это серьезно?
Что Kotlin Multiplatform потенциальный могильщик Flutter? Развитие этой мысли можно продолжить как использовать Kotlin Multiplatform для UI? Серьёзно? Автор извини. Это шутка. Я уверен, что ты знаешь что такое Kotlin Multiplatform.
Dart - непривычный язык после перехода с Kotlin или Swift. Но Dart - не ущемляет в свободе. Да, Kotlin более удобный. Ну нужно точки с запятой в конце оператора ставитьв Dart. Привыкать "обратно" - трудно :) Но что у Kotlin или Swift колоссальный отрыв от Dart - не соглашусь. Всё, что я делал на Kotlin или Swift, я смог делать и на Dart особо не напрягаясь. И скажу, что конструкции у Dart проще и не менее эффективные. Но не такие "сахарные" как у Kotlin.
Собственный рендеринг UI во Flutter в каких местах может озадачить пользователя вашего приложения? Автор точно в курсе, что у Flutter есть контролы Cupertino (iOS-style) и Material Design. Возможности по созданию сложных экранов по UI - впечатляют. Не нашел ни одного ограничения, которые невозможно реализовать в UI на Fluetter (имею опыт разработки и для iOS, и для Android нативным способом). Во Flutter разработчики получают гораздо большую свободу в UI (моё мнение). И как ни странно интерфейс очень часто более отзывчивый и более эффективный.
Можно сделать вывод, что набор причин ниже не являются основными для обоснования "погребения" Flutter :
проблемы со сканером кодов (исправлено, есть стабильное решение уже даже версии 2.0.0, и это не какая-то версия 0.xxx)
проблемы с анимацией на iOS (исправлено)
Google имеет привычку убивать свои перспективные проекты (спасибо Google за наличие такой аргументации)
Зная что в компаниях с нативной разработкой (раньше и в Озон так было, знаю по OzonTravel) по 3 - 4 разработчика на платформу (итого 6 - 8, а на Flutter обычно в два раза меньше, то как нынешний руководитель "убедил" менеджеров Озон вернуться к нативной форме команды разработки, увеличивая бюджет на команду и количество разработчиков, приведя вот такие аргументации как выше? Не странно, что эти самые менеджеры приходили с вопросов «Ну а всё же почему?»
Как кто-то выше написал, причины были другие и не технологические. Менеджеров очень часто вводят в заблуждение подобной аргументацией, преследуя какие-то свои цели, "ведущий-разрабочик-техлид-руководитель разработки". Компания тратит бюджеты на эксперименты таких руководителей "туда" и потом "обратно".
Ни один из аргументов, что Flutter хуже нативной разработки, в данной статье меня не убедил. Мне есть с чем сравнивать. Автору скорее всего просто хочется вернуться в нативную разработку iOS :)
Удачи компании Озон. Компания хорошая :). Постоянно пользуюсь услугами этой компании. Надеюсь, что такие эксперименты не отразятся на качестве программ этой компании. Хотя конкретно описанная здесь программа - это мобильная программа для внутреннего использования работниками Озон на пунктах выдачи. Так что вроде всё хорошо.
Менеджмент из бизнеса не интерисуются такими ньюансами, которые изложены в статье, эти ньюансы скорее интересны вам как разработчику и прожект менеджеру максимум, чтобы не допустить элементарную ошибку в расчетах, которую вы допустили:
"3 - 4 разработчика на платформу (итого 6 - 8, а на Flutter обычно в два раза меньше)", почитайте комментарии, даже те кто зачем-то рьяно защищают Flutter (будто я на него напал) не считают что 2 нативных разработчика = 1 Flutter разработчику. Это все рано, что полагать, что 9 женщин родят ребенка за месяц.
На данном этапе развития KMM естественно не могильщик, я предположил что его развитие в перспективе может просто потеснить сильно Flutter, как это было с другими эффектными мультиплатформами в прошлом. Compose сделают и будет вам UI на KMM, сделали же для Андройда, у нас зашло, рекомендую кстати вам как человеку, который и в нативной разработке могет.
Вернусь к бизнесу, так вот бизнес смотрит на фундаментальные показатели: сроки (ага нтивка тянет быстрее, значит пока флатеристы баги правит в чужих компонентах эти преуспеют, надо скорее пересаживаться на рельсы), качество (не надо думать что свои сотрудники стерпят любое качество приложения, мы вообще то следим за отзывами и ходим в ПВЗ сами, интересуемся что сотрудников не устраивает). И еще есть фундаментальные показатели глобальные, а они говорят за тренд сменяемости, потому что любой мультеплатформе надо поспевать и обогнать конкурентов и поспевать за изменениями в нескольких платформах - такая нагрузка рано или поздно станент отказонеустойчивой. Вы серьезно думаете что один Dart c Flutter хотябы нагонит всех-всех?
Никто не спорит, что в части проектов, уменьшение двух нативных команд в одну, по формуле "станет" = "было" * 0.5 не работает. Не развиваю вашу тему про "9 женщин и 1 месяц".
Прочитав Ваш пост у многих первое впечатление складывается такое: причина, по которой ваша команда возвращается к "нативной" схеме, в том что, flutter + dart - негодная и незрелая технология, которую вот-вот Google "закроет". Не развиваю эту мысль. Обсудили. Конкретно вашей команде flutter + dart не подошел. Кстати, Google(Аlphabet) недавное рассылал отчет по динамике роста программ на flutter в их магазине. Быстро не нашел этот отчёт. Цифры не вспомню, но взрывной рост качественных и надежных приложений на Flutter, официально опубликованных в магазине.
Про менеджеров. Не секрет, что "главный" разработчик иногда просто навязывает менеджеру, принимающему решение, выгодное ему в каком-то контексте решение. Например. Есть в организации определенная "инфрастуктура" CI / CD с конкретными требованиями по использованию конкретных средств тестирования. Ну очень тяжело втиснуть(настроить, отладить, запустить) новую платформу в эти требования. Баг за багом при настройке. Но не в самой сутевой программе. Время уходит. "Паралельные"команды обгоняют. Или. Есть в организации конкретные требования по использованию довольно конкретных "движков" аналитики, и в этом списке есть и довольно специфические. И очень тяжело какие-то аналитические движки подружить с новой платформой. Вписаться под эти требования с новой платформой типа "flutter + dart" ну очень тяжело. Тестирование ломается, аналитика не собирает нужные данные, общие показатели падают, "главного" разработчика начинают менеджеры ругать. Какой план выстраивается в голове "главного" разработчика, которого ругают? Правильно, предложить вернуться к проверенной и надежной схеме. Тем более есть соответсвующая аргументация в виде SwiftUI + jetpack compose, где тонкие нюансы менеджеру неизвестны. Это не Ваш случай? Если так, то в этом случае "flutter + dart" - не виноваты.
У меня сложилось впечатление, что ваша команда закончила эксперименты с flutter еще год назад и свежие стабильные версии просто не смотрела. А Вы по информации годичной давности написали вот этот пост :)
Были проблемы со "сканером штрихкодов", "анимацией на iOS" и системой хранения на hive. Что-то ещё можете добавить? И любопытно, что не так пошло с web-версией. Просто для объективности картины.
Я согласен про инфраструктуру полностью, она немного утяжеляет нововведения. Когда в компании были борцы за Flutter, естественно они и инфраструктуру пытались модернизировать и успешно частично. И Веб затащить пытались, но я не знаю по какой причине не вышло у них изначально, не могу прокомментировать. Так что от части это наш случай - не стало борцов с целой системой, не стало и Flutter - но только от части, это один из 5-и пунктов, и он так же есть в статье.
>>Правильно, предложить вернуться к проверенной и надежной схеме.
Не вернуться, приложение изначально было на Flutter, это дало старт и быстрое развитие со своими нюансами. Вы правы, про "наш опыт" до конца не донесено видимо, это видно и по другим коментам, другие тоже думают что мы туда сюда переписываем, пожалуй стоит немного подправить статью.
>>Были проблемы со "сканером штрихкодов", "анимацией на iOS" и системой хранения на hive. Что-то ещё можете добавить?
Это все что я по опросам смог выудить по проекту ПВЗ, по опыту других товарищей (из стартапов) могу еще добавить "Странный рендеринг на iOS", когда пиксели вдруг лезут, ну то есть картинка становилась мутненькой, может сами разработчики накосячили где, я не стал это приводить в статье, но подозреваю, что "свой рендеринг" это тоже не гуд вообще, это как я писал - надо постоянно оптимизировать движек и поспевать еще и за Apple кроме своих проблем с Android.
Проблемы с рендерингом и его поддержкой высосаны из пальца. Flutter просто имеет свой движок рендеринга + набор UI под android/ios нативные компоненты. Не вижу проблем особых с поддержкой этих наборов, т.к. он почти не меняется (ну вот скажите, что такого особо важного нового появилось в нативных компонентах за последний год-два?), а при необходимости очень легко кастомизируется.
Сканер штрихкодов. Что, правда в компании размера Ozon не найти на аутсорс двух нативщиков на неделю, чтобы они написали плагин нативный по работе с камерой, чтобы потом использовать его из Dart?
К Hive вообще много вопросов -- почему именно эту БД выбрали для проектов. Есть более качественные решения и более быстрые.
Ну вот насчет SDK для аналитики, возможно, есть нюансы, но все равно что-то слабо верится, что написать обертку над нативкой -- это такое сложное занятие. У меня был опыт, при том, что в нативке я почти не работаю, делал по слабым воспоминаниям о котлине и мануалам по свифту.
Фактически все эти обертки - это просто прокидывание вызовов к нативному коду. В чем здесь могут быть проблемы - не представляю и с такими проблемами не встречался.
Сейчас, например, делаю кросплатформенный ВПН (десктоп + мобилка). Вот сидим и пишем плагины для работы с нативным платформенным API. Один раз написали и забыли, дальше все чисто на Flutter. Понятно, что есть какие-то баги, но они минимальные, потому что у всех этих плагинов как правило очень простая логика работы -- они 1 к 1 мапят системные вызовы.
Ваш кейс вообще выглядит как очень простое приложение на Flutter. Я бы в 10 из 10 случаев рекомендовал писать его на Flutter и не обращать внимание на аргументы из разряда "мне не нравится Dart" и "Google убьет Flutter" (почему воообще, лол) пропускать мимо ушей.
Вы видимо не часто пишите движки рендеринга на эпловские продукты, раз не видите проблем в рендеринге для такой компании как Google. Может тогда Google в легкую напишет альтернативу iOS? И Apple с этим ничего не будет делать?
Зачем увеличивать штат еще больше у нас полно нативщиков так то, зачем вкладывать в технологии, которые не привели команду к успеху?, чтобы что? Я просто не понимаю, вам нравится Дарт и вы хотите чтоб Озон тоже на Дарте писал? Ну да, у нас зрелая компания которая мониторит рынок, смотрит скорость разработки продукта и знает во что вкладывать, а во что нет. Наш выбор вам кажется необоснованным, наверное у вас другая компания аля стартапа (я писал об этом), полно разработчиков Flutter, которые лезут в форточку готовы получать меньше нативщиков и задачи не требуют написания кучи плагинов и потом их еще поддерживать, нативный мир то тоже не стоит на месте
Честно говоря, после прочтения, я так и не понял почему решили перейти на Native :(
А вы бизнесмен? Разработчик? Чтобы понимать на каком языке обьяснить было проще.
Странно, при попытки диалога и попытке обьяснить другими словами вас минусуют, это шутка? может вы хотябы прокоментируете свою реакцию? смайликом или еще как
Не, я не минусовал, не стебусь и не издеваюсь. На самом деле я на основной работе Android разработчик, а на Flutter пару домашних поделок запустил. Просто вы перечислили минусы и плюсы Flutter и Native, но так толком и не пояснили, почему сделали переход. Написали что хотите использовать нативную реализацию работы с камерой - так вы можете так и так написать нативную реализацию и подключить как плагин к текущему решению на Flutter. Я надеялся найти какие-то резюмирующие выводы/строки. Что-то в духе (как я понял) "в итоге, из-за жалоб, что приложение глючное решили переписать на нативный, надеясь что глюков в полностью нативной разработке будет меньше, чем в гибридной Flutter-Native варианте". Я не стебусь и возможно я сделал неправильные выводы из статьи, но это потому, что не увидел ваших выводов в статье.
А был еще третий вариант - делать PR во Flutter. И себе помогли бы, и другим людям тоже. Хотя переписывать всегда проще, да.
Я всегда за развитие OpenSource и за то чтобы разработчики развивали комьюнити разных технологий. Но мне кажется это непосильная ноша для компании, которая к тому же избрала другой курс. Если бы мы нашли достаточное количество лидов под Flutter, то возможно так бы и вышло, но получилось все как раз наоборот. К тому же обрачу ваше внимание, что есть крупные компании как Google и Apple, которые создали операционные системы и развивает их постоянно. И есть Flutter, который должен постоянно нагонять 2-х гигантов, представляете сколько туда средств требуется вложить?
Читаю такие issues и уже вижу как Kotlin Multiplatform убивает React Native и Flutter. Мало того, что он предназначен для совсем других целей (только шеринг бизнес логики), так ещё и в своём амплуа проблем хватает. Если оно массово не зайдет комьюнити (чего пока не происходит), то активно переписывать существующие библиотеки с JVM зависимостями под него не будут и даже какой-нибудь gomobile сейчас выглядит предпочтительнее.
Распространение языков очень интересное, если смотреть ту же статистику сравнения Dart и Kotlin по странам, то создается впечатление что у KMM и Flutter не только разные цели но и разный контингент.
Боже мой, сколько защитников мультиплатформенных поделий в комментариях. Это точно Хабр?
И всё-таки кому нужен Flutter? ... Стартапы для прототипирования
Зависит от того, для кого делается прототип.
Если для инвесторов (мы после акселератора Яндекса в 2020 поговорили с ~50), то, как оказалось, многие хотят увидеть волшебную формулу CAC < 3 * LTV (стоимость привлечения клиента втрое меньше, чем мы на нём зарабатываем).
И часто бывает, что лучше выпустить прототип только на iOS, где Apple собрал «золотой миллиард» (20% людей, выпивающих 80% пива), чем «разбавлять» его Android'ом, где экономика гораздо хуже.
То есть вот просто реально, пока не дадут денег, не выпускать на Android, чтобы не ухудшать показатели.
Тоже об этом думал. Смотря какой прототип, иначе говоря, если прототип будет состоять из различных применения всевозможных аппаратных датчиков, камер, акселерометров и прочее, +это должно работать лучше чем у всех, то тут без нетива никак, ну а если документооборот то годно. Лично свои прототипы я тоже пишу на одной из платформ, для опробации достаточно будет, позже можно масштабировать на другие.
Дээ только много лет наблюдаешь как AS пожирает твой комп, а build time весь рабочий день и приятно офигиваешь от лёгкой vscode и flutter hot reload за 20ms... а что так можно было??
Давно искал статью почему натив лучше Флаттера, причины, обоснование. Пока не нашел..
Вопрос индивидуален, чем то лучше и Flutter в зависимости от проекта, я поэтому и привел сравнительную табличку с нативом, и привел область применения Flutter, где он сможет быть 100% полезyнее. Однако из реакции на статью я заключил, что к примеру банки пытаясь сэкономить и стараясь выглядить уникальными зачастую делают свои приложения на Flutter, которые тоже неплохо вписываются в общую тусовку.
После такой критики даже захотелось поработь с flutter
Примерно такой же опыт. Сейчас выгребаю этот ваш флаттер в натив. А еще сейчас требуется вменяемая поддержка айпад, со всякими там указывающими устройствами, жестами трекпада желательно, многооконностью и тд, а тут у флаттера швах опять же. Так, побаловались для MVP и хватит. Кстати, откуда берется эта установка про удвоение бюджета то, мне не очень понятно. Кстати, вменяемых разрабов на флаттере, что б не все в 3х инстансях лежало, тоже еще надо поискать. На нэйтиве многие вещи уже давно обкатаны и даже новичек может выдавать вполне себе работоспособный и поддерживаемый код.
Ага, особенно swiftui обкатан. Пробовал недавно, даже стандартный UI по примеру App Store только через танцы с бубном сделать можно (например иконку профиля напротив navigationTitle)
Отзывы разработчиков на реддите тоже почитать интересно: https://www.reddit.com/r/iOSProgramming/comments/ptw4t5/swift_ui_still_kind_of_sucks/
Я даже словом не обмолвился о SwiftUI. Речь идет о найтив разработке, а не об использовании технологии в стадии proof of concept. По существу есть что то возразить? Заранее прошу прощения что не разделяю вашей любви в флаттеру.
В SwiftUI встречается множество косяков, но в целом он намного приятнее для разработки и ревью кода, есть даже подозрение что верстка начиная на нем с iOS 14 меньше ресурсов тратит, чем AutoLayout и соответственно меньше тормозов. Когда вы выбираете что то отличное от MVC то на UIKit это выглядит костыльно, а здесь полная свобода и Combine помогает вам с реактивщиной даже. Если вам хочется крутых кастомизаций, то помогают backports, но чем дальше вы от iOS 13, тем их меньше будет.
Спасибо за ссылка, интересно всегда мнение со стороны узнать.
У семи нянек дитя без глаза. Осваиваем бюджеты. Самопальная оркестрация микросервисов. Теперь ещё это безобразие. Рука-лицо. А я же прикупил акции Ozon-а ))
Flutter vs Native: почему мы переходим с первого на второй