Анатолий Пешков

+21
с 2020

CTO в Mad Brains

0 подписчиков
31 подписка

Протестировал лично. Очень странное ощущение, иногда кажется что попал в фильм 28 дней спустя :) Даже не говоря о чекине, возможность заказать например завтрак в номер не пересекаясь с людьми (его доставляют в специальный отсек) создает интересное и немного магическое впечатление. Рекомендую опробовать

2

Ну и в качестве завершения, чтобы не разводить холивар. Я не отрицаю что KMP интересный инструмент и у него есть большие перспективы. Но причина по которой решил докопаться кроется в кликбейтном утверждении "Я тебя переиграл и уничтожил" - весомое заявление, подкрепленное только субъективными положительными аргументами, вес которых я попытался снизить сравнив их с альтернативой. Аргументация очень не объективна, что мешает воспринимать всерьез даже заявление "когда нужно сделать ставку на Kotlin Multiplatform" - не убедительно

0) Все равно звучит не убедительно про ограничения. По мне так наоборот свобода делать что хочется и как нужно. А вот в нативе как раз таки ограничений вагон и тележка. Стоит только вспомнить UISearchBar (прастихоспаде). А вот про единый интерфейс - вообще не правы, кто мешает их разделять и делать так как нужно на любой платформе (не только мобайл)? Да, будут условия в коде, но как по мне если бизнес требует - это сильно очевиднее и дешевле чем 2 отдельные кодовые базы для разных платформ
1) Да с RN все понятно, закапываем. Но аргумент с этой стороны что мол проще нанимать в корне не согласен. Хороших нативщиков днем с огнем искать, а уж тех кто желает в KMP тем более. Флаттер очень легок для входа, сами обучили уже достаточно много людей, в том числе через собственные курсы для начинающих. Опыт был и с нативными курсами, там все грустнее
2) ¯\_(ツ)_/¯
3) Понятное дело что отличия всегда можно найти. Но это не уровень RN или Cordova и тп. Для конечного пользователя разница будет не заметна в 99.99% А выгоды значительно больше. Про отдельные самописные компоненты у яндекса - думаю что на написание этих компонентов на нативе они потратили бы сильно больше времени. Тут возможность делать что-то не стандартное сразу на обе платформы сильно перевешивает условную "ненативность". по этому как по мне, аргумент слабоват
4) Ладно, может мне попадаются принципиальные iOS-еры ;)
Но вот с плавным переходом все таки не понял. То есть вы начинаете с выноса части логики в отдельные либы и подключаете их в существующий iOS проект? То есть вся бизнес-логика постепенно переезжает в набор (или одну большую) закрытую для iOS-ников библиотеку? Для однотипности подозреваю что и для андроида происходит что-то подобное. Звучит как сильное усложнение если вы это как-то скриптами не автоматизировали. Хотелось бы узнать подробнее как у вас это выглядит - пока звучит страшнова-то
5) Мои эксперименты с KMP все время упираются проблемы с версиями и совместимостью. Может что-то в последнее время поменялось, но было прям не приятно

0) Трижды были упомянуты "ограничения" про Flutter интерфейсы, например "мириться с ограничениями по дизайну". О каких ограничениях идет речь? В моем понимании ограничения это не возможность что-то сделать так как нужно. Будет интересно узнать что нельзя сделать на Flutter такого что будет выглядеть и работать так как задумано. Обратных примеров можно привести много, натив сильно ограничен стандартными компонентами

1) "Вы не хотите долго искать разработчиков" - тогда однозначно JS и React Native их уж точно больше чем нативщиков и с точки зрения работодателя выгоднее (в долгосрочной перспективе нет конечно - я тролю, все упрется в качество)

2) "Вам в приложении нужно использование блютуса" - именно этот кейс успешно прошли на Flutter, вообще проблем не возникло (для интересующихся скоро будет видео на ютуб канале Mad Brains)

3) "Вам важна нативность интерфейса" - у Яндекса на одной конфе даже был квиз-бот где нужно было угадывать натив это или Flutter. Пришлось учить скриншоты и перепроходить, так как это вообще не очевидно, если разработчик хочет сделать нативно на вид. Раньше был яркий признак - проблемный скролл, сейчас это пофиксили

4) "Вам важен плавный переход с нативного приложения" - вот тут пожалуй остановимся поподробнее. "Можно обучить iOS-разработчиков Kotlin" - ну допустим, заставим iOSников разбираться в перепетиях версионирования андроид компонентов, представим что они не взвоют от этого. "не нужно будет переписывать всё приложение с нуля" тут согласен. НО! "можно переписывать код по частям" - как вы собираете сборки под iOS на этапе когда проект лишь частично переписан. Я конечно понимаю что iOS нынче не в почете, но тут прям совсем грустно положеный болт на iOS-ников и iOS версию приложения.

P.S. 5) что там с версионированием компонентов и их совместимостью? Сколько времени тратится на обновление библиотек? У вас же серьезные бизнес приложения, они обычно долго живут и их нужно поддерживать, как с этим обстоят дела? ну и вопрос комьюнити в придачу (хоть и не сильно критично)

2

Понятие эксперта сильно широкое, лучше поясни что ты имеешь в виду.

Если ты программист, то как много задач за последний год требовало знаний выше "вот эту либу подключаем сюда, вот этот параметр сюда, JSON парсим вот так"? И при этом как много "экспертных" знаний языка не сводится к пониманию основных принципов работы систем и специфичных приколов конкретного ЯП, о которых знают только так называемые эксперты?

Я и не отрицал повсеместного распространения JS, это часть проблемы. Если все вокруг (как кажется) слушают русский рэп - это не делает его лучше в моих глазах

Сейчас бы в 2023 свою карьеру строить в зависимости от языка, вместо того чтобы относиться к языку как к инструменту, подходящему для определенных задач. Нет, давайте все на костыльном JS писать. Л - логика

Спасибо! Приятно слышать. Можем и для вашего бизнеса сделать что-то полезное, не только в мобилке

1

Все может быть, не могу такого отрицать. Но наша практика более 3-х лет показывает что пока есть только обратные примеры. Уже не один раз переписывали приложение с других технологий на Flutter: натив даже с якобы сложным для кросплатформы BLE, turbo framework, уход от прототипов на нативе и React Native - и это только то что мы делали, а запросов еще больше. Запросов на переписывание с flutter на натив пока не встречали