Konstantin
поясни для дцп плиз )
Nikita
опа, с двумя админами оперативнее спам удалять начали
Mike
С двумя? Лол, нас тут по меньшей мере пятеро
Mike
Lë
а не для тестирования
Lë
для тестирования достаточно 5-6 девайсов разных Android API, и разными форматами
Konstantin
а как лучше тестить если нет фермы а приложение объемное по экранам?
Nikita
а как лучше тестить если нет фермы а приложение объемное по экранам?
genymotion, нативный эмулятор, побольше оперативки и вперед!
Konstantin
ясно спасибо
Nikita
да и вас это не должно волновать как разработчика, пусть тестеры мучаются этим
Konstantin
меня бесит переделывать и не люблю разработку "huyaks-huyaks-v-prod-driven development"
Сергей
Жалко стикеры нельзя. У меня есть три в тему
Danil
народ гле можно купить clean code robert martin в москве
Danil
за скока
Igor
Ребят, кто как сдвигает свайпом только часть элемента в ресайклере, чтобы отобразить элемент удаления, юзаю свайп с ItemTouchHelper, но он удаляет сразу при свайпе, какой тут лучше подход?
Konstantin
смахнуть и показать кнопку отката
смахнуть и показать кнопку подтверждения
смахнуть не до конца
выбирай
Konstantin
в виде кнопки может быть даже снекбар например
Igor
смахнуть и показать кнопку отката
смахнуть и показать кнопку подтверждения
смахнуть не до конца
выбирай
смахнуть не до конца, то есть где-то на 2/3 экрана, а 1/3 кнопка удалить
Konstantin
а в последнем варианте ты рисуешь "фон" типа с кнопкой для удаления, там какая то дичь вобщем то, что ты не можешь реальный лэйаут разместить с реальными кнопками т.к. они не реагируют т.к. их превратили в битмап-фон, и вобщем то интеракции никакой с ними не будет кроме как клика где то в области итема, потом ты определяешь bounds куда нажали, сравниваешь с позициями "фона" где кликнули
Max
как лучше хендлить ЖЦ, через NonConfigurationInstances или спомощью DI ? подписаться\отписаться от презентора
Igor
а в последнем варианте ты рисуешь "фон" типа с кнопкой для удаления, там какая то дичь вобщем то, что ты не можешь реальный лэйаут разместить с реальными кнопками т.к. они не реагируют т.к. их превратили в битмап-фон, и вобщем то интеракции никакой с ними не будет кроме как клика где то в области итема, потом ты определяешь bounds куда нажали, сравниваешь с позициями "фона" где кликнули
хорошо, фон с кнопкой и ловить нажатие, а как сделать чтобы свайп блокировался на 2/3?
Konstantin
это где в тачхелпере вроде настраивается
Konstantin
понял идею спасибо, буду пробовать
https://stackoverflow.com/questions/41015101/itemtouchhelper-limit-swipe-width-of-itemtouchhelper-simplecallback-on-recycle
Igor
https://stackoverflow.com/questions/41015101/itemtouchhelper-limit-swipe-width-of-itemtouchhelper-simplecallback-on-recycle
оо спасибо, только полез искать!
Alexey
как лучше хендлить ЖЦ, через NonConfigurationInstances или спомощью DI ? подписаться\отписаться от презентора
посмотреть реализацию у moxy/moxby)
Max
в вопрос вы попали точно - но от вашего ответа толку немного😂
Mike
как лучше хендлить ЖЦ, через NonConfigurationInstances или спомощью DI ? подписаться\отписаться от презентора
Даже если не учитывать, что DI — бесполезная херь, nonConfigurationInstance получается более прямолинейно. Мне сложно представить, как вообще можно надёжно решить эту проблему с помощью DI.
Если добавить сюда save/restore, DI становится ещё более болезненным.
Max
Даже если не учитывать, что DI — бесполезная херь, nonConfigurationInstance получается более прямолинейно. Мне сложно представить, как вообще можно надёжно решить эту проблему с помощью DI.
Если добавить сюда save/restore, DI становится ещё более болезненным.
спасибо, а то вот есть примеры реализации МВП например на KOIN .. так у них там каждый раз новый презентор создаётся при создании активити😐 и вообще непонятно в чём заключается хендл ЖЦ тогда, если состояние убили
Mike
спасибо, а то вот есть примеры реализации МВП например на KOIN .. так у них там каждый раз новый презентор создаётся при создании активити😐 и вообще непонятно в чём заключается хендл ЖЦ тогда, если состояние убили
MVP вообще очень хорошо подходит для хелловорлдов, которым ни состояние сохранять не надо, ни конфигурации переживать
Denis
Даже если не учитывать, что DI — бесполезная херь, nonConfigurationInstance получается более прямолинейно. Мне сложно представить, как вообще можно надёжно решить эту проблему с помощью DI.
Если добавить сюда save/restore, DI становится ещё более болезненным.
через Dagger2 можно решить, но получится так, что ты не сможешь переиспользовать презентер
Serhii
Привет, подскажите, как паралельно загружать файлы на сервер? когда надо допустим по 10 одновременно
Max
MVP вообще очень хорошо подходит для хелловорлдов, которым ни состояние сохранять не надо, ни конфигурации переживать
ну МВП он ведь не подразумевает отсутствие состояния?
Denis
состояние чего?
Никита 🙃
MVP вообще очень хорошо подходит для хелловорлдов, которым ни состояние сохранять не надо, ни конфигурации переживать
Ой, да сейчас почти все приложения вертикальные которым это и не надо
Mike
через Dagger2 можно решить, но получится так, что ты не сможешь переиспользовать презентер
А смысл? Можно тогда просто в onCreate написать new.
Denis
ты немного не понял
Denis
через Dagger2 можно сделать presenter @Scope
Mike
Ой, да сейчас почти все приложения вертикальные которым это и не надо
Ну если они готовы проебать данные пользователя при смене языка или пересоздании процесса, тогда и не надо.
Denis
Синглетон на все приложение
Denis
и для работы с одной активностью этого достаточно
Denis
но возникает проблема, что повтороно использовать не получится его
Igor
Ребят вы тут интересную тему подняли,а если SingleActivity, то какой смысл в MVP и MVVM?
Max
А зачем для этого DI? Можно говнокодить и без него.
можно сделать скоуп в DI, открыть его при создании view и закрыть в ондестрой != смена конфигурации, это норм?
Mike
Ребят вы тут интересную тему подняли,а если SingleActivity, то какой смысл в MVP и MVVM?
А какая связь между презентейшен-шаблоном и количеством активитей?
Denis
Max
Ребят вы тут интересную тему подняли,а если SingleActivity, то какой смысл в MVP и MVVM?
сингл активити не подразумевает сингл вью .. в каждом вью своя логика отображения
Mike
можно сделать скоуп в DI, открыть его при создании view и закрыть в ондестрой != смена конфигурации, это норм?
хз, я не знаю, как это будет работать
Igor
А какая связь между презентейшен-шаблоном и количеством активитей?
ну фактически они завязываются на ЖЦ, хотя мы их скоупами DI можем регулировать и другими методами
Denis
хз, я не знаю, как это будет работать
это будет работать, но лучше написать манагера для презентеров
✙
в презентации Toothpick чувак делал в пару строчек переживание фрагмента презентером
✙
скоупами
✙
норм
Denis
но сам презенетер лучше получать из вне
Denis
используя паттерн DI
Igor
так а фрагменты чем лучше их ЖЦ зависит от активити?
Max
в презентации Toothpick чувак делал в пару строчек переживание фрагмента презентером
туспик очень скоуповый.. тоесть сделать модуль с презентором и чем нужно для кажого фрагмента, и при создании вью - создать скоуп, при дестрое вью - убить скоуп
✙
и пока не будет closeScope(), твой презентер будет жить
✙
это всё в рамках обычных классов
✙
без мокси и т.д.
Mike
потому что тогда можно будет использовать один презентер для нескольких view
Что мешает делать это без DI?
Denis
ничего)
Denis
но по правилам Clean Architecture ты должен получать зависимости из вне
Denis
паттерн DI
Igor
согласен и даже не спорю, просто я за то, чтобы регулировать презентер или вьюмодел даггером используя скоуп, а не полагаться на ЖЦ
Denis
и делать new в OnCreate() тогда не очень правильно