Реальных ошибок было найдено 16 штук, что составляет около 8% от всех предупреждений. Но при этом еще было выдано 103 штуки обоснованных предупреждений, что составляет около 54% от всех предупреждений.
То есть полезного было 64%, а очень полезного — 8%. Весьма прилично, на мой взгляд.
Ваши замечания справедливы для случая произвольных значений в массиве freq. На практике, алгоритм работает с массивом не-отрицательных значений. Каждый элемент массива не больше 256.
Есть итересное обсуждение Generate the longest error message in C++ из которого можно почерпнуть много рецептов на тему «как прострелить себе что-нибудь побольнее».
Я смотрел на этот проект, но он тоже хитрит: он рисует все сразу в битмап.
А в тестовом проекте есть примеры для разных вариантов использования кроме варианта со списком. К сожалению, списки могут быть очень длинными (в моем проекте и вообще) и нарисовать их целиком сразу не получится.
В моем текущем проекте, к сожалению, требуется показывать полупрозрачную панель поверх списка (часть списка под панелью должна выглядеть размытой).
Пользуюсь RenderScript для размытия, получается достаточно быстро, но все равно весь UI заметно подтормаживает. Пока отложил решение этой проблемы (подтормаживание UI) на потом.
Может быть у вас есть идея, как поступать в случае вроде моего? Я понимаю, что лучше всего отговорить заказчика :-), но может есть какие-то другие идеи (судя по всему, вы сталкивались с подобной ситуацией)?
Среди моих знакомых такой прием тоже успешно применяется. Сам прием у нас никак не называется, а вот получаемый эффект получил имя «эффект присутствия».
но это решение не более чем хак (его можно сформулировать как «а давайте просто всем верить!»). про решение автор написал следующее:
Note: Do not implement this in production code you are ever going to use on a network you do not entirely trust. Especially anything going over the public internet.
В общем, после мучений я просто выпилил Android Async Http и больше, скорее всего, не вернусь к нему.
Реальных ошибок было найдено 16 штук, что составляет около 8% от всех предупреждений. Но при этом еще было выдано 103 штуки обоснованных предупреждений, что составляет около 54% от всех предупреждений.
То есть полезного было 64%, а очень полезного — 8%. Весьма прилично, на мой взгляд.
А еще ошибки в коде с шаблонами очень замечательные. Длинные.
Утверждают, что для следующего кода компилятор выдаст ошибок на примерно 16 килобайт.
А в тестовом проекте есть примеры для разных вариантов использования кроме варианта со списком. К сожалению, списки могут быть очень длинными (в моем проекте и вообще) и нарисовать их целиком сразу не получится.
Пользуюсь RenderScript для размытия, получается достаточно быстро, но все равно весь UI заметно подтормаживает. Пока отложил решение этой проблемы (подтормаживание UI) на потом.
Может быть у вас есть идея, как поступать в случае вроде моего? Я понимаю, что лучше всего отговорить заказчика :-), но может есть какие-то другие идеи (судя по всему, вы сталкивались с подобной ситуацией)?
HTTPS not working
Есть решение:
Self-signed certificate and loopj for Android
но это решение не более чем хак (его можно сформулировать как «а давайте просто всем верить!»). про решение автор написал следующее:
Note: Do not implement this in production code you are ever going to use on a network you do not entirely trust. Especially anything going over the public internet.
В общем, после мучений я просто выпилил Android Async Http и больше, скорее всего, не вернусь к нему.
> There is a probability of logical error presence.
Такие фразы даже у меня (без особого образования в ин. языках) вызывают неприятные чувства.
А вы чего спросить-то хотели?