DU
спасибо, надо переосмыслить видимо, уж больно нравился подход с индивидуальной моделькой с реактивными свойставми напрямую во вью, и, видимо, это сузило область мышления
Size: a a a
2019 September 24
D
чтобы потом адаптер выяснял что поменялось
ListAdapter умеет обновлять только изменившееся, сам вычисляет через AsyncListDiffer
от вас надо только имплементацию DiffUtil.ItemCallbackтолько учтите, что в
submitList надо передавать новый объект списка, а не тот же список с изменёнными объектамиDU
СР
Всем привет! Поделитесь пожалуйста ссылкой на лучший (с вашей точки зрения или общепризнанный) туториал с поэтапным созданием андроид приложения на базе Moxy, в котором бы объяснялось шаг за шагом какие компоненты для чего необходимы (для новичков в мокси, но с хорошим пониманием андроида, mvp и прочих паттернов).
я как то если будет не лень то напишу статью об етом
2019 September 29
S
Комрады, вопрос: правильно ли я понимаю, что я не могу во фрагменте инициализировать интерфейс презентера. Только саму имплементацию? Т.е. только:
@ InjectPresenter
lateinit var presenter: SomePresenterImpl
А так не могу:
val presenter: SomePresenter = SomePresenterImpl()
потому что аннотация инжект не сработает.
Презентер наследуется от MvpPresenter<SomeView>().
Или какая тут правильная практика?
@ InjectPresenter
lateinit var presenter: SomePresenterImpl
А так не могу:
val presenter: SomePresenter = SomePresenterImpl()
потому что аннотация инжект не сработает.
Презентер наследуется от MvpPresenter<SomeView>().
Или какая тут правильная практика?
D
Комрады, вопрос: правильно ли я понимаю, что я не могу во фрагменте инициализировать интерфейс презентера. Только саму имплементацию? Т.е. только:
@ InjectPresenter
lateinit var presenter: SomePresenterImpl
А так не могу:
val presenter: SomePresenter = SomePresenterImpl()
потому что аннотация инжект не сработает.
Презентер наследуется от MvpPresenter<SomeView>().
Или какая тут правильная практика?
@ InjectPresenter
lateinit var presenter: SomePresenterImpl
А так не могу:
val presenter: SomePresenter = SomePresenterImpl()
потому что аннотация инжект не сработает.
Презентер наследуется от MvpPresenter<SomeView>().
Или какая тут правильная практика?
используйте
@ProvidePresenter для самостоятельной инициализации презентера, чтобы вернуть нужную реализациюS
используйте
@ProvidePresenter для самостоятельной инициализации презентера, чтобы вернуть нужную реализациюБлагодарю! Получилось, но только через класс, а не интерфейс, все правильно? (на эмуле работает)
https://gist.github.com/webanimal/104bb9d2994e6a361227e7325c9e113d
https://gist.github.com/webanimal/104bb9d2994e6a361227e7325c9e113d
D
Благодарю! Получилось, но только через класс, а не интерфейс, все правильно? (на эмуле работает)
https://gist.github.com/webanimal/104bb9d2994e6a361227e7325c9e113d
https://gist.github.com/webanimal/104bb9d2994e6a361227e7325c9e113d
да, я это имел ввиду
ЕХ
Благодарю! Получилось, но только через класс, а не интерфейс, все правильно? (на эмуле работает)
https://gist.github.com/webanimal/104bb9d2994e6a361227e7325c9e113d
https://gist.github.com/webanimal/104bb9d2994e6a361227e7325c9e113d
подскажите пожалуйста зачем презентеру интерфейс?
S
подскажите пожалуйста зачем презентеру интерфейс?
В моем случае, чтобы скрыть внутренности класса презентерИмпл, и оставить наружу только то, что должно быть видно из фрагмента
ЕХ
В моем случае, чтобы скрыть внутренности класса презентерИмпл, и оставить наружу только то, что должно быть видно из фрагмента
я понимаю зачем интерфейсы применяются
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
D
я понимаю зачем интерфейсы применяются
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
интерфейс это некий контракт, который позволяет четко разделить методы, которые необходимые активити от внутренних.
В случае мокси, с помощью этого котракта назначаются стратегии
Это просто более удобная реализация. Если бы не было контракта, то пришлось бы стратегии прописывать в самом презентере, а это лишний код
В случае мокси, с помощью этого котракта назначаются стратегии
Это просто более удобная реализация. Если бы не было контракта, то пришлось бы стратегии прописывать в самом презентере, а это лишний код
D
который никак не относится к презентеру
D
solid - в данном случае буковки s и i
FL
я понимаю зачем интерфейсы применяются
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
интерфейс нужен для того чтобы можно было сделать разнули реализацию, например тот же аудио плеер может иметь две view реализации в свернутом виде и в не свернутом, перезентер один...а представлений сколько угоно под разные экраны и прочее...
S
я понимаю зачем интерфейсы применяются
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
но не понятно зачем для презентера
несколько раз видел такие реализации но их авторы не смогли объяснить зачем
из вашего ответа всё ещё не понятно зачем
Я хочу, чтобы когда у инстанса презентера справа ставили точку, там не появлялось ничего, кроме дефолтных методов. Чтобы не было проперти и котлиновских фишек. А только белым жирным шрифтом показывались не реализованные методы интерфейса. Если таких нет, то всё заимплеменчено и больше презентер трогать не надо
ЕХ
интерфейс это некий контракт, который позволяет четко разделить методы, которые необходимые активити от внутренних.
В случае мокси, с помощью этого котракта назначаются стратегии
Это просто более удобная реализация. Если бы не было контракта, то пришлось бы стратегии прописывать в самом презентере, а это лишний код
В случае мокси, с помощью этого котракта назначаются стратегии
Это просто более удобная реализация. Если бы не было контракта, то пришлось бы стратегии прописывать в самом презентере, а это лишний код
вообще не понял ничего (
ЕХ
интерфейс нужен для того чтобы можно было сделать разнули реализацию, например тот же аудио плеер может иметь две view реализации в свернутом виде и в не свернутом, перезентер один...а представлений сколько угоно под разные экраны и прочее...
всё ещё не понятно зачем интерфейс презентера
FL
всё ещё не понятно зачем интерфейс презентера
друк, ну тогда ты не понимаешь ооп по-моему
FL
пол-года назад я в принципе не понимал зачем вообще интерфейсы )