Не я

Или я был бухой)

А как это связано с инверсией контроля?

Разве перекладывание на какой то там контейнер создание контроллера для @GET... ни есть инверсия?

Понапридумывали себе инверсию контроля и трахаются с ней, почему бы не взять провославный для котлина ktor и не сделать нормальный код, без вот этих вот аннотаций?

Это вообще Android...

Соу вот?

ktor нельзя на андроиде?

Нет, инверсия контроля (IOC) общее название di контейнеров например spring, dagger, koin

Нет, инверсия контроля (IOC) общее название di контейнеров например spring, dagger, koin

Кгм. https://en.wikipedia.org/wiki/Inversion_of_control

кроме di там еще есть куча всего

Вы такие умные?

я чет тоже не вижу где ретрофит нарушает иос

ktor нельзя на андроиде?

не вместо ретрофита же

не вместо ретрофита же

Есть ktor-client, который можно вместо ретрофита, ибо то же самое делает.

не вместо ретрофита же

ну вообще как раз-таки вместо

Ещё dependency lookup... Я не говорю что нарушает, просто мне странно слышать про IOC не в рамках контейнера)

я думаю имелся ввиду именно ktor-client который работает без аннотаций и т.д.

Ещё dependency lookup... Я не говорю что нарушает, просто мне странно слышать про IOC не в рамках контейнера)

IoC — это буквально об инверсии управления. Всё. Инвертировать управление (то есть делать так, что не ты вызываешь фреймворк, а он тебя) можно делать в рамках чего угодно. DI-контейнеры — это просто наиболее держащийся на слуху конструкт на эту тему в мобильном мире.

так ведь ktor не исключает ни DI ни IoC - бери и прикручивай. хоть от Java, хоть родные Котлиновские

Нет, инверсия контроля (IOC) общее название di контейнеров например spring, dagger, koin

аазаззазаза

Нуну

Эти ваши setOnClickListener — это тоже об IoC, если что.

Просто местами это оправдано, местами нет :)

Ретрофит как раз нужен, чтобы не писать кучу кода руками на "нормальных и православных" ktor-client, OkHttp и так далее

Надо бы почитать про общий IOC, окей) В ktor-client кстати вызовы на корутинах, что порадовало немного, но там много руками писать пришлось

Надо бы почитать про общий IOC, окей) В ktor-client кстати вызовы на корутинах, что порадовало немного, но там много руками писать пришлось

поэтому я пока юзаю retrofit и корутины )

а ktor-client надо глянуть будет на досуге )

Ретрофит как раз нужен, чтобы не писать кучу кода руками на "нормальных и православных" ktor-client, OkHttp и так далее

Ну как по мне, жертвовать возможностью контролировать все действия ради сокращения кода каждого вызова на 5-10 строк - совсем не имеет никакого профита

Ну как по мне, жертвовать возможностью контролировать все действия ради сокращения кода каждого вызова на 5-10 строк - совсем не имеет никакого профита

а если на 100 строк?

Каждый приходится писать такую туеву тучу кода, что 10 строк просто меркнет в сравнении

а если на 100 строк?

чего вы там в 100 строк собрались делать?

Я в целом не до конца понимаю, где вы находите необходимость писать руками много кода, при учёте что самое "страшное" — десериализация объектов из стрима респонса — покрывается install(ContentNegotiation) { gson { ... } }

для http вызова

Да и всякие авторизации конфигурируются для клиента в одном месте, а не на каждый вызов, равно как и для ретрофита.

Ретрофит как раз нужен, чтобы не писать кучу кода руками на "нормальных и православных" ktor-client, OkHttp и так далее

Ой, ну не надо, сколько пишу под ведро - от ретрофита копеечный выигрыш (тем более на Котлине). (а вот если клиент генерится свагером - другое дело)

Я в целом не до конца понимаю, где вы находите необходимость писать руками много кода, при учёте что самое "страшное" — десериализация объектов из стрима респонса — покрывается install(ContentNegotiation) { gson { ... } }

Можешь скинуть примеры свои Features для ktor-client?

Пардоньте, запамятовал, install(JsonFeature) { serializer = GsonSerializer { ... } }

Можешь скинуть примеры свои Features для ktor-client?

Чё их скидывать, всё в доке есть: https://ktor.io/clients/http-client.html (моя машина всё равно дома)

Чё их скидывать, всё в доке есть: https://ktor.io/clients/http-client.html (моя машина всё равно дома)

выглядит красиво, почему тогда везде ретрофит и даггер, а не koin и ktor (

обидно (

потому что нельзя просто так взять и вытравить "деревню" из человека

очевидно же

потому что нельзя просто так взять и вытравить "деревню" из человека

Иначе все уже на хаскелле давно бы бизнес-логику писали? :)

Ну это немного о разном

Иначе все уже на хаскелле давно бы бизнес-логику писали? :)

На кложуре же

выглядит красиво, почему тогда везде ретрофит и даггер, а не koin и ktor (

Где даггер?)

На хаскеле сейчас у людей хорошо получается писать всякие компиляторы, интерпритаторы и тд

Где даггер?)

в проектах промовских, которые попадаются

есть конечно даже блок чейн на хаскеле, но это скорее исключение

Чё их скидывать, всё в доке есть: https://ktor.io/clients/http-client.html (моя машина всё равно дома)

Да у меня что-то не завелось, сам писал... Попробую ещё потом

Rx Dagger Kotlin, архитектура, Retrofit

стандартный сейчас стэк технологий

в проектах промовских, которые попадаются

это промо самого даггера?)

везде-везде

Rx Dagger Kotlin, архитектура, Retrofit

архитектура — это технология такая?)

архитектура — это технология такая?)

ты придираешься ?

ты придираешься ?

пытаюсь понять, чего ты хочешь сказать

я назвал стэк, 90% проектов именно на этом сейчас

мне самому это не нравится

но приходится жить с даггером тем же

или Rx

хотя можно koin и корутины

на своих проектаях я их и введу думаю, но когда не мой, увы

консерватизм может

не знаю что всему виной )

хайп и инерция

не знаю что всему виной )

Обычно берут стек на котором людей изи найти

RxJava вообще не про это :)

ERROR: S client not available

RxJava идет в купе с ретрофитом для запросов

ну и чтобы комбинировать вместе разные запросы паралельно или последовательно например

да, бывает такое отклонение

также есть RxView всякие для UI

сам не юзал, но видел в одном проекте

у себя в пет я корутины засобачил и koin, а тут выходит можно ktor взять ещё вместо ретрофита, чтобы вообще модным стать ))

RxJava идет в купе с ретрофитом для запросов

Блеее, лучшую они конечно взяли абстракцию для запросов

вот займусь и таким на досуге

Да у меня что-то не завелось, сам писал... Попробую ещё потом

Главное — проверить, что все зависимости в Gradle подтянуты: io.ktor:ktor-client-core:... io.ktor:ktor-client-cio:... io.ktor:ktor-client-json:... После при инициализации клиенты устанавливаешь фичу с сериализатором и шаблонный .get должен начать работать. Единственное, ему будет не очень хорошо, если сервер не отдаёт Content-Type правильный, но это по идее можно вылечить перехватом и исправлением хедеров в респонсе (ну или пи***лями бекендщикам, что даже лучше).

Блеее, лучшую они конечно взяли абстракцию для запросов

ну вообще это сейчас больше как аксиома в аутсорце

я не видел проектов без этого уже прилично времени ))

не знаю почему вас это удивляет )) как будто я один на аутсорце работаю том же, или у нас проекты совершенно другие ))

Брать стримы чтобы процессить один запрос ?

Чем их любая другая монада не устроила, для композиций

почему один ?

в приложение один запрос ?

неочень понял

Потому что это Observable всегда от одного элемента

Single ?

заюзать

Потому что это Observable всегда от одного элемента

заменяешь на Single и радуешься жизни

Как будто это сильно что то меняет

меня не устраивает только что они тяжелые и громоздкие как и даггер

заменяешь на Single и радуешься жизни

прав

и корутины проще, меньше, легче

как и koin

Ну справедливости ради, каждый входящий респонс может гоняться через кеш, перемалываться через flatMap и параллелиться дальше, но насколько часто это встречается на практике у людей — я без руля.

в по функциям ну Rx делает свои функции на ура

не поспоришь

меня не устраивает только что они тяжелые и громоздкие как и даггер

в каком смысле?

заменяешь на Single и радуешься жизни

CompletableFuture же

CompletableFuture же

этот господин дело говорит