Вопрос не в компиляции, а в бесшовном вызове из нативного кода.
И котлин в этом плане не фреймворк, можно буквально из нативного кода создать просто экземпляр одного класса (модель) из нативного кода - и все будет работать так, как будто ты используешь айосную библиотеку
Без примера непонятно). Глобально нет, таких проблем нет. Бойлерплейта многовато, да, а так вроде все в порядке
В том то и соль, что котлин не ограничивает использование нативных фич и легко встраивается в нативный код. Мы виджеты поднимали для главного экрана, все с пол пинка заводится.
Хорошая история всегда не про классный сюжет, а про людей. Мы хоть и мало проработали вместе, но и в начале нашего знакомства, и сейчас приятно так человека узнавать.
Ну и отдельно спасибо за то, что в хабре появляется не только популистский контент)
Так аппстор здесь не при чем - у вас ровно такая же ситуация в любом типе разработки.
Если условных 10 лет назад можно было сляпать что-то на коленке и как то монетизировать - сейчас, увы. Трафик дорогой, встроенная реклама дешевая, Рынок приложений переполнен.
Я могу предположить, что можно изобрести что-то инновационное и стрельнуть, пока конкуренты не очухаются (и потом с большей вероятностью, им продаться).
Но даже такой сценарий я бы рассматривал с привлечением инвестиций и коммерческой разработкой.
А попытка свой труд монетизировать вот так - давайте будем честными, без дизайна, рекламы, маркетинга, девопса и много чего еще сделать действительно хорошее приложение - тяжело. И тем более тяжело не потратить на него пол жизни и увидеть соизмеримую своим часам сумму прибыли приложения.
А вы уверены, что в финансовой неуспешности проекта виноват именно эппл? Элементарно, ожидание прибыльности от попадания в топ - это именно проблема неверных ожиданий. Сами по себе топы ничего кроме утешения своего эго не дают
Вот да, мне тоже только это на ум пришло. Но опять же, для этого лучше использовать билдеры с анонимными функциями, как например здесь ktor.io/docs/client.html#features
По сути вместо иницализации класса мы вызываем одноименный метод, куда передаем лямбду, которая в свою очередь относится к пространству билдера. Короче сводим функциональную реализацию к декларативной, где вложенности вызовов порождают необходимые пространства.
По большому счету все это сделано только для того, чтобы не запутаться в порядке инициализации компонент и большом количестве аргументов. Если все имена аргументов самого класса и его компонентов — именованные, никаких проблем — все четко просто и понятно написано.
Я понимаю, что можно извращаться в толковании инициализации, добавлять лямбды, отдельный билдер для каждого аргумента, потом еще написать функции вроде initAfter/initBefore, но все это в конечном случае именованием аргументов решается проще, понятнее и эффективнее.
Просто для размышления — пример последнего листинга может и выглядит эффектно, но ни одного желания понять, что там внутри происходит и как оно работает, не вызывает.
Вроде бы задачка плевая была, а решаем ее, стреляя из пушки по воробьям.
Я понимаю, что пишу в Спортлото, но тем не менее — новый Gradle тянет требования к новой версии kotlin, а lifecycle библиотеки сидят вплоть до 1.3.20. Завел задачку в трекере, уже неделю все молчат.
Хочется затащить и начать пробовать в реальном проекте, но вот это легаси не дает ничего.
Ссылка на баг issuetracker.google.com/issues/181156413
Ну, 1-2 раза ты можешь в коде такое накодить и даже считать, что контроллируешь процесс.
Я скорее про случай, когда у тебя есть готовое приложение и тебе из него готового надо дергать флаттер кусочками.
Таким образом мы получаем ситуацию, когда мы получаем абсолютно не дебажную историю с абстрактным асинхронным вызовом чего-то.
Котлин в этом плане синхронен и платформенен - он просто в objC компилится.
Ну, технически - да, практически - это невозможно использовать в готовых приложениях.
Флаттер это все таки именно фреймворк, а KMP - нет.
Очевидно, используется) Наверно не так чтобы прямо максимально широко - иначе бы статья была совсем другой)
Ураааа)
Вопрос не в компиляции, а в бесшовном вызове из нативного кода.
И котлин в этом плане не фреймворк, можно буквально из нативного кода создать просто экземпляр одного класса (модель) из нативного кода - и все будет работать так, как будто ты используешь айосную библиотеку
KMP на ios уже 3 года как в стейбле, извините
Без примера непонятно). Глобально нет, таких проблем нет. Бойлерплейта многовато, да, а так вроде все в порядке
В том то и соль, что котлин не ограничивает использование нативных фич и легко встраивается в нативный код. Мы виджеты поднимали для главного экрана, все с пол пинка заводится.
Если совсем коротко, то Котлин это первый вариант бесшовногно интеропа с нативными языками. Все остальное - фреймворки.
Второй важный аспект - нативная скорость и качество андроида.
Спасибо, классная штука. Сейчас в планах попробовать поддержку свифта уже в новой версии котлина
Хорошая история всегда не про классный сюжет, а про людей. Мы хоть и мало проработали вместе, но и в начале нашего знакомства, и сейчас приятно так человека узнавать.
Ну и отдельно спасибо за то, что в хабре появляется не только популистский контент)
Прекрасный обтекаемый ответ.
Хуавей не планирует выпускать смартфоны. Это вовсе не значит, что другие вендоры не могут выпустить смартфоны с этой операционкой.
Все равно, как можно такими популистскими фразами обосновать такие изменения, которые просто с двух ног фигачат всю экономику разработки - непонятно.
Так аппстор здесь не при чем - у вас ровно такая же ситуация в любом типе разработки.
Если условных 10 лет назад можно было сляпать что-то на коленке и как то монетизировать - сейчас, увы. Трафик дорогой, встроенная реклама дешевая, Рынок приложений переполнен.
Я могу предположить, что можно изобрести что-то инновационное и стрельнуть, пока конкуренты не очухаются (и потом с большей вероятностью, им продаться).
Но даже такой сценарий я бы рассматривал с привлечением инвестиций и коммерческой разработкой.
А попытка свой труд монетизировать вот так - давайте будем честными, без дизайна, рекламы, маркетинга, девопса и много чего еще сделать действительно хорошее приложение - тяжело. И тем более тяжело не потратить на него пол жизни и увидеть соизмеримую своим часам сумму прибыли приложения.
Тогда вообще непонятен весь спич. В чем проблема? Прилага есть, топ есть, статьи на хабр - хоть обпечатайся.
Написал приложение - не взлетело - сделал выводы - пошел дальше.
А вы уверены, что в финансовой неуспешности проекта виноват именно эппл? Элементарно, ожидание прибыльности от попадания в топ - это именно проблема неверных ожиданий. Сами по себе топы ничего кроме утешения своего эго не дают
ktor.io/docs/client.html#features
По сути вместо иницализации класса мы вызываем одноименный метод, куда передаем лямбду, которая в свою очередь относится к пространству билдера. Короче сводим функциональную реализацию к декларативной, где вложенности вызовов порождают необходимые пространства.
Я понимаю, что можно извращаться в толковании инициализации, добавлять лямбды, отдельный билдер для каждого аргумента, потом еще написать функции вроде initAfter/initBefore, но все это в конечном случае именованием аргументов решается проще, понятнее и эффективнее.
Просто для размышления — пример последнего листинга может и выглядит эффектно, но ни одного желания понять, что там внутри происходит и как оно работает, не вызывает.
Вроде бы задачка плевая была, а решаем ее, стреляя из пушки по воробьям.
Хочется затащить и начать пробовать в реальном проекте, но вот это легаси не дает ничего.
Ссылка на баг
issuetracker.google.com/issues/181156413