можно делать ?.let {}

50 оттенков говнокода

да, или ?.run

51-ый

в иос легче избавляться от вложенности из-за nullable

50 оттенков говнокода

Ооочень спорно

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

прибивать презентер при смерти вьюхи

51-ый

бессовестный троль чей продакшн код еще никто не видел😀

там есть guard let

дели на модули, интерфейс в одном, реализация в другом, не надо будет стыдливо оправдываться за единственную реализацию😈

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

там есть guard let

мб не в иос, а в свифте? guard — тот же if

бессовестный троль чей продакшн код еще никто не видел😀

мне кажется ты даже пользовался)

50 оттенков говнокода

Вот именно поэтому последовал идее Igor и пушу через notifyUI ивенты (наследники sealed-класса). :)

прибивать презентер при смерти вьюхи

Так он наоборот должна жить дольше вьюхи, чтобы сохранять состояние

мб не в иос, а в свифте? guard — тот же if

да, но он не делает вложенности

бессовестный троль чей продакшн код еще никто не видел😀

А чей продакшен-код кто видел? Твоего кода я вот вообще никакого не видел

Так он наоборот должна жить дольше вьюхи, чтобы сохранять состояние

так, а что делать, когда вью отцепилась, пришло событие (ушло вникуда), вью прицепилась?

да, но он не делает вложенности

так, а что он возвращает при раннем выходе?)

nil / ничего

обычно это пишут в одну строку и это выглядит очень красиво

Xamarin Native можно использовать так же как и java/kotlin. Удобно когда back тоже на c#, многое переносится. Xamarin Forms хорош для прототипирования, но есть на нем и довольно не маленькие проекты (Instamart можешь посмотреть).

Интересно, спасибо

так, а что делать, когда вью отцепилась, пришло событие (ушло вникуда), вью прицепилась?

Да, это лучше чем краш, причём состояние сохранится

Я в котлине еще иногда пользуюсь variable ?: return, но оно подходит далеко не всегда.

А чей продакшен-код кто видел? Твоего кода я вот вообще никакого не видел

регулярно скрины проскакивают, не лукавь

Да, это лучше чем краш, причём состояние сохранится

не увидел чтобы там что-нибудь сохранялось, а вот это особенно эпично loginInteractor.requestInitialization(view?.getDeviceId())

не увидел чтобы там что-нибудь сохранялось, а вот это особенно эпично loginInteractor.requestInitialization(view?.getDeviceId())

Почему эпично?

регулярно скрины проскакивают, не лукавь

скрины — да. Без кода)

Почему эпично?

потому что туда может передаться null

потому что туда может передаться null

Надо тогда внутри requestInitialization обработать null и будет норм тогда?

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

Надо тогда внутри requestInitialization обработать null и будет норм тогда?

или не звать с нуллом

Надо тогда внутри requestInitialization обработать null и будет норм тогда?

callFunc(nullable?.get ?: return)

callFunc(nullable?.get ?: return)

ужас

нулабилити в одном месте и не размазывается

четка

А где самый традиционный способ проверки на нулл, if (var != null) {...} или он уже не модный?

Почему эпично?

а почему кстати получением девайс айди занимается именно вью?

Почему все так яростно пытаются использовать var?.let{...} ??

а почему кстати получением девайс айди занимается именно вью?

Потому что нужен контекст

да выкиньте уже в мусорку эти нуллы

Потому что нужен контекст

контекст можно заинжектить куда надо

Почему все так яростно пытаются использовать var?.let{...} ??

а какие варианты

а какие варианты

джавовский, if (var != null) {...}

джавовский, if (var != null) {...}

это то во что он компилится

зачем мне джава

джавовский, if (var != null) {...}

Т.е. писать на котлине по джавовому? Какой смысл тогда тащить котлин в проект?

контекст можно заинжектить куда надо

Тогда наверное не контекст, а TelephonyManager надо передавать, чтобы потом его замокать, верно?

лейтинитом может еще скажи обмазаться

Тогда наверное не контекст, а TelephonyManager надо передавать, чтобы потом его замокать, верно?

пиши чистые функции, и ничего не нужно будет мокать

Т.е. писать на котлине по джавовому? Какой смысл тогда тащить котлин в проект?

Видел вот такой код: var?.let{ var1?.let{ var2?.let { } } } И тут мне кажется логичнее было бы использовать if (var != null && var1 != null && var2 != null){...} От котла тут немного пользы, всему должна же быть мера

Видел вот такой код: var?.let{ var1?.let{ var2?.let { } } } И тут мне кажется логичнее было бы использовать if (var != null && var1 != null && var2 != null){...} От котла тут немного пользы, всему должна же быть мера

+

Видел вот такой код: var?.let{ var1?.let{ var2?.let { } } } И тут мне кажется логичнее было бы использовать if (var != null && var1 != null && var2 != null){...} От котла тут немного пользы, всему должна же быть мера

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

пиши чистые функции, и ничего не нужно будет мокать

Что ты имеешь ввиду под словом "чистые"?

Видел вот такой код: var?.let{ var1?.let{ var2?.let { } } } И тут мне кажется логичнее было бы использовать if (var != null && var1 != null && var2 != null){...} От котла тут немного пользы, всему должна же быть мера

val x = var?.var2?.var3?.thingy ?: return

Что ты имеешь ввиду под словом "чистые"?

без сайд-эффектов и без зависимостей

Тогда наверное не контекст, а TelephonyManager надо передавать, чтобы потом его замокать, верно?

Как тогда переписать это?

val x = var?.var2?.var3?.thingy ?: return

Как тогда переписать это?

на кой чёрт тебе это IMEI вообще? А если это планшет без GSM?

ну так напиши короче и понятнее если умеешь😀

у меня тако не вызывает отвращения например

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

Как тогда переписать это?

и что ты собрался мокать?

на кой чёрт тебе это IMEI вообще? А если это планшет без GSM?

Бизнес поддерживает только устройства, где есть IMEI

и что ты собрался мокать?

Если я вынесу этот код в Presenter, как мне здесь посоветовали, то telephonyManager придётся мокать

ну так напиши короче и понятнее если умеешь😀

Сверху привел же пример

Если я вынесу этот код в Presenter, как мне здесь посоветовали, то telephonyManager придётся мокать

передавай в презентер не менеджер, а функцию, которая вернёт imei

как установить для CheckBox дровабл параметра button по центру. хочу увеличить область нажатия чекбокса. чекбокс без текста чекбокс <CheckBox android:id="@+id/messageMyVoicePlayer" android:layout_width="32dp" android:layout_height="32dp" android:layout_marginStart="16dp" android:button="@drawable/player_padua" android:gravity="center" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintStart_toStartOf="parent" app:layout_constraintTop_toTopOf="parent" />

вид

передавай в презентер не менеджер, а функцию, которая вернёт imei

Не понял, как это будет выглядеть?

Не понял, как это будет выглядеть?

принимать () -> String в конструктор. Передавать { context.getSystemService(...)... }

вид

Я бы toggleButton использовал

Сверху привел же пример

это в два раза дольше печатать

я вот че не пойму

принимать () -> String в конструктор. Передавать { context.getSystemService(...)... }

Это же сколько лямбд мне придётся вскоре передать... Это вообще дичь

котлин делает больше за меньше символов

чего вы еще в джава стиле пишете в котлине?зачем?

котлин делает больше за меньше символов

И не читабельный код

И не читабельный код

Чё

И не читабельный код

и тебя есть ide где на все есть подсказки, типы, параметры функций, хинты

чего вы еще в джава стиле пишете в котлине?зачем?

Нужно исходить из ситуации, в том примере, то написал @devit951 гораздо приятнее смотреть на джавовские проверки, чем на лестницу из скобочек

и тебя есть ide где на все есть подсказки, типы, параметры функций, хинты

Ну в гиихабе это не канает

и тебя есть ide где на все есть подсказки, типы, параметры функций, хинты

Одним IDE код не читается, как же code review в github без доступа к ИДЕ?