Кто как строит приложения?

Всмысле канал? Всмысле я?

Кто как строит приложения?

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

привет

вопрос

как Retrofit парсить оффлайн json файл, который в assets лежит? везде инфа только про он-лайн. Есть ли вообще смысл парсить такие файлы retrofit?

Gson же для этого юзают

я умею парсить json

вопрос снят

Всем привет) Я дмитрий ведущий андроид разработчик компании Барс груп. Использую MVP, Dagger 2, Rx, retrofit2, а так же многое другое... В последнее время заинтересовался Kotlin'ом.

а MVVM в массы не зашел до сих пор?

Приветствую. Я пока что только учусь - изучаю Java SE, в планах (как только начну понимать хотя бы немного) - JS, PostgreSQL (хабрасэры говорят, что эта эскюэлька чем-то лучше других). Интересно будет почитать тут более знающих людей в андроид-разработке, и конечно я постараюсь задавать вопросы, если мне что-то будет непонятно. Узнал про вас от pro.jvm чата. #whois

Всем привет) Я дмитрий ведущий андроид разработчик компании Барс груп. Использую MVP, Dagger 2, Rx, retrofit2, а так же многое другое... В последнее время заинтересовался Kotlin'ом.

Тру пацан ?

А кто-нибудь может в двух сказать что такого умопомрачительного в Dagger'е и Rx?

Всем привет) Я дмитрий ведущий андроид разработчик компании Барс груп. Использую MVP, Dagger 2, Rx, retrofit2, а так же многое другое... В последнее время заинтересовался Kotlin'ом.

MVP тебя полностью устраивает?

А кто-нибудь может в двух сказать что такого умопомрачительного в Dagger'е и Rx?

Это надо попробовать бро

А кто-нибудь может в двух сказать что такого умопомрачительного в Dagger'е и Rx?

В rx очень легко переключать потоки исполнения, что избавляет нас от лапши колбэков

То есть просто Observable?

Dagger делает архитектуру слабосвязной, гибкой и легко добавлять новое в такую архитектураюу так чтобы старое не затронуть

*который паттерг

То есть просто Observable?

Чем то похоже, но там м функуиональщина

MVP устраивает пока) Библиотечку даже мелкую свою накатал) Слой презентеров вообще не знает у меня андроид методов как описано много в каких примерах. Он знает только когда вьюшка приаатачелась и когда она уже дестроится. При аттачинге я бинжу методы и сохраняю подписки а при детачинге отписываюсь от всех подписок

MVP устраивает пока) Библиотечку даже мелкую свою накатал) Слой презентеров вообще не знает у меня андроид методов как описано много в каких примерах. Он знает только когда вьюшка приаатачелась и когда она уже дестроится. При аттачинге я бинжу методы и сохраняю подписки а при детачинге отписываюсь от всех подписок

А mosby пробовал?

Даггер удобно строить граф зависимостей.

Мосби видел читал но так и не попробовал)

MVP устраивает пока) Библиотечку даже мелкую свою накатал) Слой презентеров вообще не знает у меня андроид методов как описано много в каких примерах. Он знает только когда вьюшка приаатачелась и когда она уже дестроится. При аттачинге я бинжу методы и сохраняю подписки а при детачинге отписываюсь от всех подписок

Все равно ссылку презентер на активити/фрагмент хранит

Ребят, а если у меня плохо получается объяснять преимущество той или иной фичи, доказать что надо делать так а не эдак, это у меня софт скиллы слабые, как прокачать? Знаю как правильно все архитектуру стек технологий какой куда лучшe, а почему объяснить трудно.

Он хранит ссылку на View он не знает что это активити или фрагмент

view.getContext

View это абстракция со своими методами

Аааа.

нет контекст не передаю

контекст передавать в перзентер считаю не комильфо)))

Если вью это активити, то можно прикастить к контексту

weakReference

и чисти ее при детачинге

А с насколько сложной вьюхой/активити это будет работать? Вот это особенно интересно.

И как это сказывается на времени разработки

weakReference

Нинужно. Прикастить можно

weakReference

В мосби поступили иначе, с этой слабой ссылкой проверки на нулл запарят. Там просто при детаче вьб не нулл будет, а мок объект, у которого можно дергать методы, но они ничего не делают.

Есть что то подобное от Никиты Баришок, где он описывает промежуточный слой который принимает на себя роль презентера и вьюхи когда та или иная часть не доступны

Ну норм тема я видел его доклад

Но честно мне не очень понравилось что презентер должен на себя взять методы андроид вьюхи. Я тоже раньше так делал... А сейчас решил что 2-х методов пока достаточно.

Вот статья интересная от Артема Зиннатулина https://artemzin.com/blog/rxui-talking-to-android-view-layer-in-a-reactive-way/

Я бинжу при аттаче и отписываюсь при детаче. Если нужны аргументы то я так же создаю Observable во вьюхе и в презентере его бинжу. Так же и на резум

Так же можно сделать Observable с boolean параметром для обновления инфы если надо (т.е. указывать надо или нет обновление данных)

вот кстати

Я бинжу при аттаче и отписываюсь при детаче. Если нужны аргументы то я так же создаю Observable во вьюхе и в презентере его бинжу. Так же и на резум

Дай что-то позырить) хело ворд какой-нибудь с твоей архитектурой

этот парень, Артём Зиннатулин, кто он? что-то в последнее время часто вижу его статьи и т д

https://github.com/retor/WeatherSampleApp самый простой и сырой пример.

Еще и подкаст у него есть) ведут с Дорфманом если не ошибаюсь

AndroidContext помоему

https://github.com/retor/WeatherSampleApp самый простой и сырой пример.

Это форк от Баришка?

это мой пример) Начинал делать тестовую аппку и так и забросил пока(

У него так же проект вроде называется)

Таких проектов полно на гите) Я тоже как то смотрел) многие делали такое)

кстати

некоторые презентер инджектят

Таких проектов полно на гите) Я тоже как то смотрел) многие делали такое)

Ты просто его упоминал вот я и подумал) спасибо гляну позже.

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

вот даже не знаю какой подход лучше

вот даже не знаю какой подход лучше

Если инжектить то инжектить и то и то))

ну я презентер не иджектю

использую mosby

там он в активити или фрагменте создается, т.е. есть метод createPresenter который надо реализовать и он возвращает презентер.

в примерах там просто создают презентер

ну там как бы и не нужно инджектить его))

А у всех презентер это синглтон?)

Вернее является

А у всех презентер это синглтон?)

вот если он из даггера инджектится, то скорее синглтон, ну там анноташку ставишь @Singltone

Это понятно

и получается презентеры будут жить даже если ты на другой экран перешел

нафига они нужны

Нет презентер не синглтон

Презентер на активити или на фрагмент

они там за собой ещё тянуть могут

кто юзает мосби, скорее всего презентер не инджектит

я лично в презентер инджектю всё что надо, всех этих синглтонов менеджеров

а жизнью презентера управляет мосби

Кстати

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

там он в активити или фрагменте создается, т.е. есть метод createPresenter который надо реализовать и он возвращает презентер.

А что тебе мешает здесь инжектить презентер и возвращать его?)

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

А если экран повернули?)

А если экран повернули?)

сдох и пересоздался вместе с активити/фрагментом. Но обычно делаю retainInstance, т.е. фрагмент не будет пересоздан и презентер выживет вместе с ним