сильно ничего не меняется

кстати господа, а в текущих реалиях как эффективнее осваивать android: брать какого нибудь Майера и т.д. или идти на dev.android.com и читать доки/смотреть там туториалы?

Stackoverflow

Нет смысла читать книги, если нет практики. Надо писать код.

Нет смысла читать книги, если нет практики. Надо писать код.

ну допустим я могу написать приложение на java с оглядкой на 5 дроид... но в текущих реалиях такой мой опыт уже не сильно кому и нужен... Поэтому как раз таки интересует больше понимание всяких "best practices"

Android освоить можно только на практике

plus :: MyType -> Int -> Int plus :: MyType -> MyType -> Int Тo есть по факту хотелось бы сделать какой-то union Int | MyType и далее для негo уже описать эти пpавила. Но чет судя по всему не судьба. Полугpуппой да, тут и не пахнет, я к тому, что выхлоп аналогичный для двух пpавил нужен, и двух типов.

Как ты в данном случае свернешь [Int, MyType, Int] [Int, Int, Int] тут уже реально, без реализации всех возможных plus для MyType | Int не обойтись

Android освоить можно только на практике

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

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

Хороший ментор ИМХО это опытные коллеги по команде. Невозможно реально расти, если сидишь в своем соку. Это мое ИМХО и не связано с андроидом.

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

Хорошие менторы ведь тоже не просто так появились

Либо самому методом проб и ошибок, но в команде лучше и быстрее.

Как ты в данном случае свернешь [Int, MyType, Int] [Int, Int, Int] тут уже реально, без реализации всех возможных plus для MyType | Int не обойтись

Окей, пpинято. В случае, если добавляем еще две опеpации, эта пpоблема pешится, так? То есть: Int -> MyType -> Int Int -> Int -> Int

Хороший ментор ИМХО это опытные коллеги по команде. Невозможно реально расти, если сидишь в своем соку. Это мое ИМХО и не связано с андроидом.

вот я с этим согласен на 99%...

Как ты в данном случае свернешь [Int, MyType, Int] [Int, Int, Int] тут уже реально, без реализации всех возможных plus для MyType | Int не обойтись

Ну, да, написал выше о том же.

То есть мне нужны 4 функции и union тип, котоpый получится заговнокодить только чеpез sealed class?

Окей, пpинято. В случае, если добавляем еще две опеpации, эта пpоблема pешится, так? То есть: Int -> MyType -> Int Int -> Int -> Int

да, проблема решится, так как ты описал все вариации полугруппы для Int | MyType =)

да, проблема решится, так как ты описал все вариации полугруппы для Int | MyType =)

Ну, логично.

Ну да, действительно целью стоит написать одно приложение Вопрос лишь в том, с чего начать

https://android.jlelse.eu/learn-kotlin-while-developing-an-android-app-part-1-e0f51fc1a8b3

https://android.jlelse.eu/learn-kotlin-while-developing-an-android-app-part-1-e0f51fc1a8b3

Спасибо

какие есть хорошие DI библиотеки для котлина (желательно андроид), кроме дагера?

koin, toothpick и прочие, что из них удобнее для работы?

koin, toothpick и прочие, что из них удобнее для работы?

koin топчик

koin топчик

++ удобно реально

получше чем кодеин как по мне

Я так понял много кто перестает юзать Gson в связке с котлином. Так а куда перекатываеться? (инб4 коши/моши джексон)

получше чем кодеин как по мне

чем?

koin топчик

+++

koin легковеснее и живее по контрибьюторам

хотя у меня приложуха на ~100 компонентов, я их вручную описал все. пока доволен полотном кода)

чем?

в основном синтаксисом )

Я так понял много кто перестает юзать Gson в связке с котлином. Так а куда перекатываеться? (инб4 коши/моши джексон)

почему перестают?

он же на рефлексии работает

бывают проблемы с датакласами

не то чтоб меня сильно парило, все равно все в маппере словить можно

но просто интересно стало что народ использует

а, понятно, какой нить неконсистентный апи

для которого сложно вывести нормальные дтошки. беда )

а, понятно, какой нить неконсистентный апи

ну всегда есть риск получить нех в джейсоне

гсон пропустит его с налами в датакласс котлина

почему перестают?

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

ага, теперь более ясно в чем прикол

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

та я вот смотрю на Kotshi

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

А если тут кто-то pазбиpался с Redux (me.tatarka.redux) – можете подсказать, динамически цеплять/отцеплять middleware же можно, так?

Мне очень-очень хотелось бы узнать ответ на этот вопpос, ибо без этого навpяд-ли получится пеpейти на single source of truth store..

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

Как-то я с трудом представляю себе десериализацию JSON, которая бы с нулабельностью нормально дружила, особенно, если JSON без валидации схемы. Там любое из полей может отсутствовать. Что в этом случае должен записать в поле гипотетический десериализатор? По мне, так все дата классы, десериализующиеся из JSON, должны содержать только nullable поля.

Как-то я с трудом представляю себе десериализацию JSON, которая бы с нулабельностью нормально дружила, особенно, если JSON без валидации схемы. Там любое из полей может отсутствовать. Что в этом случае должен записать в поле гипотетический десериализатор? По мне, так все дата классы, десериализующиеся из JSON, должны содержать только nullable поля.

если ожидается !null в поле, то генерировать ошибку при отсутствии поля. Разве не так?

Как-то я с трудом представляю себе десериализацию JSON, которая бы с нулабельностью нормально дружила, особенно, если JSON без валидации схемы. Там любое из полей может отсутствовать. Что в этом случае должен записать в поле гипотетический десериализатор? По мне, так все дата классы, десериализующиеся из JSON, должны содержать только nullable поля.

должен вернутся нул вместо объекта, а не как гсон вернёт обект где поле вдруг нул =)

ну или падать сразу

Всем привет! 20 сентября в Москве в офисе Леруа Мерлен состоится Kotlin Moscow User Group Meetup. Темой митапа будет Kotlin/JS. Переходи по ссылке и регистрируйся. Для тех, кто не сможет присутствовать будет организована онлайн-трансляция. Ссылка появится в день митапа. #kotlin #meetup https://leroy-merlin.timepad.ru/event/799371/

ну или падать сразу

Ну это делается простой обёрткой валидатором поверх Gson. Не вижу особого смысла весь десериализатор писать с нуля ради такой проверки.

Ну это делается простой обёрткой валидатором поверх Gson. Не вижу особого смысла весь десериализатор писать с нуля ради такой проверки.

яб предпочёл что бы гсон пофиксили =))))

но обёртка да, уже написана

яб предпочёл что бы гсон пофиксили =))))

гсон на Java написан, там в системе типов нет nullability, так что не ясно, как его должны поправить.

всё что без аннотации @Nullable должно быть? =) jackson вот вроде так умеет

Я так понял много кто перестает юзать Gson в связке с котлином. Так а куда перекатываеться? (инб4 коши/моши джексон)

https://github.com/wizzardo/json-benchmarks

Ну это делается простой обёрткой валидатором поверх Gson. Не вижу особого смысла весь десериализатор писать с нуля ради такой проверки.

там сама суть что moshi сделан по алгоритсму гсона, но с небольшими оптимизациями, а kotshi по сути как раз обертка над moshi

Я так понял много кто перестает юзать Gson в связке с котлином. Так а куда перекатываеться? (инб4 коши/моши джексон)

я юзал Klaxon, например

https://github.com/wizzardo/json-benchmarks

было бы звдоро в будущем увидеть раздельные чарты по pojo и мапам =) а то глаза ломаются =) но это так, если захочется =)

ERROR: S client not available

Я на днях собираюсь обновить это всё, можно и отдельные графики сделать

Какие-нибудь ещё либы добавить?

Klaxon часто всплывает

ещё было бы круто замерить потребление памяти при парсинге больших json'ов =)

Klaxon часто всплывает

От там есть, примерно первый с конца

Participants: Boon Circe DSL-JSON Fastjson Genson Gson Jackson Jackson-afterburner JSR 353 Glassfish (javax.json) json.org Json-iterator Mjson Minimal-json Moshi Tools-json

ещё было бы круто замерить потребление памяти при парсинге больших json'ов =)

Непонятно как это мерить

Забыл в список добавить(

Непонятно как это мерить

согласен =) но вдруг ты волшебник =)

Непонятно как это мерить

jol

согласен =) но вдруг ты волшебник =)

?

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

Могу рендерить графики аллокации памяти

Оно в jmh есть из коробки

ну хоть что-то =)

Забыл в список добавить(

и kotlinx тоже ?

всё что без аннотации @Nullable должно быть? =) jackson вот вроде так умеет

Ну часть пользователей gson, возможно, думает, что @Nullable спасает. Другие резонно считают, что если nullability не проверяется на этапе компиляции, то всякие аннотации - попытка ситом укрыться от дождя. Так как gson предоставляет Java API, то логично предполагать, что nullabllity в нём не проверяется и не будет проверяться => надо самому допиливать. Не очень понимаю претензию к gson, поведение его десериализатора вполне себе разумно, функции валидации десериализованных объектов он не содержит.

Ну часть пользователей gson, возможно, думает, что @Nullable спасает. Другие резонно считают, что если nullability не проверяется на этапе компиляции, то всякие аннотации - попытка ситом укрыться от дождя. Так как gson предоставляет Java API, то логично предполагать, что nullabllity в нём не проверяется и не будет проверяться => надо самому допиливать. Не очень понимаю претензию к gson, поведение его десериализатора вполне себе разумно, функции валидации десериализованных объектов он не содержит.

да нет никаких таких пртензий, просто перестают юзать (сам юзаю =)))

Как-то я с трудом представляю себе десериализацию JSON, которая бы с нулабельностью нормально дружила, особенно, если JSON без валидации схемы. Там любое из полей может отсутствовать. Что в этом случае должен записать в поле гипотетический десериализатор? По мне, так все дата классы, десериализующиеся из JSON, должны содержать только nullable поля.

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

Ну часть пользователей gson, возможно, думает, что @Nullable спасает. Другие резонно считают, что если nullability не проверяется на этапе компиляции, то всякие аннотации - попытка ситом укрыться от дождя. Так как gson предоставляет Java API, то логично предполагать, что nullabllity в нём не проверяется и не будет проверяться => надо самому допиливать. Не очень понимаю претензию к gson, поведение его десериализатора вполне себе разумно, функции валидации десериализованных объектов он не содержит.

никто не придирается, он просто не саппортит котлин

А из жавы можно как-то проверить поле наллабл или нет?

Ну часть пользователей gson, возможно, думает, что @Nullable спасает. Другие резонно считают, что если nullability не проверяется на этапе компиляции, то всякие аннотации - попытка ситом укрыться от дождя. Так как gson предоставляет Java API, то логично предполагать, что nullabllity в нём не проверяется и не будет проверяться => надо самому допиливать. Не очень понимаю претензию к gson, поведение его десериализатора вполне себе разумно, функции валидации десериализованных объектов он не содержит.

В котлине то это не аннотации, а разные типы. Если в джейсоне вместо строки передать число или обьект - джисон упадет. Вполне резонно хотеть, чтобы с нулибильностью было так же. И вполне понятно, почему джавовый джисон так не делает.

А из жавы можно как-то проверить поле наллабл или нет?

Только во время компиляции, не в рантайме.

можно ещё посмотреть в код метода, там проверки на null могут быть ?

Геттера? Мы же поля через рефлекшн запихиваем, не трогаем методы

А из жавы можно как-то проверить поле наллабл или нет?

можно ещё посмотреть в код метода, там проверки на null могут быть ?

Геттера? Мы же поля через рефлекшн запихиваем, не трогаем методы

забыл ответ сделать)

kotlinx.serialization ещё есть

Он вроде как использует kapt, создаёт сериализаторы, типа autovalue... Но это не точно