Как я могу получить контекст в ресайклере?

В адаптере? В onCreateViewHolder можно спросить у parent.

А во вьюхолдере у itemView

В адаптере? В onCreateViewHolder можно спросить у parent.

Да, верно, в адаптере, прошу прощения

А во вьюхолдере у itemView

Спасибо, сейчас поэкспериментирую

Всем привет) Читал правила оформления кода в Котлине и наткнулся на интересную часть "Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together, so that someone reading the class from top to bottom would be able to follow the logic of what's happening." Странно, я раньше думал что сортировать методы и переменные по видимости это нормально, что думаете по этому поводу?

Всем привет) Читал правила оформления кода в Котлине и наткнулся на интересную часть "Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together, so that someone reading the class from top to bottom would be able to follow the logic of what's happening." Странно, я раньше думал что сортировать методы и переменные по видимости это нормально, что думаете по этому поводу?

Всё правильно, пусть фича будет цельной, а не размазанной. Это верно для всех уровней — методов, классов, пакетов, модулей.

Всем привет) Читал правила оформления кода в Котлине и наткнулся на интересную часть "Do not sort the method declarations alphabetically or by visibility, and do not separate regular methods from extension methods. Instead, put related stuff together, so that someone reading the class from top to bottom would be able to follow the logic of what's happening." Странно, я раньше думал что сортировать методы и переменные по видимости это нормально, что думаете по этому поводу?

я думаю вообще похуй честно сказать. слева есть вкладочка "структура" и там уже можно оперативно все посмотреть с фильтрами, чем руками файл листать.

правило меньше 1к

класс меньше 1к строк

метод меньше 50

помоему отличные правила

класс <500 (без доков), метод <10-20

а в итоге мы видим около 50 тысяч строк в гугловских сорсах

Необходимо уничтожив фрагмент вернутся к активности , у меня этот фрагмент как диалог фрагмент

getDialog().dismiss()

понял) всем спасибо!)

а в итоге мы видим около 50 тысяч строк в гугловских сорсах

индусы, сэр

индусы, сэр

Ну там очень много документации

и дикое легаси

getDialog().dismiss()

Спасибо, тоже попробую

а в итоге мы видим около 50 тысяч строк в гугловских сорсах

так это же прекрасно. Гуглокод — идеальный антипример.

Но все равно в 500 строк не уложиться))

Я не знаю, как можно уместить это все в 500 строк, если в джаве нет расширений

Вьюха сама по себе имеет много методов

зачем вендора обсуждать я не понимаю

так это же прекрасно. Гуглокод — идеальный антипример.

Интересно было бы увидеть эпло-код, не зря же они его прячут 😁

Интересно было бы увидеть эпло-код, не зря же они его прячут 😁

Да и хорошо)) мы ещё молодые

Устраивайся в эпл)

И потом продавай знания)

И потом продавай знания)

Тим Кук лично отымеет за продажу чего-либо оттуда

знания и опыт, а не код)

про хороший код: можете попробовать заглянуть в исходники телеграма на гитхабе я страшнее ничего ещё не видел

Страшно в каком плане?

про хороший код: можете попробовать заглянуть в исходники телеграма на гитхабе я страшнее ничего ещё не видел

всяко лучше, чем фабричные фабрики

Страшно в каком плане?

открываешь рандомные классы — 10-15 тысяч строк, у меня подвисает что браузер, что иде

господа, помогите советом, плз. есть экран. на нем можно выделить три больших элемента: сверху AppBarLayout с CollapsableToolbarLayout внутри, под ним находится Relative с несколькими вьюхами, и под ним находится ресайклер вью. и тут такая тема: после того, когда листаем вниз, и AppBarLayout свернулся, при дальнейшем скролле сначала должен ушйти Relative, и потом начать прокручиваться RecyclerView. вариант с тем, чтобы запихнуть Relative в AppBarLayout не подходит (Relative не всегда отображается, и когда он gone, АppBarLayout ведет себя не очень хорошо). запихнуть Relative и Recycler в NestedScrollView не подходит (мне не нравится поведение Recycler'а в этой ситуации). дать люлей дизайнеру (мало ли, вдруг кто предложит) - не подходит. уволиться (встречал тут и такие ответы) тоже не подходит) как вылезти из этой ситуации? точнее, как это все будет грамотно организовать? а то у меня идеи совершенно закончились. P.S. сорян, если непонятно объяснил, на "схеме" сверху разрисовал смысл идеи.

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

открываешь рандомные классы — 10-15 тысяч строк, у меня подвисает что браузер, что иде

Видимо, не было другого выхода

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

Вот именно

https://github.com/DrKLO/Telegram можете заценить

Видимо, не было другого выхода

лол. Был, конечно

Видимо, не было другого выхода

я уверен, что был вот в таких блоках весь код

я уверен, что был вот в таких блоках весь код

Реклама котлина

Реклама котлина

конечно, ведь на котлине говнокод красивый! ❤️

Реклама котлина

а причём здесь котлин? несколько уровней вложенности — это не проблема джавы, это проблема рук

Ну как минимум в нем нет постоянных if != null

плохой код остаётся плохим кодом

Сколько больших проектов вообще опен сурс?

я уверен, что был вот в таких блоках весь код

Это сделано специально. Чем больше напишешь говнокода в проекте, тем больше ты становишься незаменимым и тебя не уволят, ибо только ты сможешь это поддерживать

Ну как минимум в нем нет постоянных if != null

очень надо if != null, сделай лучше if (a == null) { return; } …

Ну как минимум в нем нет постоянных if != null

ну?.да?.так?.гораздо?.лучше

очень надо if != null, сделай лучше if (a == null) { return; } …

a ?: return другое дело, что return должен быть строго один

a ?: return другое дело, что return должен быть строго один

почему он должен быть строго один?

очень надо if != null, сделай лучше if (a == null) { return; } …

Ну такое

почему он должен быть строго один?

для читаемости-понятности

камон, ранние ретёрны всегда будут лучше смотреться, чем уровни вложенности из-за else

камон, ранние ретёрны всегда будут лучше смотреться, чем уровни вложенности из-за else

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

a ?: return другое дело, что return должен быть строго один

ды нет не должен, early return нормальная практика для проверки пред-условий

FirebaseInstanceId .getInstance() .instanceId .addOnCompleteListener(OnCompleteListener { task -> if (!task.isSuccessful) { return@OnCompleteListener } val token = task.result?.token ?: return@OnCompleteListener ... })

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

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

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

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

FirebaseInstanceId .getInstance() .instanceId .addOnCompleteListener(OnCompleteListener { task -> if (!task.isSuccessful) { return@OnCompleteListener } val token = task.result?.token ?: return@OnCompleteListener ... })

пиздец

пиздец

это пример из документации практически

здесь все ранние ретёрны должны бросать исключения

это пример из документации практически

ну значит пиздец не тебе, а документации

войд колбэки с ранними ретернами - збс

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

здесь все ранние ретёрны должны бросать исключения

чтоб потом лишний трай-кетч делать? зачем?

это пример из документации практически

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

чтоб потом лишний трай-кетч делать? зачем?

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

я уверен, что был вот в таких блоках весь код

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

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

везде, повсюду и в любом языке говнокодят

и кстати, ифы здесь будут что в джаве, что в котлине одинаковые

я просто лестницы из кода не люблю

if(blabla) if(blabla2) if(blabla3)

я просто лестницы из кода не люблю

не пиши анимации в приложении )))

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

там миллион разных действий в одном куске кода, это всегда плохо

че бы сразу не писать if (!blabla) return if (!blabla2) return if (!blabla3) return намного проще

ну и скратить вообще в одну строку через &&

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

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