лежит, да

вот только сучонок работать не хочет)))

Расскажите, что значит вот такая запись? class Singleton { public Object get() { synchronized(Singleton.class) { return instance; } }

Можно же залочить и объектом

вот в чем принципиальная запись между ними?

synchronized(obj) {}

где, obj - заранее проинициализированное поле этого же класса

@kmaxim смотри на static-методы

Расскажите, что значит вот такая запись? class Singleton { public Object get() { synchronized(Singleton.class) { return instance; } }

это аналогично синхронизации на статичесом финальном объекте

и знаешь, такую запись считают плохой практикой

Желательно не синхронизироваться на SomeClass.class

Расскажите, что значит вот такая запись? class Singleton { public Object get() { synchronized(Singleton.class) { return instance; } }

Можно, но зачем создавать объект, если можно залочить класслоадер

запись - на .class?

запись - на .class?

На класс класса)

и знаешь, такую запись считают плохой практикой

Синглтон на enum - наше все!

Синглтон на enum - наше все!

+

Правда без ленивой инициализации

+ лучше уже Kotlin-й синглтон

ага, я когда-то читал 4 способа организации Singleton в джава

ага, я когда-то читал 4 способа организации Singleton в джава

Способов много, но каждый с проблемами

Способов много, но каждый с проблемами

какие проблемы могут быть у enum синглтона?

какие проблемы могут быть у enum синглтона?

Нет линивой инициализации

Нет линивой инициализации

справедливо

+ бывают случаии, когда для создания инстаца нужен к примеру Context (я такого не люблю, но так делают)

синглтон - воообще анти-паттерном считается

синглтон - воообще анти-паттерном считается

Следовать все правилом - так же рыть себе могилу

синглтон - воообще анти-паттерном считается

слышал ткое мнение уже - случаем не из-за нарушения SRP?

Желательно не синхронизироваться на SomeClass.class

Почему это плохо?

где считается? кто считает?)

где считается? кто считает?)

Это просто способ, который в неумелых руках превращается сквозную функциональность + найдется тот кто еще утечку памяти так заработает

первая ссылка в гугле

А так, я нормально бы к ним относился

http://automated-testing.info/t/singleton/1636

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

Та ясное дело

первая ссылка в гугле

Но это теория, а есть практика

а так вообще, я и сам долгое время баловался синглтоном ))

ну там все про большую жаву

а так вообще, я и сам долгое время баловался синглтоном ))

Да ваш же Dagger те же самые синглотоны позволяет создавать (если не вдаваться в подробности)

тут ресурсы ограничены: я не говорю что все надо в синглтонах делать - но они нужны в некоторых случаях

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

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

К примеру, можно ApplicationContext зажать в синглтон и все, в любом месте используешь

memory leaks

не стоит контекст хранить

У нас тут мобайл, нам крайне нежелательно создавать много объектов и провоцировать гц

memory leaks

А в чем проблема хранить applicationContext?

где лики?

memory leaks

В чем тут утечка?

У нас тут мобайл, нам крайне нежелательно создавать много объектов и провоцировать гц

А ырыкс наоборот кучу создает

кому нужен rx)Ну кроме мульти сетевых запросов)

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

смотря где

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

Когда один раз используешь - не страшно, но в цикле там элементарно миллисекунды съедаются

снаружи уже нет(

Вот как раз я про "снаружи" :)

@andremacareno гугл же где-то говорил, что сеттеры с геттерами далвик оптимизирует? Миллисекунды?!

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

@andremacareno гугл же где-то говорил, что сеттеры с геттерами далвик оптимизирует? Миллисекунды?!

Я сам вчера гонял, сет + нью еще перепроверю, а вот геттеры точно проигрывают что в далвике, что в арт

В чем тут утечка?

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

@volkovskiyda и что, ты его слушаешь?

всегда

не

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

Когда переопределяешь Application и хранишь в нем самого себя - не говорит

не компилятор а lint

ты ему укажи что тут безопасно

К тому же, ты можешь просто зануллить ссылку, когда тебе она больше не нужна

всегда

Дак в чем утечка? Утечка ссылки на то что для жизненного цикла приложения и ак выступает в роли синглтона?

А кстати, геттеры/сеттеры съедают же лимит методов DEX?

Я в последних приложениях для DTO стал юзать паблик-поля просто