Попробовал трюк управления зависимостей через buildSrc, но с использованием Kotlin (ради string template). В итоге навигация и авто дополнение работают, но подсветка значения — нет. Вместо значения получаю: public final val playServicesGcm: String defined in com.myapp.gradle.Libs
В случае с Java корректно показывает значение. Жаль :(
По поводу этого исследования о сравнении TDD и TDL отлично написал Robert C. Martin. Вот несколько выдержек, но советую прочитать.
...all the participants were trained in TDD. And then some of them were asked to do TLD in small chunks...In their effort to reduce the number of variables they inadvertently eliminated them all. They forced the participants doing TLD to use the TDD process of short cycles, and that forced the participants to drive the production code by thinking about tests first
И отличный вывод
What did it show? I think it showed that you can't interpret the conclusions of a study without reading the study.
Еще раз рекомендую перейти по ссылке и прочитать оригинал.
Интересует Ваш подход к устранению замечаний lint. С уровнем error — понятно (обязательно нужно устранить). А как поступаете с уровнем warning? Допускается ли их наличие? Если да, то в какой момент (при каком объеме) от них избавляетесь?
Настройка, как я понял, уже есть (возможно, еще не до конца работает). Пользователь на уровне каждого приложения может выбрать будут ли на это приложение влиять энергосберегающие режимы или нет.
The Android M Settings app has a place where users can indicate that they want to “ignore optimizations” for certain apps
А вот как работает «doze mode»
The device will briefly exit “Doze mode” for about five minutes after an hour passes, then return to “Doze mode”. You get similar windows after another two hours, then after another four hours, then after another six hours, then I ran out of time for testing.
Т.е. у приложения будут моменты, когда можно будет связаться с внешним миром. Хотя желающих, воспользоваться каналом в этот момент будет много. Источник.
Считаю, что getParentFragment() хорош если у нас один вызывающий фрагмент и один вызываемый фрагмент (отношение один к одному). Если же у нас несколько вызываемых фрагментов (отношение один ко многим), то необходимо иметь возможность различить их с помощью getTargetRequestCode(), который устанавливается через setTargetFragment.
А бывают ли реальные потребности отправлять события прямо во Activity?
К примеру, если UI реализован в Activity без использования Fragment.
Может тогда и вызывать DialogFragment в самом Activity и имплементировать ему DialogFragment абстрактные методы?
На сколько я понимаю, речь об анонимном классе. Я бы такой подход не использовал т.к я вижу всего один сомнительный плюс и два существенных минуса.
Сомнительный плюс: чуть меньше кода (не будет создания констант REQUEST_, не будет switch и не надо использовать intent).
Минусы:
Анонимный класс хранит ссылку на внешний класс. Как результат, усложняется задача по обработке пересоздания фрагментов т.к. помимо сохранения/восстановления собственных данных нам нужно будет еще и эту ссылку воостанавливать. Решаемо конечно, но уже усложнение и дополнительная возможность ошибиться.
Весь код будет в вызывающих activity/fragment, а значит повторно использовать DialogFragment уже нельзя.
public final val playServicesGcm: String defined in com.myapp.gradle.LibsВ случае с Java корректно показывает значение. Жаль :(
И отличный вывод
Еще раз рекомендую перейти по ссылке и прочитать оригинал.
Источник.
На сколько я понимаю, речь об анонимном классе. Я бы такой подход не использовал т.к я вижу всего один сомнительный плюс и два существенных минуса.
Сомнительный плюс: чуть меньше кода (не будет создания констант REQUEST_, не будет switch и не надо использовать intent).
Минусы: