Вместо этой защиты, как мне кажется, больший результат принесли бы другие действия, например: Показ сообщения что вы типа пират и это не хорошо, купите игру со скидкой например или задонатьте для отключения этого сообщения ну или что-то в этом роде. В игру играть, я бы на вашем месте разрешил, даже в пиратскую.
Koin создан для простоты, так что не нужно все усложнять. Вот несколько лайф-хаков:
Хоткеем из koin-модуля можно посмотреть на конструктор (BasketPresenter) что-бы понять что нужно
Хоткеем посмотреть где вызываются конструкторы для параметров BasketPresenter, если нет в koin-модуле - значит будет падать
При написании/рефакторинге зависимостей не писать get() для того чего еще нет. Тогда будет падать не в рантайме, а будут ошибки компиляции или если немного перефразировать: при написании нового кода koin-модуль писать в последнюю очередь, при рефакторинге - в первую
Репозиторий это шаблон который скрывает реализацию конкретного источника данных (т.е. бд) и предоставляет высокоуровневую абстракцию. Можно ли назвать REST api источником данных? Можно, но только при одном условии — то что мы туда «ложит» то и «забирает», исключение — справочные данные.
Про медицину — наверное стоит привести пример аптек, будет более показательно. Т.е. у нас если приболел — пошел в аптеку самостоятельно и купил что нужно, там же, наверное, без рецепта врача могут продать только крем от загара. Возможно я не прав, если это не так — поправьте.
Спасибо большое! И последний вопрос: У вас в приложении можно выбрать отдельно тему для всего Activity и отдельно темы для диалогов? Просто в теме Activity можно создать пользовательский атрибут для темы диалога, в диалоге сослаться на него и дальше все переопределять стандартными методами. На первый взгляд — отличное решение или есть какие-то «подводные камни»?
Вы не против если я вас еще поспрашиваю? Всегда хочется использовать чужой опыт, чем изобретать собственные велосипеды (:
А почему вы вообще планируете использовать setTheme() в таком контексте? Ведь существует стандартный механизм переопределения тем. Это для тех случаев когда один и тот же диалог на разных экранах имеет разное отображение?
Я так понял что «решение с диалогом» и «отправка событий экранов» раньше была в базовых классах, а теперь это все живет в ActivityLifecycleCallbacks. С какими вы столкнулись проблемами что решили применить такой подход или какие он дал вам преимущества по сравнению логикой основанной на базовых классах?
В принципе все написано правильно, единственное что мне режет глаз, так это то что новичку не дают шанса проявить себя. Кто знает, может все действительно сложно и есть путь проще, а у тимлида/архитектора «замылен глаз». Поэтому новичку нужно выставить формальные требования к исходному коду, и не просто ссылкой на solid в википедии, а типа: мы делаем "так" — потому "что".
Добрый день. Лучше расскажите про ваш опыт использования этой возможности в Яндекс.Деньгах. Потому что приведенные примеры, в некотором роде, относятся к категории «вредных советов», вы наверное их для того и выделили отдельной строкой "Повторяйте этот трюк ТОЛЬКО дома". Сейчас реально хороший пример только с инициализацией dagger2.
Хабр Вики — документация для IT-шников. Описание шаблонов, технологий, методологий, каталоги компонентов (типа cocoacontrols.com или android-arsenal.com) и т.д.
Всецело поддерживаю ваше замечание, но немного дополню для автора. Чтобы полностью «избавиться» от исключений обычно в систему вводят объект типа
Result<T>
и например, проверяют у него свойство success = true|false перед тем как прочитать свойство data с данными. Но, как говорится — в программировании чудес не бывает, если мы не пишем код в одном месте то мы пишем его в другом месте, т.е. в вашем случае вместо того чтобы писать код на исключениях мы напишем другой код, для того чтобы «обойти» этот подход (потому что лучший код это тот которого нет). Ну и конечно стоит добавить что не всем типам ПО такой подход подойдет, например в большинстве мобильных приложений такой подход оправдан.
Для этого есть целый список причин и некоторые не достаточно очевидны из-за скудности примера:
1. В модели из сети данные приходят в одном формате, а на стороне UI зачастую приходится работать с данными в другом формате (даты, суммы, id из справочников и т.д.)
2. Если в этот пример нужно будет добавить работу с БД — UI слой придется переписать. Кстати, сюда же можно и отнести первый пункт — в БД данные удобно хранить в других структурах и форматах и частенько они не совпадают с тем, что приходит из сети.
3. Ну и конечно, никто не застрахован от того что сетевая модель останется неизменной (:
p.s. кучу абстракций городить не нужно, например — поля модели можно вынести в интерфейс.
Во первых это слишком простой пример чтобы называться чистой архитектурой, во вторых — присутствуют ошибки: 1) BaseViewModel знает об деталях работы с сетевыми запросами. 2) Модели из «сетевого слоя» используются на стороне UI
Вместо этой защиты, как мне кажется, больший результат принесли бы другие действия, например: Показ сообщения что вы типа пират и это не хорошо, купите игру со скидкой например или задонатьте для отключения этого сообщения ну или что-то в этом роде. В игру играть, я бы на вашем месте разрешил, даже в пиратскую.
Koin создан для простоты, так что не нужно все усложнять. Вот несколько лайф-хаков:
Хоткеем из koin-модуля можно посмотреть на конструктор (BasketPresenter) что-бы понять что нужно
Хоткеем посмотреть где вызываются конструкторы для параметров BasketPresenter, если нет в koin-модуле - значит будет падать
При написании/рефакторинге зависимостей не писать get() для того чего еще нет. Тогда будет падать не в рантайме, а будут ошибки компиляции или если немного перефразировать: при написании нового кода koin-модуль писать в последнюю очередь, при рефакторинге - в первую
1. В модели из сети данные приходят в одном формате, а на стороне UI зачастую приходится работать с данными в другом формате (даты, суммы, id из справочников и т.д.)
2. Если в этот пример нужно будет добавить работу с БД — UI слой придется переписать. Кстати, сюда же можно и отнести первый пункт — в БД данные удобно хранить в других структурах и форматах и частенько они не совпадают с тем, что приходит из сети.
3. Ну и конечно, никто не застрахован от того что сетевая модель останется неизменной (:
p.s. кучу абстракций городить не нужно, например — поля модели можно вынести в интерфейс.