на практике такие заморочки с оптимизацией не нужны, просто один конкретный кейс попался. Когда загрузка занимала 240 секунд)

теперь 15с, жить можно)

11к элементов это не мало

а что там так много отправляется?

товары из сети, предв. обработка, запись в БД

а памяти в хипе сколько выделено?

Мм, так как ни бей, запись в бд замки на порядок больше

Займет

да

кроме этой оптимизации еще и саму запись в БД оптимизировали, пришлось raw SQL в обход ORM делать

а памяти в хипе сколько выделено?

Android, точно не замерял)

а.. а то на бекенде обрабатывать по 11к как-то накладно)

есть нюансы)

разбить 11к элементов на куски занимает ~200мс на моем компе, думаю, никакого значения что ты будешь для этого использовать не имеет

Итого: 11000 элементов С помощью Rx и оператор Buffer 100 - 18c 500 - 14c 1000 - 14c С помощью Kotlin и приведенный splitBy метод 100 - 47с 500 - 17с 1000 - 16с

JMH?

Иначе - отсебятина

JMH?

Это кажется вообще Android

Это кажется вообще Android

Да пофиг, алгоритмы через jmh гонять и на компе можно

Понятное дело что арт/далвик исказят немного, но это будет уже проблема чисто андроида

встал такой кейс с корутинами. а как мокать suspend функции?)

дежавю :)

?)

Я не подскажу, по какой фразе искать, но такой вопрос уже вставал раза три, в т. ч. в ближайшие пару дней.

чет не припомню. вроде регулярно почитываю чатик)

(сам не читал)

https://medium.com/@tonyowen/android-kotlin-coroutines-unit-test-16e984ba35b4

https://medium.com/@tonyowen/android-kotlin-coroutines-unit-test-16e984ba35b4

именно по этому кейсу там нет рецепта

Эх, а у object-классов никак нельзя конструктор реализовать? Прям в печаль ввело.

init {}

init на что ?)

Мне туда надо передать Context. Чем тут init поможет?

так пиши свой кастомный метод

и хранить контекст в статических классах — плохая идея

Эх, а у object-классов никак нельзя конструктор реализовать? Прям в печаль ввело.

Есть object expressions, а есть object declarations, оба являются видами классов. :)

Есть object expressions, а есть object declarations, оба являются видами классов. :)

Я про тот, что выполняет роль синглетонов)

Мне туда надо передать Context. Чем тут init поможет?

Если объекту нужны параметры, значит, он не должен быть синглтоном.

Если объекту нужны параметры, значит, он не должен быть синглтоном.

Спорное утверждение)

и хранить контекст в статических классах — плохая идея

Кстати, почему? Код фреймворка так делает. (я не про контекст Activity, конечно)

Спорное утверждение)

Какой нужен контекст?

Какой нужен контекст?

Любой который имеет доступ к шаредпреференсам)

потому что это потенциальная утечка памяти контекст — очень непонятная и сложная штука ) >Код фреймворка так делает например, какой?

так что хоть приложения самого)

Любой который имеет доступ к шаредпреференсам)

Тогда можно инициализировать работу с префами в классе приложения. By the way, есть Kotpref, и он хранит контекст статически :)

потому что это потенциальная утечка памяти контекст — очень непонятная и сложная штука ) >Код фреймворка так делает например, какой?

LocalBroadcastManager — ну ок, это не фреймворк, это support :) Кажется, в ActivityThread есть что-то такое.

Тогда можно инициализировать работу с префами в классе приложения. By the way, есть Kotpref, и он хранит контекст статически :)

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

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

Нет, не логично. Ты можешь захотеть подменить его для тестирования.

Нет, не логично. Ты можешь захотеть подменить его для тестирования.

Он происходит от интерфейса, подменить его не проблема.

тут вопрос в том, что если вы храните у себя контекст какого-то не того уровня (например, активити), оно может не умирать и висеть в памяти. а т.к. applicationContext и Activity это Context, то очень легко ошибиться я, например, от синглтонов отказался, в роли оных выступает обычно сингл-инстанс класс в графе

ты можешь инициировать свой менеджер сразу префсами

Суть сейчас не в том чем инициировать, а в том, что банальной возможности сразу нет этого сделать, т.к. конструкторам сказали досвидос в object'ах. :(

Это надо какой-то initIt() делать и там все делать, не забывая вызывать его где-то

Вот о чем и говорю, делать отдельную инициализацию придется

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

можно было бы как-то сахарно встроить инициализацию объекта

Это было бы банально как и эта инициализация руками, просто предусмотренная языком. Вместо Kotpref.init(context) можно было бы вызвать Kotpref(context) и все. Одно и тоже, но смотрится то секазнее. Имхо)

А что, кстати, за internal var?

package-private

Ох е)

Это было бы банально как и эта инициализация руками, просто предусмотренная языком. Вместо Kotpref.init(context) можно было бы вызвать Kotpref(context) и все. Одно и тоже, но смотрится то секазнее. Имхо)

Так что это за синглтон, если вы в любой момент через конструктор можете создать себе еще инстансов?

Так что это за синглтон, если вы в любой момент через конструктор можете создать себе еще инстансов?

Из моего описания ясно, что в данном случае конструктор выступал бы тупо в роли инициализации.

package-private

package-private в котлине нету. internal - это видимость на уровне модуля.

Это было бы банально как и эта инициализация руками, просто предусмотренная языком. Вместо Kotpref.init(context) можно было бы вызвать Kotpref(context) и все. Одно и тоже, но смотрится то секазнее. Имхо)

package-private в котлине нету. internal - это видимость на уровне модуля.

ну, да

module-private тогда, вернее, справедливо

Это было бы банально как и эта инициализация руками, просто предусмотренная языком. Вместо Kotpref.init(context) можно было бы вызвать Kotpref(context) и все. Одно и тоже, но смотрится то секазнее. Имхо)

А если такое выражение выполнить несколько раз? С разными аргументами. Не должен быть такой класс синглтоном.

А если такое выражение выполнить несколько раз? С разными аргументами. Не должен быть такой класс синглтоном.

Поменять или обновить его? С init'ом точно такая же ситуация, просто вид другой)

Поменять или обновить его? С init'ом точно такая же ситуация, просто вид другой)

init — это явный костыль. Таких вещей на уровне языка быть не должно.

А какого-то правила, что синглтон не должен получать и хранить данные - глупость какая-то) Синглтон главное чтобы был один, а там уже что надо пусть то и делает.

А какого-то правила, что синглтон не должен получать и хранить данные - глупость какая-то) Синглтон главное чтобы был один, а там уже что надо пусть то и делает.

А если нужны два инстанса с разными данными?

А если нужны два инстанса с разными данными?

То это уже какой-то и не синглтон)

То это уже какой-то и не синглтон)

Потому что синглтон не должен получать данные!

Он должен быть независимым.

С чего это?

Нормальные синглтоны получаются из чистых функциональных объектов.

Он должен быть один, про независимость это уже ваши какие-то правила)

С чего это?

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

Тогда уже по определению человек не так мыслит

Ему значит нужен не синглетон

Тогда уже по определению человек не так мыслит

, создавая зависимый синглтон.

Раз несколько экземпляров.

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

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

Я не фанат клин, это не о том вообще.

Суть та же - убрать зависимости)

То, что есть контекст приложения, который повсеместно нужен — не нормальная данность, а косяк Андроида.

Это факт)

Суть та же - убрать зависимости)

Ага, сделать зависимости неявными и стрелять себе в ноги.

Но от того, что андроид был изначально спроектирован через жопу - я не собираюсь отказыаться от синглов, который часто спасают) Да, это не лучший путь делать его зависимым - но от него никуда не деться)

Держать их в Application. Они будут effectively-синглтонами, но без костылей.

Как-то мне это кажется еще более зависимым, хах)

Про синглтон совсем недавно статья на Хабре была, в целом более менее толковая

Там конечно срача в комментах развели

А что касается андроида, то он сделан не удачно в этом смысле, синглтон для апликейшна так и просится. Но вроде можно обойтись если Даггер прикрутить

кто знает как решить?