Анатолий Пешков
CTO в Mad Brains
Ну и в качестве завершения, чтобы не разводить холивар. Я не отрицаю что 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) что там с версионированием компонентов и их совместимостью? Сколько времени тратится на обновление библиотек? У вас же серьезные бизнес приложения, они обычно долго живут и их нужно поддерживать, как с этим обстоят дела? ну и вопрос комьюнити в придачу (хоть и не сильно критично)
Понятие эксперта сильно широкое, лучше поясни что ты имеешь в виду.
Если ты программист, то как много задач за последний год требовало знаний выше "вот эту либу подключаем сюда, вот этот параметр сюда, JSON парсим вот так"? И при этом как много "экспертных" знаний языка не сводится к пониманию основных принципов работы систем и специфичных приколов конкретного ЯП, о которых знают только так называемые эксперты?
Я и не отрицал повсеместного распространения JS, это часть проблемы. Если все вокруг (как кажется) слушают русский рэп - это не делает его лучше в моих глазах
Сейчас бы в 2023 свою карьеру строить в зависимости от языка, вместо того чтобы относиться к языку как к инструменту, подходящему для определенных задач. Нет, давайте все на костыльном JS писать. Л - логика
А где есть? :)
Спасибо! Приятно слышать. Можем и для вашего бизнеса сделать что-то полезное, не только в мобилке
Все может быть, не могу такого отрицать. Но наша практика более 3-х лет показывает что пока есть только обратные примеры. Уже не один раз переписывали приложение с других технологий на Flutter: натив даже с якобы сложным для кросплатформы BLE, turbo framework, уход от прототипов на нативе и React Native - и это только то что мы делали, а запросов еще больше. Запросов на переписывание с flutter на натив пока не встречали
Рекомендовать им с ним тоже обратиться к нам ;)
Можно обычной конечно же
ну уж в этом мы немного разбираемся ;) проблем не возникнет
Сам с такой ситуацией не сталкивался, но насколько знаю, должно быть можно возобновить подписку без проблем.
Об этом тоже думали, на всякий случай скачал репозитории, которые пока тоже в опенсорсе https://github.com/mattermost
Отвечу аналогией - Зачем использовать шуруповерт, если отвертка нормально справляется
В целом справляется со своей задачей. Понятное дело не идеально. Есть проблемы с тормозами, но даже на средних машинах не значительно. Долго подгружает сообщения при запуске, есть проблемы с пушами - все так. В остальном удобно, общение комфортное, сообщения не теряются, найти все без проблем можно. Плюсом гибкая настройка и интеграции по моему со всем чем можно
Думаю каждый кто этим занимается по своему отвечает на этот вопрос. Если ответа нет - точно не нужно
На вопрос "Почему не использовать <вставьте_название_очередного_мессенджера>?" ответил в самом начале статьи. Кратко - субъективный выбор подходящего инструмента
10$ в месяц за примерно тот же функцинал например (и это без всяких заморочек с хостингом и поддержкой) - было прекрасно. Да я не спорю что слак лучше, но не обязательно покупать золотой молоток там где и обычный справляется на ура
Я боюсь жить по такой логике и предпочитаю надеяться на лучшее в людях, иначе можно совсем расхотеть что-то делать
Да, конечно, чужой. Это прекрасно понимаем, у этого решения тоже есть и плюсы и минусы очевидно. Если сравнивать например со своим сервером в офисе, то там накладываются уже другие риски (пожар, наводнение, уборщица розетку дернула и тп прелести - я утрирую конечно, но идея понятная)
Да, все так. Верно меня упомянули. Скоро выпустим статью с подробностями в блоге https://vc.ru/u/529440-mad-brains, если кому интересно
Прям сейчас не ручаюсь. Все может быстро меняться. На момент написания статьи все работало, иной информации пока не видел
Спасибо за дополнение!
Не знал что опять начали звонить, удивлен
По картам, подозреваю что могут быть определенные рабочие варианты, но проверить их видимо только опытным путем получится, инфы не нашел. Вот теперь будем знать про Белоруские карты, спасибо
Да, такое возможно. И не факт что описанный мной метод вообще не прекратит работать хоть сегодня. В такое время живем к сожалению
Спасибо за дополнение, до такого момента не докопался. После "у нас в лимит засчитываются даже ошибочные транзакции" и "на лимит повлиять нельзя ждите 30 дней" от техподдержки билайна, как-то отпало желание дальше с ними разбираться
Такие правила у самого Apple, как всегда ничем не объясняются. Вывести средства - тоже никак. Тоже столкнулись с этим, тут подробнее описал https://vc.ru/dev/469158-kak-oplatit-rossiyskiy-akkaunt-apple-razrabotchika-v-2022-godu
Протестировал лично. Очень странное ощущение, иногда кажется что попал в фильм 28 дней спустя :) Даже не говоря о чекине, возможность заказать например завтрак в номер не пересекаясь с людьми (его доставляют в специальный отсек) создает интересное и немного магическое впечатление. Рекомендую опробовать