Это уже специфика. Все зависит от того что нужно тебе

По RX миллион либ всяктх

у меня сервера нет потому retrofit мне не нужен. но хочется rx поюзать и грамотно обработать перевороты экрана

Я в таких кейсах не юзал рх

Я для сети и диалогов его юзаю в основном

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

Не делать запрос внутри активити/фрагмента

Тут MVC поможет. Либо прост синглетон сделать и в нём все делать, а активити просто результат забирать будет

А как в активити показать результат?

У синглетона его забрать, либо eventbus

в сторону дагера глянуть?

Нууу можно и на нем. Но если маленькая программа, то и без него можно

ок ) спасибо ))

ссылку на контекст в презентер как лучше всего передавать? weak, soft или обычный reference?

Ребята можно ли этот код... public void killPoint(View view){ Handler().postDelayed(new Runnable() {public void run() { //Code }}, 200);} ... заменить вот этими кодами? public class goRunnable implements Runnable { public void run() { //Code }} public void killPoint(View view){ Handler().postDelayed(goRunnable, 200);} И решит ли это проблему постоянного пересоздования Runnable при вызове хэндлера в целях оптимизации?

Ребят, как можно нормально подогнать кастомный свитч под api 19?

Он растягивается почему то

Ребят подскажите как лучше реализовать аналогичное поведение onPreExecute в AsyncTaskLoader?

12354 не пашет

Ребята можно ли этот код... public void killPoint(View view){ Handler().postDelayed(new Runnable() {public void run() { //Code }}, 200);} ... заменить вот этими кодами? public class goRunnable implements Runnable { public void run() { //Code }} public void killPoint(View view){ Handler().postDelayed(goRunnable, 200);} И решит ли это проблему постоянного пересоздования Runnable при вызове хэндлера в целях оптимизации?

Если goRunnable это экземпляр класса goRunnable, то да (а вообще ты пытаешься сэкономить ~32 байт, какой в этом профит?)

Так этот хэндлер выполняется каждые 1-6 секунд

Ребят, как можно нормально подогнать кастомный свитч под api 19?

9patch

Игор, а откуда такая точность -32 байта?

Или это был сарказм?

Ребят подскажите как лучше реализовать аналогичное поведение onPreExecute в AsyncTaskLoader?

эм... руками? просто сделать метод в котором сначала делаешь то что тебе надо, а потом екзекьютишь таску

Так этот хэндлер выполняется каждые 1-6 секунд

Как то подозрительно это все вместе выглядит. Точно нужна такая функциональность? А для чего?

Анна, как бы Вам обяснить? Вы знаете про Пингвиненка?

Игор, а откуда такая точность -32 байта?

Знак ~ для кого был? Скорее всего меньше, но варавнивание до 32 это максимум. https://www.liaohuqiu.net/posts/android-object-size-dalvik/

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

Анна, как бы Вам обяснить? Вы знаете про Пингвиненка?

Нет :) в целом мне можно не объяснять, это просто подозрительно похоже на кривой дизайн, из серии "лучше так не делать". Если вы точно уверены что это идеальное решение для вашего случая, то вам виднее

Так вот. Там нажимается кнопочка каждые 1-6 секунд. И после нажатия запускается objectAnimator.

Хэндлер запускает objectAnimator.

9patch

Там точки на фоне

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

ок. Больше я писать про него не буду. До заливки в стор.

Ребята можно ли этот код... public void killPoint(View view){ Handler().postDelayed(new Runnable() {public void run() { //Code }}, 200);} ... заменить вот этими кодами? public class goRunnable implements Runnable { public void run() { //Code }} public void killPoint(View view){ Handler().postDelayed(goRunnable, 200);} И решит ли это проблему постоянного пересоздования Runnable при вызове хэндлера в целях оптимизации?

Эти варианты эквивалентны,

Дмитрий, но второй же будет эффективнее?

Так этот хэндлер выполняется каждые 1-6 секунд

Экземпляр класса Runnuble создается в обоих случаях один раз через оператор new. Затем он поподает в handler где у него каждые 1-6 секунд вызывается метод run

Дмитрий, но второй же будет эффективнее?

Чем? Вся разница в том что один класс анонимный другой нет.

Т.е. никакой оптимизации не будет?

Так вот. Там нажимается кнопочка каждые 1-6 секунд. И после нажатия запускается objectAnimator.

Можно просто переменную создать в классе типа Runnable и передать хэндлеру эту переменную

Т.е. никакой оптимизации не будет?

Нет не будет ))

Дмитрий, здесь же во втором случае Runnable создается один раз, а потом тыще раз вызывается этот Runnable. А в первом случае тыще раз Runnable создавался. Это разве не оптимизация?

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

Бахром, а если через переменную Runnable закрутить, а не через класс, то оптимизация будет?

из ексекьюторов

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

Антон, определенной периодичности нету.

за тебя Даг Ли все сделал

а

1-6 секунд.

рандомно чтоли

Когда юзер нажимает на русское слово.

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

Бадя, что еще за state?

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

Хочеш сказать, что андроид может ошибочно вызвать Runnable со старыми переменными?

Дмитрий, здесь же во втором случае Runnable создается один раз, а потом тыще раз вызывается этот Runnable. А в первом случае тыще раз Runnable создавался. Это разве не оптимизация?

Сорян, речь шла о том что метод killPoint каждые 6 секунд вызывается, и тогда да, второй вариант экономичней.

ок. Тогда делаю всеобщую трансформацию кода на второй вариант.

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

Хэндлеров у меня там куча.

а почему не Future поюзать?

Жесткая у вас архитектура xD может вообще без handler обойтись?

Сорян, речь шла о том что метод killPoint каждые 6 секунд вызывается, и тогда да, второй вариант экономичней.

А объясните пожалуйста, почему?

а почему не Future поюзать?

Можно конечно поюзать. Но, есть небольшая проблема - о Future я впервые слышу. А релиз уже через три дня.

разница от ранабла только в том что колабл возвращает результат - фьючер

ERROR: S client not available

А объясните пожалуйста, почему?

Ну при каждом вызове killPoint в первом случае будет создан Runnuble, во втором оператор new отсутствует и просто в очередь задачь handler будет помещен уже существующий экземпляр класса.

Так что получилось - все единогласно за второй вариант?

туда и раннабл можно - FutureTask какой

обьясни юзкейс нормально

2ой вариант не понятен - ты както странно класс передаешь

Бадя, я его перепишу в переменную.

У меня есть таблицы Tag, Note и TagToNote для связи n:n. Если я удаляю тег, надо удалить все связанные записи в TagToNote. С greenDao это придется делать вручную или есть какой-то автоматизированный способ?

Ну при каждом вызове killPoint в первом случае будет создан Runnuble, во втором оператор new отсутствует и просто в очередь задачь handler будет помещен уже существующий экземпляр класса.

В приведённом коде нет информации о том где создаётся goRunnable, вроде. Выигрыш на new будет только если он не создаётся перед вызовом killPoint а это не очевидно ;))

Бадя, я его перепишу в переменную.

Главное не создавайте её строчкой выше :))

@donnanna - о том и речь xD

У меня есть таблицы Tag, Note и TagToNote для связи n:n. Если я удаляю тег, надо удалить все связанные записи в TagToNote. С greenDao это придется делать вручную или есть какой-то автоматизированный способ?

Вручную, каскадное удаление не поддерживается

Спасибо

Главное не создавайте её строчкой выше :))

Имели ввиду чтобы я создал глобальную переменную? Я про это уже знаю.

В приведённом коде нет информации о том где создаётся goRunnable, вроде. Выигрыш на new будет только если он не создаётся перед вызовом killPoint а это не очевидно ;))

Окай ))

Runnable goRunnable= new Runnable {public void run() { //Code }};

кто-то юзает AS 2.4 Preview?

кто-то юзает AS 2.4 Preview?

Пока что берегу свои нервы

кто-то юзает AS 2.4 Preview?

я юзаю

норм проект собирается?

норм если все сделать правильно

у тебя на dex ругается?

Гугол там поменял логику создания dex'ов

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

А пока чтобы все работало как надо, в gradle.properties надо добавить android.useDexArchive=false

либо просто откатить градл на 2.3.1

А пока чтобы все работало как надо, в gradle.properties надо добавить android.useDexArchive=false

спасибо, попробую

либо просто откатить градл на 2.3.1

я хотел потестить java8)

так что не вариант

Ага, оно работает в плане лямбд норм

а остальное с апи24+

А пока чтобы все работало как надо, в gradle.properties надо добавить android.useDexArchive=false

завелось)

Спасибо!