Evgenii Kuzovkin

Господа, правильно я понимаю, что compose пока плохо ложится на приложения, в которых основная работа происходит с картой? Видел, что гугл выпустил карты с поддержкой compose,...

Вы из какого города? Я живу в Тюмени, город хоть и не большой, но развитый. Столкнулся вот с чем: в мою прошлую компанию ищут разработчика на поддержу проекта, который я писал...

Ну вот выше Андрей написал по вашему вопросу, что можно сделать по-разному. Ваш вопрос слишком абстрактен, поэтому на него нет однозначного ответа. Это как вопрос "что лучше с...

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

Исходя из слов автора всей клин архитектуры можно сказать, что: Файл SomeInteractor.kt - это класс, содержащий набор интеракторов (каждый из которых соответствует usecase'у) ...

Что думаете насчёт такого подхода? 1) Интерфейсы для аналитики (manager, decorator) лежат в domain. Там же отдельные события, которые при необходимости можно вынести в отдельн...

Да, и на долгосрочную перспективу особо важно, взять ли MVP или MVVM? С любым из этих подходов можно как максимально упростить разработку и поддержку, так и усложнить. Поработ...

Просто если роутер используется только в необходимых презентерах, и в базовый он попадает всё равно через наследников, а вызовы на роутере простые, то есть ли смысл его в базо...

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

В смысле, проблема просто в переходах, или один фрагмент может быть как корневым, так и на другом уровне? Если первое, то простой менеджемент через fragmentManager с сохранени...

Предположим, что в одном интеракторе может быть side кейс, по которому надо обновить данные из другой фичи. Получается, что вместо одного репозитория, который разрулил бы это,...

Ладно джава и котлин, но андроид? Мне кажется, при разработке SDK много раз решение принимали руководствуясь принципом "да наследуем и ок, ничего страшного"

Привет, я немного не понял, вы говорите про проблемы anko, связанные со стилями?

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

Так мы не спорим, если я в чём то не прав, то скажите. Data source же не должен знать о репозитории и выполняемых им функциях?

Я, конечно, этим всем пользоваться умею и знаю, как оно работает, но нет ли тут и ещё во множестве мест проблем?

Если у вас простой маппинг field -> field, и, например, нет инжектируемых зависимостей, то почему нет?

Точнее, почему это важно?

И тогда репозиторий = источник данных, и в интеракторе будет их смешение?

У вас какое-то определённое собеседование в конкретную компанию?