АИ
Ребят, у кого нибудь есть книга Reactive Programming with RxJava - Ebook ? Готов купить со скидкой даже ) всмысле файл
Size: a a a
2017 January 30
М
Она в паблике есть
АИ
Тут кто-то выкладывал?
М
Тут кто-то выкладывал?
Теперь да
АИ
спасибо)
EM
@eugene_matsyuk Посмотрел доклад, спасибо, очень понравился. Такие доклады еще интереснее смотреть, когда уже сам ознокомился с MVP и CleanArchitecture, написал два прокта, понатыкался на проблемы реализации и пробелмы философии (каждый готовит MVP по-своему) и тут видишь в докладе ответы на многие вопросы и лучше начинаешь все понимать.
здорово)
набрасывайте вопросы и свой жизненный опыт, будет очень здорово послушать)
набрасывайте вопросы и свой жизненный опыт, будет очень здорово послушать)
EM
интерактор может знать о контексте?
в субботу как обсуждали это
желательно жить без контекста в бизнес-логике
но все мы люди, и понимает, что всегда есть исключения
вообще если где-то вынужден отклониться от канонов или решаешь задачу нетривиальным путем - документируй
сколько раз я себе говорил спасибо, когда возвращался к своему же коду спустя пару месяцев
желательно жить без контекста в бизнес-логике
но все мы люди, и понимает, что всегда есть исключения
вообще если где-то вынужден отклониться от канонов или решаешь задачу нетривиальным путем - документируй
сколько раз я себе говорил спасибо, когда возвращался к своему же коду спустя пару месяцев
A
Ребят, а что вы думаете по поводу того, чтобы класс модели находился в retained fragment - его время жизни должно превышать время жизни всех экранов, которые его используют. И умирать он должен только если всё закрылось.
A
Или использовать Синглтон даггера? Но как управлять его жизненным циклом?
S
@eugene_matsyuk Основные проблемы начинаются, когда тебе более авторитетный разарботчик вбрасывает такие идеи, которые сильно усложняют жизнь. Вначале я пробрасывал в presenter все методы жизненного цикла Activity. Кто-то сказал, презентер не должен знать о жизненном цикле. Ну для этого есть методы bindView unBindView и вроде их хватает.
Потом кто-то сказал, что нельзя контектс в презентере. У меня большинство случаев использования контектса в презентере - это строковые ресурсы. Все остальные боллее сложные вещи (например работы с пермишенсами) я оставляю в Activity, так как это все сильно завязано на Android. И вот со строками - либо кучу методов созадавать во View, типа покажи такую строчку, покажи такую. Либо один метод - отобрази конкретную строку у конкретного TextView. B вот если просто строчку нужно достать из ресурсов, то можно смело id строки передвать. Но если есть форматирование строки, или plurals, то уже нужен контекст в презентере. Ну и доходит до такого, что в презентер инжектится какой-нибудь ResourcesResolver, который имеет контекст и выдает тебе нужные строки. Но это сильно усложняет жизнь. Да и для тестирования презентера можно спокойно замокать context и выдавать нужные строки. Ну и вы говорите, мол, если жизненно необходимо, можно контекст и в интерактор прокинуть. И мне нравитсят такой подход. Когда начинаешь прямо слепо следовать принципам, то иногда сталкиваешься с оверхедом, нужно просто понимать почему ты себе позволяешь пробросить контекст в презентер, и что после этого будет.
Также понравился раздел про валидацию полей и enable/disable кнопки. Я лично это просто в презентере делал, но мне понравилось как вы закинули в интерактор и покрыли тестами. И с тестами у вас рельно все позновательно и понятно.
Также был момент, что кто-то сказал, что у презентера все методы должны называться как события. Типа произошло это, произошло то. И в таком подходе нельзя сказать презентеру загрузи данные, нужно назвать метод типа "готовДляДанных". Тоже за это долго парились. А на самом деле это такой бред и у вас это хорошо продемонстрированно, что можно иметь в презентере методы listenFields, loadPersonalInfo и говорить презенеру, что делать.
В общем все проблемы от того, что все по своему интерпритируют MVP и накладывают ограничения и впадают в крайности. У вас же все более гибко, и чувствуется, что подход - это инструмент, а не набор ограничений.
Потом кто-то сказал, что нельзя контектс в презентере. У меня большинство случаев использования контектса в презентере - это строковые ресурсы. Все остальные боллее сложные вещи (например работы с пермишенсами) я оставляю в Activity, так как это все сильно завязано на Android. И вот со строками - либо кучу методов созадавать во View, типа покажи такую строчку, покажи такую. Либо один метод - отобрази конкретную строку у конкретного TextView. B вот если просто строчку нужно достать из ресурсов, то можно смело id строки передвать. Но если есть форматирование строки, или plurals, то уже нужен контекст в презентере. Ну и доходит до такого, что в презентер инжектится какой-нибудь ResourcesResolver, который имеет контекст и выдает тебе нужные строки. Но это сильно усложняет жизнь. Да и для тестирования презентера можно спокойно замокать context и выдавать нужные строки. Ну и вы говорите, мол, если жизненно необходимо, можно контекст и в интерактор прокинуть. И мне нравитсят такой подход. Когда начинаешь прямо слепо следовать принципам, то иногда сталкиваешься с оверхедом, нужно просто понимать почему ты себе позволяешь пробросить контекст в презентер, и что после этого будет.
Также понравился раздел про валидацию полей и enable/disable кнопки. Я лично это просто в презентере делал, но мне понравилось как вы закинули в интерактор и покрыли тестами. И с тестами у вас рельно все позновательно и понятно.
Также был момент, что кто-то сказал, что у презентера все методы должны называться как события. Типа произошло это, произошло то. И в таком подходе нельзя сказать презентеру загрузи данные, нужно назвать метод типа "готовДляДанных". Тоже за это долго парились. А на самом деле это такой бред и у вас это хорошо продемонстрированно, что можно иметь в презентере методы listenFields, loadPersonalInfo и говорить презенеру, что делать.
В общем все проблемы от того, что все по своему интерпритируют MVP и накладывают ограничения и впадают в крайности. У вас же все более гибко, и чувствуется, что подход - это инструмент, а не набор ограничений.
EM
Ребят, а что вы думаете по поводу того, чтобы класс модели находился в retained fragment - его время жизни должно превышать время жизни всех экранов, которые его используют. И умирать он должен только если всё закрылось.
Используйте Даггер
Можете почитать мои статьи
Но не храните модель в retained fragment. Это сурово и ничего не гарантирует. Андроид может грохнуть активити, а с ней и ваши фрагменты, retained они или нет
Можете почитать мои статьи
Но не храните модель в retained fragment. Это сурово и ничего не гарантирует. Андроид может грохнуть активити, а с ней и ваши фрагменты, retained они или нет
EM
@eugene_matsyuk Основные проблемы начинаются, когда тебе более авторитетный разарботчик вбрасывает такие идеи, которые сильно усложняют жизнь. Вначале я пробрасывал в presenter все методы жизненного цикла Activity. Кто-то сказал, презентер не должен знать о жизненном цикле. Ну для этого есть методы bindView unBindView и вроде их хватает.
Потом кто-то сказал, что нельзя контектс в презентере. У меня большинство случаев использования контектса в презентере - это строковые ресурсы. Все остальные боллее сложные вещи (например работы с пермишенсами) я оставляю в Activity, так как это все сильно завязано на Android. И вот со строками - либо кучу методов созадавать во View, типа покажи такую строчку, покажи такую. Либо один метод - отобрази конкретную строку у конкретного TextView. B вот если просто строчку нужно достать из ресурсов, то можно смело id строки передвать. Но если есть форматирование строки, или plurals, то уже нужен контекст в презентере. Ну и доходит до такого, что в презентер инжектится какой-нибудь ResourcesResolver, который имеет контекст и выдает тебе нужные строки. Но это сильно усложняет жизнь. Да и для тестирования презентера можно спокойно замокать context и выдавать нужные строки. Ну и вы говорите, мол, если жизненно необходимо, можно контекст и в интерактор прокинуть. И мне нравитсят такой подход. Когда начинаешь прямо слепо следовать принципам, то иногда сталкиваешься с оверхедом, нужно просто понимать почему ты себе позволяешь пробросить контекст в презентер, и что после этого будет.
Также понравился раздел про валидацию полей и enable/disable кнопки. Я лично это просто в презентере делал, но мне понравилось как вы закинули в интерактор и покрыли тестами. И с тестами у вас рельно все позновательно и понятно.
Также был момент, что кто-то сказал, что у презентера все методы должны называться как события. Типа произошло это, произошло то. И в таком подходе нельзя сказать презентеру загрузи данные, нужно назвать метод типа "готовДляДанных". Тоже за это долго парились. А на самом деле это такой бред и у вас это хорошо продемонстрированно, что можно иметь в презентере методы listenFields, loadPersonalInfo и говорить презенеру, что делать.
В общем все проблемы от того, что все по своему интерпритируют MVP и накладывают ограничения и впадают в крайности. У вас же все более гибко, и чувствуется, что подход - это инструмент, а не набор ограничений.
Потом кто-то сказал, что нельзя контектс в презентере. У меня большинство случаев использования контектса в презентере - это строковые ресурсы. Все остальные боллее сложные вещи (например работы с пермишенсами) я оставляю в Activity, так как это все сильно завязано на Android. И вот со строками - либо кучу методов созадавать во View, типа покажи такую строчку, покажи такую. Либо один метод - отобрази конкретную строку у конкретного TextView. B вот если просто строчку нужно достать из ресурсов, то можно смело id строки передвать. Но если есть форматирование строки, или plurals, то уже нужен контекст в презентере. Ну и доходит до такого, что в презентер инжектится какой-нибудь ResourcesResolver, который имеет контекст и выдает тебе нужные строки. Но это сильно усложняет жизнь. Да и для тестирования презентера можно спокойно замокать context и выдавать нужные строки. Ну и вы говорите, мол, если жизненно необходимо, можно контекст и в интерактор прокинуть. И мне нравитсят такой подход. Когда начинаешь прямо слепо следовать принципам, то иногда сталкиваешься с оверхедом, нужно просто понимать почему ты себе позволяешь пробросить контекст в презентер, и что после этого будет.
Также понравился раздел про валидацию полей и enable/disable кнопки. Я лично это просто в презентере делал, но мне понравилось как вы закинули в интерактор и покрыли тестами. И с тестами у вас рельно все позновательно и понятно.
Также был момент, что кто-то сказал, что у презентера все методы должны называться как события. Типа произошло это, произошло то. И в таком подходе нельзя сказать презентеру загрузи данные, нужно назвать метод типа "готовДляДанных". Тоже за это долго парились. А на самом деле это такой бред и у вас это хорошо продемонстрированно, что можно иметь в презентере методы listenFields, loadPersonalInfo и говорить презенеру, что делать.
В общем все проблемы от того, что все по своему интерпритируют MVP и накладывают ограничения и впадают в крайности. У вас же все более гибко, и чувствуется, что подход - это инструмент, а не набор ограничений.
Не устаю повторять, что архитектура должна нам помогать и облегчать жизнь. Но никак не заставлять нас еще больше страдать =)
AP
чуваки как сделать чтобы градл собирал дебаг сборку с мин апи 21 ?
AP
buildTypes {
debug {
minSdkVersion 21
minifyEnabled false
shrinkResources false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.config
}
}
debug {
minSdkVersion 21
minifyEnabled false
shrinkResources false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.config
}
}
AP
доебался что не знает minSdkVersion
EM
со строками тут подсказали варитан с энамом. Его прокидываешь во вью, а она уже ставить нужную строчку
но это как вариант
но это как вариант
S
Ага, видел тут такую идею.
AI
@gaketo Activity.onRetainNonConfigurationInstance в этом плане удобнее retain-фрагментов. Но гаранти ровно те же, что и у ретайн-фрагментов/лоадеров