Для создания Dynamic link надо сперва завести ее в консоли Firebase, чтобы получить домен. Там можно заморочиться и использовать свой или дефолтный с постфиксом «page.link». После этого есть много вариантов, как собрать ссылку. Например, можно сделать ее руками
Про то, что когда-то давно для сборки Maven использовали Ant. Начиная с 3ей мажорной версии они перешли на сборку себя своим же предыдущим стабильным релизом
Согласен, но разница в два раза между 20 минут и 10 становится более ощутимой.
На семпле AndroidStudio buck собирает чистый билд где-то в 1.5 раза шустрее Gradle.
Думаю, тут каждый сам должен эту грань провести и исследовать этот вопрос в контексте решаемой проблемы.
В целом, ускорение выполнения автотестов — отдельная задача, достойная отдельной статьи.
Скорость сборки есть смысл ускорять, потому что начиная с некоторой величины она прямо влияет на скорость разработки (одно дело отлаживать проект, у которого инкрементальная сборка занимает 30 секунд, другое, когда 3 минуты). Да и на CI как правило не один flavour собирается
За такие, в теории, не должен, потому что фактически скрипт выполняет jvm, и байткод приложения не модифицируется, в отличие от подгрузки классов через ClassLoader.
Т.е. приложение с таким встроенным скриптовым движком, как бы уже содержит в себе все возможные варианты использования скрипта
Могли бы хотя бы курс порекомендовать по соответствующей предметной области, а то «Аналитик данных Python» выглядит супер несуразно в статье на тему Android разработки
Много ли кейсов где подобные оптимизации (обязательное приведение Integer -> int, геморрой с кастомными коллекциями и тд) могут реально дать ощутимый бус производительности?
На тему изменяемых (mutable) объектов было бы круто упомянуть про то, что работа с неизменяемыми (immutable) объектами будет оптимизирована на уровне языка
Вообще, люто не хватает сравнения перформанса, HashMap и Int2IntCounterMap, на каких-то +- реальных примерах, потому что сейчас проблема кажется несколько надуманной
Думаю, что не всем на 100% нравятся корутины и не все спешат на них перебираться. Особенно учитывая, что стабильный релиз пока только в анонсе. Поэтому, мне кажется, что использование альтернативных решений вполне оправдано
Можно еще про саппортные библиотеки сказать. Без них нынче тоже тяжко.
Ну и Lottie, на мой взгляд, заслуживает упоминания (многим дизайнерам хочется клевые анимашки)
Должен признать, что в у меня есть некоторые сомнения применительно к плагину для сборки Android проектов.
На семпле AndroidStudio buck собирает чистый билд где-то в 1.5 раза шустрее Gradle.
Думаю, тут каждый сам должен эту грань провести и исследовать этот вопрос в контексте решаемой проблемы.
Скорость сборки есть смысл ускорять, потому что начиная с некоторой величины она прямо влияет на скорость разработки (одно дело отлаживать проект, у которого инкрементальная сборка занимает 30 секунд, другое, когда 3 минуты). Да и на CI как правило не один flavour собирается
Т.е. приложение с таким встроенным скриптовым движком, как бы уже содержит в себе все возможные варианты использования скрипта
На тему изменяемых (mutable) объектов было бы круто упомянуть про то, что работа с неизменяемыми (immutable) объектами будет оптимизирована на уровне языка
Вообще, люто не хватает сравнения перформанса, HashMap и Int2IntCounterMap, на каких-то +- реальных примерах, потому что сейчас проблема кажется несколько надуманной
Однако немного не хватило информации про скроллы, транзишены, паддинги и тому подобные извращения
Ну и Lottie, на мой взгляд, заслуживает упоминания (многим дизайнерам хочется клевые анимашки)