Отличная статья, спасибо. Для себя в своем приложении (правда, там «тюнер» человеческого голоса) недавно отказался от FFT в пользу автокорреляции. Алгоритм, конечно, значительно медленнее FFT, но для небольшого окошка PCM, покрывающего диапазон человеческого голоса, на C++ занимает 1-3 ms на далеко не самом последнем девайсе, что в любом случае быстрее записи следующего окна.
С ноября 2012 получаю вывод в долларах на долларовый счет в банке напрямую с Google Wallet, и до сих пор никаких проблем не возникало. Даже с налоговой при подаче декларации.
Обожаю этот аргумент… «сильно понижает читабельность кода». Его обычно вставляют как какой-то универсальный ответ-клише, когда больше нечего сказать. Можете объяснить, что именно снижает читабельность? Сами вьюхи? Их использование? Их декларация в sqlannotation? Потому что, например, я нахожу views очень удобной вещью, которая избавляет меня от необходимости писать громоздкие конструкции в провайдере для совершения join'ов, ремаппинга проекции и прочих радостей.
О, какая-то лапочка поставила минусы, не утрудившись написать, почему, и с чем не согласна :) Впрочем, обычное поведение тех, кому нечего сказать на этом сайте.
Все верно, у меня обычно он сериализуется не святым духом DOM, а святым духом SAX. К тому же я вообще против объектов в адаптере, я люблю курсор. Но, бывает, мне приходится складывать десяток другой тысяч записей, пришедших в виде json с сервера в базу за умеренное время и при умеренном расходе памяти.
Я вовсе не огорчен, ведь знаю, что это не такой же обжект, как любой другой. Вы действительно думаете, что JSONObject сравним с POJO? Это «обжект», сожержащий внутри себя структуру на основе HashMap, которые имеют очень высокий memory overhead. Да и о DOM сериализации хоть сколько-нибудь внушительного json'a (которую подразумевает наличие JSONObject) я уж промолчу.
Каких-то прямых сравнений, замеров производительности и т. п. не проводил, но лично отдаю предпочтение пикассо.
Пикассо действительно имеет хороший апи. Он написан и поддерживается очень крутыми чуваками из Square, сильно оптимизирован, из коробки поддерживает загрузку, трасформации, кеширование, поддержку recycle в списках, интегрируется с OkHttp от того же Square и гарантированно будет развиваться и поддерживаться. В общем, Square тут, как обычно, довольно минималистичны, в то время, как UIL более развесист. Но если вам вся эта кастомизация не нужна, если не нужно делать какой-нибудь FuzzyKeyMemoryCache, я бы отдал предпочтение пикассо.
Не хочется Вас огорчать, но если записей будет сильно больше 100-200, вы рискуете вылетать с OOM на более старых девайсах даже не по причине картинок, а по-причине List содержащего JSONObject.
В качестве источника инфо пользовался официальной документацией Gradle, в частности, по созданию плагинов, http://www.gradle.org/docs/current/userguide/custom_plugins.html, а также скачал и поизучал исходные коды. Они доступны на этом же сайте, и там есть много готовых плагинов. Я в частности смотрел на Findbugs плагин :)
Действительно печально то, что вопрос упаковки .so в apk впервые поднялся в апреле, и Ксавье Дюкрое обещал в скором времени добавить поддержку, но с тех пор так ничего и не изменилось…
Стоит, конечно, если хотите максимально оптимизировать. Я, честно говоря, не могу сказать, насколько это что-то улучшит, т. к. Андроид, скорее всего, тоже не дурак, и не будет рисовать что-то за границами экрана, но все же. Но, это немного усложнит задачу, т. к. вам нужно будет не просто менять размер содержимого панели, а отрезать часть. В принципе, можно ее разделить на две части — «заголовок» — то, что будет торчать и остальной контент, тогда будет проще.
К сказанному выше я бы хотел добавить, что, работая напрямую с Thread, следует иметь ввиду, что по-умолчанию новый поток создается с таким же приоритетом, что и UI-поток. И, если вы наплодите их штук 10, делающих более-менее серьёзную работу, об «отзывчивости» можете забыть. Я обычно в таких случаях руками понижаю приоритет до Process.THREAD_PRIORITY_BACKGROUND.
До недавнего времени хорошей практикой работы с БД было использование уже рассмотренных Thread и AsyncTask, но в Android 3.0 были добавлены такие классы как Loader и LoaderManager
Thread? AsyncTask? Правда? Ну если уж говорить о хороших практиках до Honeycomb, я бы упомянул в первую очередь как способ работы с БД, класс AsyncQueryHandler
Пикассо действительно имеет хороший апи. Он написан и поддерживается очень крутыми чуваками из Square, сильно оптимизирован, из коробки поддерживает загрузку, трасформации, кеширование, поддержку recycle в списках, интегрируется с OkHttp от того же Square и гарантированно будет развиваться и поддерживаться. В общем, Square тут, как обычно, довольно минималистичны, в то время, как UIL более развесист. Но если вам вся эта кастомизация не нужна, если не нужно делать какой-нибудь FuzzyKeyMemoryCache, я бы отдал предпочтение пикассо.
Thread? AsyncTask? Правда? Ну если уж говорить о хороших практиках до Honeycomb, я бы упомянул в первую очередь как способ работы с БД, класс AsyncQueryHandler