Как название папки в коде проекта может повлиять на ссылку в магазине приложений?

На проекте “Я вас видел” столкнулись с интересной задачей, с которой раньше не сталкивались.
Опубликовали приложение в ru-store, отправили заказчику ссылку - https://www.rustore.ru/catalog/app/yushkoff.isawyoumobile.android

Заказчику не понравилось “yushkoff” в ссылке - это название ИП, с которым мы работаем. Попросил убрать.

Как вообще формируется эта ссылка?
yushkoff.isawyoumobile.android - это package name, который создается в самом начале разработки при создании проекта в среде для программирования.
Этот package name в дальнейшем в разных сторах будет играть роль application id и должен быть уникальным. Как правило, это что-то такое com.companyname.applicationname

Поэтому, для разработчика companyname = название ИП.

Но теперь, если заказчик захочет поделиться ссылкой на свое приложение в ру-стор, то он всегда будет видеть в адресе “yushkoff”, а это ему не нравится.

Выяснили, что в Google Play этот package name тоже будет присутствовать в ссылке на приложение.

А вот в аппсторе package name не будет отображаться.

Получается, что исправлять надо только для Андроид приложения.

Как это исправить?
Изменение package name (application ID) в Android-части KMP-проекта требует осторожности, но это выполнимо.
Советы:
1. Изменить package name можно через рефакторинг в Android Studio: используя встроенный инструмент (Refactor → Rename для пакета), но нужно проверять результаты
2. Потребуется тестирование: особенно функциональности, связанной с:
- Push-уведомлениями
- Навигацией (deep links)
- Работой с хранилищем (БД, SharedPreferences)
3. Сделать версионирование: изменить versionCode в build.gradle, чтобы избежать конфликтов с предыдущими сборками.

Итог: Процесс требует внимательности (особенно в KMP из-за связки платформ), но технически сложным не является. Главное — последовательно обновить все места, где явно указан пакет, и проверить интеграции.

Выводы на будущее: избегать фамилий в именовании пакетов при создании проекта. И даже, возможно, согласовывать с заказчиком, package name.

Приз за лучшую публикацию июня 2025 года по версии Сообщества "Управление агентством" получает подкаст "Как вырасти с нуля до миллиарда, а потом ещё раз"

https://tttttt.me/agencymanagement/3294

Публикация признана лучше по итогам вашего голосования

Авторы — команда Софториум, занимающаяся хард-разработкой сложного ПО. Поздравляем коллег!

Подкаст записан иронично и интересно. Хорошо подойдет и для того, чтобы получить новую информацию, и чтобы приятно и с пользой провести время

Почитать о премии нашего Сообщества можно по ссылке: https://tttttt.me/agencymanagement/3176

Спасибо за ваше бесценное внимание, интересные публикации и ваши голоса! Продолжаем дальше!

#лучшеезамесяц

Мерч Софториум: +100 к крутости!

На днях Влад Савин резко прокачал брутальность.

Очень трогательно, что взял с собой наш мерч — он и греет, и помогает в экстремальных условиях!

Проверено Владом:
✔️ +100 к харизме
✔️ +100 к регенерации

Подходите, к нам на UDW поделимся)

Про то, как мы транскрибируем текст телефонного разговора

Я - Саша. ПМ Софториум. Сегодня про одну интересную задачу, которую недавно завершили.

Проект ИС ЕГДС служит управлению шлагбаумами и клиентами, заказывающими эти шлагбаумы. Сюда же относятся ворота, которые необходимо открывать по запросу. В ИС и шлагбаумы, и ворота называются одним словом - барьер. Дальше по тексту так и будем их называть.

В целом, по проекту мы занимались в основном самой ИС:
- правили автоматическое (раз в месяц) формирование актов по договорам, оптимизировали его выполнение с 8 до 2ч,
- правили баги с автоплатежами по подпискам у клиентов,
- добавляли возможность возврата платежей,
- добавляли отключение барьера при приостановке услуг,
- добавляли функционал тестирования открытия барьеров для тех. специалистов
и еще ряд фиксов и доработок.

Но недавно заказчик пришел с интересной задачей: хотим обращения клиентов по телефону, когда с ними общается автоответчик и просит нажать нужную цифру в ответ, перевести на автоматическое распознавание фраз, чтобы клиентам не нужно было нажимать кнопки.

За телефонные звонки у них отвечает Астериск. Чуть поисследовали, поняли что можно реализовать в такой последовательности:

Asterisk → AGI (Asterisk Gateway Interface)-скрипт → Оффлайн-распознавание через Vosk → Обработка результата

Решили провести такой тест: протестировать запись и распознавание ответа пользователя из потока Asterisk. В результате необходимо вернуть флаг совпадения произнесенной фразы с текстом "открыть ворота"

Тест прошел успешно, но с одним но: скорость распознавания текста до возвращения ответа была 6 сек. Для распознавания использовалась библиотека Vosk, осуществлялось на рабочей машине разработчика.

Встал вопрос - как ускорить, чтобы на это уходило не более 1 сек? И как обеспечить сохранение такой скорости при одновременных запросах в 50 потоков?

Следующий тест уже был на сервере с GPU
Нужно было:
1. Доработать скрипт на приемку параметров, нарезку аудио и отправку в виспер
2. Настроить на сервере заказчика Whisper (он, как нам сказал сотрудник заказчика, имевший опыт с ним, работает быстрее Vosk-а) и создать REST API для транскрибации файлов.
3. Сделать нагрузочный тест на передачу 50 потоков аудио по 10 сек в Whisper

Результаты тестирования - в картинках

Скорость все еще не устраивала. Сделали 4 обработчика.
Вот такие получили результаты:

Как мы поняли результаты:
50% запросов завершатся за время <= 8 секунд
45% запросов завершатся за время > 8 секунд и <= 11 секунд
5% запросов завершатся за >11 секунд и < 12 секунд

Время каждого запроса 0-11 секунд, все зависит от количества одновременных запросов.
При ручном запуске одного запроса он выполняется за 500-700мс

Далее предстоит обкатать скрипт на реальных данных из Астериск.

Выводы: распознавание голоса в live-режиме телефонного разговора требует быстрой обработки и, соответственно, больших ресурсов. CPU здесь уже не подходит, нужны GPU.

Разработка методики РР.

Александр Туник пригласил меня в экспертную группу по созданию методики нового Рейтинга Рунета для сегмента разработки десктопного и серверного ПО.

Вместе с Игорем Мазайкиным и другими экспертами нам предстоит за 4 недели:
• Систематизировать подходы к разработке и интеграции ПО как услуги
• Определить типологию компаний-подрядчиков
• Выделить ключевые критерии выбора исполнителей
• Сформировать методику оценки для рейтинга 2026 года

Работа группы поможет структурировать рынок и даст заказчикам понятные ориентиры при выборе подрядчиков.

Старт обсуждений на этой неделе. Благодарен Александру за доверие и возможность внести вклад в развитие отрасли.

Главный инсайд Сибирского диджитал тура - Андрей Терехов почти сибиряк!