Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 20 2016 21:52
    @rus-speaking banned @ImangazalievM
  • Oct 12 2016 11:36
    @rus-speaking banned @postflow
  • Jan 31 2016 12:15
    @rus-speaking banned @Nikkola
  • Dec 01 2015 16:39
    @rus-speaking banned @StNekroman
  • Nov 15 2015 20:35
    User @rus-speaking unbanned @skilz2012 from this room
  • Nov 11 2015 12:32
    @rus-speaking banned @skilz2012
VolodymyrBaisa
@VolodymyrBaisa
?
ViTORossonero
@ViTORossonero
Anton
@Nookieaaa
Привет всем, есть у кого-то линк на какой-то пример подмены в рантайме презентера и вью с даггером 2?
xomyc
@xomyc
Привет, кто-то делал навигацию на нижних табах с отдельным бекстеком в каждом табе?
giffell
@giffell
@xomyc это к разработчикам Инстаграма если есть они тут, то тоже хотел бы просто узнать "нафига такие фичи?)" P.s тут паттерны, вам в другой чат :)
xomyc
@xomyc
@giffell Ну я просто подумал что раз это чат по архитектуре, то этот вопрос будет тут уместен, т.к. интересует именно архитектурное решение такого вопроса.
prokhor-andrew
@prokhor-andrew
Ребята, всем доброго времени суток(надеюсь, предыдущее сообщение удалилось). Пишу приложение с МВП. Есть ряд вопросов и я буду безумно благодарен если на них кто-то даст ответ. С МВП знаком уже месяцев 7. Но всегда лень было применять, и лень было подчищать вопросы. Но вот настал тот час, итак:
1) View это просто интерфейс, который должен быть реализован Активити, Фрагментом, или другим классом, чтобы тот стал вью, верно?
2) Модель - это один класс, который реализует все методы доступа к данным, или это множество классов, с сгруппированными методами под свои задачи? К примеру: есть экран друзей, нам надо делать запрос чтобы получить массив объектов типа друг. Этот запрос должен реализоваться в том же классе, где и все остальные запросы приложения, или лучше создать отдельный класс, который реализует интерфейс с методами конкретно касательно экрана друзей? Какой подход лучше?
3) Модель это слой, или формат данных? Часто слышу как на pojo говорят "модель".
4) Надо ли писать отдельный java interface для презентера? Видел код, где у нас есть интерфейс презентера для вью, и интерфейс презентера для модели. Их делят на два интерфейса, таким образом, у нас вью вызывает свои методы для презентера, а модель свои.
5) Насколько мне известно, Вью держит объект презентера, чтобы отправлять взаимодействовать с ним, Модель тоже держит объект презентера(в том случае, если модель это не один класс, а множество) и также с ним взаимодействует, презентер держит объект и на вью, и на модель. Вопрос: ссылку надо держать именно на объект, который реализует интерфейс, или сам интерфейс? MainPresenter implements MainViewContract, MainModelContract. MainActivity implements MainView. MainModel implements MainModelContract. Мне держать MainPresenter или MainViewContract/MainModelContract? MainActivity или MainView? MainModel или MainModelContract?
6) Последний вопрос, но самый жесткий для меня... я прочитал, что концепция МВП подразумевает максимальное разделение между слоями, а значит, они и создаваться должны независимо друг от друга. То-есть одновременно должны быть инициализированы все три слоя. Как это реализовать, если в андроиде активити создается автоматически системой, у нас нет возможности создать одновременно с ним и в то же время не в нем слой презентера и модели? Была идея создать Активити-Рутер. Класс, который будет создаваться первым в приложении(Activity intent-filter category Launcher) и инициализировать презентер и модель одновременно с вью. НО там все равно куча подводных камней, и я бы хотел мнение более опытных людей. СПасибо за внимание всем кто дочитал и не подумайте, пожалуйста, что мне было лень гуглить, я смотрел код на гитхабе, читал статьи на хабре, спрашивал у других людей, но нигде нет никакого однозначного ответа на мои вопросы. Пожалуйста не игнорируйте
ViTORossonero
@ViTORossonero
можешь вот этот телеграм чат почитать, там же вопрос свой задать
https://t.me/Android_Architecture
prokhor-andrew
@prokhor-andrew
большое спасибо)
Andrew Kaganets
@DarkMentat
Хай народ, кто-то смотрел на Architecture Components? Заметили какие-то подводные камни, и по ощущениям, удобнее чем обычные mvp, mvvm?
VolodymyrBaisa
@VolodymyrBaisa
Привет народ, вопрос по архитектуре наверное. Как сделать общий interface для двух классов если у этих классов есть два метода setData(String a) это первый клас и второй клас setData(int b)
Может паттерн фабрика?
Andrew Kaganets
@DarkMentat
interface<T>{
setData(T data); }
типа женерики. Но зачем все это?
Roman Shakirov
@rpagyc
@DarkMentat переписываю свои приложения на ААС. решил отказаться от Nucleus и StorIO. пока впечатления положительные, подход от МВП/МВВМ не особо отличается.
Rustem Saitkulov
@atetc
@rpagyc а можно ссылочки по сабжу?
Rustem Saitkulov
@atetc
Благодарю!
mirabon
@mirabon
Использование (расширение) класса сервиса интерфейсом другого объекта в качестве колбека является нормальной практикой?
SiarheiSm
@SiarheiSm
добрый день
не подскажите есть ли смысл в одном проэкте использовать moxy и dagger?
Yuri Shmakov
@senneco
Так и используем - никаких противоречий нет
SiarheiSm
@SiarheiSm
@senneco спасибо
Vladimir
@Stixxxxx
ребят, есть работа для андройд разработчиков?
Optimus Prime
@optimusprime2014
всегда есть)))
Kirill Ashikhmin
@KirillAshikhmin
@Stixxxxx https://gitter.im/rus-speaking/android-job тут смотри
Anton Belka
@dark-al
Всех приветствую. Кто как строит архитектуру приложения на практике? На листике, сразу код пишет или в голове держит? Я уже почти год работаю разработчиком и понимаю, что я не умею строить архитектуру. Возьмем например задачу, когда в приложение необходимо внедрить к примеру 5 биллинг систем. У каждой билинг системы свои методы и т.д. и все это нужно обернуть в некий Manager или Helper (не знаю как назвать), методы которого мы будем дергать он уже дальше разруливать выбирать нужную биллинг систему и т.п. в зависимости от условий. Может какую-то книгу посоветуете прочесть или статью?
Toporik
@Toporik
"Возьмем например задачу, когда в приложение необходимо внедрить к примеру 5 биллинг систем." :)
Anton Belka
@dark-al
@Toporik а что не так?
swh
@sswwhh

я не самый большой специалист, но может ответ поможет

архитектура приложения - вопрос скользский. хороших книг пока нет, все пользуются статьями с хабра и медиума.
то, что вы за год начали понимать, что не рубите в построении архитектуры, это хорошо. обычно это доходит много позже.
по большему счёту, чтобы нормально научиться писать, нужно понять: (1) языковые примитивы - синтаксис и мелочи, (2) стилистику языка, сахар (3) патерны проектирования
а после этого беритесь за создание архитектур
здесь поможет принцип SOLID (https://ru.wikipedia.org/wiki/SOLID_(объектно-ориентированное_программирование), читайте хоть на вики и пробуйте-пробуйте-пробуйте), и тут поймите, (1) как создавать правильные классы, (2) как и что нужно абстрагировать

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

@dark-al ^
Anton Belka
@dark-al
@sswwhh про SOLID знаю, но одно дело знать теорию, второе - применять на практике.
swh
@sswwhh
@dark-al постарайтесь найти человека, который тет-а-тет, за пару часов покажет вам, как теория с практикой связана. я когда-то именно так и научился.
Ghedeon
@Ghedeon
у кого-то построен View layer как тут? https://www.youtube.com/watch?v=0IKHxjkgop4
такой, Redux на андроиде. Та же идея, другими словами: https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-1-566caae0f706
Ghedeon
@Ghedeon
мне интересно, если кому-то зашел такой подход. Боюсь, во вьюхе будут дикие if-ы, чтобы разруливать состояние. Плюс, весь скрин рендерится на каждый чих
moonsweel
@moonsweel
почему весь? только те view, которые надо поменять
viewmodel/presenter меняет только то, что нужно
состояние хранит не view, а vm/presenter
Ghedeon
@Ghedeon
и в чем новость, если так всегда и делали? ты точно видео просмотрел? Может я не догнал, но там вводится понятие состояния для вью. Т.е. у тебя не гора методов, которые обновляют мелкие вьюшки, а один толстый render метод, куда контроллер пушит состояние всей вьюхи. И оно рисуется. Профит мол в том, что легко тестировать, просто посылаешь состояние с нужными полями, вызываешь render и у тебя вью всегда в нужном положении.
moonsweel
@moonsweel
я смотрел, но давно :)
по-моему, там поинт был в том, что надо разделять состояния нижнего и верхнего слоев
Ghedeon
@Ghedeon
мм.. не, глянь тут еще https://academy.realm.io/posts/kau-lee-kase-reduxing-ui-borrowing-from-web/. Мол данные по одному каналу всегда в одну сторону идут. Ты не обновляешь TextView, а пушишь целый ViewState и View уже отрисует, что изменилось
Ghedeon
@Ghedeon
сейчас многие по redux ссутся.. Wharton там говорит, что может на андроиде нет смысла его полностью копировать. Видел redux-like фреймворки под андроид на Medium кто-то постил. Думал, может кто-то пробовал.
moonsweel
@moonsweel
ну допустим, и сколько у тебя if-ов будет, 5?
экраны-то мелкие, много данных все равно не отобразишь
Ghedeon
@Ghedeon
как это мелкие?) У меня большой экран! that what she said... Лейблы, кнопки, подсказки, лоадинги, тосты с ошибками.. Накапливается, монстрик такой. Оверхед еще этот, слишком многое перерисовывается по 10 раз в пустую.
еще не решил, если стало лучше
Pankra
@Pankra

hi! читаю код, доставшийся по наследству, возник вопрос по MVC: С вызывает у V метод V.getField().setVisibility(condition ? VISIBLE : GONE)
насколько это вяжется с разделением ответственности С и V?
может быть у V нужен метод V.setFieldVisible(condition)?

почему спрашиваю - возникла ситуация, что код выполняется в коллбаке и возможна ситуация, когда V, в данном случае Fragment уже не !isAdded() и куда-то эту проверку надо воткнуть. для текущей реализации у меня получится V.getField().setVisibility(condition && V.isAdded() ? VISIBLE : GONE)
во втором варианте проверку isAdded можно сделать на стороне V, что мне кажется логичнее

Artem Rudometkin
@perfectplayer
Основная идея при разделении на слои в том, что Controller/Presenter ничего о View не знает, знает только её контракт. Соответственно всё должно свестись к тому, что C/P отдаёт команду V, а та уже оперирует со своей иерархией самостоятельно. Одно из перимуществ такой архитектуры - возможность иметь набор взаимозаменяемых View, реализующих определённый контракт.
Pankra
@Pankra
@perfectplayer спасибо, все по сути и понятно!