Вместо этой защиты, как мне кажется, больший результат принесли бы другие действия, например: Показ сообщения что вы типа пират и это не хорошо, купите игру со скидкой например или задонатьте для отключения этого сообщения ну или что-то в этом роде. В игру играть, я бы на вашем месте разрешил, даже в пиратскую.
Koin создан для простоты, так что не нужно все усложнять. Вот несколько лайф-хаков:
Хоткеем из koin-модуля можно посмотреть на конструктор (BasketPresenter) что-бы понять что нужно
Хоткеем посмотреть где вызываются конструкторы для параметров BasketPresenter, если нет в koin-модуле - значит будет падать
При написании/рефакторинге зависимостей не писать get() для того чего еще нет. Тогда будет падать не в рантайме, а будут ошибки компиляции или если немного перефразировать: при написании нового кода koin-модуль писать в последнюю очередь, при рефакторинге - в первую
Репозиторий это шаблон который скрывает реализацию конкретного источника данных (т.е. бд) и предоставляет высокоуровневую абстракцию. Можно ли назвать REST api источником данных? Можно, но только при одном условии — то что мы туда «ложит» то и «забирает», исключение — справочные данные.
Про медицину — наверное стоит привести пример аптек, будет более показательно. Т.е. у нас если приболел — пошел в аптеку самостоятельно и купил что нужно, там же, наверное, без рецепта врача могут продать только крем от загара. Возможно я не прав, если это не так — поправьте.
Спасибо большое! И последний вопрос: У вас в приложении можно выбрать отдельно тему для всего Activity и отдельно темы для диалогов? Просто в теме Activity можно создать пользовательский атрибут для темы диалога, в диалоге сослаться на него и дальше все переопределять стандартными методами. На первый взгляд — отличное решение или есть какие-то «подводные камни»?
Вы не против если я вас еще поспрашиваю? Всегда хочется использовать чужой опыт, чем изобретать собственные велосипеды (:
А почему вы вообще планируете использовать setTheme() в таком контексте? Ведь существует стандартный механизм переопределения тем. Это для тех случаев когда один и тот же диалог на разных экранах имеет разное отображение?
Я так понял что «решение с диалогом» и «отправка событий экранов» раньше была в базовых классах, а теперь это все живет в ActivityLifecycleCallbacks. С какими вы столкнулись проблемами что решили применить такой подход или какие он дал вам преимущества по сравнению логикой основанной на базовых классах?
В принципе все написано правильно, единственное что мне режет глаз, так это то что новичку не дают шанса проявить себя. Кто знает, может все действительно сложно и есть путь проще, а у тимлида/архитектора «замылен глаз». Поэтому новичку нужно выставить формальные требования к исходному коду, и не просто ссылкой на solid в википедии, а типа: мы делаем "так" — потому "что".
Добрый день. Лучше расскажите про ваш опыт использования этой возможности в Яндекс.Деньгах. Потому что приведенные примеры, в некотором роде, относятся к категории «вредных советов», вы наверное их для того и выделили отдельной строкой "Повторяйте этот трюк ТОЛЬКО дома". Сейчас реально хороший пример только с инициализацией dagger2.
Хабр Вики — документация для IT-шников. Описание шаблонов, технологий, методологий, каталоги компонентов (типа cocoacontrols.com или android-arsenal.com) и т.д.
Ваше право. Лично мне кажется, здесь больше проблема в терминах и их значении (например когда я по малолетке подрабатывал тем что ставил «венду» и принтеры заправлял — меня называли программистом). Ниже greabock хорошо написал про роли, типа компания определяет тебе роль синьора за такие-то «заслуги» (много опыта, друг директора, переспал с ним и т.д.)
— опыт как раз и отличает июня от всех остальных, ну и если его негде было набраться за n-время, то селяви, нужно было искать контору где ценится качество кода, это кстати тоже показатель
— конечно сложно, но это показывает уровень. На рабочем месте тоже нужно будет сталкиваться с незнакомым, сложным и не очевидным.
Ну, не совсем так, ваше замечание больше похоже на «синьор синьору рознь», всегда есть базовые вещи которые объединяют, условно, Senoir Web Developer и Senior Mobile Developer так же как и директоров деревенского магазина и в Газпроме. Остальное, так сказать — специфика предметной области.
Вот сразу видно что вы человек — теоретик, по своей собственной градации (: А вот если бы проводили собеседования и были, так сказать, практиком, то сначала бы расспрашивали про прошлые проекты и уже из них просили бы привести примеры. Ну и конечно, в особых случаях, ничего не мешает придумать свою собственную задачу и спросить как бы ее решили.
Если компании не важно умение писать код, то я бы подумал об том — стоит ли вообще тратить на нее время. В ней, скорее всего, ничему и не у кого будет учиться, а просто заработать денег можно и в другом месте.
Понять очень просто — нужно задавать правильные вопросы на собеседовании. Конечно тут в большей мере играет квалификация собеседующего. Но, например, я когда спрашиваю про принципы SOLID и человек отвечает не задумываясь — я прошу привести несколько примеров из жизни. Кстати, стаж != опыт
Вместо этой защиты, как мне кажется, больший результат принесли бы другие действия, например: Показ сообщения что вы типа пират и это не хорошо, купите игру со скидкой например или задонатьте для отключения этого сообщения ну или что-то в этом роде. В игру играть, я бы на вашем месте разрешил, даже в пиратскую.
Koin создан для простоты, так что не нужно все усложнять. Вот несколько лайф-хаков:
Хоткеем из koin-модуля можно посмотреть на конструктор (BasketPresenter) что-бы понять что нужно
Хоткеем посмотреть где вызываются конструкторы для параметров BasketPresenter, если нет в koin-модуле - значит будет падать
При написании/рефакторинге зависимостей не писать get() для того чего еще нет. Тогда будет падать не в рантайме, а будут ошибки компиляции или если немного перефразировать: при написании нового кода koin-модуль писать в последнюю очередь, при рефакторинге - в первую
— конечно сложно, но это показывает уровень. На рабочем месте тоже нужно будет сталкиваться с незнакомым, сложным и не очевидным.
С остальным примерно так и происходит (:
Если компании не важно умение писать код, то я бы подумал об том — стоит ли вообще тратить на нее время. В ней, скорее всего, ничему и не у кого будет учиться, а просто заработать денег можно и в другом месте.