а в чем проблема?

interface как пигется?

interface как пигется?

я так полагаю с хешмапом во главе

я так полагаю с хешмапом во главе

можно?

а почему нет?

ну если уж совсем не зайдет

всегда можно сделать массив объектов

а почему нет?

кей должен быть инт

можешь скинуть как должен выглядеть body отправки?

вот

вот

raw body реквеста, а не замаппленный скрин

кей должен быть инт

и в чем проблема?

хеш

put не работает

через инт

HashMap<Integer,Object>

с чего бы не работает?

ну Object замени на что нужно уже

HashMap<Integer,Object>

работает?

попробую

работает?

ты серьезно не знал что в HashMap интеджер может быть ключем? О_о

?

знаю

я вообще подозреваю

там только для таких вещей и навернули сам класс Integer

хотя в котлине

можно Int сувать

объект же

я вам потом в личку напишу

Здорова всем. Есть ли годные библиотеки под telegram api?

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

Здорова всем. Есть ли годные библиотеки под telegram api?

Да, у них даже на офф сайте есть ссылки

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

Уже нет

Kotlogram есть ещё

Да, у них даже на офф сайте есть ссылки

Например есть Java SDK. Я его могу для котлина использовать? У ВК есть.

Все ,что для Java можно использовать и в Kotlin

Спасибо

и соответственно T приводиться к типу ViewModel и я не могу вызвать свой метод

так ты в самом методе имя дженерику другое дай и все заработает

так ты в самом методе имя дженерику другое дай и все заработает

уже пробовал - все равно не работает

а теперь найди самое главное отличие :)

а теперь найди самое главное отличие :)

+1

у тебя в java примере просто метод, в котлине - объявлен дженерик еще и в самом методе

у тебя в java примере просто метод, в котлине - объявлен дженерик еще и в самом методе

так переопределяет метод сама студия

когда я имплеменчу ViewModelProvider.Factory

когда я имплеменчу ViewModelProvider.Factory

как выглядит этот интерфейс?

ваша джавовая реализация не соответствует интерфейсу

ваша джавовая реализация не соответствует интерфейсу

если бы было несоответствие, то студия подчеркнула бы, или был бы краш?

на котлине работает если добавить в if проверку viewModel is Spot2rViewModel, но тогда нету вообще смыла от этого дженерика

если бы было несоответствие, то студия подчеркнула бы, или был бы краш?

подчеркнула бы и не собиралась, ну тут очевидно в интерфейсе у вас дженерик метод, в java классе, у вас дженерик класс, а метод берет тип из класса уже, то есть метод не дженерик в реализации

как это у вас собирается вопрос )

как это у вас собирается вопрос )

+

подчеркнула бы и не собиралась, ну тут очевидно в интерфейсе у вас дженерик метод, в java классе, у вас дженерик класс, а метод берет тип из класса уже, то есть метод не дженерик в реализации

на java стандартно так переопределяет. Тогда вопрос, как должно быть правильно на java?

ну если исходить из интерфейса, то даймонды(<>) надо переносить в описание метода

ну это надо эксперементировать садиться

с кодом

В джаве удалось упростить метод, потому что она позволяет не указывать тип параметризации, например, в java мы можем спокойно написать List list = new ArrayList(); и дальше ты уже сам ответственен что ты ложишь в этот список. Если же перевести это в котлин, то будет ошибка - нужно указать тип

ERROR: S client not available

В джаве удалось упростить метод, потому что она позволяет не указывать тип параметризации, например, в java мы можем спокойно написать List list = new ArrayList(); и дальше ты уже сам ответственен что ты ложишь в этот список. Если же перевести это в котлин, то будет ошибка - нужно указать тип

ну вообще и в джава так писать нехорошо, мне кажется

лучше указывать тип в <>, просто это необязательно

а в котлин тип полюбому указать нужно

и соответственно T приводиться к типу ViewModel и я не могу вызвать свой метод

Что пишет

ну вообще и в джава так писать нехорошо, мне кажется

ну это удобно, если допустим у меня в андроиде адаптер с многими разными типами и я выстраиваю дерево проверяя елементы путем instanceOf

ну это удобно, если допустим у меня в андроиде адаптер с многими разными типами и я выстраиваю дерево проверяя елементы путем instanceOf

это жутко

ну это удобно, если допустим у меня в андроиде адаптер с многими разными типами и я выстраиваю дерево проверяя елементы путем instanceOf

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

все его наследуют

Что пишет

пришет, что недостаточно информации и нужно явно указать

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

+

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

можно даже без привидения методы интерфейса дергать

а в вашем случае вы и Object можете туда кидать, а потом проверять и кастить

но это не будет хорошо..

пришет, что недостаточно информации и нужно явно указать

Out пробывал ?

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

я понимаю, но это излишне для разных типов обьектов и на постореине дерева со списка это никак не отразится

например у меня для списков есть BaseRecyclerAdapter, он принимает List<BaseItem>, каждый item имплементит интерфейс BaseItem и два метода, в одном отдает layout_id для инфлэйта, в другом реализуется рендеринг, и всё, получается для всех списков я использую один и тот же адаптер, меняя только список items, и каждый элемент получается рендерит сам себя

я понимаю, но это излишне для разных типов обьектов и на постореине дерева со списка это никак не отразится

проверять instanceOf ?

ещё как отражается такое

или касты ещё какие

пришет, что недостаточно информации и нужно явно указать

Ну еще можно декомпилировать в джава и сравнит

я понимаю, но это излишне для разных типов обьектов и на постореине дерева со списка это никак не отразится

А перфомансе ? Каждий раз юзат рефлекси

А перфомансе ? Каждий раз юзат рефлекси

мне нужно при построении дерева смотреть, есть ли элемент такого-то типа следующий по счету и на основании этого оставлять или убирать текущий элемент

тут общий интерфейс не поможет

то есть, есть группа, подруппа и какой-то элемент, есть в группе ничего нету, то ее не добавляем, если в подругппе ничего нету, то не добавляем и группу и подгруппу

Би-2 - Варвара

Вспомнил про Барбару Лисков - слова как раз в тему

то есть, есть группа, подруппа и какой-то элемент, есть в группе ничего нету, то ее не добавляем, если в подругппе ничего нету, то не добавляем и группу и подгруппу

в чем проблема сделать элементы группа, подгруппа ещё, со своим дизайном, и при проверке добавлять их или не добавлять, общий интерфейс как раз нужен чтобы упорядочить элементы в адаптере, а не отдавать туда всё подряд, и там уже разбираться через instanceOf

тогда и смысла от дженериков не было бы, если бы было хорошо делать так