В том и дело, что в KMM(KMP) можно написать мультиплатформенный интерфейс, в наивном коде сделать его реализацию и подписаться под него, а потом, например, через DI прокинуть в KMM(KMP) модуль под этим интерфейсом. Т.Е тут не нужны никакие каналы, как это сделано во Flutter и тд, чтобы доставить нативную реализацию до мультиплатформенной части. Ко всему прочему, CMP позволяет обернуть любую нативную вьюху и вставить в мультиплатформенный UI. Я таким образом реализовывал видео плееры и полет нормальный
Да, самое главное, что заметит android разработчик при переходе на CMP - это то, что нету этих самых дропдаунов и тд. Для Android решается очень просто через expect/actual @Composable функцию, где для android можно подкинуть ту самую, что копировал выступающий из натива (т.е без копирования). Для iOS придется писать свою реализацию, или скопировать, как это было в примере на конференции
На Skia на CMP будут те же самые проблемы, что и в Flatter, когда он на Skia. Это связанно с устройство самой Skia, потому что там нету возможности компилировать шейдеры заранее, в лучшем случае прогревать их, как это делали на Flutter. Про переход CMP на impeller не знаю, думаю, что пока не выкатят beta, а потом stable, речи о переходе на другой движок не будет
Тем, что Android разработчики уже есть в команде и их не надо нанимать. Достаточно только внедрить технологию и настроить процессы, чем искать целый штат.
Если мы говорим про приложение с нуля, когда команды еще нет, то я тоже бы предпочел, чтобы мои коллеги были ближе к нативу, чем фронтендеры, которые решили переучиться в мультиплатформенную мобильную разработку. Последние неизвестно когда въедут, потому что платформенные нюансы будут сыпаться еще долго. К тому же у меня нет ответа на вопрос: "Зачем им это надо?"
Все зависит от задачи: если нас устраивает тот user experience, который дает Flutter, и у нас нет планов переходить на натив, то Flutter однозначный победитель. В таком случае нужна команда Flutter разработчиков.
Если же мы работаем над приложением, которое будет развиваться, и нас интересует нативное поведение UI, то мы однозначно выбираем KMM(KMP) + CMP. Потому что в таком случае мы получаем бонусы для iOS, которые я описал в статье просто потому, что android разработчик делает свою работу на нативном для себя фреймворке. У нас (iOS разработчиков) будет возможность взять уже готовую бизнес логику KMM(KMP), готовые экраны на CMP, втащить их временно в прод, а в процессе переписывать CMP на SUI, например, с chatGPT.
Звучит сложнее, чем просто написать приложение на Flutter, но найти команду на Flutter тех размеров, какие сейчас есть команды в больших компаниях просто невозможно. Потому не понятно, что еще сложнее
Не совсем так, Compose Multiplatform работает поверх Jetpack Compose для Android. Для всего остального(web, desktop) CMP работает поверх Skia. То есть для android CMP условно нативная технология, android разработчик почти не заметит разницы между CMP и jetpack compose во время работы
Эта мультиплатформенная библиотечка работает поверх sqlLight, потому справляется прекрасно.
Если есть какие-то специфические вещи, которые она не решает (а я с ходу не могу придумать какие), то можно создать мультиплатформенный интерфейс, написать реализацию на каждой платформе отдельно и прокинуть в KMM проект. Из плюсов при правильном построении архитектуры можно будет написать тесты для БД раз для обоих платформ
Лично мне для всех моих случаев было достаточно sqlDelight
Вы правы, если мы будем сравнивать Flutter с CMP без дополнительного контекста. Если лоб в лоб, то Flutter куда более развитый и стабильный, чем CMP, потому что получить рабочее приложение на нем будет гораздо проще.
Но есть пара моментов:
1) Нативный UI для iOS лучше Flutter и CMP во всех случаях. Мало какие компании готовы на user experience, который дает Flutter, потому постепенный переезд на натив обязательная необходимая опция.
2) Синтаксис CMP 1 в 1, как Jetpack Compose, который нативен для Android. Если android разработчик будет сразу писать под Android под CMP, то он не заметит разницы, а эффект будет точно таким же. CMP для Android работает поверх Jetpack Compose, а значит дает тот же эффект, что и натив.
3) Сегодня для новых экранов и приложений android разработчик с гораздо большей вероятностью выберет Jetpack Compose, чем View(xml)
Получается, что если мы добавляем к выбору библиотеки еще и контекст набора команды и построения процессов, то:
Flutter куда менее пригоден, чтобы шарить только бизнес логику на несколько платформ, чтобы потом поверх нее построить нативный UI. KMM(KMP) с этим справляется гораздо лучше. Т.E с Flutter будет сложнее слезть.
Чтобы Flutter появился в проекте - надо нанять Flutter разработчиков (и где-то их еще найти), когда как Compose и так сейчас заходит в проекты, так как это нативная для Android технология. При небольшой подготовке мы получаем CMP код для iOS в подарок просто потому, что android разработчик делал свою работу.
И вот вопрос, если Jetpack Compose и CMP - это одно и то же, и я как iOS разработчик получаю почти бесплатно экраны для iOS просто потому, что android разработчик занимается своей работой, то почему бы мне этим не воспользоваться?
Во-первых, я смогу подкинуть готовые экраны уже сейчас, в которых нет скролла/работы с жестами
Во-вторых, я смогу подкинуть все остальные экраны тоже, но временно, чтобы не срывать релиз, если вдруг не успеваю. А с выходом в beta проблем у этой технологии станет еще меньше.
Во-третьих, chatGPT переводит CMP в SUI на раз два
Даже несмотря на то, что Flutter как технология старше и стабильнее, концептуально с точки зрения расходов и настройки процессов он на мой взгляд не очень удачен.
Честно говоря, у меня не было цели сделать виновным или работодателя, или разработчика. Мне кажется, все по своему хороши, и все вместе вносят в общее дело.
Потому, я просто поделился впечатлениями, и, если показалось, что предвзято, то я смотрел глазами разработчика. Уверен, что вы тоже правы, и замечание очень в цель. Спасибо за ваше мнение, интересно
В том и дело, что в KMM(KMP) можно написать мультиплатформенный интерфейс, в наивном коде сделать его реализацию и подписаться под него, а потом, например, через DI прокинуть в KMM(KMP) модуль под этим интерфейсом. Т.Е тут не нужны никакие каналы, как это сделано во Flutter и тд, чтобы доставить нативную реализацию до мультиплатформенной части. Ко всему прочему, CMP позволяет обернуть любую нативную вьюху и вставить в мультиплатформенный UI. Я таким образом реализовывал видео плееры и полет нормальный
Да, самое главное, что заметит android разработчик при переходе на CMP - это то, что нету этих самых дропдаунов и тд. Для Android решается очень просто через expect/actual @Composable функцию, где для android можно подкинуть ту самую, что копировал выступающий из натива (т.е без копирования). Для iOS придется писать свою реализацию, или скопировать, как это было в примере на конференции
На Skia на CMP будут те же самые проблемы, что и в Flatter, когда он на Skia. Это связанно с устройство самой Skia, потому что там нету возможности компилировать шейдеры заранее, в лучшем случае прогревать их, как это делали на Flutter. Про переход CMP на impeller не знаю, думаю, что пока не выкатят beta, а потом stable, речи о переходе на другой движок не будет
Тем, что Android разработчики уже есть в команде и их не надо нанимать. Достаточно только внедрить технологию и настроить процессы, чем искать целый штат.
Если мы говорим про приложение с нуля, когда команды еще нет, то я тоже бы предпочел, чтобы мои коллеги были ближе к нативу, чем фронтендеры, которые решили переучиться в мультиплатформенную мобильную разработку. Последние неизвестно когда въедут, потому что платформенные нюансы будут сыпаться еще долго. К тому же у меня нет ответа на вопрос: "Зачем им это надо?"
Обид нет?
Все зависит от задачи: если нас устраивает тот user experience, который дает Flutter, и у нас нет планов переходить на натив, то Flutter однозначный победитель. В таком случае нужна команда Flutter разработчиков.
Если же мы работаем над приложением, которое будет развиваться, и нас интересует нативное поведение UI, то мы однозначно выбираем KMM(KMP) + CMP. Потому что в таком случае мы получаем бонусы для iOS, которые я описал в статье просто потому, что android разработчик делает свою работу на нативном для себя фреймворке. У нас (iOS разработчиков) будет возможность взять уже готовую бизнес логику KMM(KMP), готовые экраны на CMP, втащить их временно в прод, а в процессе переписывать CMP на SUI, например, с chatGPT.
Звучит сложнее, чем просто написать приложение на Flutter, но найти команду на Flutter тех размеров, какие сейчас есть команды в больших компаниях просто невозможно. Потому не понятно, что еще сложнее
Совершенно верно
Можно начать с desktop таргета, тоже интересный опыт. Он полностью stable
Не совсем так, Compose Multiplatform работает поверх Jetpack Compose для Android. Для всего остального(web, desktop) CMP работает поверх Skia. То есть для android CMP условно нативная технология, android разработчик почти не заметит разницы между CMP и jetpack compose во время работы
Ну начать стоит с:
https://github.com/cashapp/sqldelight
Эта мультиплатформенная библиотечка работает поверх sqlLight, потому справляется прекрасно.
Если есть какие-то специфические вещи, которые она не решает (а я с ходу не могу придумать какие), то можно создать мультиплатформенный интерфейс, написать реализацию на каждой платформе отдельно и прокинуть в KMM проект. Из плюсов при правильном построении архитектуры можно будет написать тесты для БД раз для обоих платформ
Лично мне для всех моих случаев было достаточно sqlDelight
Вы правы, если мы будем сравнивать Flutter с CMP без дополнительного контекста. Если лоб в лоб, то Flutter куда более развитый и стабильный, чем CMP, потому что получить рабочее приложение на нем будет гораздо проще.
Но есть пара моментов:
1) Нативный UI для iOS лучше Flutter и CMP во всех случаях. Мало какие компании готовы на user experience, который дает Flutter, потому постепенный переезд на натив обязательная необходимая опция.
2) Синтаксис CMP 1 в 1, как Jetpack Compose, который нативен для Android. Если android разработчик будет сразу писать под Android под CMP, то он не заметит разницы, а эффект будет точно таким же. CMP для Android работает поверх Jetpack Compose, а значит дает тот же эффект, что и натив.
3) Сегодня для новых экранов и приложений android разработчик с гораздо большей вероятностью выберет Jetpack Compose, чем View(xml)
Получается, что если мы добавляем к выбору библиотеки еще и контекст набора команды и построения процессов, то:
Flutter куда менее пригоден, чтобы шарить только бизнес логику на несколько платформ, чтобы потом поверх нее построить нативный UI. KMM(KMP) с этим справляется гораздо лучше. Т.E с Flutter будет сложнее слезть.
Чтобы Flutter появился в проекте - надо нанять Flutter разработчиков (и где-то их еще найти), когда как Compose и так сейчас заходит в проекты, так как это нативная для Android технология. При небольшой подготовке мы получаем CMP код для iOS в подарок просто потому, что android разработчик делал свою работу.
И вот вопрос, если Jetpack Compose и CMP - это одно и то же, и я как iOS разработчик получаю почти бесплатно экраны для iOS просто потому, что android разработчик занимается своей работой, то почему бы мне этим не воспользоваться?
Во-первых, я смогу подкинуть готовые экраны уже сейчас, в которых нет скролла/работы с жестами
Во-вторых, я смогу подкинуть все остальные экраны тоже, но временно, чтобы не срывать релиз, если вдруг не успеваю. А с выходом в beta проблем у этой технологии станет еще меньше.
Во-третьих, chatGPT переводит CMP в SUI на раз два
Даже несмотря на то, что Flutter как технология старше и стабильнее, концептуально с точки зрения расходов и настройки процессов он на мой взгляд не очень удачен.
Благодарю, спасибо
Поддерживаю, потому я возвращаю технику всегда чистую и в порядке. Это правда было бы отличной практикой, если другие взяли бы на вооружение
Честно говоря, у меня не было цели сделать виновным или работодателя, или разработчика. Мне кажется, все по своему хороши, и все вместе вносят в общее дело.
Потому, я просто поделился впечатлениями, и, если показалось, что предвзято, то я смотрел глазами разработчика. Уверен, что вы тоже правы, и замечание очень в цель. Спасибо за ваше мнение, интересно
Подписываюсь под каждым вашим словом :)
Благодарю за обратную связь, очень ценно
Благодарю за обратную связь. Буду работать над этим
У вас, кажется, плохое настроение. Желаю, чтобы оно у вас было отличное :)
Основные минусы за низкий технический уровень статьи. Она, честно говоря, на это и не претендовала, но что поделать, так значит так.
Благодарю, спасибо!
Хорошее и актуальное замечание. Эта статья как раз для того, чтобы новичок трезво оценивал куда идет, а то вдруг ему это и не надо :)