Телеграмм чат группы Android_Architecture страница 4462

ну эт проблема контейнера
такие штуки можно в модуле спрятать

На счёт прятать в модуле, предлагаешь сделать provide-метод, который будет получать named интерфейс и возвращать, как обычный?

Konstantin Dovnar in Android Architecture

23:06пожаловаться #1

KD

А кто не даёт все зависимости через конструктор провайдить?)
Слои абсолютно не меняются

Провайдив через конструктор ты тоже используешь DI.

23:08пожаловаться #2

RC

Konstantin Dovnar

Провайдив через конструктор ты тоже используешь DI.

Не обязательно, я могу руками туда сложить всё

23:11пожаловаться #3

ES

Не обязательно, я могу руками туда сложить всё

Зачем? Смысл di теряется

Konstantin Dovnar in Android Architecture

23:13пожаловаться #4

KD

Не обязательно, я могу руками туда сложить всё

class A(val dep: Dependency)

fun main() {
    val dep = DependencyImpl()
    val a = A(dep)
}

Это всё ещё DI.
Ты предоставляешь зависимости из вне.

23:13пожаловаться #5

RC

Зачем? Смысл di теряется

Так о том и соль, что жить можно по клину и без di

23:13пожаловаться #6

ES

Так о том и соль, что жить можно по клину и без di

Ну можно, удачи. Можно и не юзать ретрофит с окхттп)

23:14пожаловаться #7

ES

А еще запросы на колбеках делать)

Разбиение монолитного Android-приложения на модули уже давно не новая тема в сообществе, а такой способ организации становится всё более популярным. Даже мы уже затрагивали эту тему на встрече про лучшие практики работы с модулями у коллег. Теперь собрали этот опыт, опробовали на нашем проекте, ...

23:14пожаловаться #8

P

Pavel in Android Architecture

Драфт статейки бывшего коллеги по теме:
@Phansier
https://docs.google.com/document/d/1kOaHwPZl1klDgb87h4BPt_5MP1Auy8HrmJespCqjDrs/edit?usp=sharing

Google Docs

Многомодульность

23:14пожаловаться #9

RC

Konstantin Dovnar

class A(val dep: Dependency)

fun main() {
    val dep = DependencyImpl()
    val a = A(dep)
}

Это всё ещё DI.
Ты предоставляешь зависимости из вне.

DI - это ещё и в поля инъекции, и в методы, да. Не верно выражаюсь наверное, можно писать по клину без di-библиотек

23:14пожаловаться #10

RC

Ну можно, удачи. Можно и не юзать ретрофит с окхттп)

Так, не, давай по делу. Di-либы ломают солид, а писать самопальные штуки - это другое

23:16пожаловаться #11

RC

Разбиение монолитного Android-приложения на модули уже давно не новая тема в сообществе, а такой способ организации становится всё более популярным. Даже мы уже затрагивали эту тему на встрече про лучшие практики работы с модулями у коллег. Теперь собрали этот опыт, опробовали на нашем проекте, ...

Pavel

Драфт статейки бывшего коллеги по теме:
@Phansier
https://docs.google.com/document/d/1kOaHwPZl1klDgb87h4BPt_5MP1Auy8HrmJespCqjDrs/edit?usp=sharing

Google Docs

Многомодульность

Спасибо, гляну)

23:17пожаловаться #12

AD

Aleksey D. in Android Architecture

На счёт прятать в модуле, предлагаешь сделать provide-метод, который будет получать named интерфейс и возвращать, как обычный?

да, вариант

23:21пожаловаться #13

RC

Aleksey D.

да, вариант

Думал о чем-то подобном раньше, это не будет работать. Ты запросил конкретную реализацию, снял с нее эту пометку "конкретная реализация А" и отправил дальше. Опять же, не выйдет теперь другую реализацию подсунуть. Условно говоря, проблему под ковер запрятать, подальше от глаз

Разбиение монолитного Android-приложения на модули уже давно не новая тема в сообществе, а такой способ организации становится всё более популярным. Даже мы уже затрагивали эту тему на встрече про лучшие практики работы с модулями у коллег. Теперь собрали этот опыт, опробовали на нашем проекте, ...

23:25пожаловаться #14

YW

Yakov Weber in Android Architecture

Pavel

Драфт статейки бывшего коллеги по теме:
@Phansier
https://docs.google.com/document/d/1kOaHwPZl1klDgb87h4BPt_5MP1Auy8HrmJespCqjDrs/edit?usp=sharing

Google Docs

Многомодульность

Прикольная статья, хорошо разложил для чего нужен module-injector, даже задумался что связь между фичи модулями не всегда зло. В общем оставил в закладке у себя. Спасибо

23:28пожаловаться #15

A

ABI in Android Architecture

Ну можно, удачи. Можно и не юзать ретрофит с окхттп)

ну прям можно подумать что DI чисто для ретрофита замутили. как бы до DI ретрофит (и подобное) в синглтон загоняли и не парились... Опять же с точки зрения кода в маленьких проектах нафиг DI не нужен, если у тебя реально только один ретрофит + 2-3 фрагмента

23:30пожаловаться #16

ES

ABI

ну прям можно подумать что DI чисто для ретрофита замутили. как бы до DI ретрофит (и подобное) в синглтон загоняли и не парились... Опять же с точки зрения кода в маленьких проектах нафиг DI не нужен, если у тебя реально только один ретрофит + 2-3 фрагмента

Я писал вообщем про то, что можно отказаться от всех либ и мудрить свои велосипеды, но не стоит того По поводу маленьких проектов это да, соглашусь, больше гемора, чем пользы.

23:31пожаловаться #17

A

ABI in Android Architecture

Я писал вообщем про то, что можно отказаться от всех либ и мудрить свои велосипеды, но не стоит того По поводу маленьких проектов это да, соглашусь, больше гемора, чем пользы.

велосипеды - это святое ) их трогать низя

23:31пожаловаться #18

AD

Aleksey D. in Android Architecture

Думал о чем-то подобном раньше, это не будет работать. Ты запросил конкретную реализацию, снял с нее эту пометку "конкретная реализация А" и отправил дальше. Опять же, не выйдет теперь другую реализацию подсунуть. Условно говоря, проблему под ковер запрятать, подальше от глаз

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

аннотация здесь не нужна, можно просто через тип провайдить)

23:33пожаловаться #19

RC

Aleksey D.

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

аннотация здесь не нужна, можно просто через тип провайдить)

Кстати, прикольно