Основная проблема может быть достижение этого лимита и заливки такой сборки в google play, после чего скорей всего без общения с саппортом гугла будет проблематично её оттуда удалить.
versionCode и versionName можно расположить в gradle.properties и через аргументы запуска тасок у gradle прокидывать ваше инкремент число из ci например так ./gradlew app:assembleRelease -PversionCode=123, так можно без коммитов решить этот момент
про необходимость делать разными коды или одинаковыми конечно зависит от проекта, где то на это числа завязывают версию базы данных или делают чистку кеша между обновлениями, для тестирования таких кейсов было бы не плохо его разным делать
Почитайте про лимит в versionCode https://developer.android.com/studio/publish/versioning#appversioning чтобы избежать проблем с выкладкой в будущем, там всего лишь integer, т.е. Version код никогда не надо пытаться красиво визуализировать, а лучше сделать монотонно возрастающим при каждой сборке
Была задача искать локально на android девайсе в адресной книге одинаковые фото контактов или проверять идентичность с предыдущей(а android всегда конвертирует картинки и не оставляет исходную), как очень простое решение использовался phash от картинок, но у такого подхода были свои минусы точности сравнения, так как задается порог при котором они считаются одинаковыми даже после различных трансформаций, интересно как такую задачу можно было решать на слабом железе иначе?
это один из легальных способов кмк избавиться от открытия двух и более activity/fragment/view/dialog в android и очень надежный,
обычно все view находятся внутри чего то что имеет жц, и если клик только про переход в любой другой из activity/fragment/view/dialog, то на текущем месте вызова стейт lifecycle поменяется на paused/stopped и не даст продублировать клик, ваш вариант больше про что то внутри текущего экрана(добавить в корзину товар и тд), тут да велосипеды везде с delay логикой будут.
Основная проблема может быть достижение этого лимита и заливки такой сборки в google play, после чего скорей всего без общения с саппортом гугла будет проблематично её оттуда удалить.
versionCode и versionName можно расположить в gradle.properties и через аргументы запуска тасок у gradle прокидывать ваше инкремент число из ci например так ./gradlew app:assembleRelease -PversionCode=123, так можно без коммитов решить этот момент
про необходимость делать разными коды или одинаковыми конечно зависит от проекта, где то на это числа завязывают версию базы данных или делают чистку кеша между обновлениями, для тестирования таких кейсов было бы не плохо его разным делать
Почитайте про лимит в versionCode https://developer.android.com/studio/publish/versioning#appversioning чтобы избежать проблем с выкладкой в будущем, там всего лишь integer, т.е. Version код никогда не надо пытаться красиво визуализировать, а лучше сделать монотонно возрастающим при каждой сборке
Была задача искать локально на android девайсе в адресной книге одинаковые фото контактов или проверять идентичность с предыдущей(а android всегда конвертирует картинки и не оставляет исходную), как очень простое решение использовался phash от картинок, но у такого подхода были свои минусы точности сравнения, так как задается порог при котором они считаются одинаковыми даже после различных трансформаций, интересно как такую задачу можно было решать на слабом железе иначе?
обычно все view находятся внутри чего то что имеет жц, и если клик только про переход в любой другой из activity/fragment/view/dialog, то на текущем месте вызова стейт lifecycle поменяется на paused/stopped и не даст продублировать клик, ваш вариант больше про что то внутри текущего экрана(добавить в корзину товар и тд), тут да велосипеды везде с delay логикой будут.
или kotlin