Ладно, понял. А чего в одном то?

да я про то, что слова "даггер" и "модный" в одном предложении не уместны) все про то же короче

Ага, даггер это уже "энтерпрайзно" (куча бойлепрейта и боли)

...равно как и RxJava

Асинхронный код это всегда боль

Асинхронный код это всегда боль

Намана

Асинхронный код это всегда боль

Если смешивать его с синхронным

Асинхронный код это всегда боль

скорее многопоточный, а не асинхронный

Если смешивать его с синхронным

Если смешивать его с логикой (ну да "логика" она обычно синхронная). Не умеет народ в "Decisions - Effects - Segregation", все мешают в кучу, а потом страдают.

бойлерплейта СЛИШКОМ МНОГО кодогенерация, абсолютно невнятные ошибки

Если смешивать его с логикой (ну да "логика" она обычно синхронная). Не умеет народ в "Decisions - Effects - Segregation", все мешают в кучу, а потом страдают.

Я статью недавно по этому поводу читал, ща поищу

Чувствую холиваром пахнет. На Reddit такой тред развели на тему DI vs ServiceLocator. Koin/Toothpick/Kodein vs Dagger 2.

Если смешивать его с логикой (ну да "логика" она обычно синхронная). Не умеет народ в "Decisions - Effects - Segregation", все мешают в кучу, а потом страдают.

https://dev.to/joelnet/why-async-code-is-so-damn-confusing-and-a-how-to-make-it-easy-3441

Там js правда

Аналогично. Каждому инструменту - свое место.

Кто-то сказал даггер?!

Нашел еще одну DI библиотеку Koin https://github.com/InsertKoinIO/koin

скорее многопоточный, а не асинхронный

Ну race conditions можно и в js получить. Тем более что асинхронный-код - явный признак, что делаются "сайд эффекты", а это уже большой минус к пониманию/детерменированности программы.

для труъ Котлин-девов

Нашел еще одну DI библиотеку Koin https://github.com/InsertKoinIO/koin

С подключением

балин, всего-то месяц не заходил сюда

Нашел еще одну DI библиотеку Koin https://github.com/InsertKoinIO/koin

а я думал криозаморозку еще не изобрели)

Привет мужики

для труъ Котлин-девов

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

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

ну мало, может кто не видел. а то думают, что кроме даггера ничего нету

ну мало, может кто не видел. а то думают, что кроме даггера ничего нету

да тут Toothpick у многих в продакшне, о чем ты вообще)

ну мало, может кто не видел. а то думают, что кроме даггера ничего нету

А еще для котлина kodein есть

А еще для котлина kodein есть

мне не зашло =(

после коина

хотя в целом весьма похожи

Мне тоже (хотя я вообще считаю что DI не нужен)

Мне тоже (хотя я вообще считаю что DI не нужен)

фреймворки или в целом?

В целом. DI не нужен, нужно просто разделять эффекты и логику и все будет очень просто и тестируемо (только в ооп с этим проблеммы(.

Мне твое предложение напомнило недавнюю статью на хабре про RESS-архитектуру (https://habr.com/post/424081/)

Там чувак пишет про то, что не нужны MVC/MVVM/VIPER и т.д.

Мне твое предложение напомнило недавнюю статью на хабре про RESS-архитектуру (https://habr.com/post/424081/)

ну у него-то сарказм был, а в статье чувак обдолбался)

ну у него-то сарказм был, а в статье чувак обдолбался)

А я-то сразу не понял.

Это очень ограниченный взгляд на вопрос. За пределами андроида жизнь тоже есть и там пишут не только ооп на джаве. Советую ознакомится с: - https://youtu.be/cxs7oLGrxQ4 , в виде статьи http://blog.ploeh.dk/2017/02/02/dependency-rejection/ - https://youtu.be/9zpG_hJsrL8

Реквестирую стикер «доведение до абсурда»

https://www.gitignore.io/api/android

Мне твое предложение напомнило недавнюю статью на хабре про RESS-архитектуру (https://habr.com/post/424081/)

лень читать целиком, тезисы годные

бест практис — не использовать реалм 😃

данные же имеет смысл читать подписками?..

тогда реалм сам принесёт обновления

лень читать целиком, тезисы годные

Никто не заставляет использовать VIPER со всей его громоздкостью для одностраничного промо-приложения :) Для каждого приложения свои ограничения. Ну а в целом, если абстрагироваться, чувак описал MVC, где C - это Activity.

Никто не заставляет использовать VIPER со всей его громоздкостью для одностраничного промо-приложения :) Для каждого приложения свои ограничения. Ну а в целом, если абстрагироваться, чувак описал MVC, где C - это Activity.

Да и вообще в любом приложение стоит задуматься "а нужно ли всю доменную сложность переносить на клиент?"

бест практис — не использовать реалм 😃

+

лучше сразу Rx, чтоб по полной)

+

так, а тебе-то чем не нравится?)

Работа с потоками

Да и вообще в любом приложение стоит задуматься "а нужно ли всю доменную сложность переносить на клиент?"

Опять же, если говорим про тупые REST - да, в большинстве случаев можно вынести все на бекенд (если он свой, конечно, а не кастомера). Если про более или менее самостоятельное приложение, а не thin-client, то без домена не обойтись.

Не работает equals

Так и сделал)

Поменялось ли что-то

Опять же, если говорим про тупые REST - да, в большинстве случаев можно вынести все на бекенд (если он свой, конечно, а не кастомера). Если про более или менее самостоятельное приложение, а не thin-client, то без домена не обойтись.

Ну ты посмотри на facebook/instagram, да тот же телеграм - это же тупейший crud (да если же на сокетах). Да и инстаграм это отдельно подтвердил - выпустив Instagram Lite (просто webview).

Ну ты посмотри на facebook/instagram, да тот же телеграм - это же тупейший crud (да если же на сокетах). Да и инстаграм это отдельно подтвердил - выпустив Instagram Lite (просто webview).

VoIP, AR/VR, ML - там нельзя обойтись бекендом. Не берусь утверждать, как сделано у FB, но те же фильтры в Instagram логичнее сделать на клиенте.

VoIP, AR/VR, ML - там нельзя обойтись бекендом. Не берусь утверждать, как сделано у FB, но те же фильтры в Instagram логичнее сделать на клиенте.

ML как раз почти всегда на бекенде

Кто-то пробовал object box?

VoIP, AR/VR, ML - там нельзя обойтись бекендом. Не берусь утверждать, как сделано у FB, но те же фильтры в Instagram логичнее сделать на клиенте.

их логичнее сделать с обеих сторон :)

VoIP, AR/VR, ML - там нельзя обойтись бекендом. Не берусь утверждать, как сделано у FB, но те же фильтры в Instagram логичнее сделать на клиенте.

Там ML - это же просто обученная модель, которая вызывается одной функцией (ее же НЕ обучают на клиенте). Ну VoIP, AR/VR это же просто готовые библиотеки, это не архитектура (viper/mvp там дагеры)

Работа с потоками

ты делаешь что-то не так

их логичнее сделать с обеих сторон :)

Ну я к тому, чтобы обработать фотку локально без сети. Зачем для этого лазить на сервер?

на мосдроид сходил? xD

ну парсить протобаф

Там ML - это же просто обученная модель, которая вызывается одной функцией (ее же НЕ обучают на клиенте). Ну VoIP, AR/VR это же просто готовые библиотеки, это не архитектура (viper/mvp там дагеры)

Готовые либы, вокруг которых нужно навернуть в 95% случаев свою логику, которую куда-то надо складывать.

изменится все - ппц

Там ML - это же просто обученная модель, которая вызывается одной функцией (ее же НЕ обучают на клиенте). Ну VoIP, AR/VR это же просто готовые библиотеки, это не архитектура (viper/mvp там дагеры)

на телефонах к тому же нормальный ML не поюзаешь - слишком медленно будет

протобаф — это вообще не про скорости

протобаф — это вообще не про скорости

да и размер там не всегда намного меньше

да и размер там не всегда намного меньше

меньше чего?

меньше жсона

если мало данных ты и не заметишь

Ну я к тому, чтобы обработать фотку локально без сети. Зачем для этого лазить на сервер?

Смотри, вот псевдо-код 😏 это все что требуется от "клиента" fun addFilterOnPhone(model: MLModel, image: Image): Image = model.apply(image) "Архитектура" (на 100 модулей) тут не нужна. Все остальное сделали умные дяди и туже модель можно скачать с бэка.

меньше жсона

больше жсона только XML

больше жсона только XML

если gzipped json, то разница невелика по сравнению с протобафом

если gzipped json, то разница невелика по сравнению с протобафом

в память всё равно не gzipped загрузишь

в память всё равно не gzipped загрузишь

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

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

к сожалению, будешь, если бизнесу будет нужно)

к сожалению, будешь, если бизнесу будет нужно)

тогда протобаф тоже не подойдет и нужно придумывать что-то свое

тогда протобаф тоже не подойдет и нужно придумывать что-то свое

Чтобы что?