Knasys Dev. Блог.

Написал приложение, которое в Foreground режиме периодически пингует сервер и забирает с него некую информацию. Проблема в том, что через некоторое время приложение перестаёт выходить на связь. По коду вроде проблем нет, и я начал капать в сторону того, что сам Android убивает фоновые процессы. Интересно, что в настройках приложения я отключил всякую оптимизацию, разрешил работу в фоне, но ему оказалось этого недостаточно. Для начала рекомендую подключить устройство к ПК, и снять с него логи. Для этого нужно активировать режим…

Читать далее Читать далее

Среди прочих проблем, которые являются причиной появления данной ошибки — есть проблемы с gpu. Для того, чтобы получить более детальное описание причины Вашей ошибки, стоит посмотреть логи здесь: C:\Users\{userName}\AppData\Local\Google\AndroidStudio2024.2\log\idea.log По ошибкам отсюда можно попытаться найти решение в интернете. Но в моём случае, там не было зацепок, и я нашёл логи при прямом запуске эмулятора из командной строки. Вот пара команд для отображения списка виртуальных устройств и запуска конкретного устройства: {Your Android Sdk Directory}\emulator\emulator -list-avds {Your Android Sdk Directory}\emulator\emulator @avdName В…

Читать далее Читать далее

Проблема — клиент не восстанавливает подключение к серверу ActiveMQ после обрыва соединения. Здесь зависит от режима соединения. При обычном (не кластерном) соединении достаточно установить параметр reconnectAttempts=-1. Это заставит клиента бесконечно пытаться подключиться к узлу, с которым изначально было установлено соединение. По-умолчанию параметр установлен в значение 0, что запрещает попытки переподключения, также можно установить конкретное число попыток, например reconnectAttempts=5. В итоге соединение должно выглядеть примерно следующим образом: quarkus.artemis.url=tcp://127.0.0.1:61616?clientFailureCheckPeriod=5000&retryInterval=1000&reconnectAttempts=-1&callTimeout=3000 При кластерном подключении, значение параметра reconnectAttempts=-1 сыграет с Вами злую шутку, т.к. при…

Читать далее Читать далее

Столкнулся с некоторыми проблемами: Ошибки типа Discovered unresolved type during parsing… и Discovered unresolved method during parsing… Имеют свойство появляться в случайном порядке, если в приложении существует несколько мест вызывающих данную ошибку. Сначала пытался лечить путем добавления аргумента сборки quarkus.native.additional-build-args=—initialize-at-run-time….. но это оказалось бесполезно, т.к. при сборке, грааль сканирует весь код и находит места вызовов несуществующих классов/методов, и если найдёт, то прекращает сборку и вываливает ошибку. На эту тему есть небольшое замечание тут. Как скипнуть эту проблему или игнорировать такие…

Читать далее Читать далее

Выборка записей с максимальной датой в разрезе значений определённого поля На SQL выражение выглядит так (записи с максимальным create_timestamp у каждого sender’а): Но т.к. criteria api поддерживает подзапросы полько в секции where, то можно реализовать только такой запрос (будет делать то же самое): Если реализовать интерфейс Specification, то он будет выглядеть так: При этом, это поля из модели, сгенерированные maven-плагином: Выборка записей с максимальной датой На SQL выражение выглядит так (записи с максимальным create_timestamp): Если реализовать интерфейс Specification, то он…

Читать далее Читать далее